On Mon, 26 Feb 2018, Chris Wilson wrote:
> Quoting Oscar Mateo (2018-02-26 23:01:50)
>> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
>> index 41dc881..e41678f 100644
>> --- a/Documentation/gpu/i915.rst
>> +++ b/Documentation/gpu/i915.rst
>> @@ -58,6 +58,12 @@ Intel GVT-g Ho
On Wed, Feb 07, 2018 at 10:57:59AM -, Patchwork wrote:
> == Series Details ==
>
> Series: YCBCR 4:2:0/4:4:4 output support for LSPCON (rev3)
> URL : https://patchwork.freedesktop.org/series/36068/
> State : warning
>
> == Summary ==
>
> Series 36068v3 YCBCR 4:2:0/4:4:4 output support for L
On Mon, 26 Feb 2018, Manasi Navare wrote:
> The usual if ladder order should be from newest to oldest
> platform. However the CNL conditional statement was misplaced.
> This patch sets the DP source for platforms starting from the newest
> to oldest.
Pushed to dinq, thanks for the patch.
BR,
Jan
Quoting Michał Winiarski (2018-02-26 16:37:59)
> Since we're inhibiting context save of preempt context, we're no longer
> tracking the position of HEAD/TAIL. With GuC, we're adding a new
> breadcrumb for each preemption, which means that the HW will do more and
> more breadcrumb writes. Eventually
Quoting Chris Wilson (2018-02-26 15:26:58)
> 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 ELS
Quoting Chris Wilson (2018-02-26 14:29:56)
> For large oops dump, for example if ftrace is included, we can easily
> exceed the storage buffer and lose the most important bit of
> information: where the OOPS occurred. So repeat the location information
> just before the end marker.
>
> Signed-off-
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, 2018 at 02:01:16PM +0200, Claudiu Beznea wrote:
> >>> Add PWM mode to pwm_config() function. The drivers which uses pwm_con
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 a direct rate value in the paranoia case of
no common rates find.
Cc
On Wed, Feb 21, 2018 at 11:28:45AM +, Chris Wilson wrote:
> Export the kmsg() function for use by tests to write into the kernel
> message log, useful for tests to inline their progress with kernel error
> messages.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Arkadiusz Hiler
both patches
OK cool I'll look out for it landing, CI_DRM_3838 or CI_DRM_3839 I guess.
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Tuesday, February 27, 2018 12:50 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Lofstedt, Marta
> Subject: Re: [RFC] kernel/panic:
On Tuesday 27 February 2018 04:54 AM, Rodrigo Vivi wrote:
On Mon, Feb 26, 2018 at 10:42:34PM +0530, Ramalingam C wrote:
This series addresses the requriement of below HDCP compliance tests
DP: 1A-06 and 1B-05
HDMI: 1A-04 and 1A-07a
One of the patch uses the I915 power infra-st
On Monday 26 February 2018 11:31 PM, Sean Paul wrote:
On Mon, Feb 26, 2018 at 10:42:39PM +0530, Ramalingam C wrote:
DP and HDMI HDCP specifications are varying with respect to
detecting the R0 and ksv_fifo availability.
DP will produce CP_IRQ and set a bit for indicating the R0 and
FIFO_READY
On Monday 26 February 2018 11:07 PM, Sean Paul wrote:
On Mon, Feb 26, 2018 at 10:42:35PM +0530, Ramalingam C wrote:
As per DP spec when R0 mismatch is detected, HDCP source supported
re-read the R0 atleast twice.
And For HDMI and DP minimum wait required for the R0 availability is
100mSec. So
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, 2018 at 02:01:16PM +0200, Claudiu Beznea wrote:
> Add PWM mode to pwm_
In case of V prime mismatch, DP HDCP spec mandates the re-read of
Vprime atleast twice.
Fixes DP HDCP CTS Test: 1B-05
v2:
Moved the V' validation into a function for retry. [Sean Paul]
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 113 +++
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: Michal Wajdeczko
Cc: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915
From: Michal Wajdeczko
To allow future code reuse. While here, fix comment style.
Suggested-by: Oscar Mateo
Signed-off-by: Michal Wajdeczko
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Oscar Mateo
Cc: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_irq.
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 serialized
using runtime.lock, while we're still using struct mute
The GuC log contains a separate space used for crash dump.
We even get a separate notification for it. While we're not handling
crash differently yet, it makes sense to decouple the two right now to
simplify the following patches.
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Daniele Cera
We have many functions responsible for allocating different parts of
runtime called from multiple places. Let's stick with keeping
everything in guc_log_register instead.
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: Sagar Arun Kamble
---
We have all the information we need at relay_open call time.
Since there's no reason to split the process into relay_open and
relay_late_setup_files, let's remove the extra code.
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Sagar Arun Kamble
Cc: Michal Wajdec
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/
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
---
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
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 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 +
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
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ä
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ä
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ä
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ä
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ä
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ä
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ä
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ä
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
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
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
>
== 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
== 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: 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
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
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 |
== 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/
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
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
== 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, 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
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
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
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
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
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
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 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
== 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 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
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 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,
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,
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:
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
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
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 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 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, 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 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
== 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 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: 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
== 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: 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 [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-
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
> >
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
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 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
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
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:
> >
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
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
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
== 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/
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: 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:
== 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: 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/
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
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
== 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
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):
>
1 - 100 of 121 matches
Mail list logo
