Re: [Intel-gfx] [RFC] drm/i915: Add a new modparam for customized ring multiplier

On 01/05/2018 02:15 AM, Sagar Arun Kamble wrote: On 1/5/2018 3:22 AM, Yaodong Li wrote: On 01/03/2018 10:10 PM, Sagar Arun Kamble wrote: Since ring frequency programming needs consideration of both IA and GT frequency requests I think keeping the logic to program the ring frequency table in

Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5

Will do. On Fri, Jan 05, 2018 at 08:02:48PM +, Chris Wilson wrote: > Quoting Alexandru Chirvasitu (2018-01-05 19:58:42) > > OK, I then plan to try with the previous config, plus these > > modifications: > > > > CONFIG_PAGE_POISONING not set > > CONFIG_SLUB_STATS=y > > > > I'm a little

Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5

Quoting Alexandru Chirvasitu (2018-01-05 19:58:42) > OK, I then plan to try with the previous config, plus these > modifications: > > CONFIG_PAGE_POISONING not set > CONFIG_SLUB_STATS=y > > I'm a little puzzled about this: [snip] > > It would be CONFIG_SLUB_STATS and then you would a > >

Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5

OK, I then plan to try with the previous config, plus these modifications: CONFIG_PAGE_POISONING not set CONFIG_SLUB_STATS=y I'm a little puzzled about this: On Fri, Jan 05, 2018 at 07:51:01PM +, Chris Wilson wrote: > Quoting Alexandru Chirvasitu (2018-01-05 19:37:24) > > I'll try. I need a

Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5

