[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Implement proper fallback training for MST (rev3)

== Series Details == Series: drm/i915: Implement proper fallback training for MST (rev3) URL : https://patchwork.freedesktop.org/series/41576/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4047_full -> Patchwork_8677_full = == Summary - WARNING == Minor unknown changes

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/edp: Only use alternate fixed mode when requested (rev2)

== Series Details == Series: drm/i915/edp: Only use alternate fixed mode when requested (rev2) URL : https://patchwork.freedesktop.org/series/41492/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4047_full -> Patchwork_8676_full = == Summary - FAILURE == Serious unknown

Re: [Intel-gfx] [PATCH 1/1] drm/i915: move audio component intialization before audio driver use it

>-Original Message- >From: Jani Nikula [mailto:jani.nik...@linux.intel.com] >Sent: Wednesday, April 11, 2018 8:25 PM >To: Shi, Yang A ; De Marchi, Lucas > >Cc: Chris Wilson ; intel-gfx@lists.freedesktop.org; >He, Bo

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Pack params to engine->schedule() into a struct (rev2)

== Series Details == Series: drm/i915: Pack params to engine->schedule() into a struct (rev2) URL : https://patchwork.freedesktop.org/series/41567/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4047_full -> Patchwork_8675_full = == Summary - WARNING == Minor unknown

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Implement proper fallback training for MST (rev2)

== Series Details == Series: drm/i915: Implement proper fallback training for MST (rev2) URL : https://patchwork.freedesktop.org/series/41576/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4047_full -> Patchwork_8674_full = == Summary - SUCCESS == No regressions found.

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Move a bunch of workaround-related code to its own file

Quoting Oscar Mateo (2018-04-10 17:24:42) > > > On 4/10/2018 9:16 AM, Chris Wilson wrote: > > Quoting Oscar Mateo (2018-04-10 17:12:46) > >> This has grown to be a sizable amount of code, so move it to > >> its own file before we try to refactor anything. For the moment, > >> we are leaving

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/2] drm/i915: Move a bunch of workaround-related code to its own file

== Series Details == Series: series starting with [CI,1/2] drm/i915: Move a bunch of workaround-related code to its own file URL : https://patchwork.freedesktop.org/series/41586/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4047_full -> Patchwork_8673_full = == Summary -

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Implement proper fallback training for MST (rev3)

== Series Details == Series: drm/i915: Implement proper fallback training for MST (rev3) URL : https://patchwork.freedesktop.org/series/41576/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4047 -> Patchwork_8677 = == Summary - SUCCESS == No regressions found.

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/edp: Only use alternate fixed mode when requested (rev2)

== Series Details == Series: drm/i915/edp: Only use alternate fixed mode when requested (rev2) URL : https://patchwork.freedesktop.org/series/41492/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4047 -> Patchwork_8676 = == Summary - SUCCESS == No regressions found.

[Intel-gfx] [PATCH v8 06/10] drm/dp_mst: Add reset_state callback to topology mgr

This gives drivers subclassing drm_dp_mst_topology_state the ability to prepare their topology states for a new hub to be connected whenever it's detected that the currently connected topology has been disconnected from the system. We'll need this in order to correctly track RX capabilities in

[Intel-gfx] [PATCH v8 02/10] drm/i915: Move DP modeset retry work into intel_dp

While having the modeset_retry_work in intel_connector makes sense with SST, this paradigm doesn't make a whole ton of sense when it comes to MST since we have to deal with multiple connectors. In most cases, it's more useful to just use the intel_dp struct since it indicates whether or not we're

[Intel-gfx] [PATCH v8 09/10] drm/dp_mst: Add MST fallback retraining helpers

Unlike SST, MST can have far more then a single display hooked up on a single port. What this also means however, is that if the DisplayPort link to the top-level MST branch device becomes unstable then every single branch device also has an unstable link. Additionally, MST has a few more steps

[Intel-gfx] [PATCH v8 03/10] drm/dp_mst: Fix naming on drm_atomic_get_mst_topology_state()

Since these functions are dealing with an atomic state that needs to be modified during atomic check and commit, change the naming on this function to drm_atomic_dp_mst_get_topology_state() since we're the only one using the function, and it's more consistent with the naming scheme used in

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Pack params to engine->schedule() into a struct (rev2)

