[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/2] drm/i915/icl: Add remaining registers and bitfields for MG PHY DDI

== Series Details == Series: series starting with [v2,1/2] drm/i915/icl: Add remaining registers and bitfields for MG PHY DDI URL : https://patchwork.freedesktop.org/series/45623/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4402_full -> Patchwork_9478_full = == Summary

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/9] drm/i915: Drop posting reads to flush master interrupts

== Series Details == Series: series starting with [CI,1/9] drm/i915: Drop posting reads to flush master interrupts URL : https://patchwork.freedesktop.org/series/45613/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4400_full -> Patchwork_9477_full = == Summary - WARNING

[Intel-gfx] linux-next: build failure after merge of the fbdev tree

Hi Bartlomiej, After merging the fbdev tree, today's linux-next build (x86_64 allmodconfig) failed like this: ERROR: "dummycon_unregister_output_notifier" [drivers/video/fbdev/core/fb.ko] undefined! ERROR: "dummycon_register_output_notifier" [drivers/video/fbdev/core/fb.ko] undefined! Caused

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Mark expected switch fall-throughs (rev2)

== Series Details == Series: drm/i915: Mark expected switch fall-throughs (rev2) URL : https://patchwork.freedesktop.org/series/34495/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4402 -> Patchwork_9479 = == Summary - SUCCESS == No regressions found. External URL:

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915/icl: Add remaining registers and bitfields for MG PHY DDI

== Series Details == Series: series starting with [v2,1/2] drm/i915/icl: Add remaining registers and bitfields for MG PHY DDI URL : https://patchwork.freedesktop.org/series/45623/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4402 -> Patchwork_9478 = == Summary - SUCCESS

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/2] drm/i915/icl: Add remaining registers and bitfields for MG PHY DDI

== Series Details == Series: series starting with [v2,1/2] drm/i915/icl: Add remaining registers and bitfields for MG PHY DDI URL : https://patchwork.freedesktop.org/series/45623/ State : warning == Summary == $ dim checkpatch origin/drm-tip d33376c8e4f5 drm/i915/icl: Add remaining registers

[Intel-gfx] [PATCH] drm/i915: Mark expected switch fall-throughs

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 141432 Addresses-Coverity-ID: 141433 Addresses-Coverity-ID: 141434 Addresses-Coverity-ID: 141435 Addresses-Coverity-ID: 141436 Addresses-Coverity-ID: 1357360

Re: [Intel-gfx] [PATCH] drm/i915: mark expected switch fall-through

> > Right. That's because we've used MISSING_CASE() also in if-ladders in > addition to the switch default case. From our POV the usage is similar. > Yep. > *shrug* > > I guess I like /* fall through */ annotations next to MISSING_CASE() > better than having two different macros depending on

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/6] drm: Store the calculated vrefresh in the user mode

== Series Details == Series: series starting with [1/6] drm: Store the calculated vrefresh in the user mode URL : https://patchwork.freedesktop.org/series/45610/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4398_full -> Patchwork_9476_full = == Summary - WARNING ==

[Intel-gfx] [PATCH v2 1/2] drm/i915/icl: Add remaining registers and bitfields for MG PHY DDI

This patch adds the remaining register definitions and bit fields required for MG PHy DDI buffer initializations and voltage swing programming for MG PHy DDI ports. While at it this patch also fixes the naming for previously defined MG PHY registers in original commit id (c92f47b5ec977a

[Intel-gfx] [PATCH v2 2/2] drm/i915/icl: Implement voltage swing programming sequence for MG PHY DDI

This sequence is used to setup voltage swing before enabling MG PHY DDI as well as for changing the voltage during DisplayPort Link training. For ICL, there are two types of DDIs. This sequence needs to be used for MG PHY DDI which is ports C-F. v6 (From Manasi): * Add programming for MG_CLKHUB

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. (rev3)

== Series Details == Series: drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. (rev3) URL : https://patchwork.freedesktop.org/series/6/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4398_full -> Patchwork_9475_full = == Summary - WARNING == Minor unknown changes

Re: [Intel-gfx] [PATCH v3 2/3] drm/i915/uc: Fetch GuC/HuC firmwares from guc/huc specific init

On 6/28/2018 7:15 AM, Michal Wajdeczko wrote: We're fetching GuC/HuC firmwares directly from uc level during init_early stage but this breaks guc/huc struct isolation and also strict SW-only initialization rule for init_early. Move fw fetching to init phase and do it separately per guc/huc

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915/guc: Use intel_guc_init_misc to hide GuC internals

Quoting Michel Thierry (2018-06-28 22:44:43) > On 6/28/2018 7:15 AM, Michal Wajdeczko wrote: > > We will add more init steps to misc phase and there is no need > > to expose them separately for use in uc_init_misc function. > > > > Signed-off-by: Michal Wajdeczko > > Cc: Michel Thierry > > ---

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915/guc: Use intel_guc_init_misc to hide GuC internals

On 6/28/2018 7:15 AM, Michal Wajdeczko wrote: We will add more init steps to misc phase and there is no need to expose them separately for use in uc_init_misc function. Signed-off-by: Michal Wajdeczko Cc: Michel Thierry --- drivers/gpu/drm/i915/intel_guc.c | 28

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v3,1/3] drm/i915/guc: Use intel_guc_init_misc to hide GuC internals