Quoting Alexandru Chirvasitu (2018-01-05 19:37:24) > I'll try. I need a bit of clarification: > > On Fri, Jan 05, 2018 at 05:52:25PM +, Chris Wilson wrote: > > Quoting Alexandru Chirvasitu (2018-01-03 21:53:15) > > > All right, here's the dmesg from the kernel compiled from drm-tip (in > > >

Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5

I'll try. I need a bit of clarification: On Fri, Jan 05, 2018 at 05:52:25PM +, Chris Wilson wrote: > Quoting Alexandru Chirvasitu (2018-01-03 21:53:15) > > All right, here's the dmesg from the kernel compiled from drm-tip (in > > sync with upstream at the time of the compilation earlier

Re: [Intel-gfx] [PATCH v2 2/2] kms_content_protection: Add Content Protection test

On Tue, Dec 19, 2017 at 9:28 AM, Ramalingam C wrote: > Adding few more findings from the IGT usage with kernel solutions. > > > > On Wednesday 13 December 2017 04:07 PM, Ramalingam C wrote: >> >> Sean, >> >> Adding few more observations. >> >> >> On Thursday 07 December

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Enable vblanks after verifying power domain states.

On Fri, 2018-01-05 at 10:09 -0800, Rodrigo Vivi wrote: > On Fri, Jan 05, 2018 at 11:23:54AM +, Maarten Lankhorst wrote: > > Op 04-01-18 om 22:51 schreef Pandiyan, Dhinakaran: > > > On Thu, 2018-01-04 at 12:35 +0100, Maarten Lankhorst wrote: > > >> Wouldn't it be better to make

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Apply cond_resched() liberally to igt_ggtt_page()

Quoting Chris Wilson (2018-01-05 17:39:04) > Still occasionally hitting timeouts on bxt with igt_ggtt_page(), so > include some cond_resched() to keep the nmi watchdog appeased. On my bxt with kasan+lockdep, igt_ggtt_page() takes 0.3s. And on cases where CI passes, igt_ggtt_page() takes 0.1s.

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Enable vblanks after verifying power domain states.

On Fri, Jan 05, 2018 at 11:23:54AM +, Maarten Lankhorst wrote: > Op 04-01-18 om 22:51 schreef Pandiyan, Dhinakaran: > > On Thu, 2018-01-04 at 12:35 +0100, Maarten Lankhorst wrote: > >> Wouldn't it be better to make intel_power_domains_verify_state work > >> correctly with the vblank irq? > > I

Re: [Intel-gfx] [PATCH v2] drm/i915: Whitelist SLICE_COMMON_ECO_CHICKEN1 on Geminilake.

On Fri, Jan 05, 2018 at 05:48:35PM +, Mark Janes wrote: > Tested-by: Mark Janes Thanks for that and sorry for missing it before merging :( Also I don't know why patchwork didn't get it automatically. > > Geminilake GPU hangs caused by tesselation tests in VulkanCTS

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Apply cond_resched() liberally to igt_ggtt_page()

== Series Details == Series: drm/i915/selftests: Apply cond_resched() liberally to igt_ggtt_page() URL : https://patchwork.freedesktop.org/series/36095/ State : success == Summary == Series 36095v1 drm/i915/selftests: Apply cond_resched() liberally to igt_ggtt_page()

Re: [Intel-gfx] [PATCH i-g-t v12] tests/kms_frontbuffer_tracking: Including DRRS test coverage

On Fri, Jan 05, 2018 at 11:40:29AM +, Lohith BS wrote: > Dynamic Refresh Rate Switch(DRRS) is used to switch the panel's > refresh rate to the lowest vrefresh supported by panel, when frame is > not flipped for more than a Sec. > > In kernel, DRRS uses the front buffer tracking

Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5

Quoting Alexandru Chirvasitu (2018-01-03 21:53:15) > All right, here's the dmesg from the kernel compiled from drm-tip (in > sync with upstream at the time of the compilation earlier today), with > > CONFIG_DRM_I915_DEBUG_GEM=y > > I crashed it by opening 20+ xterm windows. Doesn't always do it

Re: [Intel-gfx] [PATCH v2] drm/i915: Whitelist SLICE_COMMON_ECO_CHICKEN1 on Geminilake.

On Fri, Jan 05, 2018 at 08:59:05AM +, Kenneth Graunke wrote: > Geminilake requires the 3D driver to select whether barriers are > intended for compute shaders, or tessellation control shaders, by > whacking a "Barrier Mode" bit in SLICE_COMMON_ECO_CHICKEN1 when > switching pipelines. Failure

Re: [Intel-gfx] [PATCH v2] drm/i915: Whitelist SLICE_COMMON_ECO_CHICKEN1 on Geminilake.

Tested-by: Mark Janes Geminilake GPU hangs caused by tesselation tests in VulkanCTS and GLCTS are fixed by the Mesa patch that toggles this bit. Kenneth Graunke writes: > Geminilake requires the 3D driver to select whether barriers are > intended

Re: [Intel-gfx] [PATCH] drm/i915: Add HAS_NATIVE_HDMI2 macro

On Fri, Jan 05, 2018 at 10:43:12AM +, Shashank Sharma wrote: > GLK/GEN 10 and higher GEN platfomrs sport native HDMI 2.0 controller. > This patch adds a macro HAS_NATIVE_HDMI2, and uses it to make checks > in the code more readable. > > Cc: Vivi Rodrigo > Cc: Ville

[Intel-gfx] [PATCH] drm/i915/selftests: Apply cond_resched() liberally to igt_ggtt_page()

Still occasionally hitting timeouts on bxt with igt_ggtt_page(), so include some cond_resched() to keep the nmi watchdog appeased. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 6 ++ 1 file changed, 6 insertions(+) diff --git

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/scheduler: Assert that we do not have a dep cycle back to request

== Series Details == Series: drm/i915/scheduler: Assert that we do not have a dep cycle back to request URL : https://patchwork.freedesktop.org/series/36082/ State : success == Summary == Series 36082v1 drm/i915/scheduler: Assert that we do not have a dep cycle back to request

[Intel-gfx] [PATCH] drm/i915/scheduler: Assert that we do not have a dep cycle back to request

When reprioritising a request, we build a list of its dependencies in topological order. This should leave our origin request as the first element in our list, if it moves we have a dependency cycle and severe breakage. Assert that it doesn't move. Complete, but expensive checking is done by

[Intel-gfx] ✓ Fi.CI.BAT: success for igt/kms_frontbuffer_tracking: Show FBC status at the start of the wait (rev3)

== Series Details == Series: igt/kms_frontbuffer_tracking: Show FBC status at the start of the wait (rev3) URL : https://patchwork.freedesktop.org/series/35699/ State : success == Summary == IGT patchset tested on top of latest successful build 6db24416fdcdf5571125f9005089241cc6ba2652

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

Signed-off-by: Chris Wilson --- tests/kms_frontbuffer_tracking.c | 4 1 file changed, 4 insertions(+) diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c index 1601cab45..8b440dadc 100644 --- a/tests/kms_frontbuffer_tracking.c +++

[Intel-gfx] ✗ Fi.CI.IGT: failure for tests/kms_frontbuffer_tracking: Idleness DRRS coverage (rev7)

== Series Details == Series: tests/kms_frontbuffer_tracking: Idleness DRRS coverage (rev7) URL : https://patchwork.freedesktop.org/series/32888/ State : failure == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-pri-indfb-multidraw: pass -> FAIL

[Intel-gfx] ✗ Fi.CI.BAT: failure for igt/kms_frontbuffer_tracking: Show FBC status at the start of the wait (rev2)

== Series Details == Series: igt/kms_frontbuffer_tracking: Show FBC status at the start of the wait (rev2) URL : https://patchwork.freedesktop.org/series/35699/ State : failure == Summary == IGT patchset tested on top of latest successful build 6db24416fdcdf5571125f9005089241cc6ba2652

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/14] drm/i915: Only defer freeing of fence callback when also using the timer

== Series Details == Series: series starting with [01/14] drm/i915: Only defer freeing of fence callback when also using the timer URL : https://patchwork.freedesktop.org/series/36077/ State : success == Summary == Series 36077v1 series starting with [01/14] drm/i915: Only defer freeing of

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

Signed-off-by: Chris Wilson --- tests/kms_frontbuffer_tracking.c | 4 1 file changed, 4 insertions(+) diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c index 1601cab45..8b440dadc 100644 --- a/tests/kms_frontbuffer_tracking.c +++

[Intel-gfx] [PATCH 01/14] drm/i915: Only defer freeing of fence callback when also using the timer

Without an accompanying timer (for internal fences), we can free the fence callback immediately as we do not need to employ the RCU barrier to serialise with the timer. By avoiding the RCU delay, we can avoid the extra mempressure under heavy inter-engine request utilisation. Signed-off-by: Chris

[Intel-gfx] [PATCH 02/14] drm/i915/fence: Separate timeout mechanism for awaiting on dma-fences

As the timeout mechanism has grown more and more complicated, using multiple deferred tasks and more than doubling the size of our struct, split the two implementations to streamline the simpler no-timeout callback variant. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin

[Intel-gfx] [PATCH 10/14] drm/i915/breadcrumbs: Drop request reference for the signaler thread

If we remember to cancel the signaler on a request when retiring it (after we know that the request has been signaled), we do not need to carry an additional request in the signaler itself. This prevents an issue whereby the signaler threads may be delayed and hold on to thousands of request

[Intel-gfx] [PATCH 08/14] drm/i915: Shrink the request kmem_cache on allocation error

If we fail to allocate a new request, make sure we recover the pages that are in the process of being freed by inserting an RCU barrier. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_request.c | 3 +++ 1 file changed, 3 insertions(+) diff --git

[Intel-gfx] [PATCH 13/14] drm/i915: Only signal from interrupt when requested

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

[Intel-gfx] [PATCH 09/14] drm/i915: Trim the retired request queue after submitting

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 request and secondly we know that we there is then a large backlog in retiring requests affecting this timeline. Given that we just

[Intel-gfx] [PATCH 11/14] drm/i915: Reduce spinlock hold time during notify_ring() interrupt

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 --- drivers/gpu/drm/i915/i915_irq.c | 29

[Intel-gfx] [PATCH 12/14] drm/i915: Move the irq_counter inside the spinlock

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 | 4 ++-- drivers/gpu/drm/i915/i915_irq.c

[Intel-gfx] [PATCH 14/14] drm/i915/breadcrumbs: Reduce signaler rbtree to a sorted list

The goal here is to try and reduce the latency of signaling additional requests following the wakeup from interrupt by reducing the list of to-be-signaled requests from an rbtree to a sorted linked list. The original choice of using an rbtree was to facilitate random insertions of request into the

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

When we finally decide the gpu is idle, that is a good time to shrink our kmem_caches. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 22 ++ 1 file changed, 22 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem.c

[Intel-gfx] [PATCH 06/14] drm/i915: Move i915_gem_retire_work_handler

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 file changed, 114 insertions(+), 114

[Intel-gfx] [PATCH 04/14] drm/i915: Use our singlethreaded wq for freeing objects

As freeing the objects require serialisation on struct_mutex, we should prefer to use our singlethreaded driver wq that is dedicated to work requiring struct_mutex (hence serialised).The benefit should be less clutter on the system wq, allowing it to make progress even when the driver/struct_mutex

[Intel-gfx] [PATCH 03/14] drm/i915: Rename some shorthand lock classes

By default, lockdep takes the stringified variable as the name for the lock class. Quite often, these are constructed from local variables that are chosen for their brevity resulting in less than distinct class names. Rename some of the worst offenders encountered in recent reports.

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

Since commit 4e773c3a8a69 ("drm/i915: Wire up shrinkctl->nr_scanned"), we track the number of objects we scan and do not wish to exceed that as it will overly penalise our own slabs under mempressure. Given that we now know the target number of objects to scan, use that as our guide for deciding

[Intel-gfx] Fun with signals

Just some fallout with handling signals when the interrupt generation rate is sufficient to saturate the CPU, leaving no time to clean up. In particular, it's quite easy to cause oom on snb with a bunch of nops. Overall though there's a small latency improvement for inter-engine signaling. -Chris

Re: [Intel-gfx] [PATCH 04/15] drm/i915/skl+: support varification of DDB HW state for NV12

In subject: s/varification/verification/ Op 07-01-18 om 10:59 schreef Vidya Srinivas: > From: Mahesh Kumar > > NV12 formats have two registers for DDB. verify both the registers for > NV12 during verify_wm_state. > > Signed-off-by: Mahesh Kumar

[Intel-gfx] ✓ Fi.CI.BAT: success for tests/kms_frontbuffer_tracking: Idleness DRRS coverage (rev7)

== Series Details == Series: tests/kms_frontbuffer_tracking: Idleness DRRS coverage (rev7) URL : https://patchwork.freedesktop.org/series/32888/ State : success == Summary == IGT patchset tested on top of latest successful build 6db24416fdcdf5571125f9005089241cc6ba2652 lib/gem: Reset the

[Intel-gfx] [PATCH i-g-t v12] tests/kms_frontbuffer_tracking: Including DRRS test coverage

Dynamic Refresh Rate Switch(DRRS) is used to switch the panel's refresh rate to the lowest vrefresh supported by panel, when frame is not flipped for more than a Sec. In kernel, DRRS uses the front buffer tracking infrastructure. Hence DRRS test coverage is added along with other frontbuffer

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] test/kms_psr_sink_crc - subtests psr_basic and psr_drrs need test cleanup

== Series Details == Series: series starting with [1/2] test/kms_psr_sink_crc - subtests psr_basic and psr_drrs need test cleanup URL : https://patchwork.freedesktop.org/series/36065/ State : success == Summary == Test kms_setmode: Subgroup basic: pass -> FAIL

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Enable vblanks after verifying power domain states.

Op 04-01-18 om 22:51 schreef Pandiyan, Dhinakaran: > On Thu, 2018-01-04 at 12:35 +0100, Maarten Lankhorst wrote: >> Wouldn't it be better to make intel_power_domains_verify_state work >> correctly with the vblank irq? > I tried to :) Since I changed the domain_use_count to atomic_t and moved > it

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

Op 05-01-18 om 10:45 schreef Shashank Sharma: > 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 patch is to replace

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add HAS_NATIVE_HDMI2 macro

== Series Details == Series: drm/i915: Add HAS_NATIVE_HDMI2 macro URL : https://patchwork.freedesktop.org/series/36071/ State : success == Summary == Series 36071v1 drm/i915: Add HAS_NATIVE_HDMI2 macro https://patchwork.freedesktop.org/api/1.0/series/36071/revisions/1/mbox/ Test

[Intel-gfx] [PATCH] drm/i915: Add HAS_NATIVE_HDMI2 macro

GLK/GEN 10 and higher GEN platfomrs sport native HDMI 2.0 controller. This patch adds a macro HAS_NATIVE_HDMI2, and uses it to make checks in the code more readable. Cc: Vivi Rodrigo Cc: Ville Syrjala Signed-off-by: Shashank Sharma

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] test/kms_psr_sink_crc - subtests psr_basic and psr_drrs need test cleanup

