Re: [Intel-gfx] [PATCH 2/3] drm/i915: Return immediately if trylock fails for direct-reclaim

On 08/11/2018 16:48, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-11-08 16:23:08) On 08/11/2018 08:17, Chris Wilson wrote: Ignore trying to shrink from i915 if we fail to acquire the struct_mutex in the shrinker while performing direct-reclaim. The trade-off being (much) lower latency

Re: [Intel-gfx] [PATCH] drm/i915/query: fix subslice length

On 09/11/2018 00:40, Daniele Ceraolo Spurio wrote: We dump the info as an array of u8, so we want to know the length in number of bytes. Current code is still safe because the variable we use BITS_PER_TYPE on is a u8. Cc: Lionel Landwerlin Cc: Tvrtko Ursulin Signed-off-by: Daniele Ceraolo

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v4,1/4] drm/i915/psr: Use intel_psr_exit() in intel_psr_disable_source()

== Series Details == Series: series starting with [v4,1/4] drm/i915/psr: Use intel_psr_exit() in intel_psr_disable_source() URL : https://patchwork.freedesktop.org/series/52113/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5106_full -> Patchwork_10780_full = == Summary -

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix hpd handling for pins with two encoders

== Series Details == Series: drm/i915: Fix hpd handling for pins with two encoders URL : https://patchwork.freedesktop.org/series/52256/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5106_full -> Patchwork_10779_full = == Summary - WARNING == Minor unknown changes

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Move drm_vblank_init() to i915_load_modeset_init()

On Thu, 2018-11-08 at 17:33 +0200, Ville Syrjälä wrote: > On Wed, Nov 07, 2018 at 04:16:44PM -0800, José Roberto de Souza > wrote: > > i915_load_modeset_init() is a more suitable place than > > i915_driver_load() as vblank is part of modeset. > > > > Cc: Jani Nikula > > Cc: Ville Syrjälä > >

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Always write both TILEOFF and LINOFF plane registers

== Series Details == Series: drm/i915: Always write both TILEOFF and LINOFF plane registers URL : https://patchwork.freedesktop.org/series/52246/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5105_full -> Patchwork_10776_full = == Summary - SUCCESS == No regressions

Re: [Intel-gfx] [PATCH v2 13/14] drm/i915: Move ddb/wm programming into plane update/disable hooks on skl+

On Wed, Nov 07, 2018 at 08:44:30PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > On SKL+ the plane WM/BUF_CFG registers are a proper part of each > plane's register set. That means accessing them will cancel any > pending plane update, and we would need a PLANE_SURF register write > to

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/query: fix subslice length

== Series Details == Series: drm/i915/query: fix subslice length URL : https://patchwork.freedesktop.org/series/52270/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5108 -> Patchwork_10784 = == Summary - SUCCESS == No regressions found. External URL:

[Intel-gfx] ✗ Fi.CI.BAT: failure for More watermarks improvements (rev2)

== Series Details == Series: More watermarks improvements (rev2) URL : https://patchwork.freedesktop.org/series/51086/ State : failure == Summary == Applying: drm/i915: don't apply Display WAs 1125 and 1126 to GLK/CNL+ Applying: drm/i915: remove padding from struct skl_wm_level Using index

[Intel-gfx] [PATCH] drm/i915: don't apply Display WAs 1125 and 1126 to GLK/CNL+

BSpec does not show these WAs as applicable to GLK, and for CNL it only shows them applicable for a super early pre-production stepping we shouldn't be caring about anymore. Remove these so we can avoid them on ICL too. v2: Change how we check for gen9 display platforms (Ville). Cc: Matt Roper

Re: [Intel-gfx] [RESEND PATCH v2 1/2] drm/dp/mst: Reprobe EDID for MST ports on resume

Are you still looking into this at all? Even if it's not the right approach I'm still interested in seeing this get fixed as well/discussing what I said before On Wed, 2018-10-24 at 22:45 +, Li, Juston wrote: > On Wed, 2018-10-24 at 18:09 -0400, Lyude Paul wrote: > > Since there's going to be

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/dp_mst: Improve VCPI helpers, use in nouveau (rev5)

== Series Details == Series: drm/dp_mst: Improve VCPI helpers, use in nouveau (rev5) URL : https://patchwork.freedesktop.org/series/51412/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5107 -> Patchwork_10783 = == Summary - WARNING == Minor unknown changes coming with

[Intel-gfx] [PATCH] drm/i915/query: fix subslice length