Quoting Michal Wajdeczko (2018-06-28 22:19:31) > On Thu, 28 Jun 2018 20:20:11 +0200, Patchwork > wrote: > > > == Series Details == > > > > Series: series starting with [v3,1/3] drm/i915/guc: Use > > intel_guc_init_misc to hide GuC internals > > URL :

[Intel-gfx] [PATCH i-g-t] igt/gem_exec_gttfill: Avoid pwrite into busy handle

The goal of gem_exec_gttfill is to exercise execbuf under heavy GTT pressure (by trying to execute more objects than may fit into the GTT). We spread the same set of handles across different processes, with the result that each would occasionally stall waiting for execution of an unrelated batch,

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v3,1/3] drm/i915/guc: Use intel_guc_init_misc to hide GuC internals

On Thu, 28 Jun 2018 20:20:11 +0200, Patchwork wrote: == Series Details == Series: series starting with [v3,1/3] drm/i915/guc: Use intel_guc_init_misc to hide GuC internals URL : https://patchwork.freedesktop.org/series/45593/ State : failure == Summary == = CI Bug Log - changes from

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/9] drm/i915: Drop posting reads to flush master interrupts

== Series Details == Series: series starting with [CI,1/9] drm/i915: Drop posting reads to flush master interrupts URL : https://patchwork.freedesktop.org/series/45613/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4400 -> Patchwork_9477 = == Summary - SUCCESS == No

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/9] drm/i915: Drop posting reads to flush master interrupts

== Series Details == Series: series starting with [CI,1/9] drm/i915: Drop posting reads to flush master interrupts URL : https://patchwork.freedesktop.org/series/45613/ State : warning == Summary == $ dim checkpatch origin/drm-tip 189a3386ae4e drm/i915: Drop posting reads to flush master

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/6] drm: Store the calculated vrefresh in the user mode

== Series Details == Series: series starting with [1/6] drm: Store the calculated vrefresh in the user mode URL : https://patchwork.freedesktop.org/series/45610/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4398 -> Patchwork_9476 = == Summary - SUCCESS == No

[Intel-gfx] [CI 7/9] drm/i915/execlists: Stop storing the CSB read pointer in the mmio register

As we now never read back our current head position from the CSB pointers register, and the HW itself doesn't use it to prevent overwriting unread CSB entries, we do not need to keep updating the register. As it turns out this register is not listed as being shadowed, and so requires forcewake --

[Intel-gfx] [CI 9/9] drm/i915/execlists: Direct submission of new requests (avoid tasklet/ksoftirqd)

Back in commit 27af5eea54d1 ("drm/i915: Move execlists irq handler to a bottom half"), we came to the conclusion that running our CSB processing and ELSP submission from inside the irq handler was a bad idea. A really bad idea as we could impose nearly 1s latency on other users of the system, on

[Intel-gfx] [CI 8/9] drm/i915/execlists: Trust the CSB

Now that we use the CSB stored in the CPU friendly HWSP, we do not need to track interrupts for when the mmio CSB registers are valid and can just check where we read up to last from the cached HWSP. This means we can forgo the atomic bit tracking from interrupt, and in the next patch it means we

[Intel-gfx] [CI 3/9] drm/i915/execlists: Pull CSB reset under the timeline.lock

In the following patch, we will process the CSB events under the timeline.lock and not serialised by the tasklet. This also means that we will need to protect access to common variables such as execlists->csb_head with the timeline.lock during reset. v2: Move sync_irq to avoid deadlocks between

[Intel-gfx] [CI 5/9] drm/i915/execlists: Unify CSB access pointers

Following the removal of the last workarounds, the only CSB mmio access is for the old vGPU interface. The mmio registers presented by vGPU do not require forcewake and can be treated as ordinary volatile memory, i.e. they behave just like the HWSP access just at a different location. We can

[Intel-gfx] [CI 1/9] drm/i915: Drop posting reads to flush master interrupts

We do not need to do a posting read of our uncached mmio write to re-enable the master interrupt lines after handling an interrupt, so don't. This saves us a slow UC read before we can process the interrupt, most noticeable in execlists where any stalls imposes extra latency on GPU command

[Intel-gfx] [CI 6/9] drm/i915/execlists: Reset CSB write pointer after reset

On HW reset, the HW clears the write pointer (to 0). But since it also writes its first CSB entry to slot 0, we need to reset the write pointer back to the element before (so the first entry we read is 0). This is required for the next patch, where we trust the CSB completely! v2: Use

[Intel-gfx] [CI 4/9] drm/i915/execlists: Process one CSB update at a time

In the next patch, we will process the CSB events directly from the submission path, rather than only after a CS interrupt. Hence, we will no longer have the need for a loop until the has-interrupt bit is clear, and in the meantime can remove that small optimisation. v2: Tvrtko pointed out it was

[Intel-gfx] [CI 2/9] drm/i915/execlists: Pull submit after dequeue under timeline lock

In the next patch, we will begin processing the CSB from inside the submission path (underneath an irqsoff section, and even from inside interrupt handlers). This means that updating the execlists->port[] will no longer be serialised by the tasklet but needs to be locked by the

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Only trigger missed-seqno checking next to boundary

Quoting Mika Kuoppala (2018-06-28 09:06:37) > Chris Wilson writes: > > > If we have more interrupts pending (because we know there are more > > breadcrumb signals before the completion), then we do not need to > > trigger an irq_seqno_barrier or even wakeup the task on this interrupt > > as

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/6] drm: Store the calculated vrefresh in the user mode

== Series Details == Series: series starting with [1/6] drm: Store the calculated vrefresh in the user mode URL : https://patchwork.freedesktop.org/series/45610/ State : warning == Summary == $ dim checkpatch origin/drm-tip 2a77f40fd19a drm: Store the calculated vrefresh in the user mode

[Intel-gfx] [PATCH 6/6] drm/i915: Filter out modes that don't match the fixed mode vrefresh

From: Ville Syrjälä We only ever drive the panel with the fixed mode, hence we don't want to advertize any modes that have a different vertical refresh rate. We tried to allow a second lower clocked mode to used for eDP but that was reverted in commit d93fa1b47b8f ("Revert "drm/i915/edp: Allow

[Intel-gfx] [PATCH 5/6] drm/i915: Make sure panel fixed_mode has vrefresh populated

From: Ville Syrjälä We want to use fixed_mode->vrefresh during mode validation, so first make sure it's set correctly. And we'll do the same for the downclock mode for consistency. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_panel.c | 9 + 1 file changed, 9

[Intel-gfx] [PATCH 3/6] drm/i915/sdvo: Fix multi function encoder stuff

From: Ville Syrjälä SDVO encoders can have multiple different types of outputs hanging off them. Currently the code tries to muck around with various is_foo flags in the encoder to figure out which type its driving. That doesn't work with atomic and other stuff, so let's nuke those flags and

[Intel-gfx] [PATCH 2/6] drm: Set mode->vrefresh before mode validation

From: Ville Syrjälä Update mode->vrefresh before mode validation. This allows the validation code to consult mode->vrefresh safely. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_probe_helper.c | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git

[Intel-gfx] [PATCH 1/6] drm: Store the calculated vrefresh in the user mode

From: Ville Syrjälä Ignore the vrefresh in the mode the user passed in and instead calculate the value based on the actual timings. This way we can actually trust mode->vrefresh to some degree. Or should we compare the user's idea of vrefresh with the one we get from the timings and return an

[Intel-gfx] [PATCH 4/6] drm/i915/sdvo: Utilize intel_panel for fixed_mode

From: Ville Syrjälä Remove the local lvds fixed mode pointer from the sdvo encoder structure and instead utilize intel_panel like everyone else. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_sdvo.c | 40 --- 1 file changed, 21 insertions(+),

[Intel-gfx] ✓ Fi.CI.IGT: success for tests/kms_plane_multiple: DDB corner testcase

== Series Details == Series: tests/kms_plane_multiple: DDB corner testcase URL : https://patchwork.freedesktop.org/series/45578/ State : success == Summary == = CI Bug Log - changes from IGT_4529_full -> IGTPW_1509_full = == Summary - WARNING == Minor unknown changes coming with

Re: [Intel-gfx] [PATCH] drm/i915: encourage BIT() macro usage in register definitions

On Thu, Jun 28, 2018 at 10:45:02AM -0700, Paulo Zanoni wrote: > Em Qui, 2018-06-28 às 15:03 +0300, Jani Nikula escreveu: > > On Wed, 27 Jun 2018, Chris Wilson wrote: > > > Quoting Michal Wajdeczko (2018-06-27 16:51:42) > > > > On Wed, 27 Jun 2018 16:41:13 +0200, Jani Nikula > > > l.com> > > >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. (rev3)

== Series Details == Series: drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. (rev3) URL : https://patchwork.freedesktop.org/series/6/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4398 -> Patchwork_9475 = == Summary - SUCCESS == No regressions found.

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. (rev3)

== Series Details == Series: drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. (rev3) URL : https://patchwork.freedesktop.org/series/6/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/glk: Add Quirk for GLK NUC HDMI port issues.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. (rev3)

== Series Details == Series: drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. (rev3) URL : https://patchwork.freedesktop.org/series/6/ State : warning == Summary == $ dim checkpatch origin/drm-tip d4f58a865a45 drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. -:31: CHECK:SPACING:

Re: [Intel-gfx] [PATCH] drm/i915: Remove unecessary check for unsupported modifiers for NV12

On Thu, Jun 28, 2018 at 11:36:00AM -0700, Dhinakaran Pandiyan wrote: > On Thu, 2018-06-28 at 08:48 +0200, Daniel Vetter wrote: > > On Wed, Jun 27, 2018 at 11:18:54PM -0700, Dhinakaran Pandiyan wrote: > > > > > > There is already a check to allow only RGB formats with CCS > > > modifiers. > >

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v3,1/3] drm/i915/guc: Use intel_guc_init_misc to hide GuC internals

== Series Details == Series: series starting with [v3,1/3] drm/i915/guc: Use intel_guc_init_misc to hide GuC internals URL : https://patchwork.freedesktop.org/series/45593/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4397_full -> Patchwork_9474_full = == Summary -

Re: [Intel-gfx] [PATCH 2/3] drm: Introduce __setplane_atomic()

On Thu, Jun 28, 2018 at 7:36 PM, Ville Syrjälä wrote: > On Thu, Jun 28, 2018 at 07:05:10PM +0200, Daniel Vetter wrote: >> On Thu, Jun 28, 2018 at 04:54:56PM +0300, Ville Syrjala wrote: >> > From: Ville Syrjälä >> > >> > All the plane->fb/old_fb/crtc dance of __setplane_internal() is >> >

[Intel-gfx] [PATCH v3] drm/i915/glk: Add Quirk for GLK NUC HDMI port issues.

From: Clint Taylor On GLK NUC platforms the HDMI retiming buffer needs additional disabled time to correctly sync to a faster incoming signal. When measured on a scope the highspeed lines of the HDMI clock turn off for ~400uS during a normal resolution change. The HDMI retimer on the GLK NUC

Re: [Intel-gfx] [PATCH] drm/i915: Remove unecessary check for unsupported modifiers for NV12

On Thu, 2018-06-28 at 08:48 +0200, Daniel Vetter wrote: > On Wed, Jun 27, 2018 at 11:18:54PM -0700, Dhinakaran Pandiyan wrote: > > > > There is already a check to allow only RGB formats with CCS > > modifiers. > > > > Signed-off-by: Dhinakaran Pandiyan > Reviewed-by: Daniel Vetter >

Re: [Intel-gfx] [PATCH i-g-t] igt/gem_userptr: Check read-only mappings

Quoting Tvrtko Ursulin (2018-06-28 17:56:24) > > On 27/06/2018 20:44, Chris Wilson wrote: > > +static void test_readonly(int i915) > > Hm.. nice interesting and novel fd naming I think. fd, gem_fd I know we > have. I wonder if we have drm_fd as well somewhere. Just thinking out > loud... Not

Re: [Intel-gfx] [PATCH v2 9/9] drm/tilcdc: Use drm_connector_has_possible_encoder()

On Thu, Jun 28, 2018 at 04:45:50PM +0300, Jyri Sarha wrote: > On 28/06/18 16:13, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Use drm_connector_has_possible_encoder() for checking > > whether the encoder has an associated connector. > > > > v2: Replace the

Re: [Intel-gfx] [PATCH] drm/i915: encourage BIT() macro usage in register definitions

Em Qui, 2018-06-28 às 15:03 +0300, Jani Nikula escreveu: > On Wed, 27 Jun 2018, Chris Wilson wrote: > > Quoting Michal Wajdeczko (2018-06-27 16:51:42) > > > On Wed, 27 Jun 2018 16:41:13 +0200, Jani Nikula > > l.com> > > > wrote: > > > > > > > There's already some BIT() usage here and there,

[Intel-gfx] ✓ Fi.CI.IGT: success for GMBUS changes (rev6)

== Series Details == Series: GMBUS changes (rev6) URL : https://patchwork.freedesktop.org/series/41632/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4397_full -> Patchwork_9472_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9472_full need to

Re: [Intel-gfx] [PATCH 2/3] drm: Introduce __setplane_atomic()

On Thu, Jun 28, 2018 at 07:05:10PM +0200, Daniel Vetter wrote: > On Thu, Jun 28, 2018 at 04:54:56PM +0300, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > All the plane->fb/old_fb/crtc dance of __setplane_internal() is > > pointless on atomic drivers. So let's just introduce a simpler > >

Re: [Intel-gfx] [PATCH v2 3/9] drm: Add drm_connector_for_each_possible_encoder()

On Thu, Jun 28, 2018 at 06:56:40PM +0200, Daniel Vetter wrote: > On Thu, Jun 28, 2018 at 04:13:09PM +0300, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Add a convenience macro for iterating connector->encoder_ids[]. > > Isolates the users from the implementation details. > > > > Note

Re: [Intel-gfx] [PATCH 0/5] drm/i915: Replace {un/reference} with {put, get} functions

On Mon, Jun 18, 2018 at 01:01:49PM +0200, Thomas Zimmermann wrote: > This patch set replaces functions named {un,reference} by their > {put,get} counterparts. Affected data types are struct drm_connector, > struct drm_gem_object, and struct drm_device. > > With the reference-counting functions

Re: [Intel-gfx] [PATCH 2/3] drm: Introduce __setplane_atomic()

On Thu, Jun 28, 2018 at 04:54:56PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > All the plane->fb/old_fb/crtc dance of __setplane_internal() is > pointless on atomic drivers. So let's just introduce a simpler > version that skips all that. > > Ideally we could also skip the

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/9] drm/i915: Drop posting reads to flush master interrupts (rev3)

== Series Details == Series: series starting with [1/9] drm/i915: Drop posting reads to flush master interrupts (rev3) URL : https://patchwork.freedesktop.org/series/45574/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4397_full -> Patchwork_9471_full = == Summary -

Re: [Intel-gfx] [PATCH v2 3/9] drm: Add drm_connector_for_each_possible_encoder()

On Thu, Jun 28, 2018 at 04:13:09PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Add a convenience macro for iterating connector->encoder_ids[]. > Isolates the users from the implementation details. > > Note that we don't seem to pass the file_priv down to drm_encoder_find() > because

Re: [Intel-gfx] [PATCH i-g-t] igt/gem_userptr: Check read-only mappings

On 27/06/2018 20:44, Chris Wilson wrote: Setup a userptr object that only has a read-only mapping back to a file store (memfd). Then attempt to write into that mapping using the GPU and assert that those writes do not land (while also writing via a writable userptr mapping into the same memfd

Re: [Intel-gfx] [PATCH 1/3] drm: Extract __setplane_check()

On Thu, Jun 28, 2018 at 04:54:55PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Pull all the error checking out from __set_plane_internal() to a helper > function. We'll have another user of this soon. > > Signed-off-by: Ville Syrjälä Reviewed-by: Rodrigo Vivi > --- >

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Show vma allocator stack when in doubt (rev4)

== Series Details == Series: drm/i915: Show vma allocator stack when in doubt (rev4) URL : https://patchwork.freedesktop.org/series/45562/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4397_full -> Patchwork_9470_full = == Summary - SUCCESS == No regressions found.

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm: Extract __setplane_check()

On Thu, Jun 28, 2018 at 03:09:30PM -, Patchwork wrote: > == Series Details == > > Series: series starting with [1/3] drm: Extract __setplane_check() > URL : https://patchwork.freedesktop.org/series/45589/ > State : failure > > == Summary == > > = CI Bug Log - changes from CI_DRM_4397 ->

[Intel-gfx] ✓ Fi.CI.BAT: success for tests/kms_plane_multiple: DDB corner testcase

== Series Details == Series: tests/kms_plane_multiple: DDB corner testcase URL : https://patchwork.freedesktop.org/series/45578/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4373 -> IGTPW_1509 = == Summary - SUCCESS == No regressions found. External URL:

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Remove delayed FBC activation.

On Thu, Jun 28, 2018 at 04:10:09PM +0200, Maarten Lankhorst wrote: > Op 27-06-18 om 16:14 schreef Ville Syrjälä: > > On Wed, Jun 27, 2018 at 01:45:04PM +0200, Maarten Lankhorst wrote: > >> Op 26-06-18 om 19:59 schreef Ville Syrjälä: > >>> On Mon, Jun 25, 2018 at 06:37:58PM +0200, Maarten Lankhorst

[Intel-gfx] ✓ Fi.CI.IGT: success for drm: Third attempt at fixing the fb-helper .best_encoder() mess

== Series Details == Series: drm: Third attempt at fixing the fb-helper .best_encoder() mess URL : https://patchwork.freedesktop.org/series/45580/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4397_full -> Patchwork_9469_full = == Summary - WARNING == Minor unknown

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3,1/3] drm/i915/guc: Use intel_guc_init_misc to hide GuC internals

== Series Details == Series: series starting with [v3,1/3] drm/i915/guc: Use intel_guc_init_misc to hide GuC internals URL : https://patchwork.freedesktop.org/series/45593/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4397 -> Patchwork_9474 = == Summary - SUCCESS ==

Re: [Intel-gfx] [PATCH v2 1/9] drm/fb-helper: Eliminate the .best_encoder() usage

On Thu, Jun 28, 2018 at 9:13 AM, Ville Syrjala wrote: > From: Ville Syrjälä > > Instead of using the .best_encoder() hook to figure out whether a given > connector+crtc combo will work, let's instead do what userspace does and > just iterate over all the encoders for the connector, and then

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm: Extract __setplane_check()

== Series Details == Series: series starting with [1/3] drm: Extract __setplane_check() URL : https://patchwork.freedesktop.org/series/45589/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4397 -> Patchwork_9473 = == Summary - FAILURE == Serious unknown changes coming

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v5,1/2] drm/i915/gmbus: Increase the Bytes per Rd/Wr Op

== Series Details == Series: series starting with [v5,1/2] drm/i915/gmbus: Increase the Bytes per Rd/Wr Op URL : https://patchwork.freedesktop.org/series/45576/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4397_full -> Patchwork_9467_full = == Summary - WARNING ==

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm: Extract __setplane_check()

== Series Details == Series: series starting with [1/3] drm: Extract __setplane_check() URL : https://patchwork.freedesktop.org/series/45589/ State : warning == Summary == $ dim checkpatch origin/drm-tip d301e6d532be drm: Extract __setplane_check() -:53: CHECK:SPACING: No space is necessary

[Intel-gfx] ✓ Fi.CI.BAT: success for GMBUS changes (rev6)

== Series Details == Series: GMBUS changes (rev6) URL : https://patchwork.freedesktop.org/series/41632/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4397 -> Patchwork_9472 = == Summary - SUCCESS == No regressions found. External URL:

Re: [Intel-gfx] [PATCH i-g-t] igt/gem_userptr: Check read-only mappings

Quoting Mika Kuoppala (2018-06-28 15:25:49) > Chris Wilson writes: > > > Setup a userptr object that only has a read-only mapping back to a file > > store (memfd). Then attempt to write into that mapping using the GPU and > > assert that those writes do not land (while also writing via a

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for GMBUS changes (rev6)

== Series Details == Series: GMBUS changes (rev6) URL : https://patchwork.freedesktop.org/series/41632/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/gmbus: Increase the Bytes per Rd/Wr Op -O:drivers/gpu/drm/i915/intel_i2c.c:403:23: warning: expression using

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for GMBUS changes (rev6)

== Series Details == Series: GMBUS changes (rev6) URL : https://patchwork.freedesktop.org/series/41632/ State : warning == Summary == $ dim checkpatch origin/drm-tip 3e6e90c178c0 drm/i915/gmbus: Increase the Bytes per Rd/Wr Op 7a76dec751ca drm/i915/gmbus: Enable burst read -:42:

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/9] drm/i915: Drop posting reads to flush master interrupts (rev3)

== Series Details == Series: series starting with [1/9] drm/i915: Drop posting reads to flush master interrupts (rev3) URL : https://patchwork.freedesktop.org/series/45574/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4397 -> Patchwork_9471 = == Summary - SUCCESS ==

Re: [Intel-gfx] [PATCH i-g-t] igt/gem_userptr: Check read-only mappings

Chris Wilson writes: > Setup a userptr object that only has a read-only mapping back to a file > store (memfd). Then attempt to write into that mapping using the GPU and > assert that those writes do not land (while also writing via a writable > userptr mapping into the same memfd to verify that

[Intel-gfx] [PATCH v3 3/3] HAX enable GuC for CI

Signed-off-by: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_params.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index aebe046..3e4e128 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++

[Intel-gfx] [PATCH v3 2/3] drm/i915/uc: Fetch GuC/HuC firmwares from guc/huc specific init

We're fetching GuC/HuC firmwares directly from uc level during init_early stage but this breaks guc/huc struct isolation and also strict SW-only initialization rule for init_early. Move fw fetching to init phase and do it separately per guc/huc struct. v2: don't forget to move wopcm_init -

[Intel-gfx] [PATCH v3 1/3] drm/i915/guc: Use intel_guc_init_misc to hide GuC internals

We will add more init steps to misc phase and there is no need to expose them separately for use in uc_init_misc function. Signed-off-by: Michal Wajdeczko Cc: Michel Thierry --- drivers/gpu/drm/i915/intel_guc.c | 28 drivers/gpu/drm/i915/intel_guc.h | 5 ++---

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/9] drm/i915: Drop posting reads to flush master interrupts (rev3)

== Series Details == Series: series starting with [1/9] drm/i915: Drop posting reads to flush master interrupts (rev3) URL : https://patchwork.freedesktop.org/series/45574/ State : warning == Summary == $ dim checkpatch origin/drm-tip 491ac3bf222c drm/i915: Drop posting reads to flush master

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Remove delayed FBC activation.

Op 27-06-18 om 16:14 schreef Ville Syrjälä: > On Wed, Jun 27, 2018 at 01:45:04PM +0200, Maarten Lankhorst wrote: >> Op 26-06-18 om 19:59 schreef Ville Syrjälä: >>> On Mon, Jun 25, 2018 at 06:37:58PM +0200, Maarten Lankhorst wrote: The only time we should start FBC is when we have waited a

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Show vma allocator stack when in doubt (rev4)

== Series Details == Series: drm/i915: Show vma allocator stack when in doubt (rev4) URL : https://patchwork.freedesktop.org/series/45562/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4397 -> Patchwork_9470 = == Summary - SUCCESS == No regressions found. External

Re: [Intel-gfx] [PATCH v7] drm/i915/execlists: Direct submission of new requests (avoid tasklet/ksoftirqd)

On 28/06/2018 14:28, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-06-28 14:21:06) On 28/06/2018 14:11, Chris Wilson wrote: +/* + * Check the unread Context Status Buffers and manage the submission of new + * contexts to the ELSP accordingly. + */ +static void

Re: [Intel-gfx] [PATCH v2 9/9] drm/tilcdc: Use drm_connector_has_possible_encoder()

On 28/06/18 16:13, Ville Syrjala wrote: > From: Ville Syrjälä > > Use drm_connector_has_possible_encoder() for checking > whether the encoder has an associated connector. > > v2: Replace the drm_for_each_connector_encoder_ids() loop > with a simple drm_connector_has_possible_encoder() call

[Intel-gfx] [PATCH 2/3] drm: Introduce __setplane_atomic()

From: Ville Syrjälä All the plane->fb/old_fb/crtc dance of __setplane_internal() is pointless on atomic drivers. So let's just introduce a simpler version that skips all that. Ideally we could also skip the __setplane_check() as drm_atomic_plane_check() already checks for everything, but the

[Intel-gfx] [PATCH 3/3] drm: Skip __drm_mode_set_config_internal() on atomic drivers

From: Ville Syrjälä Everything (apart from the actual ->set_config() call) __drm_mode_set_config_internal() does is now useless on atomic drivers. So let's just skip all the foreplay. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_crtc.c | 15 ++- 1 file changed, 10

[Intel-gfx] [PATCH 1/3] drm: Extract __setplane_check()

From: Ville Syrjälä Pull all the error checking out from __set_plane_internal() to a helper function. We'll have another user of this soon. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_plane.c | 80 +++-- 1 file changed, 49 insertions(+), 31

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Third attempt at fixing the fb-helper .best_encoder() mess

== Series Details == Series: drm: Third attempt at fixing the fb-helper .best_encoder() mess URL : https://patchwork.freedesktop.org/series/45580/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4397 -> Patchwork_9469 = == Summary - SUCCESS == No regressions found.

Re: [Intel-gfx] [PATCH v5 1/2] drm/i915/gmbus: Increase the Bytes per Rd/Wr Op

Please ignore this series as I have pushed it again to it's original series itself. Sorry for the inconvenience. https://patchwork.freedesktop.org/series/41632/ Thanks and Regards, Ram On Thursday 28 June 2018 06:18 PM, Ramalingam C wrote: GMBUS HW supports 511Bytes as Max Bytes per single

Re: [Intel-gfx] [PATCH v2 0/9] drm: Third attempt at fixing the fb-helper .best_encoder() mess

On Thu, Jun 28, 2018 at 04:13:06PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Changes from the previous version mainly involve Danoie's suggestion Can't type today either: "Daniel's" > of hiding the drm_encoder_find() in the iterator macro. I also polished > the msm and tilcdc cases

[Intel-gfx] [PATCH v6 2/2] drm/i915/gmbus: Enable burst read

Support for Burst read in HW is added for HDCP2.2 compliance requirement. This patch enables the burst read for all the gmbus read of more than 511Bytes, on capable platforms. v2: Extra line is removed. v3: Macro is added for detecting the BURST_READ Support [Jani] Runtime detection of the

[Intel-gfx] [PATCH v6 0/2] GMBUS changes

I am not aware if there is a reason for restricting the Bytes per GMBUS WR/RD to 256 at present. But HW has 9Bits for Total Byte count for a single read or Write cycle. Means we can extend a cycle of RD/WR to 511Bytes. At present nothing much as ROI, as most of the usecases are for less than

[Intel-gfx] [PATCH v5 1/2] drm/i915/gmbus: Increase the Bytes per Rd/Wr Op

GMBUS HW supports 511Bytes as Max Bytes per single RD/WR op. Instead of enabling the 511Bytes per RD/WR cycle on legacy platforms for no absolute ROIs, this change allows the max bytes per op upto 511Bytes from Gen9 onwards. v2: No Change. v3: Inline function for max_xfer_size and renaming of

Re: [Intel-gfx] [PATCH v4] drm/i915: Show vma allocator stack when in doubt

Chris Wilson writes: > At the moment, gem_exec_gttfill fails with a sporadic EBUSY due to us > wanting to unbind a pinned batch. Let's dump who first bound that vma to > see if that helps us identify who still unexpectedly has it pinned. > > v2: We cannot allocate inside the printer (as it may

[Intel-gfx] [PATCH v7] drm/i915/execlists: Direct submission of new requests (avoid tasklet/ksoftirqd)

Back in commit 27af5eea54d1 ("drm/i915: Move execlists irq handler to a bottom half"), we came to the conclusion that running our CSB processing and ELSP submission from inside the irq handler was a bad idea. A really bad idea as we could impose nearly 1s latency on other users of the system, on

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: Third attempt at fixing the fb-helper .best_encoder() mess

== Series Details == Series: drm: Third attempt at fixing the fb-helper .best_encoder() mess URL : https://patchwork.freedesktop.org/series/45580/ State : warning == Summary == $ dim checkpatch origin/drm-tip f29c8d5f4a73 drm/fb-helper: Eliminate the .best_encoder() usage 4433a1a84d27

Re: [Intel-gfx] [PATCH v7] drm/i915/execlists: Direct submission of new requests (avoid tasklet/ksoftirqd)

Quoting Tvrtko Ursulin (2018-06-28 14:21:06) > > On 28/06/2018 14:11, Chris Wilson wrote: > > +/* > > + * Check the unread Context Status Buffers and manage the submission of new > > + * contexts to the ELSP accordingly. > > + */ > > +static void execlists_submission_tasklet(unsigned long data) >

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/9] drm/i915: Drop posting reads to flush master interrupts (rev2)

== Series Details == Series: series starting with [1/9] drm/i915: Drop posting reads to flush master interrupts (rev2) URL : https://patchwork.freedesktop.org/series/45574/ State : failure == Summary == CALLscripts/checksyscalls.sh DESCEND objtool CHK include/generated/compile.h

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v5,1/2] drm/i915/gmbus: Increase the Bytes per Rd/Wr Op

== Series Details == Series: series starting with [v5,1/2] drm/i915/gmbus: Increase the Bytes per Rd/Wr Op URL : https://patchwork.freedesktop.org/series/45576/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4397 -> Patchwork_9467 = == Summary - SUCCESS == No

Re: [Intel-gfx] [i-g-t] tests/kms_plane_multiple: DDB corner testcase

Op 28-06-18 om 15:03 schreef Karthik B S: > This is to exercise DDB algorithm corner case where > DDB allocation was not happening properly for varying size plane. > > Current DDB algorithm uses datarate based DDB division among > planes, but planes with same width require same DDB allocation >

  1   2   3   >