Re: [Intel-gfx] [PATCH v11 07/11] drm: Add helper functions to handle aspect-ratio flag bits

On 4/23/2018 3:43 PM, Ville Syrjälä wrote: On Mon, Apr 23, 2018 at 10:55:54AM +0530, Nautiyal, Ankit K wrote: On 4/20/2018 7:42 PM, Ville Syrjälä wrote: On Fri, Apr 20, 2018 at 07:01:47PM +0530, Nautiyal, Ankit K wrote: From: Ankit Nautiyal This patch adds

Re: [Intel-gfx] [PATCH v11 07/11] drm: Add helper functions to handle aspect-ratio flag bits

On 4/23/2018 3:52 PM, Jani Nikula wrote: On Mon, 23 Apr 2018, "Nautiyal, Ankit K" wrote: On 4/20/2018 7:42 PM, Ville Syrjälä wrote: On Fri, Apr 20, 2018 at 07:01:47PM +0530, Nautiyal, Ankit K wrote: From: Ankit Nautiyal +bool

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915/dp: Check if the sink crc we read is 6 bytes.

== Series Details == Series: series starting with [1/3] drm/i915/dp: Check if the sink crc we read is 6 bytes. URL : https://patchwork.freedesktop.org/series/42154/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4082 -> Patchwork_8783 = == Summary - FAILURE == Serious

[Intel-gfx] [PATCH 1/3] drm/i915/dp: Check if the sink crc we read is 6 bytes.

We attempt to read 6 bytes, make sure we have. Signed-off-by: Dhinakaran Pandiyan --- drivers/gpu/drm/i915/intel_dp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index

[Intel-gfx] [PATCH 3/3] drm/i915/psr: Move sink-crc to intel_psr.c

With sink-crc now being relevant only for PSR static frames, move the code to intel_psr.c and rename the function. Signed-off-by: Dhinakaran Pandiyan --- drivers/gpu/drm/i915/i915_debugfs.c | 4 ++-- drivers/gpu/drm/i915/intel_dp.c | 35

[Intel-gfx] [PATCH 2/3] drm/i915/dp: Fix sink-crc reads.

Sink crc is calculated by the sink for static frames irrespective of what the driver sets in TEST_SINK_START dpcd. Since PSR is the only use case for sink crc, we don't really need the sink_crc_{start, stop} code. The second problem with the current implementation is vblank waits. Enabling vblank

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Build request info on stack before printk (rev2)

== Series Details == Series: drm/i915: Build request info on stack before printk (rev2) URL : https://patchwork.freedesktop.org/series/42150/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4082_full -> Patchwork_8781_full = == Summary - WARNING == Minor unknown changes

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Don't dump umpteen thousand requests

== Series Details == Series: drm/i915: Don't dump umpteen thousand requests URL : https://patchwork.freedesktop.org/series/42151/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4082 -> Patchwork_8782 = == Summary - FAILURE == Serious unknown changes coming with

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Build request info on stack before printk (rev2)

== Series Details == Series: drm/i915: Build request info on stack before printk (rev2) URL : https://patchwork.freedesktop.org/series/42150/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4082 -> Patchwork_8781 = == Summary - SUCCESS == No regressions found. External

Re: [Intel-gfx] [PATCH] drm/i915: Build request info on stack before printk

Quoting Chris Wilson (2018-04-24 02:08:39) > printk unhelpfully inserts a '\n' between consecutive calls, and since > our drm_printf wrapper may be emitting info a seq_file instead, > KERN_CONT is not an option. To work with any drm_printf destination, we > need to build up the output into a

[Intel-gfx] [PATCH] drm/i915: Don't dump umpteen thousand requests

If we have more than a few, possibly several thousand request in the queue, don't show the central portion, just the first few and the last being executed and/or queued. The first few should be enough to help identify a problem in execution, and most often comparing the first/last in the queue is

[Intel-gfx] [PATCH] drm/i915: Build request info on stack before printk

printk unhelpfully inserts a '\n' between consecutive calls, and since our drm_printf wrapper may be emitting info a seq_file instead, KERN_CONT is not an option. To work with any drm_printf destination, we need to build up the output into a temporary buf on the stack and then feed the complete

[Intel-gfx] [PATCH] drm/i915: Build request info on stack before printk

printk unhelpfully inserts a '\n' between consecutive calls, and since our drm_printf wrapper may be emitting info a seq_file instead, KERN_CONT is not an option. To work with any drm_printf destination, we need to build up the output into a temporary buf on the stack and then feed the complete

