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

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 for execution), we have

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Switch LSPCON to PCON mode if it's in LS mode

== Series Details == Series: drm/i915: Switch LSPCON to PCON mode if it's in LS mode URL : https://patchwork.freedesktop.org/series/52178/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5099_full -> Patchwork_10756_full = == Summary - SUCCESS == No regressions found.

[Intel-gfx] ✓ Fi.CI.IGT: success for drm: Check if primary mst is null

== Series Details == Series: drm: Check if primary mst is null URL : https://patchwork.freedesktop.org/series/52174/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5098_full -> Patchwork_10755_full = == Summary - WARNING == Minor unknown changes coming with

[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_5103 -> Patchwork_10767 = == Summary - FAILURE == Serious unknown changes

[Intel-gfx] ✓ Fi.CI.BAT: 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 -> Patchwork_10766 = == Summary - SUCCESS == No regressions found. External

[Intel-gfx] ✗ Fi.CI.SPARSE: warning 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 : 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] ✗ Fi.CI.CHECKPATCH: warning 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 : warning == Summary == $ dim checkpatch origin/drm-tip f6235622662a drm/dp_mst: Add some atomic state iterator macros -:7: WARNING:COMMIT_MESSAGE:

[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_5103 -> Patchwork_10765 = == Summary - WARNING

[Intel-gfx] ✓ Fi.CI.BAT: 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 -> Patchwork_10764 = == Summary - WARNING ==

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v6,1/2] drm/i915/skl: Rework MOCS tables to keep common part in a define

== Series Details == Series: series starting with [v6,1/2] drm/i915/skl: Rework MOCS tables to keep common part in a define URL : https://patchwork.freedesktop.org/series/52165/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5097_full -> Patchwork_10753_full = == Summary -

[Intel-gfx] [PATCH v4 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 v4 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 v4 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.BAT: 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 -> Patchwork_10763 = == Summary - SUCCESS == No

[Intel-gfx] [PATCH v4 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 v4 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 v4 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] ✗ Fi.CI.BAT: failure 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 : failure == Summary == = CI Bug Log - changes from CI_DRM_5103 -> Patchwork_10762 = == Summary - FAILURE

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

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 single macro receiving 2 or 3

[Intel-gfx] ✓ Fi.CI.BAT: 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 -> Patchwork_10761 = == Summary - SUCCESS ==

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v5,1/2] drm/i915/skl: Rework MOCS tables to keep common part in a define

== Series Details == Series: series starting with [v5,1/2] drm/i915/skl: Rework MOCS tables to keep common part in a define URL : https://patchwork.freedesktop.org/series/52108/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5097_full -> Patchwork_10752_full = == Summary -

[Intel-gfx] ✗ Fi.CI.SPARSE: warning 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 : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/icl: Release TC

[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_5103 -> Patchwork_10760 = == Summary - FAILURE == Serious unknown changes

[Intel-gfx] [PATCH 2/2] drm/edid: Parse manufacturer id only once per sink

It was parsing the manufacturer id of the sink for each entry in quirk list. Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/drm_edid.c | 21 - 1 file changed, 4 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c

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

This function will be helpful to drivers that wants to add its own quirks to sinks. Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/drm_edid.c | 20 include/drm/drm_edid.h | 1 + 2 files changed, 17 insertions(+), 4 deletions(-) diff --git

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

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 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

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

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

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

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 --- drivers/gpu/drm/i915/i915_drv.c | 19 +++ 1 file changed, 7 insertions(+), 12 deletions(-) diff

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

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 will help make easy disable features that depends in display being enabled in

[Intel-gfx] [PATCH 2/3] drm/i915: Call intel_hpd_cancel_work() from intel_hpd_suspend()

intel_hpd_suspend() was added to have a more generic function to handle all the sequences needed when hotplug detection will be suspended, so lets call intel_hpd_cancel_work() from intel_hpd_suspend() and make it static. Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/i915_drv.c

[Intel-gfx] [PATCH 3/3] drm/i915/icl: Delay hotplug processing for tc ports

Some USB type-C dongles requires some time to power on before being able to process aux channel transactions. It was not a problem for older gens because there was a bridge between DP port and USB-C controller adding some delay but ICL handles type-C native. So here trying to do a aux channel

[Intel-gfx] [PATCH 1/3] drm/i915/icl: Release TC ports when unloading or suspending driver

When suspending or unloading the driver, it needs to release the TC ports so HW can change it state without wait for driver handshake. Cc: Imre Deak Cc: Ville Syrjälä Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/i915_drv.c | 1 + drivers/gpu/drm/i915/i915_drv.h |

[Intel-gfx] [PATCH v3 2/3] drm/i915: Release DDI power well references in MST ports

MST ports did not had the post_pll_disable() hook causing the references get in pre_pll_enable() never being released causing DDI and AUX CH being enabled all the times. v2: renamed intel_mst_post_pll_disable_dp() parameters Reviewed-by: Ville Syrjälä Reviewed-by: Imre Deak Cc: Imre Deak Cc:

[Intel-gfx] [PATCH v3 1/3] drm/i915: Reuse the aux_domain cached

intel_dp_detect() caches the aux_domain in the beginning of the function as it is used twice, so lets also use it as the aux_domain don't change in runtime. v3: returning intel_dp_retrain_link() error insted of connector_status_disconnected Cc: Imre Deak Reviewed-by: Imre Deak Reviewed-by:

[Intel-gfx] [PATCH v3 3/3] drm/i915/mst: Drop pre_pll_enable null check

MST is only supported in DDI ports that have this hook, so the null check can be dropped. Suggested-by: Imre Deak Cc: Imre Deak Reviewed-by: Rodrigo Vivi Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/intel_dp_mst.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff

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

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915: Handle -EDEADLK from ironlake_check_fdi_lanes()

== Series Details == Series: series starting with [1/3] drm/i915: Handle -EDEADLK from ironlake_check_fdi_lanes() URL : https://patchwork.freedesktop.org/series/52191/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_5103 -> Patchwork_10759 = == Summary - FAILURE ==

Re: [Intel-gfx] [v7 1/4] i915/dp/fec: Add fec_enable to the crtc state.

>-Original Message- >From: Navare, Manasi D >Sent: Tuesday, November 6, 2018 6:40 PM >To: Srivatsa, Anusha >Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Ville >Syrjala >; Jani Nikula >Subject: Re: [v7 1/4] i915/dp/fec: Add fec_enable to the crtc state. > >On

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

On Wed, 2018-11-07 at 22:59 +0100, Daniel Vetter wrote: > On Wed, Nov 07, 2018 at 04:39:57PM -0500, Lyude Paul wrote: > > On Wed, 2018-11-07 at 16:23 -0500, Lyude Paul wrote: > > > On Wed, 2018-11-07 at 21:59 +0100, Daniel Vetter wrote: > > > > On Tue, Nov 06, 2018 at 08:21:14PM -0500, Lyude Paul

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915: Handle -EDEADLK from ironlake_check_fdi_lanes()

== Series Details == Series: series starting with [1/3] drm/i915: Handle -EDEADLK from ironlake_check_fdi_lanes() URL : https://patchwork.freedesktop.org/series/52191/ State : warning == Summary == $ dim checkpatch origin/drm-tip 9c3a2b626b3e drm/i915: Handle -EDEADLK from

Re: [Intel-gfx] [PATCH v8 07/19] drm/i915/dp: Compute DSC pipe config in atomic check

On Tue, Nov 06, 2018 at 12:37:59PM -0800, Manasi Navare wrote: > On Tue, Nov 06, 2018 at 04:42:56PM +0200, Ville Syrjälä wrote: > > On Fri, Nov 02, 2018 at 07:09:03PM -0700, Manasi Navare wrote: > > > On Fri, Nov 02, 2018 at 02:31:26PM -0700, Manasi Navare wrote: > > > > DSC params like the

[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

[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 1/3] drm/i915: Make 48bit full ppgtt configuration generic (v9)

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

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Handle -EDEADLK from ironlake_check_fdi_lanes()

On Wed, Nov 07, 2018 at 11:35:20PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > ironlake_check_fdi_lanes() may try to grab some extra crtc locks. > If that fails we need to propagate the -EDEADLK all the way up, > and we shouldn't dump out the crtc state or other debug messages > either

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/dp_mst: Add some atomic state iterator macros

== Series Details == Series: drm/dp_mst: Add some atomic state iterator macros URL : https://patchwork.freedesktop.org/series/52130/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5097_full -> Patchwork_10749_full = == Summary - WARNING == Minor unknown changes coming

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

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 Syrjälä > --- > drivers/gpu/drm/i915/intel_pm.c | 20 +--- > 1

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

1;5202;0cOn 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ä Reviewed-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/intel_pm.c |

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

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

On Wed, Nov 07, 2018 at 04:39:57PM -0500, Lyude Paul wrote: > On Wed, 2018-11-07 at 16:23 -0500, Lyude Paul wrote: > > On Wed, 2018-11-07 at 21:59 +0100, Daniel Vetter wrote: > > > On Tue, Nov 06, 2018 at 08:21:14PM -0500, Lyude Paul wrote: > > > > There has been a TODO waiting for quite a long

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 > invisible planes later on for skl plane ddbs and for pre-skl pipe >

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

On Wed, 2018-11-07 at 16:23 -0500, Lyude Paul wrote: > On Wed, 2018-11-07 at 21:59 +0100, Daniel Vetter wrote: > > On Tue, Nov 06, 2018 at 08:21:14PM -0500, Lyude Paul wrote: > > > There has been a TODO waiting for quite a long time in > > > drm_dp_mst_topology.c: > > > > > > /* We cannot rely

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

On Wed, Nov 07, 2018 at 01:26:18PM -0800, Rodrigo Vivi wrote: > On Thu, Nov 01, 2018 at 05:05:57PM +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] [PATCH 1/3] drm/i915: Handle -EDEADLK from ironlake_check_fdi_lanes()

From: Ville Syrjälä ironlake_check_fdi_lanes() may try to grab some extra crtc locks. If that fails we need to propagate the -EDEADLK all the way up, and we shouldn't dump out the crtc state or other debug messages either since it wasn't the crtc state that caused the failure. Just hit this on

[Intel-gfx] [PATCH 3/3] drm/i915: Clean up the baseline bpp computation

From: Ville Syrjälä Pass on the errno all the way from connected_sink_max_bpp(), and make the base_bpp handling in intel_modeset_pipe_config() a bit less ugly. We'll also rename connected_sink_max_bpp() to not give the impression that it return the bpp value, and we'll pimp up the debug message

[Intel-gfx] [PATCH 2/3] drm/i915: Remove pointless goto fail

From: Ville Syrjälä We just 'return ret' immediately after jumping to the label. Let's return directly instead. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 21 + 1 file changed, 9 insertions(+), 12 deletions(-) diff --git

Re: [Intel-gfx] [PATCH 08/14] drm/i915: Generalize skl_ddb_allocation_overlaps()

On Thu, Nov 01, 2018 at 05:05:59PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Make skl_ddb_allocation_overlaps() useful for other callers > besides skl_update_crtcs(). We'll need it to do plane updates > as well. > > And while we're here we can reduce the stack utilization a > bit by

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

On Thu, Nov 01, 2018 at 05:05:57PM +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 >

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.BAT: failure for series starting with [1/2] drm/i915/ddi: Add more sanity check to the encoder HW readout

On Wed, Nov 07, 2018 at 08:39:24PM +, Patchwork wrote: > == 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 : failure > > == Summary == > > = CI Bug

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

On Wed, 2018-11-07 at 21:59 +0100, Daniel Vetter wrote: > On Tue, Nov 06, 2018 at 08:21:14PM -0500, Lyude Paul wrote: > > 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 > > *

[Intel-gfx] ✓ Fi.CI.IGT: success for Make GEN macros more similar (rev2)

== Series Details == Series: Make GEN macros more similar (rev2) URL : https://patchwork.freedesktop.org/series/51860/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5097_full -> Patchwork_10747_full = == Summary - WARNING == Minor unknown changes coming with

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

On Tue, Nov 06, 2018 at 08:21:14PM -0500, Lyude Paul wrote: > 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 >*

Re: [Intel-gfx] [PATCH 04/14] drm/i915: Polish the skl+ plane keyval/msk/max register setup

On Wed, Nov 07, 2018 at 11:55:27AM -0800, Rodrigo Vivi wrote: > On Thu, Nov 01, 2018 at 05:05:55PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Due to the constant alpha we're going to have to program two of > > the the tree keying registers anyway, so might as well always > >

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

Hi Dave, First fixes pull for 4.20, some NULL protection for sun4i. drm-misc-fixes-2018-11-07: - sun4i: tcon->panel NULL deref protections (Giulio) Cc: Giulio Benetti Cheers, Sean The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a: Linux 4.20-rc1 (2018-11-04

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

On Wed, Nov 07, 2018 at 09:31:51PM +0100, Daniel Vetter wrote: > On Wed, Nov 7, 2018 at 9:29 PM Sean Paul wrote: > > > > On Wed, Nov 07, 2018 at 09:18:16PM +0100, Daniel Vetter wrote: > > > On Wed, Nov 07, 2018 at 12:58:56PM +0100, Maarten Lankhorst wrote: > > > > Hey Dave, > > > > > > > > First

Re: [Intel-gfx] [PATCH v2 5/5] drm/i915/icl: Fix port B combo PHY context loss after DC transitions

On Tue, 2018-11-06 at 18:06 +0200, Imre Deak wrote: > On ICL DMC/PCODE retains the HW context only for port A across DC > transitions, for the other port B combo PHY, it doesn't. So we need > to > do this manually after exiting from DC6. Do the reinit even after > exiting from DC5, it won't hurt

Re: [Intel-gfx] [PATCH v2 3/5] drm/i915/cnl+: Verify combo PHY HW state during PHY uninit

On Tue, 2018-11-06 at 18:06 +0200, Imre Deak wrote: > Verify on CNL, ICL that the combo PHY HW state stayed intact after > PHY > initialization. > > v2: > - Print 'Port X' as we do elsewhere instead of 'Port-X'. (Jose) > > Cc: Paulo Zanoni > Cc: Ville Syrjälä Reviewed-by: José Roberto de

Re: [Intel-gfx] [PATCH v2 2/5] drm/i915/cnl+: Move the combo PHY init/uninit code to a new file

On Tue, 2018-11-06 at 18:06 +0200, Imre Deak wrote: > Similarly to the GEN9_LP DPIO PHY code keep the CNL+ combo PHY code > in a > separate file. > > No functional change. > > v2: > - Use SPDX license tag instead of boilerplate. (Rodrigo) > > Suggested-by: Ville Syrjälä > Cc: Paulo Zanoni >

[Intel-gfx] ✗ Fi.CI.BAT: failure 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 : failure == Summary == = CI Bug Log - changes from CI_DRM_5100 -> Patchwork_10758 = == Summary - FAILURE ==

Re: [Intel-gfx] [PATCH v2 1/5] drm/i915/icl: Fix combo PHY uninit

On Tue, 2018-11-06 at 18:06 +0200, Imre Deak wrote: > BSpec says to clear the comp init HW flag too during combo PHY > uninit, > so do that. The lack of this could badly interact with the PHY reinit > after a DC6/9 transition at least, where (after a follow-up patch > fixing > the init code) we'd

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/icl: Fix power well 2 wrt. DC-off toggling order

On Fri, Nov 02, 2018 at 11:54:51PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/icl: Fix power well 2 wrt. DC-off toggling order > URL : https://patchwork.freedesktop.org/series/51971/ > State : success Thanks for the review, pushed to -dinq. > > == Summary == > > =

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

On Wed, Nov 7, 2018 at 9:29 PM Sean Paul wrote: > > On Wed, Nov 07, 2018 at 09:18:16PM +0100, Daniel Vetter wrote: > > On Wed, Nov 07, 2018 at 12:58:56PM +0100, Maarten Lankhorst wrote: > > > Hey Dave, > > > > > > First pull for drm-next this cycle. There's been a lot of changes, so I > > > hope

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

On Wed, Nov 07, 2018 at 09:18:16PM +0100, Daniel Vetter wrote: > On Wed, Nov 07, 2018 at 12:58:56PM +0100, Maarten Lankhorst wrote: > > Hey Dave, > > > > First pull for drm-next this cycle. There's been a lot of changes, so I > > hope I recorded everything from the changelog correctly. > > > >

[Intel-gfx] [PATCH 1/2] drm/i915/ddi: Add more sanity check to the encoder HW readout

Check for reserved register field values and conflicting transcoder->port mappings (both MST and non-MST mappings or multiple SST mappings). This is also needed for the next patch to determine if a port is in MST mode during sanitization after HW readout. Cc: Paulo Zanoni Cc: Ville Syrjälä Cc:

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

On Wed, Nov 07, 2018 at 12:58:56PM +0100, Maarten Lankhorst wrote: > Hey Dave, > > First pull for drm-next this cycle. There's been a lot of changes, so I > hope I recorded everything from the changelog correctly. > > drm-misc-next-2018-11-07: > drm-misc-next for v4.21, part 1: > > UAPI

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

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 in SST mode) whose active state determines if

Re: [Intel-gfx] [PATCH 05/14] drm/i915: Clean up skl+ PLANE_POS vs. scaler handling

On Thu, Nov 01, 2018 at 05:05:56PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > On skl+ the scaler (when enabled) will take care of the plane output > position. Make the code less ugly by just setting crtc_x/y to 0 > when the scaler is enabled. > > Signed-off-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH 04/14] drm/i915: Polish the skl+ plane keyval/msk/max register setup

On Thu, Nov 01, 2018 at 05:05:55PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Due to the constant alpha we're going to have to program two of > the the tree keying registers anyway, so might as well always > program all three. > > And parametrize the plane constant alpha define while

Re: [Intel-gfx] [PATCH] drm: Check if primary mst is null

Thanks for noticing this one! With the changes that Ville mentioned in their response: Reviewed-by: Lyude Paul If you need me to push this for you; poke me here or on IRC On Wed, 2018-11-07 at 18:11 +0200, Stanislav Lisovskiy wrote: > Unfortunately drm_dp_get_mst_branch_device which is called

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Program SKL+ watermarks/ddb more carefully (rev6)

== Series Details == Series: drm/i915: Program SKL+ watermarks/ddb more carefully (rev6) URL : https://patchwork.freedesktop.org/series/51878/ State : failure == Summary == Applying: drm/i915: Nuke posting reads from plane update/disable funcs error: sha1 information is lacking or useless

Re: [Intel-gfx] [PATCH 03/14] drm/i915: Remove the PS_PWR_GATE write from skl_program_scaler()

On Thu, Nov 01, 2018 at 05:05:54PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > If we don't need the PS_PWR_GATE write when programming the > pipe scaler I don't see why we'd need it for plane scalers either. > Just remove it. > > Signed-off-by: Ville Syrjälä Reviewed-by: Rodrigo

Re: [Intel-gfx] [PATCH v5 5/5] drm/i915: Add short HPD IRQ storm detection for non-MST systems

On Tue, Nov 06, 2018 at 04:30:16PM -0500, Lyude Paul wrote: > Unfortunately, it seems that the HPD IRQ storm problem from the early > days of Intel GPUs was never entirely solved, only mostly. Within the > last couple of days, I got a bug report from one of our customers who > had been having

Re: [Intel-gfx] [PATCH] drm/i915/icl: Fix power well 2 wrt. DC-off toggling order

On Fri, Nov 02, 2018 at 08:22:00PM +0200, Imre Deak wrote: > To enable DC5/6 power well 2 has to be disabled as for previous > platforms, so fix things up. > > Bspec: 4234 > Fixes: 67ca07e7ac10 ("drm/i915/icl: Add power well support") > Cc: Animesh Manna > Cc: Paulo Zanoni > Cc: Ville Syrjälä

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: HPD IRQ storm detection fixes (rev5)

== Series Details == Series: drm/i915: HPD IRQ storm detection fixes (rev5) URL : https://patchwork.freedesktop.org/series/51556/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5096_full -> Patchwork_10746_full = == Summary - WARNING == Minor unknown changes coming with

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

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 arm the wm/ddb change as well. To avoid all the problems with that let's

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

From: Ville Syrjälä We memset(0) the entire watermark struct the start, so there's no need to clear things later on. v2: Rebase due to some stale w/a removal Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_pm.c | 16 1 file changed, 4 insertions(+), 12

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

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 - tileoff/linoff/offset/aux_offset are self-arming as well so we want them

[Intel-gfx] [PATCH v2 04/14] drm/i915: Polish the skl+ plane keyval/msk/max register setup

From: Ville Syrjälä Due to the constant alpha we're going to have to program two of the the tree keying registers anyway, so might as well always program all three. And parametrize the plane constant alpha define while at it. v2: Rebase due to input CSC Signed-off-by: Ville Syrjälä ---

Re: [Intel-gfx] [PATCH v2 02/14] drm/i915: Clean up skl_program_scaler()

On Thu, Nov 01, 2018 at 11:13:50AM -0700, Rodrigo Vivi wrote: > On Thu, Nov 01, 2018 at 05:17:36PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Remove the "sizes are 0 based" stuff that is not even true for the > > scaler. > > > > v2: Rebase > > > > Signed-off-by: Ville Syrjälä

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Switch LSPCON to PCON mode if it's in LS mode

== Series Details == Series: drm/i915: Switch LSPCON to PCON mode if it's in LS mode URL : https://patchwork.freedesktop.org/series/52178/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5099 -> Patchwork_10756 = == Summary - SUCCESS == No regressions found. External

Re: [Intel-gfx] [PATCH v14 1/2] drm: Add connector property to limit max bpc

On 11/7/18 1:10 PM, Rodrigo Vivi wrote: > On Wed, Nov 07, 2018 at 04:56:00PM +, Kazlauskas, Nicholas wrote: >> On 10/24/18 6:49 PM, Rodrigo Vivi wrote: >>> On Fri, Oct 12, 2018 at 11:42:32AM -0700, Radhakrishna Sripada wrote: At times 12bpc HDMI cannot be driven due to faulty cables,

Re: [Intel-gfx] [PATCH v14 1/2] drm: Add connector property to limit max bpc

On Wed, Nov 07, 2018 at 04:56:00PM +, Kazlauskas, Nicholas wrote: > On 10/24/18 6:49 PM, Rodrigo Vivi wrote: > > On Fri, Oct 12, 2018 at 11:42:32AM -0700, Radhakrishna Sripada wrote: > >> At times 12bpc HDMI cannot be driven due to faulty cables, dongles > >> level shifters etc. To workaround

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/atomic: Use explicit old crtc state in drm_atomic_add_affected_planes() (rev2)

== Series Details == Series: series starting with [1/3] drm/atomic: Use explicit old crtc state in drm_atomic_add_affected_planes() (rev2) URL : https://patchwork.freedesktop.org/series/51894/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5096_full -> Patchwork_10745_full

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Check if primary mst is null

== Series Details == Series: drm: Check if primary mst is null URL : https://patchwork.freedesktop.org/series/52174/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5098 -> Patchwork_10755 = == Summary - SUCCESS == No regressions found. External URL:

[Intel-gfx] [PATCH] drm/i915: Switch LSPCON to PCON mode if it's in LS mode

From: Ville Syrjälä We no longer change LSPCON into PCON mode if it boots up in LS mode. This was broken by some code shuffling in commit 96e35598cead ("drm/i915: Check LSPCON vendor OUI"). I actually can't see a reason why that code shuffling had to be done. The commit msg notes it but doesn't

Re: [Intel-gfx] [PATCH] drm: Check if primary mst is null

On Wed, Nov 07, 2018 at 06:11:30PM +0200, Stanislav Lisovskiy wrote: > Unfortunately drm_dp_get_mst_branch_device which is called from both > drm_dp_mst_handle_down_rep and drm_dp_mst_handle_up_rep seem to rely > on that mgr->mst_primary is not NULL, which seem to be wrong as it can be > cleared

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: Check if primary mst is null

== Series Details == Series: drm: Check if primary mst is null URL : https://patchwork.freedesktop.org/series/52174/ State : warning == Summary == $ dim checkpatch origin/drm-tip f8a61b5fe3ea drm: Check if primary mst is null -:10: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit

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

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

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

== Series Details == Series: series starting with [01/13] locking/lockdep: restore cross-release checks 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 checks

  1   2   >