We dump the info as an array of u8, so we want to know the length in number of bytes. Current code is still safe because the variable we use BITS_PER_TYPE on is a u8. Cc: Lionel Landwerlin Cc: Tvrtko Ursulin Signed-off-by: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/i915_query.c | 3 +--

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/icl: replace check for combo phy

== Series Details == Series: drm/i915/icl: replace check for combo phy URL : https://patchwork.freedesktop.org/series/52269/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_5107 -> Patchwork_10782 = == Summary - FAILURE == Serious unknown changes coming with

Re: [Intel-gfx] [PATCH 2/2] drm/i915/icl: Fix PLL mapping sanitization for DP ports

On 11/07/2018 12:08 PM, Imre Deak wrote: We shouldn't consider an encoder inactive if it doesn't have a CRTC linked, but has virtual MST encoders with a crtc linked. Fix this. Also we should not sanitize the mapping for MST encoders, as it's always their primary encoder (which could be even

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/ddi: Add more sanity check to the encoder HW readout

== Series Details == Series: series starting with [1/2] drm/i915/ddi: Add more sanity check to the encoder HW readout URL : https://patchwork.freedesktop.org/series/52187/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5100_full -> Patchwork_10758_full = == Summary -

Re: [Intel-gfx] [PATCH] drm/i915/icl: replace check for combo phy

On Thu, Nov 08, 2018 at 03:34:39PM -0800, Lucas De Marchi wrote: > These are the only places that assume ports A and B are the ones with > combo phy. Let's use intel_port_is_combophy() there to make sure > it check for combo phy ports the same way everywhere. > > Signed-off-by: Lucas De Marchi

Re: [Intel-gfx] [PATCH 11/14] drm/i915: Fix latency==0 handling for level 0 watermark on skl+

On Thu, Nov 01, 2018 at 05:06:02PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > If the level 0 latency is 0 we can't do anything. Return an error > rather than success. > > Signed-off-by: Ville Syrjälä Is it possible to get 0 latency here? I thought we increased the latency to 2us

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/dp_mst: Improve VCPI helpers, use in nouveau (rev5)

== Series Details == Series: drm/dp_mst: Improve VCPI helpers, use in nouveau (rev5) URL : https://patchwork.freedesktop.org/series/51412/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_5107 -> Patchwork_10781 = == Summary - FAILURE == Serious unknown changes coming with

Re: [Intel-gfx] [PATCH 10/14] drm/i915: Pass the new crtc_state to ->disable_plane()

On Thu, Nov 01, 2018 at 05:06:01PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > We're going to need access to the new crtc state in ->disable_plane() > for SKL+ wm/ddb programming and pre-skl pipe gamma/csc control. Pass > the crtc state down. > > We'll also try to make

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/dp_mst: Improve VCPI helpers, use in nouveau (rev5)

== Series Details == Series: drm/dp_mst: Improve VCPI helpers, use in nouveau (rev5) URL : https://patchwork.freedesktop.org/series/51412/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/dp_mst: Add some atomic state iterator macros Okay! Commit:

[Intel-gfx] [PATCH] drm/i915/icl: replace check for combo phy

These are the only places that assume ports A and B are the ones with combo phy. Let's use intel_port_is_combophy() there to make sure it check for combo phy ports the same way everywhere. Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/intel_combo_phy.c | 4 ++-- 1 file changed, 2

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/dp_mst: Improve VCPI helpers, use in nouveau (rev5)

== Series Details == Series: drm/dp_mst: Improve VCPI helpers, use in nouveau (rev5) URL : https://patchwork.freedesktop.org/series/51412/ State : warning == Summary == $ dim checkpatch origin/drm-tip 6c1d46966cc3 drm/dp_mst: Add some atomic state iterator macros -:7: WARNING:COMMIT_MESSAGE:

Re: [Intel-gfx] [PATCH] drm/i915: Fix hpd handling for pins with two encoders

lgtm Reviewed-by: Lyude Paul On Thu, 2018-11-08 at 22:04 +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > In my haste to remove irq_port[] I accidentally changed the > way we deal with hpd pins that are shared by multiple encoders > (DP and HDMI for pre-DDI platforms). Previously we

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Sanitize PCH port transcoder select on IBX

== Series Details == Series: drm/i915: Sanitize PCH port transcoder select on IBX URL : https://patchwork.freedesktop.org/series/52239/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5105_full -> Patchwork_10775_full = == Summary - SUCCESS == No regressions found.

Re: [Intel-gfx] [PATCH 09/14] drm/i915: Introduce crtc_state->update_planes bitmask