Re: [Intel-gfx] [PATCH v3 2/4] drm/i915/psr: Prevent PSR exit when a non-pipe related register is written

On Fri, 2018-04-20 at 15:57 -0700, Rodrigo Vivi wrote: > On Fri, Apr 20, 2018 at 03:27:56PM -0700, José Roberto de Souza > wrote: > > Any write in any display register was causing HW to exit PSR, > > masking it to allow more power savings. Writes to pipe related > > registers will still cause HW

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/6] drm/i915: Stop tracking timeline->inflight_seqnos (rev2)

== Series Details == Series: series starting with [v2,1/6] drm/i915: Stop tracking timeline->inflight_seqnos (rev2) URL : https://patchwork.freedesktop.org/series/42139/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4082 -> Patchwork_8780 = == Summary - FAILURE ==

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/6] drm/i915: Stop tracking timeline->inflight_seqnos (rev2)

== Series Details == Series: series starting with [v2,1/6] drm/i915: Stop tracking timeline->inflight_seqnos (rev2) URL : https://patchwork.freedesktop.org/series/42139/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Stop tracking timeline->inflight_seqnos

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/kbl: Add KBL GT2 sku (rev2)

== Series Details == Series: drm/i915/kbl: Add KBL GT2 sku (rev2) URL : https://patchwork.freedesktop.org/series/42144/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4081_full -> Patchwork_8779_full = == Summary - FAILURE == Serious unknown changes coming with

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/6] drm/i915: Stop tracking timeline->inflight_seqnos (rev2)

== Series Details == Series: series starting with [v2,1/6] drm/i915: Stop tracking timeline->inflight_seqnos (rev2) URL : https://patchwork.freedesktop.org/series/42139/ State : warning == Summary == $ dim checkpatch origin/drm-tip 84a91bc19416 drm/i915: Stop tracking

[Intel-gfx] [PATCH igt] test/gem_exec_schedule: Check each engine is an independent timeline

In the existing ABI, each engine operates its own timeline (fence.context) and so should execute independently of any other. If we install a blocker on all other engines, that should not affect execution on the local engine. v2: Move the requirements checks from the fixture to subtest so that the

[Intel-gfx] [PATCH] drm/i915: Split i915_gem_timeline into individual timelines

We need to move to a more flexible timeline that doesn't assume one fence context per engine, and so allow for a single timeline to be used across a combination of engines. This means that preallocating a fence context per engine is now a hindrance, and so we want to introduce the singular

Re: [Intel-gfx] [PATCH] drm/i915/kbl: Add KBL GT2 sku

On Mon, Apr 23, 2018 at 03:28:03PM -0700, matthew.s.atw...@intel.com wrote: > From: Matt Atwood > > Adding a missing GT2 sku discovered off hardware. > > Signed-off-by: Matt Atwood > Reviewed-by: Clint Taylor

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/kbl: Add KBL GT2 sku (rev2)

== Series Details == Series: drm/i915/kbl: Add KBL GT2 sku (rev2) URL : https://patchwork.freedesktop.org/series/42144/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4081 -> Patchwork_8779 = == Summary - SUCCESS == No regressions found. External URL:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/kbl: Add KBL GT2 sku

== Series Details == Series: drm/i915/kbl: Add KBL GT2 sku URL : https://patchwork.freedesktop.org/series/42144/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4081 -> Patchwork_8778 = == Summary - SUCCESS == No regressions found. External URL:

[Intel-gfx] [PATCH] drm/i915/kbl: Add KBL GT2 sku

From: Matt Atwood Adding a missing GT2 sku discovered off hardware. Signed-off-by: Matt Atwood Reviewed-by: Clint Taylor --- include/drm/i915_pciids.h | 1 + 1 file changed, 1 insertion(+) diff --git

Re: [Intel-gfx] [PATCH] drm/i915/kbl: Add KBL GT2 sku

On 04/23/2018 03:01 PM, matthew.s.atw...@intel.com wrote: From: Matt Atwood Adding a missing GT2 sku discovered off hardware. Signed-off-by: Matt Atwood --- include/drm/i915_pciids.h | 1 + 1 file changed, 1 insertion(+) diff

[Intel-gfx] [PATCH] drm/i915/kbl: Add KBL GT2 sku

From: Matt Atwood Adding a missing GT2 sku discovered off hardware. Signed-off-by: Matt Atwood --- include/drm/i915_pciids.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index

[Intel-gfx] UHD 620: How to debug a screen resolution that does not work reliably