== Series Details == Series: series starting with [1/2] test/kms_psr_sink_crc - subtests psr_basic and psr_drrs need test cleanup URL : https://patchwork.freedesktop.org/series/36065/ State : success == Summary == IGT patchset tested on top of latest successful build

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for GuC Interrupts/Log updates (rev3)

On 1/5/2018 2:42 PM, Patchwork wrote: == Series Details == Series: GuC Interrupts/Log updates (rev3) URL : https://patchwork.freedesktop.org/series/32179/ State : failure == Summary == Series 32179v3 GuC Interrupts/Log updates

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Whitelist SLICE_COMMON_ECO_CHICKEN1 on Geminilake. (rev2)

== Series Details == Series: drm/i915: Whitelist SLICE_COMMON_ECO_CHICKEN1 on Geminilake. (rev2) URL : https://patchwork.freedesktop.org/series/36039/ State : success == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-offscren-pri-shrfb-draw-blt: fail

[Intel-gfx] ✗ Fi.CI.BAT: warning for YCBCR 4:2:0/4:4:4 output support for LSPCON

== Series Details == Series: YCBCR 4:2:0/4:4:4 output support for LSPCON URL : https://patchwork.freedesktop.org/series/36068/ State : warning == Summary == Series 36068v1 YCBCR 4:2:0/4:4:4 output support for LSPCON https://patchwork.freedesktop.org/api/1.0/series/36068/revisions/1/mbox/

