Ville, thanks for the patch and
Sorry for not being able to review this earlier.
Please find some comments below:
On Wed, Jan 31, 2018 at 03:27:10PM +0200, Ville Syrjälä wrote:
> On Tue, Jan 30, 2018 at 06:16:59PM -0500, Lyude Paul wrote:
> > On Wed, 2018-01-17 at 21:21 +0200, Ville Syrjala wrote
On Tuesday 27 February 2018 06:26 PM, Ville Syrjala wrote:
From: Ville Syrjälä
Currently we have a mix of static and dynamic information stored in
the display info structure. That makes it rather difficult to repopulate
the dynamic parts when a new EDID appears. Let's make life easier by
spli
== Series Details ==
Series: series starting with [1/3] drm/i915: Improve PSR activation timing
URL : https://patchwork.freedesktop.org/series/39075/
State : warning
== Summary ==
Series 39075v1 series starting with [1/3] drm/i915: Improve PSR activation
timing
https://patchwork.freedesktop.o
On Wed, Feb 28, 2018 at 12:26 AM, Chris Wilson wrote:
> Quoting Andy Lutomirski (2018-02-24 00:07:23)
>> On Tue, Feb 13, 2018 at 11:26 PM, Rodrigo Vivi
>> wrote:
>> > From: Andy Lutomirski
>> >
>> > +
>> > + dev_priv->psr.activate_timer.expires = jiffies - 1;
>>
>> That can't possibly be
On Wed, Feb 28, 2018 at 12:22 AM, Chris Wilson wrote:
> Quoting Rodrigo Vivi (2018-02-28 00:14:08)
>> From: Andy Lutomirski
>>
>> The current PSR code has a two call sites that each schedule delayed
>> work to activate PSR. As far as I can tell, each call site intends
>> to keep PSR inactive for
On Tue, 2018-02-27 at 23:34 +0200, Ville Syrjälä wrote:
> On Tue, Feb 27, 2018 at 01:23:59PM -0800, José Roberto de Souza
> wrote:
> > When PSR/PSR2/GTC is enabled hardware can do AUX transactions by it
> > self, so lets use the mutex register that is available in gen9+ to
> > avoid concurrent acce
On Thu, Feb 22, 2018 at 12:55:04AM -0300, Paulo Zanoni wrote:
> This commit introduces the definitions for the ICL clocks and adds the
> basic functions to the shared DPLL framework. It adds code for the
> Enable and Disable sequences for some PLLs, but it does not have the
> code to compute the ac
== Series Details ==
Series: drm/i915/dp: Add HBR3 rate (8.1 Gbps) to default rates array
URL : https://patchwork.freedesktop.org/series/39071/
State : success
== Summary ==
Known issues:
Test gem_eio:
Subgroup in-flight:
pass -> INCOMPLETE (shard-apl) fdo#1
Quoting Andy Lutomirski (2018-02-24 00:07:23)
> On Tue, Feb 13, 2018 at 11:26 PM, Rodrigo Vivi wrote:
> > From: Andy Lutomirski
> >
> > +
> > + dev_priv->psr.activate_timer.expires = jiffies - 1;
>
> That can't possibly be okay.
As an initialisation value, set to the previous jiffie? You
Quoting Rodrigo Vivi (2018-02-28 00:14:08)
> From: Andy Lutomirski
>
> The current PSR code has a two call sites that each schedule delayed
> work to activate PSR. As far as I can tell, each call site intends
> to keep PSR inactive for the given amount of time and then allow it
> to be activated
== Series Details ==
Series: drm/i915/cnl: Add WaRsDisableCoarsePowerGating
URL : https://patchwork.freedesktop.org/series/38807/
State : warning
== Summary ==
Possible new issues:
Test kms_chv_cursor_fail:
Subgroup pipe-b-128x128-left-edge:
pass -> DMESG-WA
It is a fact that scheduled work is now improved.
But it is also a fact that on core platforms that shouldn't
be needed. We only need to actually wait on VLV/CHV.
The immediate enabling is actually not an issue for the
HW perspective for core platforms that have HW tracking.
HW will wait few iden
WA 0884:bxt:all,cnl:*:A - "When FBC is enabled with eDP PSR,
the CPU host modify writes may not get updated on the Display
as expected.
WA: Write 0x to CUR_SURFLIVE_A with every CPU
host modify write to trigger PSR exit."
We can also find on spec other cases where they describe
bogus write
From: Andy Lutomirski
The current PSR code has a two call sites that each schedule delayed
work to activate PSR. As far as I can tell, each call site intends
to keep PSR inactive for the given amount of time and then allow it
to be activated.
The call sites are:
- intel_psr_enable(), which ex
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/psr2: Fix max resolution
supported.
URL : https://patchwork.freedesktop.org/series/39068/
State : failure
== Summary ==
Possible new issues:
Test perf_pmu:
Subgroup busy-check-all-vcs0:
pass
On Mon, Feb 26, 2018 at 05:25:12PM -0800, Radhakrishna Sripada wrote:
> On Thu, Feb 22, 2018 at 12:05:35PM -0800, Rodrigo Vivi wrote:
> > Old Wa added now forever on CNL all steppings.
> >
> > With CPU P states enabled along with RC6, dispatcher
> > hangs can happen.
> >
> > Cc: Rafael Antognolli
On Tue, Feb 27, 2018 at 02:47:26PM -0800, Pandiyan, Dhinakaran wrote:
>
> On Tue, 2018-02-27 at 13:29 -0800, Rodrigo Vivi wrote:
> > We can still use PSR1 when PSR2 conditions are not met.
> >
> > So, let's split the check in a way that we make sure has_psr
> > gets set independently of PSR2 crit
On Tue, 2018-02-27 at 23:34 +0200, Ville Syrjälä wrote:
> On Tue, Feb 27, 2018 at 01:23:59PM -0800, José Roberto de Souza wrote:
> > When PSR/PSR2/GTC is enabled hardware can do AUX transactions by it
> > self, so lets use the mutex register that is available in gen9+ to
> > avoid concurrent acc
On Sat, Feb 24, 2018 at 12:24:35AM +, Pandiyan, Dhinakaran wrote:
> On Tue, 2018-02-13 at 15:26 -0800, Rodrigo Vivi wrote:
> > WA 0884:bxt:all,cnl:*:A - "When FBC is enabled with eDP PSR,
> > the CPU host modify writes may not get updated on the Display
> > as expected.
> > WA: Write 0x
== Series Details ==
Series: drm/i915/dp: Add HBR3 rate (8.1 Gbps) to default rates array
URL : https://patchwork.freedesktop.org/series/39071/
State : success
== Summary ==
Series 39071v1 drm/i915/dp: Add HBR3 rate (8.1 Gbps) to default rates array
https://patchwork.freedesktop.org/api/1.0/se
== Series Details ==
Series: drm/i915/cnl: Add WaRsDisableCoarsePowerGating
URL : https://patchwork.freedesktop.org/series/38807/
State : success
== Summary ==
Series 38807v1 drm/i915/cnl: Add WaRsDisableCoarsePowerGating
https://patchwork.freedesktop.org/api/1.0/series/38807/revisions/1/mbox/
On Tue, 2018-02-27 at 13:29 -0800, Rodrigo Vivi wrote:
> We can still use PSR1 when PSR2 conditions are not met.
>
> So, let's split the check in a way that we make sure has_psr
> gets set independently of PSR2 criteria.
>
> v2: Duh! Handle proper return to avoid breaking PSR2.
> v3: (DK):
>
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/psr2: Fix max resolution
supported.
URL : https://patchwork.freedesktop.org/series/39068/
State : success
== Summary ==
Series 39068v1 series starting with [v2,1/2] drm/i915/psr2: Fix max resolution
supported.
https://patchw
default_rates[] array is a superset of all the link rates supported
by sink devices. DP 1.3 specification adds HBR3 (8.1Gbps) link rate
to the set of link rates supported by sink. This patch adds this rate
to default_rates[] array that gets used to populate the sink_rates[]
array limited by max rat
On Thu, Feb 22, 2018 at 12:55:03AM -0300, Paulo Zanoni wrote:
> There's a lot of code for the PLL enabling, so let's first only
> introduce the register definitions in order to make patch reviewing a
> little easier.
>
> v2: Coding style (Jani).
> v3: Preparation for upstreaming.
>
> Signed-off-b
== Series Details ==
Series: drm/i915/skl+: Add and enable DP AUX CH mutex
URL : https://patchwork.freedesktop.org/series/39067/
State : warning
== Summary ==
Series 39067v1 drm/i915/skl+: Add and enable DP AUX CH mutex
https://patchwork.freedesktop.org/api/1.0/series/39067/revisions/1/mbox/
== Series Details ==
Series: drm/i915: Repeat the GEM_BUG_ON message in the ftrace log
URL : https://patchwork.freedesktop.org/series/39065/
State : failure
== Summary ==
Series 39065v1 drm/i915: Repeat the GEM_BUG_ON message in the ftrace log
https://patchwork.freedesktop.org/api/1.0/series/3
== Series Details ==
Series: series starting with [CI,1/6] drm/i915/psr: New power domain for AUX IO.
URL : https://patchwork.freedesktop.org/series/38892/
State : success
== Summary ==
Known issues:
Test kms_flip:
Subgroup 2x-plain-flip-fb-recreate-interruptible:
On Tue, Feb 27, 2018 at 01:23:59PM -0800, José Roberto de Souza wrote:
> When PSR/PSR2/GTC is enabled hardware can do AUX transactions by it
> self, so lets use the mutex register that is available in gen9+ to
> avoid concurrent access by hardware and driver.
> Older gen handling will be done separ
== Series Details ==
Series: drm/i915/cnl: Add WaRsDisableCoarsePowerGating
URL : https://patchwork.freedesktop.org/series/38807/
State : failure
== Summary ==
Series 38807v1 drm/i915/cnl: Add WaRsDisableCoarsePowerGating
https://patchwork.freedesktop.org/api/1.0/series/38807/revisions/1/mbox/
According to spec:
"PSR2 is supported for pipe active sizes up to
3640 pixels wide and 2304 lines tall."
BSpec: 7713
Cc: Dhinakaran Pandiyan
Signed-off-by: Rodrigo Vivi
Reviewed-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/intel_psr.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletio
We can still use PSR1 when PSR2 conditions are not met.
So, let's split the check in a way that we make sure has_psr
gets set independently of PSR2 criteria.
v2: Duh! Handle proper return to avoid breaking PSR2.
v3: (DK):
- better name for psr2 conditions check function
- Don't re
When PSR/PSR2/GTC is enabled hardware can do AUX transactions by it
self, so lets use the mutex register that is available in gen9+ to
avoid concurrent access by hardware and driver.
Older gen handling will be done separated.
Reference:
https://01.org/sites/default/files/documentation/intel-gfx-p
Em Ter, 2018-02-27 às 11:51 -0800, Daniele Ceraolo Spurio escreveu:
>
> On 20/02/18 07:37, Mika Kuoppala wrote:
> > v2: Rebase.
> >
> > v3:
> >* Remove DPF, it has been removed from SKL+.
> >* Fix -internal rebase wrt. execlists interrupt handling.
> >
> > v4: Rebase.
> >
> > v5:
> >
As the ftrace log is overflowing the pstore capture, we lose the gasps
from dmesg which includes the GEM_BUG_ON function:line and condition that
failed. Vital information for tracking down the bug, so append it to the
frace log as well.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Joonas La
On Tue, Feb 27, 2018 at 08:52:49PM +0200, Jani Nikula wrote:
> On Tue, 27 Feb 2018, "Pandiyan, Dhinakaran"
> wrote:
> > On Tue, 2018-02-27 at 12:59 +0200, Jani Nikula wrote:
> >> Localize link rate arrays by moving them to the functions where they're
> >> used.
> >
> > I feel this array expresses
Quoting Lofstedt, Marta (2018-02-27 11:12:52)
> OK cool I'll look out for it landing, CI_DRM_3838 or CI_DRM_3839 I guess.
Bah, wrong path. This is only called to handle WARN() and we need the
extra information in BUG(). In fact, the information we need is in a raw
printk and not given to WARN, so
On Fri, 2018-02-23 at 18:03 -0800, José Roberto de Souza wrote:
> As gen < 9 hardware don't have the aux ch mutex, we need to exit PSR
> and wait until it is back to inactive state before do any aux ch
> transaction.
>
I wonder if we need this for CHV/VLV since the HW does not send PSR aux
tra
On Tue, Feb 27, 2018 at 09:55:56AM -0800, Nathan Ciobanu wrote:
> On Mon, Feb 26, 2018 at 07:27:23PM -0800, Dhinakaran Pandiyan wrote:
> > eDP spec says - "If PSR/PSR2 is supported, the SET_POWER_CAPABLE bit in the
> > EDP_GENERAL_CAPABILITY_1 register (DPCD Address 00701h, bit d7) must be set
> >
== Series Details ==
Series: series starting with [1/2] igt/gem_fd_exhaustion: Actually test error
handling on fd exhaustion
URL : https://patchwork.freedesktop.org/series/39051/
State : failure
== Summary ==
Possible new issues:
Test kms_vblank:
Subgroup pipe-b-ts-continuation-
== Series Details ==
Series: drm: Try to make display info less nuts
URL : https://patchwork.freedesktop.org/series/39046/
State : failure
== Summary ==
Possible new issues:
Test kms_vblank:
Subgroup pipe-b-ts-continuation-suspend:
skip -> PASS (shard-
== Series Details ==
Series: series starting with [01/15] drm/i915/guc: Tidy guc_log_control
URL : https://patchwork.freedesktop.org/series/39043/
State : failure
== Summary ==
Possible new issues:
Test drv_missed_irq:
pass -> SKIP (shard-apl)
Test drv_selftes
On Tue, Feb 27, 2018 at 10:24:27AM -0800, Nathan Ciobanu wrote:
> On Fri, Feb 23, 2018 at 02:15:15PM -0800, Dhinakaran Pandiyan wrote:
> > From: "Dhinakaran Pandiyan"
> >
> > PSR on CNL requires AUX IO wells to be kept on and the existing AUX domain
> > for AUX-A enables DC_OFF well too. This is
== Series Details ==
Series: drm/i915/dp: move link rate arrays where they're used
URL : https://patchwork.freedesktop.org/series/39032/
State : failure
== Summary ==
Possible new issues:
Test kms_draw_crc:
Subgroup draw-method-rgb565-blt-untiled:
pass -> SK
On 20/02/18 07:37, Mika Kuoppala wrote:
v2: Rebase.
v3:
* Remove DPF, it has been removed from SKL+.
* Fix -internal rebase wrt. execlists interrupt handling.
v4: Rebase.
v5:
* Updated for POR changes. (Daniele Ceraolo Spurio)
* Merged with irq handling fixes by Daniele Ceraolo S
== Series Details ==
Series: series starting with [CI,1/6] drm/i915/psr: New power domain for AUX IO.
URL : https://patchwork.freedesktop.org/series/38892/
State : success
== Summary ==
Series 38892v1 series starting with [CI,1/6] drm/i915/psr: New power domain for
AUX IO.
https://patchwork.f
On Tue, 27 Feb 2018, "Pandiyan, Dhinakaran"
wrote:
> On Tue, 2018-02-27 at 12:59 +0200, Jani Nikula wrote:
>> Localize link rate arrays by moving them to the functions where they're
>> used.
>
> I feel this array expresses platform capability concisely and it's easy
> to quickly check what rates
On Tue, 27 Feb 2018, Manasi Navare wrote:
> On Tue, Feb 27, 2018 at 12:59:11PM +0200, Jani Nikula wrote:
>> Localize link rate arrays by moving them to the functions where they're
>> used. Further clarify the distinction between source and sink
>> capabilities. Split pre and post Haswell arrays, a
On Fri, Feb 23, 2018 at 02:15:15PM -0800, Dhinakaran Pandiyan wrote:
> From: "Dhinakaran Pandiyan"
>
> PSR on CNL requires AUX IO wells to be kept on and the existing AUX domain
> for AUX-A enables DC_OFF well too. This is not required, so add a new
> AUX_IO_A domain for AUX-A to allow DC states
On Tue, Feb 27, 2018 at 12:59:11PM +0200, Jani Nikula wrote:
> Localize link rate arrays by moving them to the functions where they're
> used. Further clarify the distinction between source and sink
> capabilities. Split pre and post Haswell arrays, and get rid of the
> array size arithmetics. Use
On Tue, 2018-02-27 at 12:59 +0200, Jani Nikula wrote:
> Localize link rate arrays by moving them to the functions where they're
> used.
I feel this array expresses platform capability concisely and it's easy
to quickly check what rates a platform supports when the array is at the
top. But,that's
On Mon, Feb 26, 2018 at 07:27:23PM -0800, Dhinakaran Pandiyan wrote:
> eDP spec says - "If PSR/PSR2 is supported, the SET_POWER_CAPABLE bit in the
> EDP_GENERAL_CAPABILITY_1 register (DPCD Address 00701h, bit d7) must be set
> to 1."
>
> Reject PSR on panels without this cap bit set as such panels
Ok, please update the workaround page to show all the impacted projects
https://gfxspecs.intel.com/Predator/Home/Index/21829
> -Original Message-
> From: Mullah, Abid A
> Sent: Tuesday, 27 February, 2018 8:52 AM
> To: Runyan, Arthur J ; Pandiyan, Dhinakaran
> ; Singh, Gaurav K
> ; Neelaga
Yes. It will be needed for BXT also.
-Original Message-
From: Runyan, Arthur J
Sent: Tuesday, February 27, 2018 8:49 AM
To: Pandiyan, Dhinakaran ; Singh, Gaurav K
; Mullah, Abid A ;
Neelagandan, Harigaran
Cc: intel-gfx@lists.freedesktop.org; Vivi, Rodrigo ;
Nikula, Jani
Subject: RE:
Abid or Hari, please check. There was a workaround to set AUD_CHICKENBIT_REG
bit 15 (Codec Wake overwrite to DACFEUNIT) on SKL and KBL. Does it apply to
BXT also?
> -Original Message-
> From: Pandiyan, Dhinakaran
> Sent: Monday, 26 February, 2018 6:04 PM
> To: Runyan, Arthur J ; Singh,
On 27.02.2018 17:38, Daniel Thompson wrote:
> On Tue, Feb 27, 2018 at 01:40:58PM +0200, Claudiu Beznea wrote:
>> On 27.02.2018 12:54, Daniel Thompson wrote:
>>> On Mon, Feb 26, 2018 at 04:24:15PM +0200, Claudiu Beznea wrote:
On 26.02.2018 11:57, Jani Nikula wrote:
> On Thu, 22 Feb 2018,
On Tue, Feb 27, 2018 at 01:40:58PM +0200, Claudiu Beznea wrote:
> On 27.02.2018 12:54, Daniel Thompson wrote:
> > On Mon, Feb 26, 2018 at 04:24:15PM +0200, Claudiu Beznea wrote:
> >> On 26.02.2018 11:57, Jani Nikula wrote:
> >>> On Thu, 22 Feb 2018, Daniel Thompson wrote:
> On Thu, Feb 22, 20
On Tue, Feb 27, 2018 at 03:37:25PM +0100, Michal Wajdeczko wrote:
> On Tue, 27 Feb 2018 13:52:24 +0100, Michał Winiarski
> wrote:
>
> > We only need those fast memcpy_wc when we're using relay to read
> > continuous GuC log. Let's prevent the user from creating a relay if we
> > know we won't be
== Series Details ==
Series: series starting with [1/2] igt/gem_fd_exhaustion: Actually test error
handling on fd exhaustion
URL : https://patchwork.freedesktop.org/series/39051/
State : success
== Summary ==
IGT patchset tested on top of latest successful build
77411862d239916b40e218eeb6519b
On Monday 26 February 2018 11:22 PM, Sean Paul wrote:
On Mon, Feb 26, 2018 at 10:42:38PM +0530, Ramalingam C wrote:
In a connected state, If a HDMI HDCP sink is responded with NACK for
HDCP I2C register access, then HDMI HDCP spec mandates the polling
of any HDCP space registers for accessibil
Quoting Karol Krol (2018-02-27 14:30:43)
> Long time ago, there was an issue with driver crashing due to lack of
> error handling on struct file creation (gem_create()). We're unable to hit
> this scenario, because dup() does not creat flip. Let's replace dup() with
> open() and assert that error i
On Tue, 27 Feb 2018 13:52:24 +0100, Michał Winiarski
wrote:
We only need those fast memcpy_wc when we're using relay to read
continuous GuC log. Let's prevent the user from creating a relay if we
know we won't be able to keep up with GuC.
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc
On Mon, 26 Feb 2018, Rodrigo Vivi wrote:
> On Mon, Feb 26, 2018 at 03:45:51PM -0800, Azhar Shaikh wrote:
>> SAGV handling is currently broken which can result in system hangs.
>> Add a parameter to disable SAGV, till the SAGV handling is fixed.
>
> Not just handling of the limitations we have with
We also need to adjust fs.nr_open to allow setting rlimit equal to
fs.file-max. Otherwise we're getting EPREM on setrlimit().
Signed-off-by: Karol Krol
---
tests/gem_fd_exhaustion.c | 49 ---
1 file changed, 42 insertions(+), 7 deletions(-)
diff --git
Long time ago, there was an issue with driver crashing due to lack of
error handling on struct file creation (gem_create()). We're unable to hit
this scenario, because dup() does not creat flip. Let's replace dup() with
open() and assert that error is returned on exhaustion.
Signed-off-by: Karol K
On Tue, 27 Feb 2018 13:52:20 +0100, Michał Winiarski
wrote:
Currently, we're treating relay and mapping of GuC log as a separate
concepts. We're also using inconsistent locking, sometimes using
relay_lock, sometimes using struct mutex.
Let's correct that. Anything touching the runtime is now
On Tue, 27 Feb 2018 13:52:17 +0100, Michał Winiarski
wrote:
We have many functions responsible for allocating different parts of
runtime called from multiple places. Let's stick with keeping
s/runtime/GuC log runtime ?
everything in guc_log_register instead.
Signed-off-by: Michał Winiars
== Series Details ==
Series: drm: Try to make display info less nuts
URL : https://patchwork.freedesktop.org/series/39046/
State : success
== Summary ==
Series 39046v1 drm: Try to make display info less nuts
https://patchwork.freedesktop.org/api/1.0/series/39046/revisions/1/mbox/
Possibl
On Tue, Feb 27, 2018 at 03:38:58PM +0200, Petri Latvala wrote:
> On Mon, Feb 05, 2018 at 12:56:10PM +0100, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > testdisplay.h includes the glib.h header file but the Makefile does not
> > explicitly pass a -I option with the path containing that h
On Tue, 27 Feb 2018 13:52:16 +0100, Michał Winiarski
wrote:
We plan to decouple log runtime (mapping + relay) from verbosity control.
Let's tidy the code now to reduce the churn in the following patches.
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Micha
== Series Details ==
Series: series starting with [01/15] drm/i915/guc: Tidy guc_log_control
URL : https://patchwork.freedesktop.org/series/39043/
State : success
== Summary ==
Series 39043v1 series starting with [01/15] drm/i915/guc: Tidy guc_log_control
https://patchwork.freedesktop.org/api/
Quoting Mika Kuoppala (2018-02-27 13:25:35)
> > uint32_t result = gem_create(fd, 4096);
> > @@ -981,12 +1117,26 @@ igt_main
> > igt_subtest_f("preempt-contexts-%s",
> > e->name)
> > preempt(fd, e->exec_id |
On Mon, Feb 05, 2018 at 12:56:10PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> testdisplay.h includes the glib.h header file but the Makefile does not
> explicitly pass a -I option with the path containing that header, hence
> causing the build to fail. Note that this doesn't seem to
== Series Details ==
Series: series starting with [01/15] drm/i915/guc: Tidy guc_log_control
URL : https://patchwork.freedesktop.org/series/39043/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915/guc: Tidy guc_log_control
Okay!
Commit: drm/i915/guc: Create common ent
== Series Details ==
Series: HDCP1.4 fixes (rev2)
URL : https://patchwork.freedesktop.org/series/38978/
State : failure
== Summary ==
Applying: drm/i915: Read HDCP R0 thrice in case of mismatch
Applying: drm/i915: read Vprime thrice incase of mismatch
Applying: drm/i915: Check hdcp key loadabi
Chris Wilson writes:
> In investigating the issue with having to force preemption within the
> executing ELSP[], we want to trigger preemption between all elements of
> that array. To that end, we issue a series of requests with different
> priorities to fill the in-flight ELSP[] and then demand
== Series Details ==
Series: drm/i915/dp: move link rate arrays where they're used
URL : https://patchwork.freedesktop.org/series/39032/
State : success
== Summary ==
Series 39032v1 drm/i915/dp: move link rate arrays where they're used
https://patchwork.freedesktop.org/api/1.0/series/39032/rev
On Tue, 2018-02-27 at 14:56 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Currently we have a mix of static and dynamic information stored in
> the display info structure. That makes it rather difficult to repopulate
> the dynamic parts when a new EDID appears. Let's make life easier by
>
On Tue, Feb 27, 2018 at 02:56:53PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Currently we have a mix of static and dynamic information stored in
> the display info structure. That makes it rather difficult to repopulate
> the dynamic parts when a new EDID appears. Let's make life easi
From: Ville Syrjälä
edid and display_info are protected by mode_config.mutex. Add lockdep
asserts to make sure we're not accessing things w/o the lock.
FIXME: pretty sure this will blow up with amdgpu as they seem
to be doing edid updates even from the modeset path. Need to figure
out what to do
From: Ville Syrjälä
The edid is protected by mode_config.mutex so extend the locking to
protect the property readout part as well.
Cc: Keith Packard
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_connector.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
From: Ville Syrjälä
The edid is protected by mode_config.mutex. Grab the lock when frobbing
the debugfs edid_override thing.
Cc: Keith Packard
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_debugfs.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
From: Ville Syrjälä
Wrap the ->fill_modes() call in a small helper that first clears out the
stale data from connector->display_info. This should guarantee that we
get consistent display_info whether or not the drivers use the EDID
based stuff to clear and fill it.
TODO: what about just after in
From: Ville Syrjälä
If we have to backoff there's no point in going over the mode list again
to mark all the modes as stale. We can defer that until we're ready to
refresh the mode list. Avoids multiple list walks if we have to do the
locking backoff.
Cc: Keith Packard
Cc: Daniel Vetter
Signed
From: Ville Syrjälä
drm_mode_connector_update_edid_property() will call
drm_add_display_info() if an invalid edid is passed in.
This differs from the behaviour of drm_add_edid_modes() which
doesn't try to populate the display info from an invalid edid.
Adjust drm_mode_connector_update_edid_proper
From: Ville Syrjälä
Now that we have split the display info into static and dynamic parts,
we can just zero out the entire dynamic part with memset(). Previously
we were just clearing parts of it, leaving stale data in other parts
(eg. HDMI SCDC capabilities).
Also when the edid is NULL drm_add_
From: Ville Syrjälä
Currently we have a mix of static and dynamic information stored in
the display info structure. That makes it rather difficult to repopulate
the dynamic parts when a new EDID appears. Let's make life easier by
splitting the structure up into static and dynamic parts.
The stat
From: Ville Syrjälä
Currently the display info is cleared/populated in a very ad-hoc manner.
I'd like to make it more robust by making sure it gets cleared by the
core forcing drivers to repopulate in .fill_modes().
The bus_formats stuff looks very much ad-hoc all over, so I left that
out from c
From: Ville Syrjälä
shmobile is already populating display_info.width_mm and
display_info.height_mm from the .get_modes() hook which is what
we want. No need to populate it from the init path as well.
Cc: Keith Packard
Cc: Daniel Vetter
Cc: Laurent Pinchart
Cc: linux-renesas-...@vger.kernel.o
From: Ville Syrjälä
display_info.width_mm and display_info.height_mm are dynamic metadata
that either gets parsed from the EDID or filled by the driver by some
other means. Either way we should update it in the same place, ie.
the .fill_modes()/.get_modes() hooks.
Cc: Keith Packard
Cc: Daniel V
From: Ville Syrjälä
display_info.width_mm and display_info.height_mm are dynamic metadata
that either gets parsed from the EDID or filled by the driver by some
other means. Either way we should update it in the same place, ie.
the .fill_modes()/.get_modes() hooks.
Cc: Keith Packard
Cc: Daniel V
While some of the content in this file is related to GuC submission
only, that's not the case with log related statistics.
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Sagar Arun Kamble
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/i915_debugfs.c | 15 +
If nobody has enabled the relay, we're not comunicating with GuC, which
means that the stats don't have any meaning. Let's also remove interrupt
counter and tidy the debugfs formatting.
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Sagar Arun Kamble
Cc: Michal
While both naming and actual log enable logic in GuC interface are
confusing, we can simply expose the default log as yet another log
level.
GuC logic aside, from i915 point of view we now have the following GuC
log levels:
0 Log disabled
1 Non-verbose log
2-5 Verbose log
S
---
drivers/gpu/drm/i915/i915_params.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index 430f5f9d0ff4..53037b5eff22 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_p
Now that we've decoupled logging from relay, GuC log level is only
controlling the GuC behavior - there shouldn't be any impact on i915
behaviour. We're only going to see a single extra interrupt when log
will get half full.
That, and the fact that we're seeing igt/gem_exec_nop/basic-series
failing
We only need those fast memcpy_wc when we're using relay to read
continuous GuC log. Let's prevent the user from creating a relay if we
know we won't be able to keep up with GuC.
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Sagar Arun Kamble
Cc: Michal Wajdec
Those two concepts are really separate. Since GuC is writing data into
its own buffer and we even provide a way for userspace to read directly
from it using i915_guc_log_dump debugfs, there's no real reason to tie
log level with relay creation.
Let's create a separate debugfs, giving userspace a wa
Having both guc_flush_logs and guc_log_flush functions is confusing.
While we could just rename things, guc_flush_logs implementation is
quite simple. Let's get rid of it and move its content to unregister.
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Sagar Ar
Keeping a separate runtime struct is only making the code dealing with
relay less clear to read. Let's get rid of it, keeping everything in the
log instead.
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Sagar Arun Kamble
Cc: Michal Wajdeczko
---
drivers/gpu/
1 - 100 of 121 matches
Mail list logo