Hi I have a secondary monitor connected via USB-C adapter to HDMI. It can manage resolutions up to 2560x1440. Most of the time, when the system is booted the resolution is detected ok, but If I suspend the machine, or replug the screen, or alternate to the text console, the resolution is

Re: [Intel-gfx] [PATCH v11 2/3] drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads

Sorry, I added a debug patch when submitting to trybot and forgot to remove that from my local branch. I will resubmit to a new series. Yunwei On 4/23/2018 12:55 PM, Rodrigo Vivi wrote: On Mon, Apr 23, 2018 at 09:12:46AM -0700, Yunwei Zhang wrote: L3Bank could be fused off in hardware for

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/6] drm/i915: Stop tracking timeline->inflight_seqnos

== Series Details == Series: series starting with [v2,1/6] drm/i915: Stop tracking timeline->inflight_seqnos URL : https://patchwork.freedesktop.org/series/42139/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4081 -> Patchwork_8777 = == Summary - FAILURE == Serious

[Intel-gfx] [PATCH igt v2] test/gem_exec_schedule: Check each engine is an independent timeline

In the existing ABI, each engine operates its own timeline (fence.context) and so should execute independently of any other. If we install a blocker on all other engines, that should not affect execution on the local engine. v2: Move the requirements checks from the fixture to subtest so that the

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/6] drm/i915: Stop tracking timeline->inflight_seqnos

== Series Details == Series: series starting with [v2,1/6] drm/i915: Stop tracking timeline->inflight_seqnos URL : https://patchwork.freedesktop.org/series/42139/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Stop tracking timeline->inflight_seqnos

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/6] drm/i915: Stop tracking timeline->inflight_seqnos

== Series Details == Series: series starting with [v2,1/6] drm/i915: Stop tracking timeline->inflight_seqnos URL : https://patchwork.freedesktop.org/series/42139/ State : warning == Summary == $ dim checkpatch origin/drm-tip 397f93096828 drm/i915: Stop tracking timeline->inflight_seqnos

Re: [Intel-gfx] [PATCH] drm/i915: Wait for vblank after register read

On Mon, Apr 23, 2018 at 01:24:39PM -0700, Dhinakaran Pandiyan wrote: > > > > On Mon, 2018-04-23 at 12:34 -0700, Rodrigo Vivi wrote: > > On Mon, Apr 23, 2018 at 12:21:39PM -0700, Dhinakaran Pandiyan wrote: > > > > > > > > > > > > On Fri, 2018-04-20 at 14:15 +0300, Mika Kahola wrote: > > > >

Re: [Intel-gfx] [PATCH] drm/i915: Wait for vblank after register read

On Mon, 2018-04-23 at 12:34 -0700, Rodrigo Vivi wrote: > On Mon, Apr 23, 2018 at 12:21:39PM -0700, Dhinakaran Pandiyan wrote: > > > > > > > > On Fri, 2018-04-20 at 14:15 +0300, Mika Kahola wrote: > > > On Fri, 2018-04-20 at 11:22 +0300, Jani Nikula wrote: > > > > On Fri, 20 Apr 2018, Mika

Re: [Intel-gfx] [PATCH v11 2/3] drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads

On Mon, Apr 23, 2018 at 09:12:46AM -0700, Yunwei Zhang wrote: > L3Bank could be fused off in hardware for debug purpose, and it > is possible that subslice is enabled while its corresponding L3Bank pairs > are disabled. In such case, if MCR packet control register(0xFDC) is > programed to point to

Re: [Intel-gfx] [PATCH] drm/i915: Wait for vblank after register read

On Mon, Apr 23, 2018 at 12:21:39PM -0700, Dhinakaran Pandiyan wrote: > > > > On Fri, 2018-04-20 at 14:15 +0300, Mika Kahola wrote: > > On Fri, 2018-04-20 at 11:22 +0300, Jani Nikula wrote: > > > On Fri, 20 Apr 2018, Mika Kahola wrote: > > > > > > > > On Thu, 2018-04-19

Re: [Intel-gfx] [PATCH] drm/i915: Wait for vblank after register read

On Fri, 2018-04-20 at 14:15 +0300, Mika Kahola wrote: > On Fri, 2018-04-20 at 11:22 +0300, Jani Nikula wrote: > > On Fri, 20 Apr 2018, Mika Kahola wrote: > > > > > > On Thu, 2018-04-19 at 17:09 +0300, Jani Nikula wrote: > > > > > > > > On Wed, 18 Apr 2018, Mika Kahola

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/6] drm/i915: Stop tracking timeline->inflight_seqnos