Re: [Intel-gfx] [RFC] drm/i915: Add a new modparam for customized ring multiplier

On 1/5/2018 3:22 AM, Yaodong Li wrote: On 01/03/2018 10:10 PM, Sagar Arun Kamble wrote: Since ring frequency programming needs consideration of both IA and GT frequency requests I think keeping the logic to program the ring frequency table in driver that monitors both IA/GT busyness and

[Intel-gfx] [PATCH v3 5/7] drm/i915: Write AVI infoframes for MCA LSPCON

As LSPCON is a DP branch device, LSPCON vendors define specific methods to pass AVI infoframes to the the chip. This patch adds: - a generic wrapper function for writing AVI infoframes for all LSPCON devices. - a vendor specific function to wrire AVI infoframes into MCA LSPCON devices. V2:

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

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 patch is to replace this bool with an enum, and plug this in in the existing

[Intel-gfx] [PATCH v3 3/7] drm/i915: Check LSPCON vendor OUI

Intel LSPCON chip is provided by 2 vendors: - Megachips America (MCA) - Parade technologies (Parade tech) Its important to know the vendor of this chip, as the address to write AVI infoframes is different for those two. This patch reads the vendor OUI signature, and marks into LSPCON encoder

[Intel-gfx] [PATCH v3 6/7] drm/i915: Write AVI infoframes for Parade LSPCON

