On Mon, Apr 09, 2018 at 03:11:38PM -0700, Kumar, Abhay wrote:
>
>
> On 4/9/2018 3:33 AM, Ville Syrjälä wrote:
> > On Fri, Apr 06, 2018 at 04:47:08PM +0300, Jani Nikula wrote:
> >> On Thu, 05 Apr 2018, Abhay Kumar wrote:
> >>> In glk when device boots with 1366x768 panel, HDA codec doesn't comeup
On Tue, Apr 10, 2018 at 08:00:10PM -0700, Kumar, Abhay wrote:
>
>
> On 4/10/2018 1:49 AM, Nikula, Jani wrote:
> > On Tue, 10 Apr 2018, Jani Nikula wrote:
> >> On Mon, 09 Apr 2018, "Kumar, Abhay" wrote:
> >>> Dynamic cdclk is disabled in BIOS/GOP hence gop makes it to highest
> >>> clock i.e 316
>-Original Message-
>From: De Marchi, Lucas
>Sent: Wednesday, April 11, 2018 9:37 AM
>To: Jani Nikula
>Cc: Shi, Yang A ; Chris Wilson
>;
>intel-gfx@lists.freedesktop.org; He, Bo ; Deak, Imre
>
>Subject: Re: [Intel-gfx] [PATCH 1/1] drm/i915: move audio component
>intialization
>before aud
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
> low-latency heuristic as discussed in the paragraph
On 4/10/2018 1:49 AM, Nikula, Jani wrote:
On Tue, 10 Apr 2018, Jani Nikula wrote:
On Mon, 09 Apr 2018, "Kumar, Abhay" wrote:
Dynamic cdclk is disabled in BIOS/GOP hence gop makes it to highest
clock i.e 316.8. Will attach logs with drm debug enabled in bug.
I am also inclined towards 192 wh
> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Tuesday, April 10, 2018 12:53 PM
> To: Srinivas, Vidya ; intel-
> g...@lists.freedesktop.org
> Cc: Kamath, Sunil
> Subject: Re: [Intel-gfx] [PATCH v1 00/14] Preparation patches for NV12
>
>
>-Original Message-
>From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>Sent: Tuesday, April 10, 2018 6:57 PM
>To: Shi, Yang A ; Chris Wilson
>;
>intel-gfx@lists.freedesktop.org
>Cc: He, Bo ; De Marchi, Lucas
>Subject: RE: [Intel-gfx] [PATCH 1/1] drm/i915: move audio component
>inti
On Tue, Apr 10, 2018 at 10:58:28AM -0300, Jani Nikula wrote:
> On Tue, 10 Apr 2018, Jani Nikula wrote:
> > On Tue, 10 Apr 2018, "Shi, Yang A" wrote:
> >>>On Tue, 10 Apr 2018, "Shi, Yang A" wrote:
> issue: snd_soc_skl meet "failed to add i915 component master (-19)"
> when platform don'
On Fri, 2018-04-06 at 22:03 +0100, Chris Wilson wrote:
> Quoting José Roberto de Souza (2018-04-06 21:53:49)
> > A simple page flip can cause the CFB required size to increase and
> > if it is bigger than the currently allocated CFB it needs to be
> > resized to activate FBC again.
>
> I would hav
Francisco Jerez writes:
> This series attempts to solve an energy efficiency problem of the
> current active-mode non-HWP governor of the intel_pstate driver used
> for the most part on low-power platforms. Under heavy IO load the
> current controller tends to increase frequencies to the maximum
Quoting Chris Wilson (2018-04-10 12:14:17)
> %phn is not a valid specifier, and the trailing 'n' is being eaten by
> the format-specifier and defaulting to the ' ' separator. Avoid angering
> smatch by using the unknown specifier, and use the default we expect.
>
> drivers/gpu/drm/i915/intel_guc_c
Em Ter, 2018-04-10 às 22:01 +0100, Chris Wilson escreveu:
> Quoting Paulo Zanoni (2018-04-10 21:39:31)
> > Em Ter, 2018-04-10 às 09:51 +0100, Chris Wilson escreveu:
> > > Quoting Paulo Zanoni (2018-03-23 17:24:16)
> > > > From: Manasi Navare
> > > >
> > > > This table is used for voltage swing pr
Em Ter, 2018-04-10 às 22:07 +0100, Chris Wilson escreveu:
> Quoting Chris Wilson (2018-04-10 22:01:33)
> > Quoting Paulo Zanoni (2018-04-10 21:39:31)
> > > Em Ter, 2018-04-10 às 09:51 +0100, Chris Wilson escreveu:
> > > > Quoting Paulo Zanoni (2018-03-23 17:24:16)
> > > > > From: Manasi Navare
> >
Quoting Chris Wilson (2018-04-10 22:01:33)
> Quoting Paulo Zanoni (2018-04-10 21:39:31)
> > Em Ter, 2018-04-10 às 09:51 +0100, Chris Wilson escreveu:
> > > Quoting Paulo Zanoni (2018-03-23 17:24:16)
> > > > From: Manasi Navare
> > > >
> > > > This table is used for voltage swing programming seque
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: Jani Nikula
Reviewed-by: Paulo Zanoni
> ---
> dr
Quoting Paulo Zanoni (2018-04-10 21:39:31)
> Em Ter, 2018-04-10 às 09:51 +0100, Chris Wilson escreveu:
> > Quoting Paulo Zanoni (2018-03-23 17:24:16)
> > > From: Manasi Navare
> > >
> > > This table is used for voltage swing programming sequence during
> > > DDI
> > > Buffer initialization for MG
== Series Details ==
Series: drm/i915/edp: Only use alternate fixed mode when requested
URL : https://patchwork.freedesktop.org/series/41492/
State : warning
== Summary ==
= CI Bug Log - changes from CI_DRM_4041_full -> Patchwork_8661_full =
== Summary - WARNING ==
Minor unknown changes co
Em Ter, 2018-04-10 às 09:51 +0100, Chris Wilson escreveu:
> Quoting Paulo Zanoni (2018-03-23 17:24:16)
> > From: Manasi Navare
> >
> > This table is used for voltage swing programming sequence during
> > DDI
> > Buffer initialization for MG PHY DDI Buffers on Icelake.
>
> Except it is not used a
Quoting clinton.a.tay...@intel.com (2018-04-10 19:33:36)
> 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: series starting with [1/2] drm/i915: Move a bunch of workaround-related
code to its own file
URL : https://patchwork.freedesktop.org/series/41491/
State : warning
== Summary ==
= CI Bug Log - changes from CI_DRM_4041_full -> Patchwork_8660_full =
== Summary - WAR
== Series Details ==
Series: series starting with [1/2] drm/i915: Move a bunch of workaround-related
code to its own file
URL : https://patchwork.freedesktop.org/series/41486/
State : warning
== Summary ==
= CI Bug Log - changes from CI_DRM_4041_full -> Patchwork_8659_full =
== Summary - WAR
== Series Details ==
Series: drm/i915/edp: Only use alternate fixed mode when requested
URL : https://patchwork.freedesktop.org/series/41492/
State : warning
== Summary ==
Series 41492v1 drm/i915/edp: Only use alternate fixed mode when requested
https://patchwork.freedesktop.org/api/1.0/series
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
On Tue, 2018-04-10 at 10:59 -0700, Rodrigo Vivi wrote:
> On Tue, Apr 10, 2018 at 12:49:25AM -, Patchwork wrote:
> > == Series Details ==
> >
> > Series: series starting with [v4] drm/i915: Enable edp psr error interrupts
> > on hsw (rev3)
> > URL : https://patchwork.freedesktop.org/serie
On Tue, Apr 10, 2018 at 12:00:26PM +0100, Chris Wilson wrote:
> Quoting Rodrigo Vivi (2018-04-09 20:14:32)
> > On Sat, Apr 07, 2018 at 10:05:25AM +0100, Chris Wilson wrote:
> > > Quoting Rodrigo Vivi (2018-04-06 23:18:16)
> > > > On Fri, Apr 06, 2018 at 11:12:27AM -0700, Souza, Jose wrote:
> > > >
On Tue, Apr 10, 2018 at 12:49:25AM -, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [v4] drm/i915: Enable edp psr error interrupts
> on hsw (rev3)
> URL : https://patchwork.freedesktop.org/series/41095/
> State : warning
>
> == Summary ==
>
> $ dim checkpatch or
== Series Details ==
Series: series starting with [1/2] drm/i915: Move a bunch of workaround-related
code to its own file
URL : https://patchwork.freedesktop.org/series/41491/
State : success
== Summary ==
Series 41491v1 series starting with [1/2] drm/i915: Move a bunch of
workaround-related
== Series Details ==
Series: series starting with [1/2] drm/i915: Move a bunch of workaround-related
code to its own file
URL : https://patchwork.freedesktop.org/series/41491/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
18b0bd9fdeb1 drm/i915: Move a bunch of workaround-relat
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 them apart, it should
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_ prefix for code that de
== Series Details ==
Series: series starting with [1/2] drm/i915: Move a bunch of workaround-related
code to its own file
URL : https://patchwork.freedesktop.org/series/41486/
State : success
== Summary ==
Series 41486v1 series starting with [1/2] drm/i915: Move a bunch of
workaround-related
== Series Details ==
Series: series starting with [1/2] drm/i915: Move a bunch of workaround-related
code to its own file
URL : https://patchwork.freedesktop.org/series/41486/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Move a bunch of workaround-related code t
== Series Details ==
Series: series starting with [1/2] drm/i915: Move a bunch of workaround-related
code to its own file
URL : https://patchwork.freedesktop.org/series/41486/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8044c5a3e8e3 drm/i915: Move a bunch of workaround-relat
Hello,
any news about this patch? The bug is rotting here:
https://bugs.freedesktop.org/show_bug.cgi?id=105468
On Monday 12 March 2018 08:25:34 Jani Nikula wrote:
> On Fri, 09 Mar 2018, Ondrej Zary wrote:
> > Radiant P845 does not have LVDS, only VGA.
>
> Hi, thanks for the patch. Would you mind
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 behind the WA BB code and the WAs that get applied
(incorrectly) in i
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 behind the WA BB code and the WAs that get applied
> (incorrectly) in init_clock_gating, but we will deal with
Quoting Patchwork (2018-04-10 16:46:06)
> == Series Details ==
>
> Series: drm/i915: Don't fiddle with rps/rc6 across GPU reset
> URL : https://patchwork.freedesktop.org/series/41474/
> State : warning
>
> == Summary ==
>
> = CI Bug Log - changes from CI_DRM_4040_full -> Patchwork_8657_full =
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 them apart, it should
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_ prefix for code that de
Hi All,
I see the latest BAT test failed but the only thing I changed in this
new patchset is comment. It should be false alarm, not sure if this is
halting the further review. Please see if the code needs more change.
Thanks,
Yunwei
On 3/29/2018 8:44 AM, Yunwei Zhang wrote:
WaProgramMgsr
== Series Details ==
Series: drm/i915: Don't fiddle with rps/rc6 across GPU reset
URL : https://patchwork.freedesktop.org/series/41474/
State : warning
== Summary ==
= CI Bug Log - changes from CI_DRM_4040_full -> Patchwork_8657_full =
== Summary - WARNING ==
Minor unknown changes coming w
== Series Details ==
Series: drm/i915: Replace use of pipe_crc->lock with an atomic
URL : https://patchwork.freedesktop.org/series/41485/
State : failure
== Summary ==
Applying: drm/i915: Replace use of pipe_crc->lock with an atomic
error: sha1 information is lacking or useless (drivers/gpu/dr
pipe_crc->lock only protects pipe_crc->skipped. Replace the lock with
atomic operations instead, it should work just as well, without the
spinlock. In the case we don't skip CRC in the irq, the fastpath is
only a single atomic_read().
Signed-off-by: Maarten Lankhorst
Cc: Ville Syrjälä
---
drive
Quoting Chris Wilson (2018-04-10 15:56:03)
> Quoting Tvrtko Ursulin (2018-04-10 15:42:07)
> >
> > On 10/04/2018 15:24, Chris Wilson wrote:
> > > Quoting Tvrtko Ursulin (2018-04-10 15:05:33)
> > >> Although I failed to understand what do we do in both cases if a new
> > >> request arrives of higher
Tvrtko Ursulin writes:
> On 09/04/2018 18:03, Scott D Phillips wrote:
>> Tvrtko Ursulin writes:
>>
>>> From: Tvrtko Ursulin
>>>
>>> Back to a clean build with no warnings, at least for me.
>>
>> Why c90? If that's the language we mean to target then we should
>> probably add it to the build s
Quoting Tvrtko Ursulin (2018-04-10 15:42:07)
>
> On 10/04/2018 15:24, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-04-10 15:05:33)
> >>
> >> On 09/04/2018 12:13, Chris Wilson wrote:
> >>> We can refine our current execlists->queue_priority if we inspect
> >>> ELSP[1] rather than the head o
On 10/04/2018 15:24, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-04-10 15:05:33)
On 09/04/2018 12:13, Chris Wilson wrote:
We can refine our current execlists->queue_priority if we inspect
ELSP[1] rather than the head of the unsubmitted queue. Currently, we use
the unsubmitted queue and s
Op 09-04-18 om 21:48 schreef Rodrigo Vivi:
> On Wed, Mar 28, 2018 at 06:20:26PM +0200, Maarten Lankhorst wrote:
>> Op 28-03-18 om 12:21 schreef Jani Nikula:
>>> On Wed, 28 Mar 2018, Maarten Lankhorst
>>> wrote:
Adding a i915_fifo_underrun_reset debugfs file will make it possible
for IGT
== Series Details ==
Series: drm/i915/gvt: fix memory leak of a cmd_entry struct on error exit path
URL : https://patchwork.freedesktop.org/series/41469/
State : warning
== Summary ==
= CI Bug Log - changes from CI_DRM_4040_full -> Patchwork_8656_full =
== Summary - WARNING ==
Minor unknow
Quoting Tvrtko Ursulin (2018-04-10 15:05:33)
>
> On 09/04/2018 12:13, Chris Wilson wrote:
> > We can refine our current execlists->queue_priority if we inspect
> > ELSP[1] rather than the head of the unsubmitted queue. Currently, we use
> > the unsubmitted queue and say that if a subsequent reques
== Series Details ==
Series: drm/i915: Don't fiddle with rps/rc6 across GPU reset
URL : https://patchwork.freedesktop.org/series/41474/
State : success
== Summary ==
Series 41474v1 drm/i915: Don't fiddle with rps/rc6 across GPU reset
https://patchwork.freedesktop.org/api/1.0/series/41474/revis
On 09/04/2018 12:13, Chris Wilson wrote:
We can refine our current execlists->queue_priority if we inspect
ELSP[1] rather than the head of the unsubmitted queue. Currently, we use
the unsubmitted queue and say that if a subsequent request is more than
important than the current queue, we will re
On Tue, 10 Apr 2018, Jani Nikula wrote:
> On Tue, 10 Apr 2018, "Shi, Yang A" wrote:
>>>On Tue, 10 Apr 2018, "Shi, Yang A" wrote:
issue: snd_soc_skl meet "failed to add i915 component master (-19)"
when platform don't connect any display output.
i915 do initialization before t
== Series Details ==
Series: drm/i915/pmu: Inspect runtime PM state more carefully while estimating
RC6 (rev3)
URL : https://patchwork.freedesktop.org/series/41453/
State : warning
== Summary ==
= CI Bug Log - changes from CI_DRM_4040_full -> Patchwork_8655_full =
== Summary - WARNING ==
Resetting the GPU doesn't affect the RPS/RC6 state, so we can stop
forcibly reloading the registers.
Ville suggested this many moons ago, I said at that time that sanitizing
was no harm and meant that our bookkeeping was kept consistent with the
HW. However, in a forthcoming series, we want to spl
== Series Details ==
Series: drm/i915/gvt: fix memory leak of a cmd_entry struct on error exit path
URL : https://patchwork.freedesktop.org/series/41469/
State : success
== Summary ==
Series 41469v1 drm/i915/gvt: fix memory leak of a cmd_entry struct on error
exit path
https://patchwork.freed
== Series Details ==
Series: drm/i915/guc: Replace %phn with %phN (rev2)
URL : https://patchwork.freedesktop.org/series/41452/
State : warning
== Summary ==
= CI Bug Log - changes from CI_DRM_4040_full -> Patchwork_8654_full =
== Summary - WARNING ==
Minor unknown changes coming with Patch
Quoting Colin King (2018-04-10 13:33:12)
> From: Colin Ian King
>
> The error exit path when a duplicate is found does not kfree and cmd_entry
> struct and hence there is a small memory leak. Fix this by kfree'ing it.
>
> Detected by CoverityScan, CID#1370198 ("Resource Leak")
>
> Fixes: be1da
== Series Details ==
Series: drm/i915/pmu: Inspect runtime PM state more carefully while estimating
RC6 (rev3)
URL : https://patchwork.freedesktop.org/series/41453/
State : success
== Summary ==
Series 41453v3 drm/i915/pmu: Inspect runtime PM state more carefully while
estimating RC6
https:/
Quoting Sagar Arun Kamble (2018-03-19 09:51:08)
>
>
> On 3/14/2018 3:07 PM, Chris Wilson wrote:
> > @@ -757,8 +767,10 @@ static void guc_submission_tasklet(unsigned long data)
> >
> > rq = port_request(&port[0]);
> > }
> > - if (!rq)
> > + if (!rq) {
> >
Quoting Sagar Arun Kamble (2018-03-17 15:10:08)
>
>
> On 3/14/2018 3:07 PM, Chris Wilson wrote:
> > When choosing the initial frequency in intel_gt_pm_busy() we also need
> > to calculate the current min/max bounds. As this calculation is going to
> > become more complex with the intersection of
On Tue, 10 Apr 2018, Yang wrote:
> From: Yang Shi
>
> issue: snd_soc_skl meet "failed to add i915 component master (-19)" when
> platform don't connect any display output.
>
> i915 do initialization before than skl_probe, but if there is no display
> output connect, in function drm_dp_dpcd_access
Quoting Sagar Arun Kamble (2018-03-16 14:28:27)
>
>
> On 3/14/2018 3:07 PM, Chris Wilson wrote:
> > void intel_gt_pm_irq_handler(struct drm_i915_private *dev_priv, u32
> > pm_iir)
> > {
> > struct intel_rps *rps = &dev_priv->gt_pm.rps;
> >
> > - if (pm_iir & rps->pm_events) {
>
Quoting Sagar Arun Kamble (2018-03-16 14:01:22)
>
>
> On 3/14/2018 3:07 PM, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index b9c7b21e5cc8..8a5bf1e26515 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i
Quoting Sagar Arun Kamble (2018-03-16 13:03:03)
>
>
> On 3/16/2018 2:22 PM, Sagar Arun Kamble wrote:
> >
> >
> > On 3/14/2018 3:07 PM, Chris Wilson wrote:
> >> Allow ourselves to individually toggle rps or rc6. This will be used
> >> later when we want to enable rps/rc6 at different phases during
From: Colin Ian King
The error exit path when a duplicate is found does not kfree and cmd_entry
struct and hence there is a small memory leak. Fix this by kfree'ing it.
Detected by CoverityScan, CID#1370198 ("Resource Leak")
Fixes: be1da7070aea ("drm/i915/gvt: vGPU command scanner")
Signed-off
== Series Details ==
Series: drm/i915/guc: Replace %phn with %phN (rev2)
URL : https://patchwork.freedesktop.org/series/41452/
State : success
== Summary ==
Series 41452v2 drm/i915/guc: Replace %phn with %phN
https://patchwork.freedesktop.org/api/1.0/series/41452/revisions/2/mbox/
Possib
From: Tvrtko Ursulin
While thinking about sporadic failures of perf_pmu/rc6-runtime-pm* tests
on some CI machines I have concluded that: a) the PMU readout of RC6 can
race against runtime PM transitions, and b) there are other reasons than
being runtime suspended which can cause intel_runtime_pm_
%phn is not a valid specifier, and the trailing 'n' is being eaten by
the format-specifier and defaulting to the ' ' separator. Avoid angering
smatch by using the unknown specifier, and use the default we expect.
drivers/gpu/drm/i915/intel_guc_ct.c:616 ctb_read() warn: '%ph' cannot be
followed by
== Series Details ==
Series: drm/i915/guc: Replace %phn with %phN
URL : https://patchwork.freedesktop.org/series/41452/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4038_full -> Patchwork_8652_full =
== Summary - SUCCESS ==
No regressions found, the changes are of accep
Quoting Michal Wajdeczko (2018-04-10 11:57:03)
> On Tue, 10 Apr 2018 11:14:35 +0200, Chris Wilson
> wrote:
>
> > %phn is not a valid specifier,
>
> Well, implementation allows that as alias for default separator ;)
>
> switch (fmt[1]) {
> case 'C':
> separator
== Series Details ==
Series: drm/i915/guc: Replace %phn with %phN
URL : https://patchwork.freedesktop.org/series/41452/
State : failure
== Summary ==
Possible new issues:
Test kms_frontbuffer_tracking:
Subgroup fbc-rgb565-draw-mmap-gtt:
pass -> FAIL (s
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:
> On Sun, 08 Apr 2018, G
Quoting Rodrigo Vivi (2018-04-09 20:14:32)
> On Sat, Apr 07, 2018 at 10:05:25AM +0100, Chris Wilson wrote:
> > Quoting Rodrigo Vivi (2018-04-06 23:18:16)
> > > On Fri, Apr 06, 2018 at 11:12:27AM -0700, Souza, Jose wrote:
> > > > On Thu, 2018-04-05 at 12:49 +0100, Chris Wilson wrote:
> > > > > +
On Tue, 10 Apr 2018 11:14:35 +0200, Chris Wilson
wrote:
%phn is not a valid specifier,
Well, implementation allows that as alias for default separator ;)
switch (fmt[1]) {
case 'C':
separator = ':';
break;
case 'D':
se
On Tue, 10 Apr 2018, "Shi, Yang A" wrote:
>>On Tue, 10 Apr 2018, "Shi, Yang A" wrote:
>>> issue: snd_soc_skl meet "failed to add i915 component master (-19)"
>>> when platform don't connect any display output.
>>>
>>> i915 do initialization before than skl_probe, but if there is no
>>> display ou
On 10/04/2018 11:34, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-04-10 11:22:55)
On 10/04/2018 10:57, Chris Wilson wrote:
But I'm not understanding the failure -- why is the estimate bad? At the
very least we still ensure that it is monotonic? Is it just the jitter
you are worrying about
Quoting Tvrtko Ursulin (2018-04-10 11:34:40)
> From: Tvrtko Ursulin
>
> While thinking about sporadic failures of perf_pmu/rc6-runtime-pm* tests
> on some CI machines I have concluded that: a) the PMU readout of RC6 can
> race against runtime PM transitions, and b) there are other reasons than
>
== Series Details ==
Series: drm/i915/bios: remove duplicated code
URL : https://patchwork.freedesktop.org/series/41448/
State : warning
== Summary ==
= CI Bug Log - changes from CI_DRM_4038_full -> Patchwork_8651_full =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_8
From: Tvrtko Ursulin
While thinking about sporadic failures of perf_pmu/rc6-runtime-pm* tests
on some CI machines I have concluded that: a) the PMU readout of RC6 can
race against runtime PM transitions, and b) there are other reasons than
being runtime suspended which can cause intel_runtime_pm_
Quoting Tvrtko Ursulin (2018-04-10 11:22:55)
>
> On 10/04/2018 10:57, Chris Wilson wrote:
> > But I'm not understanding the failure -- why is the estimate bad? At the
> > very least we still ensure that it is monotonic? Is it just the jitter
> > you are worrying about? (If the estimate is bad here
Quoting Souza, Jose (2018-04-06 19:12:27)
> On Thu, 2018-04-05 at 12:49 +0100, Chris Wilson wrote:
> > Inside the psr work function, we want to wait for PSR to idle first
> > and
> > wish to do so without blocking the normal modeset path, so we do so
> > without holding the PSR lock. However, we fi
== Series Details ==
Series: drm/i915/bios: remove duplicated code
URL : https://patchwork.freedesktop.org/series/41448/
State : success
== Summary ==
Known issues:
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-varying-size:
pass -> FAIL (shard-hsw)
On 10/04/2018 10:57, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-04-10 10:23:28)
From: Tvrtko Ursulin
While thinking about sporadic failures of perf_pmu/rc6-runtime-pm* tests
on some CI machines I have concluded that: a) the PMU readout of RC6 can
race against runtime PM transitions, and
On Mon, Apr 09, 2018 at 04:17:43PM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/gen9_lp: Increase DDI PHY0 power well enabling timeout
> URL : https://patchwork.freedesktop.org/series/41366/
> State : success
Pushed to -dinq, thanks for the review.
>
> == Summary ==
>
== Series Details ==
Series: drm/i915/pmu: Inspect runtime PM state more carefully while estimating
RC6
URL : https://patchwork.freedesktop.org/series/41453/
State : warning
== Summary ==
Series 41453v1 drm/i915/pmu: Inspect runtime PM state more carefully while
estimating RC6
https://patchw
== Series Details ==
Series: drm/i915/guc: Replace %phn with %phN
URL : https://patchwork.freedesktop.org/series/41452/
State : success
== Summary ==
Series 41452v1 drm/i915/guc: Replace %phn with %phN
https://patchwork.freedesktop.org/api/1.0/series/41452/revisions/1/mbox/
Known issues:
Quoting Tvrtko Ursulin (2018-04-10 10:23:28)
> From: Tvrtko Ursulin
>
> While thinking about sporadic failures of perf_pmu/rc6-runtime-pm* tests
> on some CI machines I have concluded that: a) the PMU readout of RC6 can
> race against runtime PM transitions, and b) there are other reasons than
>
== Series Details ==
Series: drm/i915/bios: remove duplicated code
URL : https://patchwork.freedesktop.org/series/41448/
State : success
== Summary ==
Series 41448v1 drm/i915/bios: remove duplicated code
https://patchwork.freedesktop.org/api/1.0/series/41448/revisions/1/mbox/
Known issue
Quoting Chris Wilson (2018-04-09 15:49:22)
> Quoting Michal Wajdeczko (2018-04-09 15:08:40)
> > On Mon, 09 Apr 2018 14:42:19 +0200, Chris Wilson
> > wrote:
> >
> > > Our execlists emulation for GuC requires use of the breadcrumb following
> > > every request as a simulcrum for the context-switc
From: Tvrtko Ursulin
While thinking about sporadic failures of perf_pmu/rc6-runtime-pm* tests
on some CI machines I have concluded that: a) the PMU readout of RC6 can
race against runtime PM transitions, and b) there are other reasons than
being runtime suspended which can cause intel_runtime_pm_
Quoting Sagar Arun Kamble (2018-04-10 06:32:29)
>
>
> On 4/9/2018 9:02 PM, Michal Wajdeczko wrote:
> > On Mon, 09 Apr 2018 17:09:18 +0200, Patchwork
> > wrote:
> >
> >> == Series Details ==
> >>
> >> Series: series starting with [v8,01/12] drm/i915: Park before
> >> resetting the submission ba
%phn is not a valid specifier, so I presume %phN was meant for an
encoded hex string with no separator (and not that the hex string should
be followed by the letter 'n'!).
drivers/gpu/drm/i915/intel_guc_ct.c:616 ctb_read() warn: '%ph' cannot be
followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:
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: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/
Quoting Patchwork (2018-04-10 00:57:45)
> == Series Details ==
>
> Series: series starting with [1/2] drm/i915/guc: Check that the breadcrumb
> irq is enabled
> URL : https://patchwork.freedesktop.org/series/41396/
> State : failure
>
> == Summary ==
>
> Possible new issues:
>
> Test ge
Quoting Paulo Zanoni (2018-03-23 17:24:16)
> From: Manasi Navare
>
> This table is used for voltage swing programming sequence during DDI
> Buffer initialization for MG PHY DDI Buffers on Icelake.
Except it is not used at all...
drivers/gpu/drm/i915/intel_ddi.c:601:46: error: ‘icl_mg_phy_ddi_tr
On Tue, 10 Apr 2018, Jani Nikula wrote:
> On Mon, 09 Apr 2018, "Kumar, Abhay" wrote:
>> Dynamic cdclk is disabled in BIOS/GOP hence gop makes it to highest
>> clock i.e 316.8. Will attach logs with drm debug enabled in bug.
>> I am also inclined towards 192 which will make max cdclk..
>
> Please
>-Original Message-
>From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>Sent: Tuesday, April 10, 2018 3:57 PM
>To: Shi, Yang A ; Chris Wilson
>;
>intel-gfx@lists.freedesktop.org
>Cc: He, Bo
>Subject: RE: [Intel-gfx] [PATCH 1/1] drm/i915: move audio component
>intialization
>before a
On Mon, 09 Apr 2018, "Kumar, Abhay" wrote:
> Dynamic cdclk is disabled in BIOS/GOP hence gop makes it to highest
> clock i.e 316.8. Will attach logs with drm debug enabled in bug.
> I am also inclined towards 192 which will make max cdclk..
Please also attach /sys/kernel/debug/dri/0/i915_vbt to
On Tue, 10 Apr 2018, "Shi, Yang A" wrote:
> issue: snd_soc_skl meet "failed to add i915 component master (-19)"
> when platform don't connect any display output.
>
> i915 do initialization before than skl_probe, but if there is no
> display output connect, in function drm_dp_dpcd_access, there is
1 - 100 of 106 matches
Mail list logo
