Re: [Intel-gfx] [PATCH] drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits

On Wed, Jan 17, 2018 at 12:51:08PM +0100, Maarten Lankhorst wrote: > From: "Leo (Sunpeng) Li" > > During a non-blocking commit, it is possible to return before the > commit_tail work is queued (-ERESTARTSYS, for example). > > Since a reference on the crtc commit object is

Re: [Intel-gfx] [PATCH v3 7/7] drm/i915: Add YCBCR 4:2:0/4:4:4 support for LSPCON

On Fri, Jan 05, 2018 at 03:15:35PM +0530, Shashank Sharma wrote: > LSPCON chips can generate YCBCR outputs, if asked nicely :). > > In order to generate YCBCR 4:2:0 outputs, a source must: > - send YCBCR 4:4:4 signals to LSPCON > - program color space as 4:2:0 in AVI infoframes > > Whereas for

Re: [Intel-gfx] [PATCH v3 1/7] drm/i915: Add CRTC output format YCBCR 4:2:0

On Fri, Jan 05, 2018 at 03:15:29PM +0530, Shashank Sharma wrote: > Currently, we are using a bool in CRTC state (state->ycbcr420), > to indicate modeset, that the output format is YCBCR 4:2:0. Now in > order to support other YCBCR formats, we will need more such flags. > > The idea behind this

Re: [Intel-gfx] [PATCH v3 2/7] drm/i915: Add CRTC output format YCBCR 4:4:4

On Fri, Jan 05, 2018 at 03:15:30PM +0530, Shashank Sharma wrote: > This patch adds support for YCBCR 4:4:4 CRTC output format. > To do this, this patch extends the existing YCBCR 4:2:0 > framework by: > - Adding new parameter in for YCBCR 4:4:4 enum crtc_iutput_format. > - Adding case for YCBCR

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add tracking for CDCLK bypass frequency

== Series Details == Series: drm/i915: Add tracking for CDCLK bypass frequency URL : https://patchwork.freedesktop.org/series/36636/ State : success == Summary == Series 36636v1 drm/i915: Add tracking for CDCLK bypass frequency

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm: i915: remove timeval users (rev2)

== Series Details == Series: drm: i915: remove timeval users (rev2) URL : https://patchwork.freedesktop.org/series/33147/ State : failure == Summary == Test drv_suspend: Subgroup fence-restore-untiled: skip -> PASS (shard-snb) fdo#102365 Test

Re: [Intel-gfx] [PATCH] drm/i915: Add tracking for CDCLK bypass frequency

On Wed, Jan 17, 2018 at 07:25:08PM +0200, Imre Deak wrote: > The CDCLK bypass frequency can vary on upcoming platforms, so prepare > for that now by tracking its value in the CDCLK state. > > Currently on BDW+ the bypass frequency is always the reference clock and > I didn't bother with earlier

Re: [Intel-gfx] [PATCH] drm/i915: Allow user to override PWM backlight frequency and duty cycle

17.01.2018, 16:13, "Jani Nikula" : > I'm divided. Clearly, the patch at hand is a technically better solution > than what the blog post has. > > But I also think the folks over at the blog know they're directly > hacking on graphics registers, and whatever it is

[Intel-gfx] [PATCH] drm/i915: Add tracking for CDCLK bypass frequency

The CDCLK bypass frequency can vary on upcoming platforms, so prepare for that now by tracking its value in the CDCLK state. Currently on BDW+ the bypass frequency is always the reference clock and I didn't bother with earlier platforms since it's not all that clear what's the bypass clock on

Re: [Intel-gfx] [PATCH v8 6/6] drm/i915: expose rcs topology through query uAPI

On 17/01/18 15:50, Lionel Landwerlin wrote: On 17/01/18 15:39, Lionel Landwerlin wrote: With the introduction of asymmetric slices in CNL, we cannot rely on the previous SUBSLICE_MASK getparam to tell userspace what subslices are available. Here we introduce a more detailed way of querying the

Re: [Intel-gfx] [PATCH v4] drm/i915/selftests: Wait for the dma-fence timeout

Quoting Tvrtko Ursulin (2018-01-17 14:25:17) > > On 17/01/2018 13:57, Chris Wilson wrote: > > When testing that the timeout fired, we need to be sure we have waited > > just long enough for the timeout to have occurred and for the softirq > > (on another cpu) to have completed. Sleeping for an

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915: Convert intel_hpd_irq_event() into an encoder hotplug hook

On Mon, Jan 15, 2018 at 11:51:19AM -, Patchwork wrote: > == Series Details == > > Series: series starting with [1/3] drm/i915: Convert intel_hpd_irq_event() > into an encoder hotplug hook > URL : https://patchwork.freedesktop.org/series/36431/ > State : failure > > == Summary == > >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: i915: remove timeval users (rev2)

