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

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 poll-based detection. After a short delay or > > when resetting storm

Re: [Intel-gfx] [PATCH] edp-DRRS test

On Friday 14 July 2017 02:21 AM, Paulo Zanoni wrote: Em Qua, 2017-06-21 às 13:40 +0530, Lohith BS escreveu: Idleness DRRS: By default the DRRS state will be at DRRS_HIGH_RR. When a Display content is Idle for more than 1Sec Idleness will be declared and DRRS_LOW_RR will

[Intel-gfx] [PATCH i-g-t] lib/igt_core: Handle glib errors correctly to avoid stderr spew

This adds the required error clean/free calls after calling configuration parsing functions. In addition to properly handling memory, this avoids glib spewing out error messages on stderr, which breaks the whole CI. Signed-off-by: Paul Kocialkowski ---

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

On Wed, Jul 19, 2017 at 04:01:03PM +0200, Maarten Lankhorst wrote: > Op 19-07-17 om 14:55 schreef Daniel Vetter: > > The core already does this in setup_commit(). With this we can also > > remove the unpin_work_count since it's the last user. > > > > Cc: Maarten Lankhorst

Re: [Intel-gfx] [RFC 12/14] drm/i915: Interface for controling engine stats collection

On 19/07/2017 12:04, Chris Wilson wrote: [snip] Long term though having a global static key is going to be a nasty wart. Joonas will definitely ask the question how much will it cost us to use an engine->bool and what we can do to minimise that cost. Why you think it is nasty? Sounds pretty

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

On Thu, 20 Jul 2017, 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 least an initial YUV420 modeset > (added in a

Re: [Intel-gfx] [PATCH] edp-DRRS test

On Thu, Jul 20, 2017 at 8:27 AM, Ramalingam C wrote: > Agreed Paulo. As per daniel's suggestion we tried to reuse the > infrastructure > provided by frontbuffer tracking igt. But we couldn't as the test case > requirements > were not matching. DRRS _is_ using the

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

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 patch adds the remaining bits. > > Fixes: a21960339c8c ("drm/i915:

[Intel-gfx] [PATCH] drm/i915: Keep a small stash of preallocated WC pages

We use WC pages for coherent writes into the ppGTT on !llc architectuures. However, to create a WC page requires a stop_machine(), i.e. is very slow. To compensate we currently keep a per-vm cache of recently freed pages, but we still see the slow startup of new contexts. We can amoritize that

Re: [Intel-gfx] [RFC 01/14] RFC drm/i915: Expose a PMU interface for perf queries

On 19/07/2017 10:53, Kamble, Sagar A wrote: Can we reuse calc_residency defined in i915_sysfs.c Looks like it, that is intel_pm.c/intel_rc6_residency_us. I will incorporate the change in the series or the patch. Thanks for spotting this! Regards, Tvrtko On 7/18/2017 8:06 PM, Tvrtko

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

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 leads to a black screen after suspend/resume. References:

[Intel-gfx] [PATCH 0/2] drm/i915: revert DPCD backlight and DBC enabling by default

The two commits being reverted regress machines, a production ThinkPad, and BXT-P in CI, and there hasn't been adequate response to follow-up or fix the issues. The regressions were reported 3½ weeks ago. The reverts are long overdue already. Back to the drawing board. BR, Jani. Cc: Jenny TC

[Intel-gfx] [PATCH 1/2] Revert "drm/i915: Add option to support dynamic backlight via DPCD"

This reverts commit ae25eceab616d16a07bcaa434b84463d58a3bdc3. 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 leads to a black screen after suspend/resume. References:

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

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? >> On some panels, this causes backlight issues on

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Fix scaler init during CRTC HW state readout

== Series Details == Series: series starting with [1/2] drm/i915: Fix scaler init during CRTC HW state readout URL : https://patchwork.freedesktop.org/series/27607/ State : success == Summary == Series 27607v1 Series without cover letter

Re: [Intel-gfx] [PATCH i-g-t] lib/igt_core: Handle glib errors correctly to avoid stderr spew

On Thu, 2017-07-20 at 10:45 +0300, Paul Kocialkowski wrote: > This adds the required error clean/free calls after calling > configuration parsing functions. In addition to properly handling > memory, > this avoids glib spewing out error messages on stderr, which breaks > the > whole CI. Fixes:

[Intel-gfx] [PATCH i-g-t v2] lib/igt_core: Handle glib errors correctly to avoid stderr spew

This adds the required error clean/free calls after calling configuration parsing functions. In addition to properly handling memory, this avoids glib spewing out error messages on stderr, which breaks the whole CI with this message: GLib-WARNING **: GError set over the top of a previous

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

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. > > Signed-off-by: Paul Kocialkowski

Re: [Intel-gfx] [PATCH i-g-t v2] lib/igt_core: Handle glib errors correctly to avoid stderr spew

On Thu, Jul 20, 2017 at 11:07:42AM +0300, Paul Kocialkowski wrote: > This adds the required error clean/free calls after calling > configuration parsing functions. In addition to properly handling memory, > this avoids glib spewing out error messages on stderr, which breaks the > whole CI with

Re: [Intel-gfx] [RFC 00/14] i915 PMU and engine busy stats

On 19/07/2017 13:05, Chris Wilson wrote: Quoting Tvrtko Ursulin (2017-07-18 15:36:04) From: Tvrtko Ursulin Rough sketch of the idea I mentioned a few times to various people - merging the engine busyness tracking with Chris i915 PMU RFC. First patch is the actual

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

On Thu, Jul 20, 2017 at 11:58:35AM +0300, Jani Nikula wrote: > On Thu, 20 Jul 2017, 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

[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] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Use mul_u32_u32() for 32b x 32b -> 64b result

== Series Details == Series: series starting with [1/2] drm/i915: Use mul_u32_u32() for 32b x 32b -> 64b result URL : https://patchwork.freedesktop.org/series/27629/ State : success == Summary == Series 27629v1 Series without cover letter

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

[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

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

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

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

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

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

[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

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

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

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

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

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

Re: [Intel-gfx] [PATCH i-g-t] CONTRIBUTING: formalize review rules

On Wed, Jul 19, 2017 at 11:03:46AM +0300, Arkadiusz Hiler wrote: > On Tue, Jul 18, 2017 at 06:00:20PM +0200, Daniel Vetter wrote: > > There's a bunch of reasons why I think we should formalize and enforce > > our review rules for igt patches: > > > > - We have a lot of new engineers joining and

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915: Fix scaler init during CRTC HW state readout (rev2)

== Series Details == Series: series starting with [v2,1/2] drm/i915: Fix scaler init during CRTC HW state readout (rev2) URL : https://patchwork.freedesktop.org/series/27607/ State : success == Summary == Series 27607v2 Series without cover letter

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

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

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

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

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] ✗ 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

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

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 >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Fix an error handling path in 'mock_gem_device()'

== Series Details == Series: drm/i915/selftests: Fix an error handling path in 'mock_gem_device()' URL : https://patchwork.freedesktop.org/series/27604/ State : success == Summary == Series 27604v1 drm/i915/selftests: Fix an error handling path in 'mock_gem_device()'

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: revert DPCD backlight and DBC enabling by default

== Series Details == Series: drm/i915: revert DPCD backlight and DBC enabling by default URL : https://patchwork.freedesktop.org/series/27623/ State : success == Summary == Series 27623v1 drm/i915: revert DPCD backlight and DBC enabling by default

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

On Thu, Jul 20, 2017 at 12:25:30PM +0300, Imre Deak wrote: > On Thu, Jul 20, 2017 at 11:58:35AM +0300, Jani Nikula wrote: > > On Thu, 20 Jul 2017, Imre Deak wrote: > > > The scaler allocation code depends on a non-zero default value for the > > > crtc scaler_id, so make sure

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

On 20/07/17 12:39, 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 patches, in-reply-to each patch being replaced is fine. I think this is more clear, and also gives patchwork a better

[Intel-gfx] [PATCH 2/2] drm/i915/selftests: Use mul_u32_u32() for 32b x 32b -> 64b result

As realised by commit 9e3d6223d209 ("math64, timers: Fix 32bit mul_u64_u32_shr() and friends"), GCC does not always generate ideal code for performing a 32b x 32b multiply returning a 64b result (i.e. where we idiomatically use u64 result = (u64)x * (u32)x). Signed-off-by: Chris Wilson

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

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 least an initial YUV420 modeset (added in a follow-up patchset by Shashank) when booting with the screen off: after

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

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 > patches, > in-reply-to each patch being replaced is fine. I think this is more > clear, and also gives

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

On Thu, Jul 20, 2017 at 11:41:35AM +0200, Greg Kroah-Hartman wrote: > On Thu, Jul 20, 2017 at 12:25:30PM +0300, Imre Deak wrote: > > On Thu, Jul 20, 2017 at 11:58:35AM +0300, Jani Nikula wrote: > > > On Thu, 20 Jul 2017, Imre Deak wrote: > > > > The scaler allocation code

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

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

For future reference, please post new versions of the entire series as new threads. When posting new versions of just some individual patches, in-reply-to each patch being replaced is fine. I think this is more clear, and also gives patchwork a better chance to apply the right patches for testing

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: s/INTEL_INFO(dev_priv)->gen/INTEL_GEN(dev_priv) in i915_irq

On 18/07/2017 19:48, Patchwork wrote: == Series Details == Series: drm/i915: s/INTEL_INFO(dev_priv)->gen/INTEL_GEN(dev_priv) in i915_irq URL : https://patchwork.freedesktop.org/series/27510/ State : success == Summary == Series 27510v1 drm/i915:

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Fix an error handling path in 'mock_gem_device()'

On 19/07/2017 23:35, Christophe JAILLET wrote: Goto the right label in case of error, otherwise there is a leak. This has been introduced by c5cf9a9147ff. In this patch a goto has not been updated. Fixes: c5cf9a9147ff ("drm/i915: Create a kmem_cache to allocate struct i915_priolist from")

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Fix an error handling path in 'mock_gem_device()'

Quoting Tvrtko Ursulin (2017-07-20 11:09:53) > > On 19/07/2017 23:35, Christophe JAILLET wrote: > > Goto the right label in case of error, otherwise there is a leak. > > This has been introduced by c5cf9a9147ff. In this patch a goto has not been > > updated. > > > > Fixes: c5cf9a9147ff

Re: [Intel-gfx] [PATCH 7/8] drm/i915: Add NV12 as supported format for sprite plane

> -Original Message- > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > Sent: Tuesday, July 11, 2017 9:42 PM > To: Srinivas, Vidya > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH 7/8] drm/i915: Add NV12 as supported > format

Re: [Intel-gfx] [PATCH 06/15] drm/i915: Check the execlist queue for pending requests before declaring idle

Chris Wilson writes: > Including a check against the execlist queue before calling the engine > idle and passing hangcheck. > > Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala > --- >

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

> >> 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 /sys/kernel/debug/dri/0/eDP-1/i915_dpcd ... 0701: bb ff 00 00 With below change its

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Keep a small stash of preallocated WC pages

== Series Details == Series: drm/i915: Keep a small stash of preallocated WC pages URL : https://patchwork.freedesktop.org/series/27622/ State : success == Summary == Series 27622v1 drm/i915: Keep a small stash of preallocated WC pages

[Intel-gfx] [PATCH 1/2] drm/i915: Use mul_u32_u32() for 32b x 32b -> 64b result

As realised by commit 9e3d6223d209 ("math64, timers: Fix 32bit mul_u64_u32_shr() and friends"), GCC does not always generate ideal code for performing a 32b x 32b multiply returning a 64b result (i.e. where we idiomatically use u64 result = (u64)x * (u32)x). This catches a couple of instances in

[Intel-gfx] [PATCH] drm/i915: Remove assertion from raw __i915_vma_unpin()

After we detect a i915_vma pin overflow, we call __i915_vma_unpin to cleanup. However, on an overflow the pin_count bitfield will be zero, triggering an assertion, even though we the intention is to merely warn and report the error back to the user (as historically the culprit has be a leak in the

[Intel-gfx] [PATCH] drm/i915: Only mark the execobject as pinned on success

If we fail to acquire a fence (for old school fenced GPU access) then we unwind the vma reservation, including its pin. However, we were making the execobject as holding the pin before erring out, leading to a double unpin: [ 3193.991802] kernel BUG at drivers/gpu/drm/i915/i915_vma.h:287! [

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

Quoting Mika Kuoppala (2017-07-20 13:18:40) > > diff --git a/drivers/gpu/drm/i915/intel_lrc.c > > b/drivers/gpu/drm/i915/intel_lrc.c > > index 3c83f2dd6798..ad61d1998fb7 100644 > > --- a/drivers/gpu/drm/i915/intel_lrc.c > > +++ b/drivers/gpu/drm/i915/intel_lrc.c > > @@ -1327,6 +1327,31 @@ static

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

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

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

  1   2   >