On Thu, Nov 01, 2018 at 05:06:00PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Keep track which planes need updating during the commit. For now this > is just (was_visible || is_visible) but I'll have need to update When gen11 nv12 is in use, it also contains was_slave || is_slave as

[Intel-gfx] [PATCH v5 5/5] drm/dp_mst: Stop unsetting mstc->port, check connector registration

Same thing we did in i915, but for nouveau now. Signed-off-by: Lyude Paul Cc: Daniel Vetter --- drivers/gpu/drm/nouveau/dispnv50/disp.c | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c

[Intel-gfx] [PATCH v5 4/5] drm/nouveau: Use atomic VCPI helpers for MST

Currently, nouveau uses the yolo method of setting up MST displays: it uses the old VCPI helpers (drm_dp_find_vcpi_slots()) for computing the display configuration. These helpers don't take care to make sure they take a reference to the mstb port that they're checking, and additionally don't

[Intel-gfx] [PATCH v5 0/5] drm/dp_mst: Improve VCPI helpers, use in nouveau

This patchset does some cleaning up of the atomic VCPI helpers for MST, and converts nouveau over to using them. I would have included amdgpu in this patch as well, but at the moment moving them over to the atomic helpers is nontrivial. Cc: Daniel Vetter Lyude Paul (5): drm/dp_mst: Add some

[Intel-gfx] [PATCH v5 2/5] drm/dp_mst: Start tracking per-port VCPI allocations

There has been a TODO waiting for quite a long time in drm_dp_mst_topology.c: /* We cannot rely on port->vcpi.num_slots to update * topology_state->avail_slots as the port may not exist if the parent * branch device was unplugged. This should be fixed by tracking

[Intel-gfx] [PATCH v5 1/5] drm/dp_mst: Add some atomic state iterator macros

Signed-off-by: Lyude Paul Reviewed-by: Daniel Vetter --- include/drm/drm_dp_mst_helper.h | 77 + 1 file changed, 77 insertions(+) diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h index 59f005b419cf..3faceb66f5cb 100644 ---

[Intel-gfx] [PATCH v5 3/5] drm/dp_mst: Check payload count in drm_dp_mst_atomic_check()

It occurred to me that we never actually check this! So let's start doing that. Signed-off-by: Lyude Paul Reviewed-by: Daniel Vetter --- drivers/gpu/drm/drm_dp_mst_topology.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Set MI_INVALIDATE_BSD for all video-decode engines

== Series Details == Series: drm/i915: Set MI_INVALIDATE_BSD for all video-decode engines URL : https://patchwork.freedesktop.org/series/52237/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5105_full -> Patchwork_10774_full = == Summary - WARNING == Minor unknown

Re: [Intel-gfx] [PATCH 07/14] drm/i915: Move single buffered plane register writes to the end

On Thu, Nov 01, 2018 at 05:05:58PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > The plane color correction registers are single buffered. So > ideally we would write them at the start of vblank just after the > double buffered plane registers have been latched. Since we have > no

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: fix subslice mask array size

On 07/11/2018 08:10, Patchwork wrote: == Series Details == Series: drm/i915: fix subslice mask array size URL : https://patchwork.freedesktop.org/series/52110/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5096_full -> Patchwork_10742_full = == Summary - WARNING ==

[Intel-gfx] [PATCH 1/3] drm/i915: Make 48bit full ppgtt configuration generic (v10)

48 bit ppgtt device configuration is really just extended address range full ppgtt and may actually be something other than 48 bits. Change HAS_FULL_48BIT_PPGTT() to HAS_4LVL_PPGTT() to better describe that a 4 level walk table extended range PPGTT is being used. Add a new device info field that

[Intel-gfx] [PATCH 2/3] drm/i915: Remove HAS_4LVL_PPGTT

We no longer need to differentiate between 4LVL and FULL ppgtt as the number of bits in the address range provides that information now. Signed-off-by: Bob Paauwe --- drivers/gpu/drm/i915/i915_drv.h | 2 -- drivers/gpu/drm/i915/i915_pci.c | 4 ++--

[Intel-gfx] [PATCH 3/3] drm/i915: Remove HAS_FULL_PPGTT and device_info.ppgtt enum (v2)

With the address range being specified for each platform, we can use that instead of the .ppgtt enum to handle the differences between 3 level and 4 level PPGTT. In most cases, we really only care if the platform supports PPGTT or not. Because of this, we can now remove the HAS_FULL_PPGTT macro

Re: [Intel-gfx] [PATCH 1/2] drm/edid: Add and export function to parse manufacturer id

On Thu, Nov 08, 2018 at 08:42:52PM +, Souza, Jose wrote: > On Thu, 2018-11-08 at 09:31 +0100, Daniel Vetter wrote: > > On Wed, Nov 07, 2018 at 04:23:52PM -0800, José Roberto de Souza > > wrote: > > > This function will be helpful to drivers that wants to add its own > > > quirks to sinks. > >

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v4,1/4] drm/i915/psr: Use intel_psr_exit() in intel_psr_disable_source()

== Series Details == Series: series starting with [v4,1/4] drm/i915/psr: Use intel_psr_exit() in intel_psr_disable_source() URL : https://patchwork.freedesktop.org/series/52113/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5106 -> Patchwork_10780 = == Summary - WARNING

Re: [Intel-gfx] [PATCH 1/2] drm/edid: Add and export function to parse manufacturer id

On Thu, 2018-11-08 at 09:31 +0100, Daniel Vetter wrote: > On Wed, Nov 07, 2018 at 04:23:52PM -0800, José Roberto de Souza > wrote: > > This function will be helpful to drivers that wants to add its own > > quirks to sinks. > > Why would you want to do that? The point of a shared edid parsing >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix hpd handling for pins with two encoders

== Series Details == Series: drm/i915: Fix hpd handling for pins with two encoders URL : https://patchwork.freedesktop.org/series/52256/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5106 -> Patchwork_10779 = == Summary - SUCCESS == No regressions found. External

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/execlists: Force write serialisation into context image vs execution

== Series Details == Series: drm/i915/execlists: Force write serialisation into context image vs execution URL : https://patchwork.freedesktop.org/series/52207/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5103_full -> Patchwork_10768_full = == Summary - WARNING ==

[Intel-gfx] [PATCH] drm/i915: Fix hpd handling for pins with two encoders

From: Ville Syrjälä In my haste to remove irq_port[] I accidentally changed the way we deal with hpd pins that are shared by multiple encoders (DP and HDMI for pre-DDI platforms). Previously we would only handle such pins via ->hpd_pulse(), but now we queue up the hotplug work for the HDMI

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915/execlists: Force write serialisation into context image vs execution

== Series Details == Series: series starting with [1/3] drm/i915/execlists: Force write serialisation into context image vs execution URL : https://patchwork.freedesktop.org/series/52209/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5103_full -> Patchwork_10769_full = ==

Re: [Intel-gfx] [PATCH v2 06/14] drm/i915: Reorganize plane register writes to make them more atomic

On Thu, Nov 08, 2018 at 11:30:07AM -0800, Matt Roper wrote: > On Wed, Nov 07, 2018 at 08:42:55PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Some observations about the plane registers: > > - the control register will self-arm if the plane is not already > > enabled, thus we

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/dp_mst: Improve VCPI helpers, use in nouveau (rev4)

== Series Details == Series: drm/dp_mst: Improve VCPI helpers, use in nouveau (rev4) URL : https://patchwork.freedesktop.org/series/51412/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5103_full -> Patchwork_10766_full = == Summary - WARNING == Minor unknown changes

Re: [Intel-gfx] [PATCH v2 06/14] drm/i915: Reorganize plane register writes to make them more atomic

On Wed, Nov 07, 2018 at 08:42:55PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Some observations about the plane registers: > - the control register will self-arm if the plane is not already > enabled, thus we want to write it as close to (or ideally after) > the surface register >

[Intel-gfx] v4.20-rc1: list_del corruption on thinkpad x220

Hi! My machine locked hard (thinkpad x220). After reboot, I found this in syslog: Sounds like memory corruption..? Does not sound like easy to debug. ...otoh, it still looks like an addres, so maybe it is "just" race in GPU drivers? Any ideas?

Re: [Intel-gfx] [PATCH xf86-video-intel v6] sna: Added AYUV format support for textured and sprite video adapters.

On Thu, Nov 08, 2018 at 05:17:13PM +, Chris Wilson wrote: > Quoting Stanislav Lisovskiy (2018-11-02 10:06:03) > > v2: Renamed DRM_FORMAT_XYUV to DRM_FORMAT_XYUV. > > Added comment about AYUV byte ordering in Gstreamer. > > > > v3: Removed sna_composite_op flags related change to the

Re: [Intel-gfx] [PATCH xf86-video-intel v6] sna: Added AYUV format support for textured and sprite video adapters.

On Fri, Nov 02, 2018 at 12:06:03PM +0200, Stanislav Lisovskiy wrote: > v2: Renamed DRM_FORMAT_XYUV to DRM_FORMAT_XYUV. > Added comment about AYUV byte ordering in Gstreamer. > > v3: Removed sna_composite_op flags related change to the separate patch. > > v4: Fixed review comments, done

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl: Fix combo PHY HW context loss (rev2)

On Wed, Nov 07, 2018 at 11:44:31AM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/icl: Fix combo PHY HW context loss (rev2) > URL : https://patchwork.freedesktop.org/series/51970/ > State : success > > == Summary == Thanks for the reviews, pushed to -dinq with the

Re: [Intel-gfx] [PATCH xf86-video-intel v6] sna: Added AYUV format support for textured and sprite video adapters.

Quoting Stanislav Lisovskiy (2018-11-02 10:06:03) > v2: Renamed DRM_FORMAT_XYUV to DRM_FORMAT_XYUV. > Added comment about AYUV byte ordering in Gstreamer. > > v3: Removed sna_composite_op flags related change to the separate patch. > > v4: Fixed review comments, done code refactoring >

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v3,1/3] drm/i915: Reuse the aux_domain cached

== Series Details == Series: series starting with [v3,1/3] drm/i915: Reuse the aux_domain cached URL : https://patchwork.freedesktop.org/series/52194/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_5105 -> Patchwork_10778 = == Summary - FAILURE == Serious unknown changes

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Return immediately if trylock fails for direct-reclaim

Quoting Tvrtko Ursulin (2018-11-08 16:23:08) > > On 08/11/2018 08:17, Chris Wilson wrote: > > Ignore trying to shrink from i915 if we fail to acquire the struct_mutex > > in the shrinker while performing direct-reclaim. The trade-off being > > (much) lower latency for non-i915 clients at an

Re: [Intel-gfx] [PATCH 3/3] drm/i915/userptr: Avoid struct_mutex recursion for mmu_invalidate_range_start

On 08/11/2018 08:17, Chris Wilson wrote: Since commit 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu notifiers") we have been able to report failure from mmu_invalidate_range_start which allows us to use a trylock on the struct_mutex to avoid potential recursion and report -EBUSY

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Move skip_intermediate_wm handling into ilk_compute_intermediate_wm()

== Series Details == Series: drm/i915: Move skip_intermediate_wm handling into ilk_compute_intermediate_wm() URL : https://patchwork.freedesktop.org/series/52248/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_5105 -> Patchwork_10777 = == Summary - FAILURE == Serious

Re: [Intel-gfx] [PATCH] drm/i915: Sanitize PCH port transcoder select on IBX

On Thu, Nov 08, 2018 at 04:23:48PM +, Chris Wilson wrote: > Quoting Ville Syrjala (2018-11-08 14:36:35) > > From: Ville Syrjälä > > > > IBX has a documented workaround which states that when we disable the > > port we must change its transcoder select to A, otherwise it will > > prevent the

Re: [Intel-gfx] [PATCH] drm/i915: Sanitize PCH port transcoder select on IBX

Quoting Ville Syrjala (2018-11-08 14:36:35) > From: Ville Syrjälä > > IBX has a documented workaround which states that when we disable the > port we must change its transcoder select to A, otherwise it will > prevent the other port (DP vs. HDMI/SDVO) from using transcoder A. > We implement the

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Return immediately if trylock fails for direct-reclaim

On 08/11/2018 08:17, Chris Wilson wrote: Ignore trying to shrink from i915 if we fail to acquire the struct_mutex in the shrinker while performing direct-reclaim. The trade-off being (much) lower latency for non-i915 clients at an increased risk of being unable to obtain a page from

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v3,1/3] drm/i915: Reuse the aux_domain cached

On Thu, Nov 08, 2018 at 04:47:50PM +0200, Imre Deak wrote: > On Thu, Nov 08, 2018 at 12:25:52AM +, Patchwork wrote: > > == Series Details == > > > > Series: series starting with [v3,1/3] drm/i915: Reuse the aux_domain cached > > URL : https://patchwork.freedesktop.org/series/52194/ > >

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

Hey Dave, Try #2! Same as try #1, but with less syncobj timeline, and more explicit use of old/new state in atomic core. drm-misc-next-2018-11-08: drm-misc-next for v4.21, part 1 try 2: UAPI Changes: - Revert syncobj timeline support to drm. Cross-subsystem Changes: - Remove shared fence

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Always write both TILEOFF and LINOFF plane registers

== Series Details == Series: drm/i915: Always write both TILEOFF and LINOFF plane registers URL : https://patchwork.freedesktop.org/series/52246/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5105 -> Patchwork_10776 = == Summary - WARNING == Minor unknown changes coming

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/edid: Add and export function to parse manufacturer id

== Series Details == Series: series starting with [1/2] drm/edid: Add and export function to parse manufacturer id URL : https://patchwork.freedesktop.org/series/52197/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5103_full -> Patchwork_10764_full = == Summary - WARNING

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Move drm_vblank_init() to i915_load_modeset_init()

On Wed, Nov 07, 2018 at 04:16:44PM -0800, José Roberto de Souza wrote: > i915_load_modeset_init() is a more suitable place than > i915_driver_load() as vblank is part of modeset. > > Cc: Jani Nikula > Cc: Ville Syrjälä > Signed-off-by: José Roberto de Souza Reviewed-by: Ville Syrjälä > ---

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Keep overlay functions naming consistent

On Wed, Nov 07, 2018 at 04:16:47PM -0800, José Roberto de Souza wrote: > All other overlay functions(almost all other functions in i915) > follow intel_overlay_verb, so renaming overlay ones that do not match > that. > > Cc: Jani Nikula > Cc: Ville Syrjälä > Signed-off-by: José Roberto de Souza

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Move intel_init_ipc() call to i915_load_modeset_init()

On Wed, Nov 07, 2018 at 04:16:46PM -0800, José Roberto de Souza wrote: > IPC is a display feature, so i915_load_modeset_init() is the right > place to initialize it. > > Cc: Jani Nikula > Cc: Ville Syrjälä > Signed-off-by: José Roberto de Souza > --- > drivers/gpu/drm/i915/i915_drv.c | 4 ++--

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Move FBC init and cleanup calls to modeset functions

On Wed, Nov 07, 2018 at 04:16:45PM -0800, José Roberto de Souza wrote: > Although FBC helps save power it do not belongs to power management > also the cleanup was placed in i915_driver_unload() also not a good > place. intel_modeset_init()/intel_modeset_cleanup() are better places > also this

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Sanitize PCH port transcoder select on IBX

On Thu, Nov 08, 2018 at 03:08:25PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Sanitize PCH port transcoder select on IBX > URL : https://patchwork.freedesktop.org/series/52239/ > State : success > > == Summary == > > = CI Bug Log - changes from CI_DRM_5105 ->

Re: [Intel-gfx] [PATCH] drm/i915: Set MI_INVALIDATE_BSD for all video-decode engines

Chris Wilson writes: > We have multiple instances of VCS but only remember to invalidate the > BSD caches on the first, ignoring the stale caches of any other engine. > > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala > Cc: Tvrtko Ursulin Missing this prolly would have caused much hair

[Intel-gfx] [PATCH] drm/i915: Move skip_intermediate_wm handling into ilk_compute_intermediate_wm()

From: Ville Syrjälä No point in cluttering the common codepaths with the skip_intermediate_wm handling. Just move it into ilk_compute_intermediate_wm() as those are the only platforms using this. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 7 +--

[Intel-gfx] [PATCH] drm/i915: Always write both TILEOFF and LINOFF plane registers

From: Ville Syrjälä Reduce the clutter in the sprite update functions by writing both TILEOFF and LINOFF registers unconditionally. We already did this for primary planes so might as well do it for the sprites too. There is no harm in writing both registers. Which one gets used depends on the

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Sanitize PCH port transcoder select on IBX

== Series Details == Series: drm/i915: Sanitize PCH port transcoder select on IBX URL : https://patchwork.freedesktop.org/series/52239/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5105 -> Patchwork_10775 = == Summary - SUCCESS == No regressions found. External URL:

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/4] drm/i915: Move drm_vblank_init() to i915_load_modeset_init()

== Series Details == Series: series starting with [1/4] drm/i915: Move drm_vblank_init() to i915_load_modeset_init() URL : https://patchwork.freedesktop.org/series/52196/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5103_full -> Patchwork_10763_full = == Summary -

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v3,1/3] drm/i915: Reuse the aux_domain cached

On Thu, Nov 08, 2018 at 12:25:52AM +, Patchwork wrote: > == Series Details == > > Series: series starting with [v3,1/3] drm/i915: Reuse the aux_domain cached > URL : https://patchwork.freedesktop.org/series/52194/ > State : failure > > == Summary == > > = CI Bug Log - changes from

[Intel-gfx] [PATCH] drm/i915: Sanitize PCH port transcoder select on IBX

From: Ville Syrjälä IBX has a documented workaround which states that when we disable the port we must change its transcoder select to A, otherwise it will prevent the other port (DP vs. HDMI/SDVO) from using transcoder A. We implement the workaround during encoder disable, but looks like some

Re: [Intel-gfx] [PATCH v10 05/15] drm/i915/icl: Get HW state for DSI encoder

On Fri, 2018-11-02 at 13:47 +0200, Jani Nikula wrote: > From: Madhav Chauhan > > This patch read out the current hw state for DSI and > return true if encoder is active. > > v2 by Jani: > - Squash connector get hw state hook here > - Squash encode get hw state fix here > > v3 by Jani: > -

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Set MI_INVALIDATE_BSD for all video-decode engines

== Series Details == Series: drm/i915: Set MI_INVALIDATE_BSD for all video-decode engines URL : https://patchwork.freedesktop.org/series/52237/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5105 -> Patchwork_10774 = == Summary - SUCCESS == No regressions found.

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915/icl: Release TC ports when unloading or suspending driver

== Series Details == Series: series starting with [1/3] drm/i915/icl: Release TC ports when unloading or suspending driver URL : https://patchwork.freedesktop.org/series/52195/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5103_full -> Patchwork_10761_full = == Summary -

[Intel-gfx] [PATCH] drm/i915: Set MI_INVALIDATE_BSD for all video-decode engines

We have multiple instances of VCS but only remember to invalidate the BSD caches on the first, ignoring the stale caches of any other engine. Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_lrc.c | 2 +- 1 file changed, 1 insertion(+), 1

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

Hi Dave, Here's drm-intel-fixes for -rc2. This now includes the GVT fixes too. There's one OOPS fix and memory corruption fix for GVT, as the most important ones. Also a fix for user reported Bugzilla #108282 on 32-bit systems with new Mesa. HDMI 2.0 audio clock mode corrections and removal of

Re: [Intel-gfx] [PATCH 1/3] drm/i915/execlists: Force write serialisation into context image vs execution

Quoting Chris Wilson (2018-11-08 12:11:05) > Quoting Mika Kuoppala (2018-11-08 12:00:39) > > Chris Wilson writes: > > > > > Ensure that the writes into the context image are completed prior to the > > > register mmio to trigger execution. Although previously we were assured > > > by the SDM that

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/execlists: Force write serialisation into context image vs execution

== Series Details == Series: drm/i915/execlists: Force write serialisation into context image vs execution URL : https://patchwork.freedesktop.org/series/52207/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5103 -> Patchwork_10768 = == Summary - WARNING == Minor

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/execlists: Force write serialisation into context image vs execution

== Series Details == Series: drm/i915/execlists: Force write serialisation into context image vs execution URL : https://patchwork.freedesktop.org/series/52207/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_5103 -> Patchwork_10768 = == Summary - FAILURE == Serious

Re: [Intel-gfx] [PATCH 1/3] drm/i915/execlists: Force write serialisation into context image vs execution

Quoting Mika Kuoppala (2018-11-08 12:13:42) > Chris Wilson writes: > > > Quoting Mika Kuoppala (2018-11-08 12:00:39) > >> Chris Wilson writes: > >> > + /* > >> > + * Make sure the context image is complete before we submit it to > >> > HW. > >> > + * > >> > + * Ostensibly,

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Remove HAS_FULL_PPGTT and device_info.ppgtt enum (v2)

://github.com/0day-ci/linux/commits/Bob-Paauwe/drm-i915-Make-48bit-full-ppgtt-configuration-generic-v9/20181108-104436 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: x86_64-allmodconfig (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: # save

Re: [Intel-gfx] [PATCH 1/3] drm/i915/execlists: Force write serialisation into context image vs execution

Chris Wilson writes: > Quoting Mika Kuoppala (2018-11-08 12:00:39) >> Chris Wilson writes: >> >> > Ensure that the writes into the context image are completed prior to the >> > register mmio to trigger execution. Although previously we were assured >> > by the SDM that all writes are flushed

Re: [Intel-gfx] [PATCH 1/3] drm/i915/execlists: Force write serialisation into context image vs execution

Quoting Mika Kuoppala (2018-11-08 12:00:39) > Chris Wilson writes: > > > Ensure that the writes into the context image are completed prior to the > > register mmio to trigger execution. Although previously we were assured > > by the SDM that all writes are flushed before an uncached memory > >

[Intel-gfx] ✗ Fi.CI.BAT: failure for Add XYUV format support (rev9)

== Series Details == Series: Add XYUV format support (rev9) URL : https://patchwork.freedesktop.org/series/48007/ State : failure == Summary == Applying: drm: Introduce new DRM_FORMAT_XYUV Using index info to reconstruct a base tree... M drivers/gpu/drm/drm_fourcc.c M

Re: [Intel-gfx] [PATCH 1/3] drm/i915/execlists: Force write serialisation into context image vs execution

Chris Wilson writes: > Ensure that the writes into the context image are completed prior to the > register mmio to trigger execution. Although previously we were assured > by the SDM that all writes are flushed before an uncached memory > transaction (our mmio write to submit the context to HW

[Intel-gfx] [PATCH v12 0/2] Add XYUV format support

Introduced new XYUV scan-in format for framebuffer and added support for it to i915(SkyLake+). Stanislav Lisovskiy (2): drm: Introduce new DRM_FORMAT_XYUV drm/i915: Adding YUV444 packed format support for skl+ drivers/gpu/drm/drm_fourcc.c | 1 + drivers/gpu/drm/i915/i915_reg.h

[Intel-gfx] [PATCH v12 1/2] drm: Introduce new DRM_FORMAT_XYUV

v5: This is YUV444 packed format same as AYUV, but without alpha, as supported by i915. v6: Removed unneeded initializer for new XYUV format. v7: Added is_yuv field initialization according to latest drm_fourcc format structure initialization changes. v8: Edited commit message to be

[Intel-gfx] [PATCH v12 2/2] drm/i915: Adding YUV444 packed format support for skl+

PLANE_CTL_FORMAT_AYUV is already supported, according to hardware specification. v2: Edited commit message, removed redundant whitespaces. v3: Fixed fallthrough logic for the format switch cases. v4: Yet again fixed fallthrough logic, to reuse code from other case labels. v5: Started to

Re: [Intel-gfx] [PATCH 12/14] drm/i915: Remove some useless zeroing on skl+ wm calculations

On Wed, Nov 07, 2018 at 02:11:10PM -0800, Rodrigo Vivi wrote: > > On Thu, Nov 01, 2018 at 05:06:03PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > We memset(0) the entire watermark struct the start, so there's no > > need to clear things later on. > > > > Signed-off-by: Ville

Re: [Intel-gfx] [PATCH 10/14] drm/i915: Pass the new crtc_state to ->disable_plane()

On Wed, Nov 07, 2018 at 02:08:43PM -0800, Rodrigo Vivi wrote: > On Thu, Nov 01, 2018 at 05:06:01PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > We're going to need access to the new crtc state in ->disable_plane() > > for SKL+ wm/ddb programming and pre-skl pipe gamma/csc control.

Re: [Intel-gfx] [PATCH 09/14] drm/i915: Introduce crtc_state->update_planes bitmask

On Wed, Nov 07, 2018 at 01:49:39PM -0800, Rodrigo Vivi wrote: > On Thu, Nov 01, 2018 at 05:06:00PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Keep track which planes need updating during the commit. For now this > > is just (was_visible || is_visible) but I'll have need to

Re: [Intel-gfx] [PATCH v2 0/7] Make GEN macros more similar

On 08/11/2018 00:57, Lucas De Marchi wrote: On Wed, Nov 07, 2018 at 10:05:19AM +, Tvrtko Ursulin wrote: On 06/11/2018 21:51, Lucas De Marchi wrote: This is the second version of the series trying to make GEN checks more similar. These or roughly the changes from v1: - We don't have a

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/13] locking/lockdep: restore cross-release checks (rev2)

== Series Details == Series: series starting with [01/13] locking/lockdep: restore cross-release checks (rev2) URL : https://patchwork.freedesktop.org/series/52167/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_5103 -> Patchwork_10772 = == Summary - FAILURE == Serious

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/13] locking/lockdep: restore cross-release checks (rev2)

== Series Details == Series: series starting with [01/13] locking/lockdep: restore cross-release checks (rev2) URL : https://patchwork.freedesktop.org/series/52167/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: locking/lockdep: restore cross-release

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/13] locking/lockdep: restore cross-release checks (rev2)

== Series Details == Series: series starting with [01/13] locking/lockdep: restore cross-release checks (rev2) URL : https://patchwork.freedesktop.org/series/52167/ State : warning == Summary == $ dim checkpatch origin/drm-tip d34529c13d64 locking/lockdep: restore cross-release checks -:9:

  1   2   >