== Series Details == Series: drm: i915: remove timeval users (rev2) URL : https://patchwork.freedesktop.org/series/33147/ State : success == Summary == Series 33147v2 drm: i915: remove timeval users https://patchwork.freedesktop.org/api/1.0/series/33147/revisions/2/mbox/ Test debugfs_test:

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: expose RCS topology to userspace

== Series Details == Series: drm/i915: expose RCS topology to userspace URL : https://patchwork.freedesktop.org/series/36622/ State : warning == Summary == Series 36622v1 drm/i915: expose RCS topology to userspace https://patchwork.freedesktop.org/api/1.0/series/36622/revisions/1/mbox/ Test

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Wait for the dma-fence timeout (rev4)

== Series Details == Series: drm/i915/selftests: Wait for the dma-fence timeout (rev4) URL : https://patchwork.freedesktop.org/series/36610/ State : success == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-primscrn-pri-shrfb-draw-render: pass ->

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits

== Series Details == Series: drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits URL : https://patchwork.freedesktop.org/series/36608/ State : success == Summary == Series 36608v1 drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits

Re: [Intel-gfx] [PULL] gvt-next fixes for 4.16

On Wed, Jan 17, 2018 at 04:23:48AM +, Zhenyu Wang wrote: > > Hi, > > Here's queued gvt-next fixes for 4.16-rc1. Mostly with regression > fixes on vGPU display dmabuf, mmio switch and other misc changes, > details below. > > thanks > -- > The following changes since commit

Re: [Intel-gfx] [PATCH RFC] drm/i915/vlv: Ramp up gpu freq gradually

Hi, On 17-01-18 16:45, Ville Syrjälä wrote: On Wed, Jan 17, 2018 at 10:31:09AM +0200, Mika Kuoppala wrote: Chris Wilson writes: Quoting Mika Kuoppala (2018-01-16 15:21:16) There is a suspicion that with aggressive upclocking, power rail voltage fluctuations can

Re: [Intel-gfx] [PATCH v8 6/6] drm/i915: expose rcs topology through query uAPI

On 17/01/18 15:39, Lionel Landwerlin wrote: With the introduction of asymmetric slices in CNL, we cannot rely on the previous SUBSLICE_MASK getparam to tell userspace what subslices are available. Here we introduce a more detailed way of querying the Gen's GPU topology that doesn't aggregate

[Intel-gfx] [PATCH] [RESEND] drm: i915: remove timeval users

struct timeval is deprecated because it cannot represent times past 2038. In this driver, the only use of this structure is to capture debug information. This is easily changed to ktime_t, which we then format as needed when printing it later. Reviewed-by: Chris Wilson

[Intel-gfx] [PATCH] intel: Future-proof ring names for aubinator_error_decode

The kernel is moving to a $class$instance naming scheme in preparation for accommodating more rings in the future in a consistent manner. It is already using the naming scheme internally, and now we are looking at updating some soft-ABI such as the error state to use the new naming scheme. This of

Re: [Intel-gfx] [PATCH RFC] drm/i915/vlv: Ramp up gpu freq gradually

On Wed, Jan 17, 2018 at 10:31:09AM +0200, Mika Kuoppala wrote: > Chris Wilson writes: > > > Quoting Mika Kuoppala (2018-01-16 15:21:16) > >> There is a suspicion that with aggressive upclocking, power rail > >> voltage fluctuations can disrupt c state transition,

[Intel-gfx] [PATCH v8 4/6] drm/i915: add rcs topology to error state

This might be useful information for developers looking at an error state. v2: Place topology towards the end of the error state (Chris) v3: Reuse common printing code (Michal) v4: Make this a one-liner (Chris) Signed-off-by: Lionel Landwerlin Reviewed-by:

[Intel-gfx] [PATCH v8 5/6] drm/i915: add query uAPI