Different LSPCON vendors specify their custom methods to pass AVI infoframes to the LSPCON chip, so does Parade tech. This patch adds functions to arrange and write AVI infoframes into Parade LSPCON chips. V2: rebase V3: Added r-b from Maarten Cc: Imre Deak Cc: Ville

[Intel-gfx] [PATCH v3 4/7] drm/i915: Add AVI infoframe support for LSPCON

In order to pass AVI infoframes to LSPCON devices, a source has to write them in a vendor recommended method and location. This patch series: - adds generic LSPCON infoframe setup functions. - registers these functions into existing AVI infoframe framework. - triggers these functions from modeset

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

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 4:4:4 in while setting AVI infoframes. - Adding necessary checks in modeset

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

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 YCBCR 4:4:4 outputs, the source must: - send YCBCR 4:4:4 signals to LSPCON -

[Intel-gfx] [PATCH v3 0/7] YCBCR 4:2:0/4:4:4 output support for LSPCON

This patch series adds YCBCR 4:2:0 output support for LSPCON displays. In order to indicate the color format of output, to the LSPCON device, a source has to set and send proper AVI infoframes to LSPCON. So this patch series: - first adds AVI infoframes support for LSPCON - then adds YCBCR 4:2:0

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Whitelist SLICE_COMMON_ECO_CHICKEN1 on Geminilake. (rev2)

