On Wed, 2018-04-11 at 09:26 -0700, Francisco Jerez wrote:
>
> "just like" here is possibly somewhat unfair to the schedutil
> governor,
> admittedly its progressive IOWAIT boosting behavior seems somewhat
> less
> wasteful than the intel_pstate non-HWP governor's IOWAIT boosting
> behavior, but it
== 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 c
== 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 c
>-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
>; Deak, Imre
>Subject: RE: [Intel-gfx] [PATCH 1/1] drm/i915: move audio
== 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 chan
== 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.
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 behin
== 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 -
== 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.
External
== 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.
Ex
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 i915
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 d
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 tha
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 drm_atom
== 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.
Ext
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 is
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 VC
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 changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic.c
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 con
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.
Signe
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 t
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
drm/
== 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: WARNIN
== 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.
External
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 for the higher rate. This pa
== 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 drm/i91
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 well as the rest of the mode
== 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 w
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, m
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 t
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 i915
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
d
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 d
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 is
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 tha
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 VC
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.
Signe
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 drm_atom
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 con
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 changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic.c
== 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 Patchwork
== 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 ==
== 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 workaround-re
== 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 c
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 how. Also, by splitting th
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 later.
v2: Use intel_ pre
== 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 cha
== 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: h
== 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: Move
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 tha
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 VC
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 is
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 t
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 i915
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.
Signe
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 con
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 d
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 changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic.c
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 drm_atom
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 into
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 +0300, Jani Nikula wrote
== 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: https://intel-
== 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 U
== 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: WARNING:FILE_
== 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 -
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:
> > > >
> > > >
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 cannot depend on bdb->version
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, m
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 wondering what's going on, Srinivas pointed me
>>> at
>>> a larger idle power usage in
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 to enumerate engines, probe their
configuration features,
== 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
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 idle power usage increase off-list, ultimately caused by the
== 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 chang
== 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: WARNING:C
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.
Rationa
== 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 cha
== 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 ==
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:
> > >
== 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 p
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 since commit 8cd1b5bd70cccda
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: HSDES#2201832410
?
-Mika
> Cc
== 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: http
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 systematic error.
* More
== 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 wi
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 truthful test duration calculati
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 a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/
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
b/drivers/gpu/drm/i915/intel_bios.c
index 447b721c3be9..036307af8419 100644
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 bog
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 backport.
>>
>> Signed-off-by: Jan
== 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: WARNIN
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
> >> --- a/drivers/gpu/drm/i
== 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.
Ex
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.
>>>
>>
>> I included 'Cc: stable' so the patch would get
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
>> +++ b/drivers/gpu/drm/i915/intel_b
== 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: WARNI
== 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 ==
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 kernels which I have test
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 Component_master_add_with_match.
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 sim
== 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 cha
1 - 100 of 146 matches
Mail list logo