There are a number of information that are readable from hardware registers and that we would like to make accessible to userspace. One particular example is the topology of the execution units (how are execution units grouped in subslices and slices and also which ones have been fused off for die

[Intel-gfx] [PATCH v8 2/6] drm/i915/debugfs: reuse max slice/subslices already stored in sseu

Now that we have that information in topology fields, let's just reused it. v2: Style tweaks (Tvrtko) Signed-off-by: Lionel Landwerlin Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_debugfs.c | 27 +++

[Intel-gfx] [PATCH v8 1/6] drm/i915: store all subslice masks

Up to now, subslice mask was assumed to be uniform across slices. But starting with Cannonlake, slices can be asymmetric (for example slice0 has different number of subslices as slice1+). This change stores all subslices masks for all slices rather than having a single mask that applies to all

[Intel-gfx] [PATCH v8 3/6] drm/i915/debugfs: add rcs topology entry

While the end goal is to make this information available to userspace through a new ioctl, there is no reason we can't display it in a human readable fashion through debugfs. slice0: 3 subslice(s) (0x7): subslice0: 8 EUs (0xff) subslice1: 8 EUs (0xff) subslice2: 8 EUs

[Intel-gfx] [PATCH v8 6/6] drm/i915: expose rcs topology through query uAPI

With the introduction of asymmetric slices in CNL, we cannot rely on the previous SUBSLICE_MASK getparam to tell userspace what subslices are available. Here we introduce a more detailed way of querying the Gen's GPU topology that doesn't aggregate numbers. This is essential for monitoring parts

[Intel-gfx] [PATCH v8 0/6] drm/i915: expose RCS topology to userspace

Hi all, More changes on the uAPI. I dropped the Reviewed-by Tvrtko on patch 5. The changes about reporting errors on query items rather than through the single ioctl() return value don't seem to crazy to handle from an userspace point of view. Hopefully that's close enough to a final version ;)

Re: [Intel-gfx] [PATCH v2] drm/i915: Use the engine name directly in the error_state file

Quoting Michel Thierry (2018-01-16 18:33:32) > > > On 1/15/2018 9:15 AM, Tvrtko Ursulin wrote: > > > > On 10/01/2018 01:21, Michel Thierry wrote: > >> Instead of using local string names that we will have to keep > >> maintaining, use the engine->name directly. > >> > >> v2: Better invalid

[Intel-gfx] ✗ Fi.CI.IGT: failure for igt/gem_tiled_fence_blits: Allocate bo array

== Series Details == Series: igt/gem_tiled_fence_blits: Allocate bo array URL : https://patchwork.freedesktop.org/series/36607/ State : failure == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-offscren-pri-shrfb-draw-blt: fail -> PASS

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits

== Series Details == Series: drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits URL : https://patchwork.freedesktop.org/series/36608/ State : warning == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-primscrn-cur-indfb-draw-mmap-cpu: pass

Re: [Intel-gfx] [PATCH v4] drm/i915/selftests: Wait for the dma-fence timeout

On 17/01/2018 13:57, Chris Wilson wrote: When testing that the timeout fired, we need to be sure we have waited just long enough for the timeout to have occurred and for the softirq (on another cpu) to have completed. Sleeping for an arbitrary amount is prone to error, so wait for the timeout

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Wait for the dma-fence timeout (rev4)

== Series Details == Series: drm/i915/selftests: Wait for the dma-fence timeout (rev4) URL : https://patchwork.freedesktop.org/series/36610/ State : success == Summary == Series 36610v4 drm/i915/selftests: Wait for the dma-fence timeout

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Wait for the dma-fence timeout (rev3)

== Series Details == Series: drm/i915/selftests: Wait for the dma-fence timeout (rev3) URL : https://patchwork.freedesktop.org/series/36610/ State : success == Summary == Series 36610v3 drm/i915/selftests: Wait for the dma-fence timeout

[Intel-gfx] [PATCH v4] drm/i915/selftests: Wait for the dma-fence timeout

When testing that the timeout fired, we need to be sure we have waited just long enough for the timeout to have occurred and for the softirq (on another cpu) to have completed. Sleeping for an arbitrary amount is prone to error, so wait for the timeout instead and complain if it was too late. v2:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Wait for the dma-fence timeout (rev2)

== Series Details == Series: drm/i915/selftests: Wait for the dma-fence timeout (rev2) URL : https://patchwork.freedesktop.org/series/36610/ State : success == Summary == Series 36610v2 drm/i915/selftests: Wait for the dma-fence timeout

Re: [Intel-gfx] [PATCH v2] drm/i915/selftests: Wait for the dma-fence timeout

Quoting Tvrtko Ursulin (2018-01-17 13:36:06) > > On 17/01/2018 13:11, Chris Wilson wrote: > > When testing that the timeout fired, we need to be sure we have waited > > just long enough for the timeout to have occurred and for the softirq > > (on another cpu) to have completed. Sleeping for an

Re: [Intel-gfx] [PATCH v2] drm/i915/selftests: Wait for the dma-fence timeout

On 17/01/2018 13:11, Chris Wilson wrote: When testing that the timeout fired, we need to be sure we have waited just long enough for the timeout to have occurred and for the softirq (on another cpu) to have completed. Sleeping for an arbitrary amount is prone to error, so wait for the timeout

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Wait for the dma-fence timeout

Quoting Saarinen, Jani (2018-01-17 13:29:13) > HI, > > -Original Message- > > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf > > Of > > Patchwork > > Sent: keskiviikko 17. tammikuuta 2018 15.26 > > To: Chris Wilson > > Cc:

[Intel-gfx] [PATCH v3] drm/i915/selftests: Wait for the dma-fence timeout

When testing that the timeout fired, we need to be sure we have waited just long enough for the timeout to have occurred and for the softirq (on another cpu) to have completed. Sleeping for an arbitrary amount is prone to error, so wait for the timeout instead and complain if it was too late. v2:

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Wait for the dma-fence timeout

HI, > -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of > Patchwork > Sent: keskiviikko 17. tammikuuta 2018 15.26 > To: Chris Wilson > Cc: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] ✓ Fi.CI.BAT:

Re: [Intel-gfx] [PATCH v2 1/6] drm/i915: Lock out execlist tasklet while peeking inside for busy-stats

Quoting Mika Kuoppala (2018-01-17 13:22:09) > Chris Wilson writes: > > > In order to prevent a race condition where we may end up overaccounting > > the active state and leaving the busy-stats believing the GPU is 100% > > busy, lock out the tasklet while we reconstruct

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Wait for the dma-fence timeout

== Series Details == Series: drm/i915/selftests: Wait for the dma-fence timeout URL : https://patchwork.freedesktop.org/series/36610/ State : success == Summary == Series 36610v1 drm/i915/selftests: Wait for the dma-fence timeout

Re: [Intel-gfx] [PATCH v2 1/6] drm/i915: Lock out execlist tasklet while peeking inside for busy-stats

Chris Wilson writes: > In order to prevent a race condition where we may end up overaccounting > the active state and leaving the busy-stats believing the GPU is 100% > busy, lock out the tasklet while we reconstruct the busy state. There is > no direct spinlock guard

Re: [Intel-gfx] [PATCH] drm/i915: Allow user to override PWM backlight frequency and duty cycle

On Tue, 16 Jan 2018, Alex Ivanov wrote: > Since vendor may set bad defaults or user just generally may prefer her > health over > display life. > 1. Allow overriding of PWM frequency otherwise people use solutions like >

[Intel-gfx] [PATCH v2] drm/i915/selftests: Wait for the dma-fence timeout

When testing that the timeout fired, we need to be sure we have waited just long enough for the timeout to have occurred and for the softirq (on another cpu) to have completed. Sleeping for an arbitrary amount is prone to error, so wait for the timeout instead and complain if it was too late. v2:

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Wait for the dma-fence timeout

On 17/01/2018 12:44, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-01-17 12:27:50) On 17/01/2018 12:15, Chris Wilson wrote: When testing that the timeout fired, we need to be sure we have waited just long enough for the timeout to have occurred and for the softirq (on another cpu) to have

Re: [Intel-gfx] [PATCH v7 6/6] drm/i915: expose rcs topology through query uAPI

Quoting Lionel Landwerlin (2018-01-17 12:39:48) > On 16/01/18 21:48, Chris Wilson wrote: > > Quoting Lionel Landwerlin (2018-01-16 19:18:24) > >> diff --git a/drivers/gpu/drm/i915/i915_query.c > >> b/drivers/gpu/drm/i915/i915_query.c > >> index 51736af7f573..038f292e1f2a 100644 > >> ---

Re: [Intel-gfx] [PATCH v7 5/6] drm/i915: add query uAPI

On 17/01/18 10:10, Tvrtko Ursulin wrote: On 16/01/2018 19:18, Lionel Landwerlin wrote: There are a number of information that are readable from hardware registers and that we would like to make accessible to userspace. One particular example is the topology of the execution units (how are

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Wait for the dma-fence timeout

Quoting Tvrtko Ursulin (2018-01-17 12:27:50) > > On 17/01/2018 12:15, Chris Wilson wrote: > > When testing that the timeout fired, we need to be sure we have waited > > just long enough for the timeout to have occurred and for the softirq > > (on another cpu) to have completed. Sleeping for an

Re: [Intel-gfx] [PATCH v7 6/6] drm/i915: expose rcs topology through query uAPI

On 16/01/18 21:48, Chris Wilson wrote: Quoting Lionel Landwerlin (2018-01-16 19:18:24) diff --git a/drivers/gpu/drm/i915/i915_query.c b/drivers/gpu/drm/i915/i915_query.c index 51736af7f573..038f292e1f2a 100644 --- a/drivers/gpu/drm/i915/i915_query.c +++ b/drivers/gpu/drm/i915/i915_query.c @@

Re: [Intel-gfx] [PATCH igt] igt/gem_tiled_fence_blits: Allocate bo array

Quoting Tvrtko Ursulin (2018-01-17 12:33:16) > > On 17/01/2018 11:49, Chris Wilson wrote: > > As we allow more buffers to be allocated to fill larger apertures, we > > may exceed the static allocation of 4096 buffers. > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104669 > >

Re: [Intel-gfx] [PATCH igt] igt/gem_tiled_fence_blits: Allocate bo array

On 17/01/2018 11:49, Chris Wilson wrote: As we allow more buffers to be allocated to fill larger apertures, we may exceed the static allocation of 4096 buffers. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104669 Signed-off-by: Chris Wilson ---

Re: [Intel-gfx] [PATCH i-g-t 2/2] tests: add i915 query tests

On 16/01/18 21:34, Chris Wilson wrote: Quoting Lionel Landwerlin (2018-01-16 16:07:28) Signed-off-by: Lionel Landwerlin --- tests/Makefile.sources | 1 + tests/meson.build | 1 + tests/query.c | 268

Re: [Intel-gfx] [PATCH i-g-t 2/2] tests: add i915 query tests

On 16/01/18 21:38, Chris Wilson wrote: Quoting Chris Wilson (2018-01-16 21:34:34) Quoting Lionel Landwerlin (2018-01-16 16:07:28) Signed-off-by: Lionel Landwerlin --- tests/Makefile.sources | 1 + tests/meson.build | 1 + tests/query.c |

[Intel-gfx] ✓ Fi.CI.BAT: success for igt/gem_tiled_fence_blits: Allocate bo array

== Series Details == Series: igt/gem_tiled_fence_blits: Allocate bo array URL : https://patchwork.freedesktop.org/series/36607/ State : success == Summary == IGT patchset tested on top of latest successful build d4e5b77b341010ae1aac8624175650c32913e3fd CONTRIBUTING: Fix spelling mistake and

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Wait for the dma-fence timeout

On 17/01/2018 12:15, Chris Wilson wrote: When testing that the timeout fired, we need to be sure we have waited just long enough for the timeout to have occurred and for the softirq (on another cpu) to have completed. Sleeping for an arbitrary amount is prone to error, so wait for the timeout

Re: [Intel-gfx] [PATCH 09/10] drm/i915: Only signal from interrupt when requested

On 15/01/2018 21:24, Chris Wilson wrote: Avoid calling dma_fence_signal() from inside the interrupt if we haven't enabled signaling on the request. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_request.c | 2 +- drivers/gpu/drm/i915/i915_irq.c

Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: expose rcs topology through query uAPI

Quoting Tvrtko Ursulin (2018-01-17 09:58:33) > > Engine-stats I had no plans to expose here. You think it would be > useful? Main issue would be that we'd need commands to enable/disable > and not just queries. Unless some magic to auto-enable on first query > and drop after some timeout..

[Intel-gfx] [PATCH] drm/i915/selftests: Wait for the dma-fence timeout

When testing that the timeout fired, we need to be sure we have waited just long enough for the timeout to have occurred and for the softirq (on another cpu) to have completed. Sleeping for an arbitrary amount is prone to error, so wait for the timeout instead and complain if it was too late.

Re: [Intel-gfx] [PATCH 08/10] drm/i915: Move the irq_counter inside the spinlock

On 15/01/2018 21:24, Chris Wilson wrote: Rather than have multiple locked instructions inside the notify_ring() irq handler, move them inside the spinlock and reduce their intrinsic locking. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_request.c |

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits

== Series Details == Series: drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits URL : https://patchwork.freedesktop.org/series/36608/ State : success == Summary == Series 36608v1 drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits

[Intel-gfx] [PATCH] drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits

From: "Leo (Sunpeng) Li" During a non-blocking commit, it is possible to return before the commit_tail work is queued (-ERESTARTSYS, for example). Since a reference on the crtc commit object is obtained for the pending vblank event when preparing the commit, the above

[Intel-gfx] [PATCH igt] igt/gem_tiled_fence_blits: Allocate bo array

As we allow more buffers to be allocated to fill larger apertures, we may exceed the static allocation of 4096 buffers. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104669 Signed-off-by: Chris Wilson --- tests/gem_tiled_fence_blits.c | 13 ++--- 1

Re: [Intel-gfx] [PATCH 03/15] drm/i915/skl+: add NV12 in skl_format_to_fourcc

On Sun, 2018-01-21 at 03:15 +0530, Vidya Srinivas wrote: > From: Mahesh Kumar > > Add support of recognizing DRM_FORMAT_NV12 from plane_format > register value. > Reviewed-by: Mika Kahola > Signed-off-by: Mahesh Kumar

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/guc: Don't enable GuC when vGPU is active

On 17/01/2018 02:36, Du, Changbin wrote: On Tue, Jan 16, 2018 at 11:17:39AM +0100, Michal Wajdeczko wrote: On Tue, 16 Jan 2018 10:53:47 +0100, Joonas Lahtinen wrote: On Mon, 2018-01-15 at 13:10 +0200, Tomi Sarvela wrote: On 15/01/18 12:28, Zhenyu Wang

Re: [Intel-gfx] [PATCH 07/10] drm/i915: Reduce spinlock hold time during notify_ring() interrupt

On 15/01/2018 21:24, Chris Wilson wrote: By taking advantage of the RCU protection of the task struct, we can find the appropriate signaler under the spinlock and then release the spinlock before waking the task and signaling the fence. Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH igt] igt/kms_frontbuffer_tracking: Show FBC status at the start of the wait

On Tue, Jan 16, 2018 at 08:52:19PM +, Chris Wilson wrote: > Signed-off-by: Chris Wilson Please remember to send igt patches to the new mailing list in the future. Adding it. -Daniel > --- > tests/kms_frontbuffer_tracking.c | 9 + > 1 file changed, 5

Re: [Intel-gfx] [PATCH igt] igt/kms_frontbuffer_tracking: Show FBC status at the start of the wait

On Tue, Jan 16, 2018 at 03:10:23PM +, Chris Wilson wrote: > Signed-off-by: Chris Wilson Makes sense for debugging. Reviewed-by: Daniel Vetter > --- > tests/kms_frontbuffer_tracking.c | 4 > 1 file changed, 4 insertions(+) > > diff

Re: [Intel-gfx] [PATCH i-g-t v2 1/1] meson: Refactor get_option() calls for directories

On Wed, Jan 17, 2018 at 11:32:22AM +0100, Daniel Vetter wrote: > On Mon, Jan 15, 2018 at 01:14:56PM +0200, Petri Latvala wrote: > > Fetch the configuration values in the toplevel meson.build for all > > subdirs to share. > > > > v2: Also remember tests/intel-ci/meson.build > > > > Signed-off-by:

Re: [Intel-gfx] [PATCH 02/10] drm/i915: Move i915_gem_retire_work_handler

On 15/01/2018 21:24, Chris Wilson wrote: In preparation for the next patch, move i915_gem_retire_work_handler() later to avoid a forward declaration. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 228 1

Re: [Intel-gfx] [PATCH i-g-t v2 1/1] meson: Refactor get_option() calls for directories

On Mon, Jan 15, 2018 at 01:14:56PM +0200, Petri Latvala wrote: > Fetch the configuration values in the toplevel meson.build for all > subdirs to share. > > v2: Also remember tests/intel-ci/meson.build > > Signed-off-by: Petri Latvala > Cc: Daniel Vetter

Re: [Intel-gfx] [PATCH 01/10] drm/i915: Only attempt to scan the requested number of shrinker slabs

On 15/01/2018 21:24, Chris Wilson wrote: Since commit 4e773c3a8a69 ("drm/i915: Wire up shrinkctl->nr_scanned"), Sounds like it deserves this in the Fixes: tag as well? we track the number of objects we scan and do not wish to exceed that as it will overly penalise our own slabs under

Re: [Intel-gfx] [PATCH i-g-t 1/6] meson: split out simple makefile integration into a makefile

On Fri, Jan 12, 2018 at 12:53:21PM +0200, Petri Latvala wrote: > On Tue, Oct 24, 2017 at 12:52:51PM +0300, Jani Nikula wrote: > > A separate makefile is easier to read and maintain than a here > > document. The meson.sh shell script becomes trivial too. > > > > Signed-off-by: Jani Nikula

Re: [Intel-gfx] [PATCH 05/10] drm/i915: Trim the retired request queue after submitting

On 16/01/2018 10:32, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-01-16 10:18:55) On 15/01/2018 21:24, Chris Wilson wrote: If we submit a request and see that the previous request on this timeline was already signaled, we first do not need to add the dependency tracker for that completed

Re: [Intel-gfx] [PATCH i-g-t v3 1/2] CONTRIBUTING: Fix spelling mistake and line length

On Mon, Jan 08, 2018 at 10:55:20AM -0500, Sean Paul wrote: > Noticed while I was reading it. Makes for a good first contribution, I > guess. > > Changes in v2: > - None > Changes in v3: > - None > > Reviewed-by: Petri Latvala > Signed-off-by: Sean Paul

Re: [Intel-gfx] [PATCH v2] drm/i915: Shrink the GEM kmem_caches upon idling

On 16/01/2018 17:36, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-01-16 17:25:25) On 16/01/2018 15:21, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-01-16 15:12:43) On 16/01/2018 13:05, Chris Wilson wrote: When we finally decide the gpu is idle, that is a good time to shrink our

Re: [Intel-gfx] [PATCH v7 5/6] drm/i915: add query uAPI

On 16/01/2018 19:18, Lionel Landwerlin wrote: There are a number of information that are readable from hardware registers and that we would like to make accessible to userspace. One particular example is the topology of the execution units (how are execution units grouped in subslices and

Re: [Intel-gfx] [PATCH i-g-t v3] tests/gem_reset_stats: Fix retrieval of hangcheck stats expectation

On Tue, Jan 16, 2018 at 12:56:51PM -0800, Antonio Argenziano wrote: > The test expected IOCTL 'I915_GET_RESET_STATS' would return an error > when not root. That is no longer true in the driver since commit > 4c9c0d09741d ("drm/i915: Fix retrieval of hangcheck stats") and therefore > the test was

Re: [Intel-gfx] [PATCH i-g-t v3] tests/gem_reset_stats: Fix retrieval of hangcheck stats expectation

On Tue, Jan 16, 2018 at 12:56:51PM -0800, Antonio Argenziano wrote: > The test expected IOCTL 'I915_GET_RESET_STATS' would return an error > when not root. That is no longer true in the driver since commit > 4c9c0d09741d ("drm/i915: Fix retrieval of hangcheck stats") and therefore > the test was

Re: [Intel-gfx] [PATCH i-g-t v3 0/8] kms_plane_scaling tests.

On Mon, Jan 15, 2018 at 03:28:26PM +0100, Maarten Lankhorst wrote: > This series fixes the current scaler igt test failures and enhances > kms_plane_scaling and kms_plane for covering subtests below: > - verify all the supported pixel formats in planes > - combination of rotation and scaling > -

Re: [Intel-gfx] [PATCH i-g-t 1/2] include: bump drm uAPI headers

On Tue, Jan 16, 2018 at 04:07:27PM +, Lionel Landwerlin wrote: > Signed-off-by: Lionel Landwerlin Please remember to send igt patches to the new mailing list in the future. Adding it. -Daniel > --- > include/drm-uapi/i915_drm.h | 126 >

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm: Fix PANEL_ORIENTATION_QUIRKS breaking the Kconfig DRM menuconfig

== Series Details == Series: drm: Fix PANEL_ORIENTATION_QUIRKS breaking the Kconfig DRM menuconfig URL : https://patchwork.freedesktop.org/series/36595/ State : failure == Summary == Test pm_rc6_residency: Subgroup rc6-accuracy: pass -> SKIP (shard-snb)

Re: [Intel-gfx] IGT news - New mailing list, switching to meson

Cc'ing dri-devel. -Daniel On Mon, Jan 15, 2018 at 04:06:01PM +0200, Petri Latvala wrote: > > New mailing list > > > > IGT now has its own mailing list. For a transition period, patches on > both the new mailing list and intel-gfx (with the appropriate patch > subjectprefix)

Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: expose rcs topology through query uAPI

On 16/01/2018 17:40, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-01-16 16:22:52) On 16/01/2018 16:02, Lionel Landwerlin wrote: diff --git a/drivers/gpu/drm/i915/i915_query.c b/drivers/gpu/drm/i915/i915_query.c index 6468ca613d27..81367c8224ee 100644 ---

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 4/4] meson: Name the project intel-gpu-tools

On Tue, 16 Jan 2018, Petri Latvala wrote: > Eventually we're switching the official name to "IGT GPU Tools" *shudder* at that tongue twister... :p -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list

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

Hi Dave, drm-misc-fixes-2018-01-17: Final 4.15 drm-misc pull: Just 3 sun4i patches to fix clock computation/checks. Cheers, Daniel The following changes since commit b0bb222440a5c8273f67dd37946707e6ba6ad832: Merge branch 'linux-4.15' of git://github.com/skeggsb/linux into drm-fixes

Re: [Intel-gfx] [PATCH i-g-t v3 8/8] tests/kms_plane_scaling: test for multi pipe with scaling, v3.

Op 16-01-18 om 14:56 schreef Mika Kahola: > On Tue, 2018-01-16 at 14:47 +0100, Maarten Lankhorst wrote: >> Op 16-01-18 om 14:46 schreef Mika Kahola: >>> On Mon, 2018-01-15 at 15:28 +0100, Maarten Lankhorst wrote: From: Jyoti Yadav Add a subtest to display

Re: [Intel-gfx] [PATCH RFC] drm/i915/vlv: Ramp up gpu freq gradually

Hi, On 17-01-18 09:31, Mika Kuoppala wrote: Chris Wilson writes: Quoting Mika Kuoppala (2018-01-16 15:21:16) There is a suspicion that with aggressive upclocking, power rail voltage fluctuations can disrupt c state transition, leading to system hang. When

Re: [Intel-gfx] [PATCH] drm/i915: Do not WARN_ON with small framebuffers.

Op 17-01-18 om 00:57 schreef Rodrigo Vivi: > On Tue, Jan 16, 2018 at 03:53:31PM +, Maarten Lankhorst wrote: >> It's perfectly legal to create a fb with stride < 512, and one of >> the kms_plane_scaling subtests creates a very small fb. >> >> Downgrade the WARN_ON to a simple check check, and

Re: [Intel-gfx] [PATCH] drm: Fix PANEL_ORIENTATION_QUIRKS breaking the Kconfig DRM menuconfig

Hi, On 17-01-18 09:48, Daniel Vetter wrote: On Wed, Jan 17, 2018 at 9:42 AM, Hans de Goede wrote: Hi, On 17-01-18 09:40, Daniel Vetter wrote: On Wed, Jan 17, 2018 at 09:10:32AM +0100, Hans de Goede wrote: All Kconfig menu menu entries should have a depends on

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Allow user to override PWM backlight frequency and duty cycle (rev2)

== Series Details == Series: drm/i915: Allow user to override PWM backlight frequency and duty cycle (rev2) URL : https://patchwork.freedesktop.org/series/36540/ State : warning == Summary == Warning: bzip Patchwork_7691/shard-snb5/results0.json.bz2 wasn't in correct JSON format Test

Re: [Intel-gfx] [PATCH] drm: Fix PANEL_ORIENTATION_QUIRKS breaking the Kconfig DRM menuconfig

On Wed, Jan 17, 2018 at 9:42 AM, Hans de Goede wrote: > Hi, > > On 17-01-18 09:40, Daniel Vetter wrote: >> >> On Wed, Jan 17, 2018 at 09:10:32AM +0100, Hans de Goede wrote: >>> >>> All Kconfig menu menu entries should have a depends on MENU_OPTION, the >>> menu stops

Re: [Intel-gfx] [PATCH] drm: Fix PANEL_ORIENTATION_QUIRKS breaking the Kconfig DRM menuconfig

Hi, On 17-01-18 09:40, Daniel Vetter wrote: On Wed, Jan 17, 2018 at 09:10:32AM +0100, Hans de Goede wrote: All Kconfig menu menu entries should have a depends on MENU_OPTION, the menu stops after the first Kconfig entry without this depends on. Since the PANEL_ORIENTATION_QUIRKS option is

Re: [Intel-gfx] [PATCH] drm: Fix PANEL_ORIENTATION_QUIRKS breaking the Kconfig DRM menuconfig

On Wed, Jan 17, 2018 at 09:10:32AM +0100, Hans de Goede wrote: > All Kconfig menu menu entries should have a depends on MENU_OPTION, the > menu stops after the first Kconfig entry without this depends on. > > Since the PANEL_ORIENTATION_QUIRKS option is also used outside of DRM, > it deliberately

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Fix PANEL_ORIENTATION_QUIRKS breaking the Kconfig DRM menuconfig

== Series Details == Series: drm: Fix PANEL_ORIENTATION_QUIRKS breaking the Kconfig DRM menuconfig URL : https://patchwork.freedesktop.org/series/36595/ State : success == Summary == Series 36595v1 drm: Fix PANEL_ORIENTATION_QUIRKS breaking the Kconfig DRM menuconfig

Re: [Intel-gfx] [PATCH RFC] drm/i915/vlv: Ramp up gpu freq gradually

Chris Wilson writes: > Quoting Mika Kuoppala (2018-01-16 15:21:16) >> There is a suspicion that with aggressive upclocking, power rail >> voltage fluctuations can disrupt c state transition, leading >> to system hang. >> >> When upclocking with 4 cpu Baytrails, bring

[Intel-gfx] [PATCH] drm: Fix PANEL_ORIENTATION_QUIRKS breaking the Kconfig DRM menuconfig

All Kconfig menu menu entries should have a depends on MENU_OPTION, the menu stops after the first Kconfig entry without this depends on. Since the PANEL_ORIENTATION_QUIRKS option is also used outside of DRM, it deliberately does not have a depends on DRM, but this causes all items after it to