== Series Details == Series: drm/i915: Whitelist SLICE_COMMON_ECO_CHICKEN1 on Geminilake. (rev2) URL : https://patchwork.freedesktop.org/series/36039/ State : success == Summary == Series 36039v2 drm/i915: Whitelist SLICE_COMMON_ECO_CHICKEN1 on Geminilake.

[Intel-gfx] ✗ Fi.CI.BAT: failure for GuC Interrupts/Log updates (rev3)

== Series Details == Series: GuC Interrupts/Log updates (rev3) URL : https://patchwork.freedesktop.org/series/32179/ State : failure == Summary == Series 32179v3 GuC Interrupts/Log updates https://patchwork.freedesktop.org/api/1.0/series/32179/revisions/3/mbox/ Test core_auth:

[Intel-gfx] [PATCH i-g-t 2/2] test/kms_psr_sink : HACK run psr_drrs on BAT

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104260 Signed-off-by: Marta Lofstedt --- tests/intel-ci/fast-feedback.testlist | 575 +- 1 file changed, 288 insertions(+), 287 deletions(-) diff --git

[Intel-gfx] [PATCH i-g-t 1/2] test/kms_psr_sink_crc - subtests psr_basic and psr_drrs need test cleanup

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104260 Signed-off-by: Marta Lofstedt --- tests/kms_psr_sink_crc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c index 83a69f0b..26cf434a 100644 ---

[Intel-gfx] [PATCH v2] drm/i915: Whitelist SLICE_COMMON_ECO_CHICKEN1 on Geminilake.

Geminilake requires the 3D driver to select whether barriers are intended for compute shaders, or tessellation control shaders, by whacking a "Barrier Mode" bit in SLICE_COMMON_ECO_CHICKEN1 when switching pipelines. Failure to do this properly can result in GPU hangs. Unfortunately, this means

Re: [Intel-gfx] [PATCH v3 04/12] drm/i915/guc: Add description and comments about guc_log_level parameter

On 1/5/2018 10:24 AM, Sagar Arun Kamble wrote: On 1/4/2018 10:22 PM, Michal Wajdeczko wrote: On Thu, 04 Jan 2018 17:21:46 +0100, Sagar Arun Kamble wrote: guc_log_level parameter takes effect when GuC is loaded which is controlled through enable_guc parameter.

[Intel-gfx] [PATCH v4 7/9] drm/i915/guc: Add client support to enable/disable GuC interrupts

This patch adds support to enable/disable GuC interrupts for different features without impacting other's need. Currently GuC log capture and CT buffer receive mechanisms use the GuC interrupts. GuC interrupts are currently enabled and disabled in different logging scenarios all gated by log