== Series Details == Series: drm/i915: Pack params to engine->schedule() into a struct (rev2) URL : https://patchwork.freedesktop.org/series/41567/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4047 -> Patchwork_8675 = == Summary - SUCCESS == No regressions found.

[Intel-gfx] [PATCH v8 10/10] drm/i915: Implement proper fallback training for MST

For a while we actually haven't had any way of retraining MST links with fallback link parameters like we do with SST. While uncommon, certain setups such as my Caldigit TS3 + EVGA MST hub require this since otherwise, they end up getting stuck in an infinite MST retraining loop. MST retraining

[Intel-gfx] [PATCH v8 08/10] drm/i915: Make intel_dp_mst_atomic_check() idempotent

The current way of handling changing VCPI allocations doesn't make a whole ton of sense. Since drm_atomic_helper_check_modeset() can be called multiple times which means that intel_dp_mst_atomic_check() can also be called multiple times. However, since we make the silly mistake of trying to free

[Intel-gfx] [PATCH v8 05/10] drm/dp_mst: Make drm_dp_mst_topology_state subclassable

This is useful for drivers (which will probably be all of them soon) which need to track state that is exclusive to the topology, and not a specific connector on said topology. This includes things such as the link rate and lane count that are shared by all of the connectors on the topology.

[Intel-gfx] [PATCH v8 01/10] drm/atomic: Print debug message on atomic check failure

Does what it says on the label, it's a little confusing debugging atomic check failures otherwise. Cc: Manasi Navare Cc: Ville Syrjälä Signed-off-by: Lyude Paul --- drivers/gpu/drm/drm_atomic.c | 5 - 1 file

[Intel-gfx] [PATCH v8 04/10] drm/dp_mst: Remove all evil duplicate state pointers

There's no reason to track the atomic state three times. Unfortunately, this is currently what we're doing, and even worse is that there is only one actually correct state pointer: the one in mst_state->base.state. mgr->state never seems to be used, along with the one in mst_state->state. This

[Intel-gfx] [PATCH v8 07/10] drm/i915: Only use one link bw config for MST topologies

When a DP MST link needs retraining, sometimes the hub will detect that the current link bw config is impossible and will update it's RX caps in the DPCD to reflect the new maximum link rate. Currently, we make the assumption that the RX caps in the dpcd will never change like this. This means if

[Intel-gfx] [PATCH v8 00/10] drm/i915: Implement proper fallback training for MST

Next version of https://patchwork.freedesktop.org/series/41576/ Only changes are removing duplicate SoBs that git send-email annoyingly added. Sorry about that :( Lyude Paul (10): drm/atomic: Print debug message on atomic check failure drm/i915: Move DP modeset retry work into intel_dp

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Pack params to engine->schedule() into a struct (rev2)

== Series Details == Series: drm/i915: Pack params to engine->schedule() into a struct (rev2) URL : https://patchwork.freedesktop.org/series/41567/ State : warning == Summary == $ dim checkpatch origin/drm-tip 748e33a64fe4 drm/i915: Pack params to engine->schedule() into a struct -:337:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Implement proper fallback training for MST (rev2)

== Series Details == Series: drm/i915: Implement proper fallback training for MST (rev2) URL : https://patchwork.freedesktop.org/series/41576/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4047 -> Patchwork_8674 = == Summary - SUCCESS == No regressions found.

Re: [Intel-gfx] [PATCH] drm/i915/edp: Only use alternate fixed mode when requested

Quoting clinton.a.tay...@intel.com (2018-04-12 00:13:26) > From: Clint Taylor > > In commit dc911f5bd8aa ("drm/i915/edp: Allow alternate fixed mode for eDP > if available."), the patch was always selecting the alternate refresh rate > even though user space was asking

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Implement proper fallback training for MST (rev2)

== Series Details == Series: drm/i915: Implement proper fallback training for MST (rev2) URL : https://patchwork.freedesktop.org/series/41576/ State : warning == Summary == $ dim checkpatch origin/drm-tip b5a1cc33318b drm/atomic: Print debug message on atomic check failure 75ceb33d2660

[Intel-gfx] [PATCH] drm/i915/edp: Only use alternate fixed mode when requested

From: Clint Taylor In commit dc911f5bd8aa ("drm/i915/edp: Allow alternate fixed mode for eDP if available."), the patch was always selecting the alternate refresh rate even though user space was asking for the higher rate. This patch adds a check for vrefresh rate as

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Implement proper fallback training for MST

== Series Details == Series: drm/i915: Implement proper fallback training for MST URL : https://patchwork.freedesktop.org/series/41576/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4047_full -> Patchwork_8672_full = == Summary - WARNING == Minor unknown changes coming

[Intel-gfx] [PATCH v2] drm/i915: Pack params to engine->schedule() into a struct

Today we only want to pass along the priority to engine->schedule(), but in the future we want to have much more control over the various aspects of the GPU during a context's execution, for example controlling the frequency allowed. As we need an ever growing number of parameters for scheduling,

[Intel-gfx] [PATCH v7 07/10] drm/i915: Only use one link bw config for MST topologies

When a DP MST link needs retraining, sometimes the hub will detect that the current link bw config is impossible and will update it's RX caps in the DPCD to reflect the new maximum link rate. Currently, we make the assumption that the RX caps in the dpcd will never change like this. This means if

[Intel-gfx] [PATCH v7 06/10] drm/dp_mst: Add reset_state callback to topology mgr

This gives drivers subclassing drm_dp_mst_topology_state the ability to prepare their topology states for a new hub to be connected whenever it's detected that the currently connected topology has been disconnected from the system. We'll need this in order to correctly track RX capabilities in

[Intel-gfx] [PATCH v7 00/10] drm/i915: Implement proper fallback training for MST

Next version of https://patchwork.freedesktop.org/series/41576/ All changes in this patch series are just to make checkpatch a little happier, no functional changes. Lyude Paul (10): drm/atomic: Print debug message on atomic check failure drm/i915: Move DP modeset retry work into intel_dp

[Intel-gfx] [PATCH v7 02/10] drm/i915: Move DP modeset retry work into intel_dp

While having the modeset_retry_work in intel_connector makes sense with SST, this paradigm doesn't make a whole ton of sense when it comes to MST since we have to deal with multiple connectors. In most cases, it's more useful to just use the intel_dp struct since it indicates whether or not we're

[Intel-gfx] [PATCH v7 10/10] drm/i915: Implement proper fallback training for MST

For a while we actually haven't had any way of retraining MST links with fallback link parameters like we do with SST. While uncommon, certain setups such as my Caldigit TS3 + EVGA MST hub require this since otherwise, they end up getting stuck in an infinite MST retraining loop. MST retraining

[Intel-gfx] [PATCH v7 08/10] drm/i915: Make intel_dp_mst_atomic_check() idempotent

The current way of handling changing VCPI allocations doesn't make a whole ton of sense. Since drm_atomic_helper_check_modeset() can be called multiple times which means that intel_dp_mst_atomic_check() can also be called multiple times. However, since we make the silly mistake of trying to free

[Intel-gfx] [PATCH v7 09/10] drm/dp_mst: Add MST fallback retraining helpers

Unlike SST, MST can have far more then a single display hooked up on a single port. What this also means however, is that if the DisplayPort link to the top-level MST branch device becomes unstable then every single branch device also has an unstable link. Additionally, MST has a few more steps

[Intel-gfx] [PATCH v7 05/10] drm/dp_mst: Make drm_dp_mst_topology_state subclassable

This is useful for drivers (which will probably be all of them soon) which need to track state that is exclusive to the topology, and not a specific connector on said topology. This includes things such as the link rate and lane count that are shared by all of the connectors on the topology.

[Intel-gfx] [PATCH v7 03/10] drm/dp_mst: Fix naming on drm_atomic_get_mst_topology_state()

Since these functions are dealing with an atomic state that needs to be modified during atomic check and commit, change the naming on this function to drm_atomic_dp_mst_get_topology_state() since we're the only one using the function, and it's more consistent with the naming scheme used in

[Intel-gfx] [PATCH v7 04/10] drm/dp_mst: Remove all evil duplicate state pointers

There's no reason to track the atomic state three times. Unfortunately, this is currently what we're doing, and even worse is that there is only one actually correct state pointer: the one in mst_state->base.state. mgr->state never seems to be used, along with the one in mst_state->state. This

[Intel-gfx] [PATCH v7 01/10] drm/atomic: Print debug message on atomic check failure

Does what it says on the label, it's a little confusing debugging atomic check failures otherwise. Cc: Manasi Navare Cc: Ville Syrjälä Signed-off-by: Lyude Paul --- drivers/gpu/drm/drm_atomic.c | 5 - 1 file

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/psr: vbt change for psr (rev2)

== Series Details == Series: drm/i915/psr: vbt change for psr (rev2) URL : https://patchwork.freedesktop.org/series/41289/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4047_full -> Patchwork_8671_full = == Summary - WARNING == Minor unknown changes coming with

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915: Move a bunch of workaround-related code to its own file

== Series Details == Series: series starting with [CI,1/2] drm/i915: Move a bunch of workaround-related code to its own file URL : https://patchwork.freedesktop.org/series/41586/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4047 -> Patchwork_8673 = == Summary - SUCCESS

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/2] drm/i915: Move a bunch of workaround-related code to its own file

== Series Details == Series: series starting with [CI,1/2] drm/i915: Move a bunch of workaround-related code to its own file URL : https://patchwork.freedesktop.org/series/41586/ State : warning == Summary == $ dim checkpatch origin/drm-tip e95c3b723634 drm/i915: Move a bunch of

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Pack params to engine->schedule() into a struct

== Series Details == Series: drm/i915: Pack params to engine->schedule() into a struct URL : https://patchwork.freedesktop.org/series/41567/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4047_full -> Patchwork_8670_full = == Summary - FAILURE == Serious unknown changes

[Intel-gfx] [CI 2/2] drm/i915: Split out functions for different kinds of workarounds

From: Oscar Mateo There are different kind of workarounds (those that modify registers that live in the context image, those that modify global registers, those that whitelist registers, etc...) and they have different requirements in terms of where they are applied and

[Intel-gfx] [CI 1/2] drm/i915: Move a bunch of workaround-related code to its own file

From: Oscar Mateo This has grown to be a sizable amount of code, so move it to its own file before we try to refactor anything. For the moment, we are leaving behind the WA BB code and the WAs that get applied (incorrectly) in init_clock_gating, but we will deal with it

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Add Exec param to control data port coherency. (rev3)

== Series Details == Series: drm/i915: Add Exec param to control data port coherency. (rev3) URL : https://patchwork.freedesktop.org/series/40181/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4046_full -> Patchwork_8669_full = == Summary - FAILURE == Serious unknown

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Implement proper fallback training for MST

== Series Details == Series: drm/i915: Implement proper fallback training for MST URL : https://patchwork.freedesktop.org/series/41576/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4047 -> Patchwork_8672 = == Summary - SUCCESS == No regressions found. External URL:

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Implement proper fallback training for MST

== Series Details == Series: drm/i915: Implement proper fallback training for MST URL : https://patchwork.freedesktop.org/series/41576/ State : warning == Summary == $ dim checkpatch origin/drm-tip 79ee10fad03d drm/atomic: Print debug message on atomic check failure 1806094a081c drm/i915:

[Intel-gfx] [PATCH v6 09/10] drm/dp_mst: Add MST fallback retraining helpers

Unlike SST, MST can have far more then a single display hooked up on a single port. What this also means however, is that if the DisplayPort link to the top-level MST branch device becomes unstable then every single branch device also has an unstable link. Additionally, MST has a few more steps

[Intel-gfx] [PATCH v6 08/10] drm/i915: Make intel_dp_mst_atomic_check() idempotent

The current way of handling changing VCPI allocations doesn't make a whole ton of sense. Since drm_atomic_helper_check_modeset() can be called multiple times which means that intel_dp_mst_atomic_check() can also be called multiple times. However, since we make the silly mistake of trying to free

[Intel-gfx] [PATCH v6 10/10] drm/i915: Implement proper fallback training for MST

For a while we actually haven't had any way of retraining MST links with fallback link parameters like we do with SST. While uncommon, certain setups such as my Caldigit TS3 + EVGA MST hub require this since otherwise, they end up getting stuck in an infinite MST retraining loop. MST retraining

[Intel-gfx] [PATCH v6 07/10] drm/i915: Only use one link bw config for MST topologies

When a DP MST link needs retraining, sometimes the hub will detect that the current link bw config is impossible and will update it's RX caps in the DPCD to reflect the new maximum link rate. Currently, we make the assumption that the RX caps in the dpcd will never change like this. This means if

[Intel-gfx] [PATCH v6 06/10] drm/dp_mst: Add reset_state callback to topology mgr

This gives drivers subclassing drm_dp_mst_topology_state the ability to prepare their topology states for a new hub to be connected whenever it's detected that the currently connected topology has been disconnected from the system. We'll need this in order to correctly track RX capabilities in

[Intel-gfx] [PATCH v6 05/10] drm/dp_mst: Make drm_dp_mst_topology_state subclassable

This is useful for drivers (which will probably be all of them soon) which need to track state that is exclusive to the topology, and not a specific connector on said topology. This includes things such as the link rate and lane count that are shared by all of the connectors on the topology.

[Intel-gfx] [PATCH v6 04/10] drm/dp_mst: Remove all evil duplicate state pointers

There's no reason to track the atomic state three times. Unfortunately, this is currently what we're doing, and even worse is that there is only one actually correct state pointer: the one in mst_state->base.state. mgr->state never seems to be used, along with the one in mst_state->state. This

[Intel-gfx] [PATCH v6 02/10] drm/i915: Move DP modeset retry work into intel_dp

While having the modeset_retry_work in intel_connector makes sense with SST, this paradigm doesn't make a whole ton of sense when it comes to MST since we have to deal with multiple connectors. In most cases, it's more useful to just use the intel_dp struct since it indicates whether or not we're

[Intel-gfx] [PATCH v6 01/10] drm/atomic: Print debug message on atomic check failure

Does what it says on the label, it's a little confusing debugging atomic check failures otherwise. Cc: Manasi Navare Cc: Ville Syrjälä Signed-off-by: Lyude Paul --- drivers/gpu/drm/drm_atomic.c | 5 - 1 file

[Intel-gfx] [PATCH v6 03/10] drm/dp_mst: Fix naming on drm_atomic_get_mst_topology_state()

Since these functions are dealing with an atomic state that needs to be modified during atomic check and commit, change the naming on this function to drm_atomic_dp_mst_get_topology_state() since we're the only one using the function, and it's more consistent with the naming scheme used in

[Intel-gfx] [PATCH v6 00/10] drm/i915: Implement proper fallback training for MST

Latest version of PW series 39642, hopefully this should also actually come up on intel-gfx and go through CI. No changes other than rebasing to the current drm-intel-next-queued Lyude Paul (10): drm/atomic: Print debug message on atomic check failure drm/i915: Move DP modeset retry work

Re: [Intel-gfx] [PATCH] drm/i915/audio: Fix audio detection issue on GLK

On 4/10/2018 4:32 PM, Jani Nikula wrote: On Mon, 09 Apr 2018, "Kumar, Abhay" wrote: On 4/9/2018 4:20 PM, Pandiyan, Dhinakaran wrote: On Mon, 2018-04-09 at 12:18 -0700, Kumar, Abhay wrote: On 4/9/2018 12:10 PM, Rodrigo Vivi wrote: On Mon, Apr 09, 2018 at 05:07:31PM

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/psr: vbt change for psr (rev2)

== Series Details == Series: drm/i915/psr: vbt change for psr (rev2) URL : https://patchwork.freedesktop.org/series/41289/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4047 -> Patchwork_8671 = == Summary - SUCCESS == No regressions found. External URL:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Pack params to engine->schedule() into a struct

== Series Details == Series: drm/i915: Pack params to engine->schedule() into a struct URL : https://patchwork.freedesktop.org/series/41567/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4047 -> Patchwork_8670 = == Summary - SUCCESS == No regressions found. External

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Pack params to engine->schedule() into a struct

== Series Details == Series: drm/i915: Pack params to engine->schedule() into a struct URL : https://patchwork.freedesktop.org/series/41567/ State : warning == Summary == $ dim checkpatch origin/drm-tip 203e77ff5941 drm/i915: Pack params to engine->schedule() into a struct -:309:

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/2] drm/i915/bios: filter out invalid DDC pins from VBT child devices

== Series Details == Series: series starting with [v2,1/2] drm/i915/bios: filter out invalid DDC pins from VBT child devices URL : https://patchwork.freedesktop.org/series/41547/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4046_full -> Patchwork_8668_full = == Summary -

Re: [Intel-gfx] [PATCH] drm/i915/psr: enable psr1 on psr2 panels

On Wed, 2018-04-11 at 07:40 -0700, Rodrigo Vivi wrote: > On Wed, Apr 11, 2018 at 03:01:24PM +0530, vathsala nagaraju wrote: > > > > + puthik > > On Saturday 07 April 2018 12:36 AM, Vivi, Rodrigo wrote: > > > On Fri, Apr 06, 2018 at 12:10:24PM -0700, Dhinakaran Pandiyan wrote: > > > > > > > >

[Intel-gfx] [PATCH] drm/i915/psr: vbt change for psr

From: Vathsala Nagaraju For psr block #9, the vbt description has moved to options [0-3] for TP1,TP2,TP3 Wakeup time from decimal value without any change to vbt structure. Since spec does not mention from which VBT version this change was added to vbt.bsf file, we

[Intel-gfx] [PATCH] drm/i915: Pack params to engine->schedule() into a struct

Today we only want to pass along the priority to engine->schedule(), but in the future we want to have much more control over the various aspects of the GPU during a context's execution, for example controlling the frequency allowed. As we need an ever growing number of parameters for scheduling,

Re: [Intel-gfx] [PATCH 0/9] GPU-bound energy efficiency improvements for the intel_pstate driver.

Francisco Jerez writes: > Hi Srinivas, > > Srinivas Pandruvada writes: > >> On Tue, 2018-04-10 at 15:28 -0700, Francisco Jerez wrote: >>> Francisco Jerez writes: >>> >> [...] >> >> >>> For the case anyone is

Re: [Intel-gfx] [RFC v2] drm/i915: Engine discovery query

Looks good to me, a few nits below. I'll try to find some time to display this information in gputop. Reviewed-by: Lionel Landwerlin On 11/04/18 02:46, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Engine discovery query allows userspace

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add Exec param to control data port coherency. (rev3)

== Series Details == Series: drm/i915: Add Exec param to control data port coherency. (rev3) URL : https://patchwork.freedesktop.org/series/40181/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4046 -> Patchwork_8669 = == Summary - WARNING == Minor unknown changes coming

Re: [Intel-gfx] [PATCH 0/9] GPU-bound energy efficiency improvements for the intel_pstate driver.

Hi Srinivas, Srinivas Pandruvada writes: > On Tue, 2018-04-10 at 15:28 -0700, Francisco Jerez wrote: >> Francisco Jerez writes: >> > [...] > > >> For the case anyone is wondering what's going on, Srinivas pointed me >> at >> a larger

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/selftests: Wait for idle between idle resets as well

== Series Details == Series: drm/i915/selftests: Wait for idle between idle resets as well URL : https://patchwork.freedesktop.org/series/41543/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4045_full -> Patchwork_8667_full = == Summary - FAILURE == Serious unknown

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Add Exec param to control data port coherency. (rev3)

== Series Details == Series: drm/i915: Add Exec param to control data port coherency. (rev3) URL : https://patchwork.freedesktop.org/series/40181/ State : warning == Summary == $ dim checkpatch origin/drm-tip bcf7786e9207 drm/i915: Add Exec param to control data port coherency. -:14:

[Intel-gfx] [PATCH v2] drm/i915: Add Exec param to control data port coherency.

The patch adds a parameter to control the data port coherency functionality on a per-exec call basis. When data port coherency flag value is different than what it was in previous call for the context, a command to switch data port coherency state is added before the buffer to be executed.

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/execlists: Set queue priority from secondary port (rev3)

== Series Details == Series: drm/i915/execlists: Set queue priority from secondary port (rev3) URL : https://patchwork.freedesktop.org/series/40869/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4045_full -> Patchwork_8666_full = == Summary - WARNING == Minor unknown

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915/bios: filter out invalid DDC pins from VBT child devices

== Series Details == Series: series starting with [v2,1/2] drm/i915/bios: filter out invalid DDC pins from VBT child devices URL : https://patchwork.freedesktop.org/series/41547/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4046 -> Patchwork_8668 = == Summary - SUCCESS

Re: [Intel-gfx] [PATCH] drm/i915/psr: enable psr1 on psr2 panels

On Wed, Apr 11, 2018 at 03:01:24PM +0530, vathsala nagaraju wrote: > > + puthik > On Saturday 07 April 2018 12:36 AM, Vivi, Rodrigo wrote: > > On Fri, Apr 06, 2018 at 12:10:24PM -0700, Dhinakaran Pandiyan wrote: > > > > > > > > > On Sat, 2018-04-07 at 00:12 +0530, vathsala nagaraju wrote: > > >

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/2] drm/i915/bios: filter out invalid DDC pins from VBT child devices

== Series Details == Series: series starting with [v2,1/2] drm/i915/bios: filter out invalid DDC pins from VBT child devices URL : https://patchwork.freedesktop.org/series/41547/ State : warning == Summary == $ dim checkpatch origin/drm-tip c57f8a17744e drm/i915/bios: filter out invalid DDC

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

Hi Dave, I misspoke yesterday when I said we were up-to-date. I have this patch from Tomi to fix a regression in omap. drm-misc-next-fixes-2018-04-11: omap: Fix crash on AM4 EVM, and all OMAP2/3 boards (Tomi) Cc: Tomi Valkeinen Cheers, Sean The following changes

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Add Wa_2201832410

Rodrigo Vivi writes: > "Clock gating bug in GWL may not clear barrier state when an EOT > is received, causing a hang the next time that barrier is used." > > HSDES: 2201832410 > A bit late here but do we have a preference of going like the above or, References:

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Engine discovery query (rev2)

== Series Details == Series: drm/i915: Engine discovery query (rev2) URL : https://patchwork.freedesktop.org/series/39958/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4044_full -> Patchwork_8665_full = == Summary - SUCCESS == No regressions found. External URL:

Re: [Intel-gfx] [PATCH i-g-t v4] tests/perf_pmu: Avoid RT thread for accuracy test

On 11/04/2018 14:23, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-04-04 10:51:52) From: Tvrtko Ursulin Realtime scheduling interferes with execlists submission (tasklet) so try to simplify the PWM loop in a few ways: * Drop RT. * Longer batches for smaller

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Wait for idle between idle resets as well

== Series Details == Series: drm/i915/selftests: Wait for idle between idle resets as well URL : https://patchwork.freedesktop.org/series/41543/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4045 -> Patchwork_8667 = == Summary - WARNING == Minor unknown changes coming

Re: [Intel-gfx] [PATCH i-g-t v4] tests/perf_pmu: Avoid RT thread for accuracy test

Quoting Tvrtko Ursulin (2018-04-04 10:51:52) > From: Tvrtko Ursulin > > Realtime scheduling interferes with execlists submission (tasklet) so try > to simplify the PWM loop in a few ways: > > * Drop RT. > * Longer batches for smaller systematic error. > * More

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/bios: reduce the scope of some local variables in parse_ddi_port()

Quoting Jani Nikula (2018-04-11 14:15:19) > No functional changes. > > Cc: Chris Wilson > Signed-off-by: Jani Nikula > --- > drivers/gpu/drm/i915/intel_bios.c | 10 -- > 1 file changed, 4 insertions(+), 6 deletions(-) > > diff --git

[Intel-gfx] [PATCH v2 2/2] drm/i915/bios: reduce the scope of some local variables in parse_ddi_port()

No functional changes. Cc: Chris Wilson Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_bios.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_bios.c

[Intel-gfx] [PATCH v2 1/2] drm/i915/bios: filter out invalid DDC pins from VBT child devices

The VBT contains the DDC pin to use for specific ports. Alas, sometimes the field appears to contain bogus data, and while we check for it later on in intel_gmbus_get_adapter() we fail to check the returned NULL on errors. Oops results. The simplest approach seems to be to catch and ignore the

Re: [Intel-gfx] [PATCH] drm/i915/bios: remove duplicated code

On Tue, 10 Apr 2018, Paulo Zanoni wrote: > Em Ter, 2018-04-10 às 12:12 +0300, Jani Nikula escreveu: >> Apparently caused by a merge fail at some point. Due to the nature of >> the duplicated block, the second one will have no effect, and there's >> no >> need to

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/selftests: Wait for idle between idle resets as well

== Series Details == Series: drm/i915/selftests: Wait for idle between idle resets as well URL : https://patchwork.freedesktop.org/series/41543/ State : warning == Summary == $ dim checkpatch origin/drm-tip b63ecede2893 drm/i915/selftests: Wait for idle between idle resets as well -:17:

Re: [Intel-gfx] [PATCH] drm/i915/bios: filter out invalid DDC pins from VBT child devices

Quoting Jani Nikula (2018-04-11 13:53:09) > On Wed, 11 Apr 2018, Chris Wilson wrote: > > Quoting Jani Nikula (2018-04-11 10:01:46) > >> diff --git a/drivers/gpu/drm/i915/intel_bios.c > >> b/drivers/gpu/drm/i915/intel_bios.c > >> index c5c7530ba157..6db845991a69 100644 >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/execlists: Set queue priority from secondary port (rev3)

== Series Details == Series: drm/i915/execlists: Set queue priority from secondary port (rev3) URL : https://patchwork.freedesktop.org/series/40869/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4045 -> Patchwork_8666 = == Summary - SUCCESS == No regressions found.

Re: [Intel-gfx] [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

On 11 April 2018 at 22:27, Jani Nikula wrote: > On Wed, 11 Apr 2018, Ian W MORRISON wrote: >> >> >>> >>> NAK on indiscriminate Cc: stable. There are zero guarantees that older >>> kernels will work with whatever firmware you throw at them.

Re: [Intel-gfx] [PATCH] drm/i915/bios: filter out invalid DDC pins from VBT child devices

On Wed, 11 Apr 2018, Chris Wilson wrote: > Quoting Jani Nikula (2018-04-11 10:01:46) >> diff --git a/drivers/gpu/drm/i915/intel_bios.c >> b/drivers/gpu/drm/i915/intel_bios.c >> index c5c7530ba157..6db845991a69 100644 >> --- a/drivers/gpu/drm/i915/intel_bios.c >> +++

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/execlists: Set queue priority from secondary port (rev3)

== Series Details == Series: drm/i915/execlists: Set queue priority from secondary port (rev3) URL : https://patchwork.freedesktop.org/series/40869/ State : warning == Summary == $ dim checkpatch origin/drm-tip 7aa8f3485832 drm/i915/execlists: Set queue priority from secondary port -:28:

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [RESEND,1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

== Series Details == Series: series starting with [RESEND,1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake URL : https://patchwork.freedesktop.org/series/41533/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4043_full -> Patchwork_8664_full = == Summary - WARNING ==

Re: [Intel-gfx] [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

On Wed, 11 Apr 2018, Ian W MORRISON wrote: > > >> >> NAK on indiscriminate Cc: stable. There are zero guarantees that older >> kernels will work with whatever firmware you throw at them. >> > > I included 'Cc: stable' so the patch would get added to the v4.16 and > v4.15

Re: [Intel-gfx] [PATCH 1/1] drm/i915: move audio component intialization before audio driver use it

On Wed, 11 Apr 2018, "Shi, Yang A" wrote: > This issue is not related to request_module. When issue happened, > request_module get i915 Correctly and return 0 successfully. It just > be caused by acomp->ops is null in function snd_hdac_i915_init after > it called

Re: [Intel-gfx] [PATCH] drm/i915/bios: filter out invalid DDC pins from VBT child devices

Quoting Jani Nikula (2018-04-11 10:01:46) > The VBT contains the DDC pin to use for specific ports. Alas, sometimes > the field appears to contain bogus data, and while we check for it later > on in intel_gmbus_get_adapter() we fail to check the returned NULL on > errors. Oops results. > > The

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/bios: filter out invalid DDC pins from VBT child devices

== Series Details == Series: drm/i915/bios: filter out invalid DDC pins from VBT child devices URL : https://patchwork.freedesktop.org/series/41531/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4043_full -> Patchwork_8663_full = == Summary - WARNING == Minor unknown

[Intel-gfx] [PATCH] drm/i915/selftests: Wait for idle between idle resets as well

Even though we weren't injecting guilty requests to be reset, we could still fall over the issue of resetting the same request too fast -- where the GPU refuses to start again. (Although it is interesting to note that reloading the driver is sufficient, suggesting that we could recover if we

  1   2   >