== Series Details == Series: series starting with [v2,1/6] drm/i915: Stop tracking timeline->inflight_seqnos URL : https://patchwork.freedesktop.org/series/42139/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4079 -> Patchwork_8776 = == Summary - FAILURE == Serious

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/6] drm/i915: Stop tracking timeline->inflight_seqnos

== Series Details == Series: series starting with [v2,1/6] drm/i915: Stop tracking timeline->inflight_seqnos URL : https://patchwork.freedesktop.org/series/42139/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Stop tracking timeline->inflight_seqnos

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/2] drm/i915: Use ktime on wait_for

== Series Details == Series: series starting with [CI,1/2] drm/i915: Use ktime on wait_for URL : https://patchwork.freedesktop.org/series/42115/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4078_full -> Patchwork_8774_full = == Summary - WARNING == Minor unknown

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/6] drm/i915: Stop tracking timeline->inflight_seqnos

== Series Details == Series: series starting with [v2,1/6] drm/i915: Stop tracking timeline->inflight_seqnos URL : https://patchwork.freedesktop.org/series/42139/ State : warning == Summary == $ dim checkpatch origin/drm-tip b1a184759165 drm/i915: Stop tracking timeline->inflight_seqnos

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Remove src adjustment in intel_check_sprite_plane.

== Series Details == Series: drm/i915: Remove src adjustment in intel_check_sprite_plane. URL : https://patchwork.freedesktop.org/series/42113/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4078_full -> Patchwork_8773_full = == Summary - WARNING == Minor unknown changes

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/hisilicon/hibmc: Using module_pci_driver.

== Series Details == Series: drm/hisilicon/hibmc: Using module_pci_driver. URL : https://patchwork.freedesktop.org/series/42103/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4078_full -> Patchwork_8771_full = == Summary - WARNING == Minor unknown changes coming with

[Intel-gfx] [PATCH v2 4/6] drm/i915: Move timeline from GTT to ring

In the future, we want to move a request between engines. To achieve this, we first realise that we have two timelines in effect here. The first runs through the GTT is required for ordering vma access, which is tracked currently by engine. The second is implied by sequential execution of commands

[Intel-gfx] [PATCH v2 2/6] drm/i915: Retire requests along rings

In the next patch, rings are the central timeline as requests may jump between engines. Therefore in the future as we retire in order along the engine timeline, we may retire out-of-order within a ring (as the ring now occurs along multiple engines), leading to much hilarity in miscomputing the

[Intel-gfx] [PATCH v2 1/6] drm/i915: Stop tracking timeline->inflight_seqnos

In commit 9b6586ae9f6b ("drm/i915: Keep a global seqno per-engine"), we moved from a global inflight counter to per-engine counters in the hope that will be easy to run concurrently in future. However, with the advent of the desire to move requests between engines, we do need a global counter to

[Intel-gfx] [PATCH v2 5/6] drm/i915: Split i915_gem_timeline into individual timelines

We need to move to a more flexible timeline that doesn't assume one fence context per engine, and so allow for a single timeline to be used across a combination of engines. This means that preallocating a fence context per engine is now a hindrance, and so we want to introduce the singular

[Intel-gfx] [PATCH v2 6/6] drm/i915: Lazily unbind vma on close

When userspace is passing around swapbuffers using DRI, we frequently have to open and close the same object in the foreign address space. This shows itself as the same object being rebound at roughly 30fps (with a second object also being rebound at 30fps), which involves us having to rewrite the

[Intel-gfx] [PATCH v2 3/6] drm/i915: Only track live rings for retiring

We don't need to track every ring for its lifetime as they are managed by the contexts/engines. What we do want to track are the live rings so that we can sporadically clean up requests if userspace falls behind. We can simply restrict the gt->rings list to being only gt->live_rings. v2:

Re: [Intel-gfx] [igt-dev] [PATCH igt] test/gem_exec_schedule: Check each engine is an independent timeline

Quoting Tvrtko Ursulin (2018-04-23 17:52:54) > > On 23/04/2018 14:43, Chris Wilson wrote: > > In the existing ABI, each engine operates its own timeline > > (fence.context) and so should execute independently of any other. If we > > install a blocker on all other engines, that should not affect

Re: [Intel-gfx] [igt-dev] [PATCH igt] test/gem_exec_schedule: Check each engine is an independent timeline

On 23/04/2018 14:43, Chris Wilson wrote: In the existing ABI, each engine operates its own timeline (fence.context) and so should execute independently of any other. If we install a blocker on all other engines, that should not affect execution on the local engine. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH v11 2/3] drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads

L3Bank could be fused off in hardware for debug purpose, and it is possible that subslice is enabled while its corresponding L3Bank pairs are disabled. In such case, if MCR packet control register(0xFDC) is programed to point to a disabled bank pair, a MMIO read into L3Bank range will return 0

[Intel-gfx] 4.17-rc2: Could not determine valid watermarks for inherited state

This warning just started appearing during boot on a machine I upgraded to 4.17-rc2. The warning seems to have been there since 2015, but it has never triggered before today. Dave [1.158500] fb: switching to inteldrmfb from EFI VGA [1.159073] Console: switching to colour dummy

Re: [Intel-gfx] [PULL] gvt-next for 4.18

Thanks! :) On 04/23/18 18:25, Jani Nikula wrote: On Mon, 23 Apr 2018, Zhi Wang wrote: Hi Jani: I picked out the patch which causes conflicts and may put it back in the next back merge from drm-intel-next to gvt-next. So there shouldn't be any conflict in this pull.

Re: [Intel-gfx] [igt-dev] [PATCH igt] test/gem_exec_schedule: Check each engine is an independent timeline

On 23/04/18 08:51, Chris Wilson wrote: Quoting Antonio Argenziano (2018-04-23 16:37:17) On 23/04/18 06:43, Chris Wilson wrote: In the existing ABI, each engine operates its own timeline (fence.context) and so should execute independently of any other. If we install a blocker on all other

Re: [Intel-gfx] [igt-dev] [PATCH igt] test/gem_exec_schedule: Check each engine is an independent timeline

Quoting Antonio Argenziano (2018-04-23 16:37:17) > > > On 23/04/18 06:43, Chris Wilson wrote: > > In the existing ABI, each engine operates its own timeline > > (fence.context) and so should execute independently of any other. If we > > install a blocker on all other engines, that should not

Re: [Intel-gfx] [igt-dev] [PATCH igt] test/gem_exec_schedule: Check each engine is an independent timeline

On 23/04/18 06:43, Chris Wilson wrote: In the existing ABI, each engine operates its own timeline (fence.context) and so should execute independently of any other. If we install a blocker on all other engines, that should not affect execution on the local engine. Signed-off-by: Chris Wilson

Re: [Intel-gfx] [CI 1/2] drm/i915: Use ktime on wait_for

On Mon, Apr 23, 2018 at 4:37 AM, Mika Kuoppala wrote: > We use jiffies to determine when wait expires. However > Imre did find out that jiffies can and will do a >1 > increments on certain situations [1]. When this happens > in a wait_for loop, we return timeout

Re: [Intel-gfx] [PATCH] drm/i915: Remove src adjustment in intel_check_sprite_plane.

On Mon, Apr 23, 2018 at 04:39:54PM +0200, Maarten Lankhorst wrote: > Op 23-04-18 om 16:30 schreef Ville Syrjälä: > > On Mon, Apr 23, 2018 at 12:49:22PM +0200, Maarten Lankhorst wrote: > >> The rounding can cause a perfectly normal 16x16 src to full-screen > >> dst to be rounded down, even without

Re: [Intel-gfx] [PATCH 06/18] drm/i915/breadcrumbs: Keep the fake irq armed across reset

Quoting Mika Kuoppala (2018-04-23 14:03:02) > Chris Wilson writes: > > @@ -148,6 +149,12 @@ static void intel_breadcrumbs_fake_irq(struct > > timer_list *t) > > if (!b->irq_armed) > > return; > > > > + /* If the user has disabled the fake-irq,

Re: [Intel-gfx] [PATCH] drm/i915: Remove src adjustment in intel_check_sprite_plane.

Op 23-04-18 om 16:30 schreef Ville Syrjälä: > On Mon, Apr 23, 2018 at 12:49:22PM +0200, Maarten Lankhorst wrote: >> The rounding can cause a perfectly normal 16x16 src to full-screen >> dst to be rounded down, even without clipping involved. Because of >> this we should just remove the adjustment,

Re: [Intel-gfx] [PATCH] drm/i915: Remove src adjustment in intel_check_sprite_plane.

On Mon, Apr 23, 2018 at 12:49:22PM +0200, Maarten Lankhorst wrote: > The rounding can cause a perfectly normal 16x16 src to full-screen > dst to be rounded down, even without clipping involved. Because of > this we should just remove the adjustment, as no other driver or plane > does it. > >

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: Don't pass the index to drm_property_add_enum() (rev2)

== Series Details == Series: drm: Don't pass the index to drm_property_add_enum() (rev2) URL : https://patchwork.freedesktop.org/series/40122/ State : failure == Summary == Applying: drm: Don't pass the index to drm_property_add_enum() error: patch failed: drivers/gpu/drm/drm_connector.c:1069

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915: Use ktime on wait_for

== Series Details == Series: series starting with [CI,1/2] drm/i915: Use ktime on wait_for URL : https://patchwork.freedesktop.org/series/42115/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4078 -> Patchwork_8774 = == Summary - SUCCESS == No regressions found.

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove src adjustment in intel_check_sprite_plane.

== Series Details == Series: drm/i915: Remove src adjustment in intel_check_sprite_plane. URL : https://patchwork.freedesktop.org/series/42113/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4078 -> Patchwork_8773 = == Summary - SUCCESS == No regressions found.

Re: [Intel-gfx] [v2] drm/i915/fbdev: Enable late fbdev initial configuration

On Fri, 20 Apr 2018, Paul Menzel wrote: > Dear Jose, > > > On 04/19/18 01:41, Souza, Jose wrote: >> If the initial fbdev configuration(intel_fbdev_initial_config()) runs and > > Nit: Space before (. > >> there still no sink connected it will cause >>

Re: [Intel-gfx] [PATCH] drm: Don't pass the index to drm_property_add_enum()

Acked-by: Stanislav Lisovskiy Best Regards, Lisovskiy Stanislav Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo> From: Ville Syrjala [ville.syrj...@linux.intel.com] Sent: Friday, March 16,

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/6] drm/i915: Stop tracking timeline->inflight_seqnos

Quoting Patchwork (2018-04-23 14:40:51) > igt@core_auth@basic-auth: > fi-glk-j4005: PASS -> INCOMPLETE (k.org#198133, fdo#103359) > fi-bdw-gvtdvm: PASS -> INCOMPLETE (fdo#105600) > fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927) > fi-cnl-psr: PASS

Re: [Intel-gfx] [PATCH v7 1/2] drm: content-type property for HDMI connector

Ping From: Intel-gfx [intel-gfx-boun...@lists.freedesktop.org] on behalf of StanLis [stanislav.lisovs...@intel.com] Sent: Monday, April 23, 2018 10:34 AM To: dri-de...@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Subject: [Intel-gfx] [PATCH v7

[Intel-gfx] [PATCH igt] test/gem_exec_schedule: Check each engine is an independent timeline

In the existing ABI, each engine operates its own timeline (fence.context) and so should execute independently of any other. If we install a blocker on all other engines, that should not affect execution on the local engine. Signed-off-by: Chris Wilson Cc: Tvrtko

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/6] drm/i915: Stop tracking timeline->inflight_seqnos

== Series Details == Series: series starting with [1/6] drm/i915: Stop tracking timeline->inflight_seqnos URL : https://patchwork.freedesktop.org/series/42111/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4078 -> Patchwork_8772 = == Summary - FAILURE == Serious

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/6] drm/i915: Stop tracking timeline->inflight_seqnos

== Series Details == Series: series starting with [1/6] drm/i915: Stop tracking timeline->inflight_seqnos URL : https://patchwork.freedesktop.org/series/42111/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Stop tracking timeline->inflight_seqnos

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/6] drm/i915: Stop tracking timeline->inflight_seqnos

== Series Details == Series: series starting with [1/6] drm/i915: Stop tracking timeline->inflight_seqnos URL : https://patchwork.freedesktop.org/series/42111/ State : warning == Summary == $ dim checkpatch origin/drm-tip cdd8eb08a9de drm/i915: Stop tracking timeline->inflight_seqnos -:14:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/hisilicon/hibmc: Using module_pci_driver.

== Series Details == Series: drm/hisilicon/hibmc: Using module_pci_driver. URL : https://patchwork.freedesktop.org/series/42103/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4078 -> Patchwork_8771 = == Summary - SUCCESS == No regressions found. External URL:

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Lazily unbind vma on close

On 23/04/2018 11:14, Chris Wilson wrote: When userspace is passing around swapbuffers using DRI, we frequently have to open and close the same object in the foreign address space. This shows itself as the same object being rebound at roughly 30fps (with a second object also being rebound at

Re: [Intel-gfx] [PATCH 06/18] drm/i915/breadcrumbs: Keep the fake irq armed across reset

Chris Wilson writes: > Instead of synchronously cancelling the timer and re-enabling it inside > the reset callbacks, keep the timer enabled and let it die on its next > wakeup if no longer required. This allows > intel_engine_reset_breadcrumbs() to be used from an

Re: [Intel-gfx] [PATCH 5/6] drm/i915: Split i915_gem_timeline into individual timelines

Quoting Tvrtko Ursulin (2018-04-23 13:33:04) > > On 23/04/2018 11:13, Chris Wilson wrote: > > We need to move to a more flexible timeline that doesn't assume one > > fence context per engine, and so allow for a single timeline to be used > > across a combination of engines. This means that

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Move timeline from GTT to ring

Quoting Tvrtko Ursulin (2018-04-23 11:44:19) > > On 23/04/2018 11:13, Chris Wilson wrote: > > diff --git a/drivers/gpu/drm/i915/i915_gem.c > > b/drivers/gpu/drm/i915/i915_gem.c > > index 0097a77fae8d..1635975dbc16 100644 > > --- a/drivers/gpu/drm/i915/i915_gem.c > > +++

Re: [Intel-gfx] [PATCH 5/6] drm/i915: Split i915_gem_timeline into individual timelines

On 23/04/2018 11:13, Chris Wilson wrote: We need to move to a more flexible timeline that doesn't assume one fence context per engine, and so allow for a single timeline to be used across a combination of engines. This means that preallocating a fence context per engine is now a hindrance, and

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v6] intel-gpu-top: Rewrite the tool to be safe to use

Ping? >Понедельник, 9 апреля 2018, 15:26 +03:00 от Tvrtko Ursulin >: > > >[Adding some people to Cc for more ack/nack type feedback.] > >Executive question is ack or nack on replacing intel_gpu_top with a new >implementation which uses only perf PMU for counter

[Intel-gfx] [CI 1/2] drm/i915: Use ktime on wait_for

We use jiffies to determine when wait expires. However Imre did find out that jiffies can and will do a >1 increments on certain situations [1]. When this happens in a wait_for loop, we return timeout errorneously much earlier than what the real wallclock would say. We can't afford our waits to

[Intel-gfx] [CI 2/2] drm/i915: Add compiler barrier to wait_for

We need to be careful to not let compiler evaluate the expiration and the operation on it's terms. Document and enforce that COND will be evaluated before checking timeout expiration. Suggested-by: Chris Wilson Cc: Chris Wilson Signed-off-by:

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Only track live rings for retiring

On 23/04/2018 11:36, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-04-23 11:25:54) On 23/04/2018 11:13, Chris Wilson wrote: We don't need to track every ring for its lifetime as they are managed by the contexts/engines. What we do want to track are the live rings so that we can

[Intel-gfx] [PATCH] drm/i915: Remove src adjustment in intel_check_sprite_plane.

The rounding can cause a perfectly normal 16x16 src to full-screen dst to be rounded down, even without clipping involved. Because of this we should just remove the adjustment, as no other driver or plane does it. Signed-off-by: Maarten Lankhorst ---

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Move timeline from GTT to ring

On 23/04/2018 11:13, Chris Wilson wrote: In the future, we want to move a request between engines. To achieve this, we first realise that we have two timelines in effect here. The first runs through the GTT is required for ordering vma access, which is tracked currently by engine. The second is

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Only track live rings for retiring

Quoting Tvrtko Ursulin (2018-04-23 11:25:54) > > On 23/04/2018 11:13, Chris Wilson wrote: > > We don't need to track every ring for its lifetime as they are managed > > by the contexts/engines. What we do want to track are the live rings so > > that we can sporadically clean up requests if

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Only track live rings for retiring

On 23/04/2018 11:13, Chris Wilson wrote: We don't need to track every ring for its lifetime as they are managed by the contexts/engines. What we do want to track are the live rings so that we can sporadically clean up requests if userspace falls behind. We can simply restrict the gt->rings list

Re: [Intel-gfx] [PULL] gvt-next for 4.18

On Mon, 23 Apr 2018, Zhi Wang wrote: > Hi Jani: > > I picked out the patch which causes conflicts and may put it back in the > next back merge from drm-intel-next to gvt-next. So there shouldn't be > any conflict in this pull. Thanks for your efforts. Thanks, pulled to

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Retire requests along rings

On 23/04/2018 11:13, Chris Wilson wrote: In the next patch, rings are the central timeline as requests may jump between engines. Therefore in the future as we retire in order along the engine timeline, we may retire out-of-order within a ring (as the ring now occurs along multiple engines),

Re: [Intel-gfx] [PATCH v11 07/11] drm: Add helper functions to handle aspect-ratio flag bits

On Mon, 23 Apr 2018, "Nautiyal, Ankit K" wrote: > On 4/20/2018 7:42 PM, Ville Syrjälä wrote: >> On Fri, Apr 20, 2018 at 07:01:47PM +0530, Nautiyal, Ankit K wrote: >>> From: Ankit Nautiyal >>> +bool >>> +drm_mode_aspect_ratio_allowed(const

Re: [Intel-gfx] [PATCH v11 09/11] drm: Expose modes with aspect ratio, only if requested

On Mon, Apr 23, 2018 at 11:19:08AM +0530, Nautiyal, Ankit K wrote: > > > On 4/20/2018 7:52 PM, Ville Syrjälä wrote: > > On Fri, Apr 20, 2018 at 07:01:49PM +0530, Nautiyal, Ankit K wrote: > >> From: Ankit Nautiyal > >> > >> We parse the EDID and add all the modes in

[Intel-gfx] [PATCH 4/6] drm/i915: Move timeline from GTT to ring

In the future, we want to move a request between engines. To achieve this, we first realise that we have two timelines in effect here. The first runs through the GTT is required for ordering vma access, which is tracked currently by engine. The second is implied by sequential execution of commands

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Retire requests along rings

On 23/04/2018 10:06, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-04-23 09:47:57) On 20/04/2018 14:20, Chris Wilson wrote: void i915_retire_requests(struct drm_i915_private *i915) { - struct intel_engine_cs *engine; - enum intel_engine_id id; + struct intel_ring *ring,

[Intel-gfx] [PATCH 3/6] drm/i915: Only track live rings for retiring

We don't need to track every ring for its lifetime as they are managed by the contexts/engines. What we do want to track are the live rings so that we can sporadically clean up requests if userspace falls behind. We can simply restrict the gt->rings list to being only gt->live_rings.

[Intel-gfx] [PATCH 5/6] drm/i915: Split i915_gem_timeline into individual timelines

We need to move to a more flexible timeline that doesn't assume one fence context per engine, and so allow for a single timeline to be used across a combination of engines. This means that preallocating a fence context per engine is now a hindrance, and so we want to introduce the singular

[Intel-gfx] [PATCH 6/6] drm/i915: Lazily unbind vma on close

When userspace is passing around swapbuffers using DRI, we frequently have to open and close the same object in the foreign address space. This shows itself as the same object being rebound at roughly 30fps (with a second object also being rebound at 30fps), which involves us having to rewrite the

[Intel-gfx] [PATCH 1/6] drm/i915: Stop tracking timeline->inflight_seqnos

In commit 9b6586ae9f6b ("drm/i915: Keep a global seqno per-engine"), we moved from a global inflight counter to per-engine counters in the hope that will be easy to run concurrently in future. However, with the advent of the desire to move requests between engines, we do need a global counter to

[Intel-gfx] [PATCH 2/6] drm/i915: Retire requests along rings

In the next patch, rings are the central timeline as requests may jump between engines. Therefore in the future as we retire in order along the engine timeline, we may retire out-of-order within a ring (as the ring now occurs along multiple engines), leading to much hilarity in miscomputing the

Re: [Intel-gfx] [PATCH v11 07/11] drm: Add helper functions to handle aspect-ratio flag bits

On Mon, Apr 23, 2018 at 10:55:54AM +0530, Nautiyal, Ankit K wrote: > > > On 4/20/2018 7:42 PM, Ville Syrjälä wrote: > > On Fri, Apr 20, 2018 at 07:01:47PM +0530, Nautiyal, Ankit K wrote: > >> From: Ankit Nautiyal > >> > >> This patch adds helper functions for

Re: [Intel-gfx] [PATCH v11 06/11] drm: Add DRM client cap for aspect-ratio

On Mon, Apr 23, 2018 at 10:43:47AM +0530, Nautiyal, Ankit K wrote: > > > On 4/20/2018 7:37 PM, Ville Syrjälä wrote: > > On Fri, Apr 20, 2018 at 07:01:46PM +0530, Nautiyal, Ankit K wrote: > >> From: Ankit Nautiyal > >> > >> To enable aspect-ratio support in DRM,

  1   2   >