[Intel-gfx] [PATCH v4 8/9] drm/i915/guc: Restore GuC interrupts across suspend/reset if enabled

In order to override the disable/enable control of GuC interrupts during suspend/reset cycle we are creating two new functions suspend/restore guc_interrupts which check if interrupts were enabled and disable them on suspend and enable them on resume. They are used to restore interrupts across

[Intel-gfx] [PATCH v4 6/9] drm/i915/guc: Make GuC log related functions depend only on log level

With GuC log level set properly only for cases where GuC is loaded we can remove the GuC submission checks from flush_guc_logs and guc_log_register, unregister and uc_fini_hw functions. It is important to note that GuC log runtime data has to be freed during driver unregister. Freeing of that data

[Intel-gfx] [PATCH v4 3/9] drm/i915/guc: Separate creation/release of runtime logging data from base logging data

GuC log runtime/relay channel data will get released during i915 unregister, and only GuC log vma needs to be released during fini. To achieve this, prepare separate helpers to create/destroy base and runtime logging. This separation is also needed to couple runtime log data and interrupts

[Intel-gfx] [PATCH v4 4/9] drm/i915/guc: Grab RPM wakelock while disabling GuC interrupts

Disabling GuC interrupts involves access to GuC IRQ control registers hence ensure device is RPM awake. v2: Add comment about need to synchronize flush work and log runtime destroy v3: Moved patch earlier in the series and removed comment about future work. (Tvrtko) v4: Rebase.

[Intel-gfx] [PATCH v4 1/9] drm/i915/guc: Move GuC interrupts related functions from i915_irq.c to intel_guc.c

GuC interrupts handling is core GuC functionality. Better to keep it with other core functions in intel_guc.c. Since they are used from uC functions, GuC log and i915 irq handling we are keeping them grouped in intel_guc.c instead of intel_uc.c. Also update the function parameter from dev_priv to

[Intel-gfx] [PATCH v4 5/9] drm/i915/guc: Make guc_log_level parameter immutable

This patch introduces i915 internal state variable in GuC log struct, "level" which will be copied from guc_log_level modparam during i915 load and thereafter be available for user updates. This will make guc_log_level parameter immutable. v2: Rebase. Suggested-by: Tvrtko Ursulin

[Intel-gfx] [PATCH v4 2/9] drm/i915/guc: Fix GuC interrupts disabling with logging

With guc_log_unregister disabling runtime logging and interrupts, there is no need to disable interrupts during uc_fini_hw hence it is removed. With GuC CT buffer mechanism, interrupt disabling can be added later at a point where CT mechanism ceases. v2: Rebase. v3: Moved this patch earlier in

[Intel-gfx] [PATCH v4 0/9] GuC Interrupts/Log updates

This series addresses following features/fixes: 1. Restructuring to move GuC interrupts related functions to guc.c 2. Making GuC interrupts enable/disable client based and tying up with logging at all places. 3. Handle suspend/resume/reset for GuC interrupts. 4. Logging fixes about RPM wakeref

[Intel-gfx] [PATCH v4 9/9] HAX: drm/i915/guc: enable GuC submission/logging for CI

Also 1) revert ("drm/i915/guc: Assert that we switch between known ggtt->invalidate functions") 2) fix RPM resume interrupt enabling w.r.t GuC resume 3) disable guc log streaming DRM logs --- drivers/gpu/drm/i915/i915_drv.c | 4 ++-- drivers/gpu/drm/i915/i915_gem_gtt.c | 8 ++--

Re: [Intel-gfx] [PATCH i-g-t 1/2] test/kms_psr_sink_crc - subtests psr_basic and psr_drrs need test cleanup

Arek, I didn't get any PW for this maybe because I sent it together with a HACK patch to get a test run on BAT. Should I rename both patches and re-send to the list? /Marta > -Original Message- > From: Lofstedt, Marta > Sent: Thursday, January 4, 2018 4:07 PM > To: