== Series Details ==
Series: igt/gem_busy: Replace arbitrary busy batch with indefinite spinbatch
(rev2)
URL : https://patchwork.freedesktop.org/series/34780/
State : failure
== Summary ==
Test pm_rpm:
Subgroup drm-resources-equal:
pass -> SKIP (shard-hsw)
== Series Details ==
Series: series starting with [1/2] drm/i915: Implement WaDisableVFclkgate.
URL : https://patchwork.freedesktop.org/series/34785/
State : failure
== Summary ==
Test drv_module_reload:
Subgroup basic-reload:
dmesg-warn -> PASS (shard-hsw) fdo#10
Hi all,
The following changes tagged drm-intel-testing-2017-12-01:
drm-intel-next-2017-12-01:
- Init clock gate fix (Ville)
- Execlists event handling corrections (Chris, Michel)
- Improvements on GPU Cache invalidation and context switch (Chris)
- More perf OA changes (Lionel)
- More selftests
== Series Details ==
Series: igt/perf_pmu: Tighten semaphore-wait measurement
URL : https://patchwork.freedesktop.org/series/34786/
State : failure
== Summary ==
IGT patchset tested on top of latest successful build
476c4b462e0453c70ee81664c0227fdddc26cbd0 igt/gem_eio: Increase wakeup delay fo
Record the before/after semaphore-wait values around the sleep to try to
reduce the inaccuracy from scheduler delays. Previously, the samples
were taken before submitting the batch and then after synchronising its
completion. The measurement will then be the total that the semaphore
was being sampl
== Series Details ==
Series: igt/gem_busy: Replace arbitrary busy batch with indefinite spinbatch
(rev2)
URL : https://patchwork.freedesktop.org/series/34780/
State : success
== Summary ==
IGT patchset tested on top of latest successful build
476c4b462e0453c70ee81664c0227fdddc26cbd0 igt/gem_e
On Thu, 2017-11-30 at 13:19 +0200, Imre Deak wrote:
> > > +#define NEEDS_CSR_GT_PERF_WA(dev_priv) \
> > > + (HAS_CSR(dev_priv) && IS_GEN9(dev_priv) && !
> IS_SKYLAKE(dev_priv))
>
> Nitpick: could be just !IS_SKYLAKE(), but works in the above way too.
> For all other platforms the GT_IRQ doma
== Series Details ==
Series: series starting with [1/2] drm/i915: Implement WaDisableVFclkgate.
URL : https://patchwork.freedesktop.org/series/34785/
State : success
== Summary ==
Series 34785v1 series starting with [1/2] drm/i915: Implement
WaDisableVFclkgate.
https://patchwork.freedesktop.o
On Thu, 2017-11-30 at 13:19 +0200, Imre Deak wrote:
> On Thu, Nov 30, 2017 at 09:45:25AM +, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2017-11-30 09:18:20)
> > > From: Tvrtko Ursulin
> > >
> > > It seems that the DMC likes to transition between the DC states a lot when
> > > there are no
There seems to be another clock gating issue which the workaround is
described as:
"WA: Set 0xE4F0[1] = 1 to disable Early EOT of thread."
Signed-off-by: Rafael Antognolli
---
drivers/gpu/drm/i915/i915_reg.h| 1 +
drivers/gpu/drm/i915/intel_engine_cs.c | 3 +++
2 files changed, 4 ins
This workaround supposedly fixes some hangs in the VF unit.
Signed-off-by: Rafael Antognolli
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_pm.c | 5 +
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
in
In CI, we were observing situations where the busy blt would complete
before the very next instruction (in userspace) to assert that it was
busy. This is entirely possible if the process was scheduled away and
slept for longer than the arbitrary batch. Instead replace arbitrariness
with a precise i
== Series Details ==
Series: igt/gem_busy: Replace arbitrary busy batch with indefinite spinbatch
URL : https://patchwork.freedesktop.org/series/34780/
State : failure
== Summary ==
IGT patchset tested on top of latest successful build
476c4b462e0453c70ee81664c0227fdddc26cbd0 igt/gem_eio: Incr
== Series Details ==
Series: IGT/tests/firmware: Test firmware loading by reading debugfs
URL : https://patchwork.freedesktop.org/series/34778/
State : warning
== Summary ==
Test gem_busy:
Subgroup close-race:
fail -> PASS (shard-snb) fdo#103829
Test kms_cur
In CI, we were observing situations where the busy blt would complete
before the very next instruction (in userspace) to assert that it was
busy. This is entirely possible if the process was scheduled away and
slept for longer than the arbitrary batch. Instead replace arbitrariness
with a precise i
On Fri, Dec 01, 2017 at 09:40:35PM +, Anusha Srivatsa wrote:
> Read debugfs and sysfs entries to check for GuC
> loading conditions.
>
> The patch is still WIP. Once all check conditions are
> covered, it can be extended to huc debugfs file too.
>
> Cc: Rodrigo Vivi
> Signed-off-by: Anusha S
== Series Details ==
Series: IGT/tests/firmware: Test firmware loading by reading debugfs
URL : https://patchwork.freedesktop.org/series/34778/
State : success
== Summary ==
IGT patchset tested on top of latest successful build
476c4b462e0453c70ee81664c0227fdddc26cbd0 igt/gem_eio: Increase wak
Read debugfs and sysfs entries to check for GuC
loading conditions.
The patch is still WIP. Once all check conditions are
covered, it can be extended to huc debugfs file too.
Cc: Rodrigo Vivi
Signed-off-by: Anusha Srivatsa
---
tests/Makefile.sources | 1 +
tests/test_firmware.c | 96
On 01/12/17 20:02, Paulo Zanoni wrote:
Em Sex, 2017-11-10 às 19:08 +, Lionel Landwerlin escreveu:
We use to have this fixed per generation, but starting with CNL
userspace
cannot tell just off the PCI ID. Let's make this information
available. This
is particularly useful for performance moni
On Fri, Dec 01, 2017 at 02:17:19PM -0500, Sean Paul wrote:
> On Fri, Dec 1, 2017 at 2:06 PM, Ville Syrjälä
> wrote:
> > On Fri, Dec 01, 2017 at 12:20:28PM -0500, Sean Paul wrote:
> >> Once the Aksv is available in the PCH, we need to get it on the wire to
> >> the receiver via DDC. The hardware do
Em Sex, 2017-11-10 às 19:08 +, Lionel Landwerlin escreveu:
> We use to have this fixed per generation, but starting with CNL
> userspace
> cannot tell just off the PCI ID. Let's make this information
> available. This
> is particularly useful for performance monitoring where much of the
> norma
On Fri, Dec 1, 2017 at 2:06 PM, Ville Syrjälä
wrote:
> On Fri, Dec 01, 2017 at 12:20:28PM -0500, Sean Paul wrote:
>> Once the Aksv is available in the PCH, we need to get it on the wire to
>> the receiver via DDC. The hardware doesn't allow us to read the value
>> directly, so we need to tell GMBU
On 17-11-15 17:37:01, Gabriel Krisman Bertazi wrote:
Two scenarios tested:
- unaligned stride
- Stride too small
Since v4:
- Fix SIGFPE if width <= 1024 (Arkadiusz Hiler/Ville Syrjälä)
- Add test for pitches[1]=0 (Ville Syrjälä)
Signed-off-by: Gabriel Krisman Bertazi
[snip]
Reviewed-by: B
On Fri, Dec 01, 2017 at 12:20:28PM -0500, Sean Paul wrote:
> Once the Aksv is available in the PCH, we need to get it on the wire to
> the receiver via DDC. The hardware doesn't allow us to read the value
> directly, so we need to tell GMBUS to source the Aksv internally and
> send it to the right
On Fri, Dec 1, 2017 at 1:47 PM, Hans Verkuil wrote:
> Hi Sean,
>
> On 12/01/2017 06:20 PM, Sean Paul wrote:
>> Ok, here's v2 of the HDCP patchset, no longer RFC since I've tackled the TODO
>> list I set out in the first version (Annotated below for convenience).
>>
>> The big changes to take note
Hi Sean,
On 12/01/2017 06:20 PM, Sean Paul wrote:
> Ok, here's v2 of the HDCP patchset, no longer RFC since I've tackled the TODO
> list I set out in the first version (Annotated below for convenience).
>
> The big changes to take note of in v2 is locking. To account for atomic async
> +
> the p
On Saturday, November 25, 2017 08:35:46 PM Hans de Goede wrote:
> Here is v7 of my series to add a "panel orientation" property to
> the drm-connector for the LCD panel to let userspace know about LCD
> panels which are not mounted upright, as well as detecting upside-down
> panels without needing
On Fri, Dec 1, 2017 at 12:57 PM, Chris Wilson wrote:
> Quoting Chris Wilson (2017-12-01 17:55:15)
>> Quoting Sean Paul (2017-12-01 17:48:17)
>> > On Fri, Dec 1, 2017 at 12:44 PM, Chris Wilson
>> > wrote:
>> > > The current wait_for() is a little more complicated nowadays (variable
>> > > W).
>>
Quoting Chris Wilson (2017-12-01 17:55:15)
> Quoting Sean Paul (2017-12-01 17:48:17)
> > On Fri, Dec 1, 2017 at 12:44 PM, Chris Wilson
> > wrote:
> > > The current wait_for() is a little more complicated nowadays (variable
> > > W).
> > >
> >
> > Hmm, am I based off the wrong tree? I'm using drm
Quoting Sean Paul (2017-12-01 17:48:17)
> On Fri, Dec 1, 2017 at 12:44 PM, Chris Wilson
> wrote:
> > Quoting Sean Paul (2017-12-01 17:20:24)
> >> /**
> >> - * _wait_for - magic (register) wait macro
> >> + * __wait_for - magic wait macro
> >> *
> >> - * Does the right thing for modeset paths w
On Fri, Dec 1, 2017 at 12:44 PM, Chris Wilson wrote:
> Quoting Sean Paul (2017-12-01 17:20:24)
>> /**
>> - * _wait_for - magic (register) wait macro
>> + * __wait_for - magic wait macro
>> *
>> - * Does the right thing for modeset paths when run under kdgb or similar
>> atomic
>> - * contexts.
Quoting Sean Paul (2017-12-01 17:20:24)
> /**
> - * _wait_for - magic (register) wait macro
> + * __wait_for - magic wait macro
> *
> - * Does the right thing for modeset paths when run under kdgb or similar
> atomic
> - * contexts. Note that it's important that we check the condition again aft
On Fri, Dec 01, 2017 at 02:17:00AM +, James Ausmus wrote:
> Without masking out the old value, we can end up pointing the DDI to a
> disabled PLL, which makes the system fall over. Mask out the previous
> value before setting the PLL to DDI mapping.
>
> This can be observed by running igt/test
== Series Details ==
Series: drm/i915: Implement HDCP (rev2)
URL : https://patchwork.freedesktop.org/series/34671/
State : failure
== Summary ==
Applying: drm: Fix link-status kerneldoc line lengths
error: Failed to merge in the changes.
Using index info to reconstruct a base tree...
M d
This patch adds HDCP support for DisplayPort connectors by implementing
the intel_hdcp_shim.
Most of this is straightforward read/write from/to DPCD registers. One
thing worth pointing out is the Aksv output bit. It wasn't easily
separable like it's HDMI counterpart, so it's crammed in with the re
This patch adds HDCP support for HDMI connectors by implementing
the intel_hdcp_shim.
Nothing too special, just a bunch of DDC reads/writes.
Changes in v2:
- Rebased on drm-intel-next
Signed-off-by: Sean Paul
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_ddi.c | 5
Once the Aksv is available in the PCH, we need to get it on the wire to
the receiver via DDC. The hardware doesn't allow us to read the value
directly, so we need to tell GMBUS to source the Aksv internally and
send it to the right offset on the receiver.
The way we do this is to initiate an index
This patch adds a new optional connector property to allow userspace to enable
protection over the content it is displaying. This will typically be implemented
by the driver using HDCP.
The property is a tri-state with the following values:
- OFF: Self explanatory, no content protection
- DESIRED:
This patch adds the framework required to add HDCP support to intel
connectors. It implements Aksv loading from fuse, and parts 1/2/3
of the HDCP authentication scheme.
Note that without shim implementations, this does not actually implement
HDCP. That will come in subsequent patches.
Changes in
In preparation for implementing HDCP in i915, add some HDCP related
register offsets and defines. The dpcd register offsets will go in
drm_dp_helper.h whereas the ddc offsets along with generic HDCP stuff
will get stuffed in drm_hdcp.h, which is new.
Changes in v2:
- drm_hdcp.h gets MIT license (D
This patch adds a little more control to a couple wait_for routines such
that we can avoid open-coding read/wait/timeout patterns which:
- need the value of the register after the wait_for
- run arbitrary operation for the read portion
This patch also chooses the correct sleep function (based on
I'm adding some stuff below it and it's killing my editor's vibe.
Changes in v2:
- Added to the series
Cc: Manasi Navare
Acked-by: Daniel Vetter
Signed-off-by: Sean Paul
---
drivers/gpu/drm/drm_connector.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gp
Ok, here's v2 of the HDCP patchset, no longer RFC since I've tackled the TODO
list I set out in the first version (Annotated below for convenience).
The big changes to take note of in v2 is locking. To account for atomic async +
the property's mutability, I'm using a dedicated mutex and moved prop
On Fri, 01 Dec 2017 17:39:38 +0100, Sagar Arun Kamble
wrote:
On 12/1/2017 4:03 PM, Michal Wajdeczko wrote:
Our new "enable_guc" modparam allows to control whenever HuC
should be loaded. However existing code will try load and
authenticate HuC always when we use the GuC. This patch is
tryin
On 12/1/2017 4:03 PM, Michal Wajdeczko wrote:
Our new "enable_guc" modparam allows to control whenever HuC
should be loaded. However existing code will try load and
authenticate HuC always when we use the GuC. This patch is
trying to enforce modparam selection.
Signed-off-by: Michal Wajdeczko
Quoting Patchwork (2017-12-01 14:00:49)
> == Series Details ==
>
> Series: drm/i915: Sleep and retry a GPU reset if at first we don't succeed
> (rev2)
> URL : https://patchwork.freedesktop.org/series/34747/
> State : success
>
> == Summary ==
>
> Test drv_selftest:
> Subgroup mock_san
On Fri, 01 Dec 2017 16:55:41 +0100, Sagar Arun Kamble
wrote:
On 12/1/2017 6:01 PM, Chris Wilson wrote:
Quoting Michal Wajdeczko (2017-12-01 10:33:14)
-EIO has special meaning and is used when we want to allow
engine initialization to fail and mark GPU as wedged.
Missing firmware does not
On Fri, 01 Dec 2017 16:47:40 +0100, Sagar Arun Kamble
wrote:
On 12/1/2017 4:03 PM, Michal Wajdeczko wrote:
We currently have two module parameters that control GuC:
"enable_guc_loading" and "enable_guc_submission". Whenever
we need submission=1, we also need loading=1. We also need
loading
On 12/1/2017 6:01 PM, Chris Wilson wrote:
Quoting Michal Wajdeczko (2017-12-01 10:33:14)
-EIO has special meaning and is used when we want to allow
engine initialization to fail and mark GPU as wedged.
Missing firmware does not fit into this scenario as this is
permanent error not related to G
On 12/1/2017 4:03 PM, Michal Wajdeczko wrote:
We currently have two module parameters that control GuC:
"enable_guc_loading" and "enable_guc_submission". Whenever
we need submission=1, we also need loading=1. We also need
loading=1 when we want to want to load and verify the HuC.
Lets combine
== Series Details ==
Series: igt: Make dependency on libunwind mandatory
URL : https://patchwork.freedesktop.org/series/34752/
State : success
== Summary ==
Test gem_tiled_swapping:
Subgroup non-threaded:
incomplete -> PASS (shard-snb) fdo#104009 +1
Test kms_front
On Wed, Nov 29, 2017 at 03:07:03PM -0800, Rodrigo Vivi wrote:
> On Wed, Nov 29, 2017 at 06:08:47PM +, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Reject interlaced modes on VLV/CHV DP outputs. This simply does
> > not work correctly in the hardware. We do get some output, but
> > it'
On Wed, Nov 29, 2017 at 02:54:11PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> i830_disable_pipe() gets called from the power well code, and thus
> we're already holding the power domain mutex. That means we can't
> call plane->get_hw_state() as it will also try to grab the
> same mutex
On Wed, Nov 29, 2017 at 03:45:41PM +, Chris Wilson wrote:
> Quoting Ville Syrjala (2017-11-29 15:37:32)
> > From: Ville Syrjälä
> >
> > Get rid of the crtc->config usages from within
> > intel_pipe_{enable,disable}() by passing in the appropriate
> > crtc state.
> >
> > Signed-off-by: Ville
On Wed, Nov 29, 2017 at 03:22:33PM -0800, Rodrigo Vivi wrote:
> On Wed, Nov 29, 2017 at 04:43:01PM +, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Apparently g4x doesn't support audio over DP. Bspec lists the
> > bit as "Reserved for Audio Output Enable", and empirical evidence
> > te
Quoting Arkadiusz Hiler (2017-12-01 13:19:54)
> With Android support gone there is not much reason for keeping libunwind
> dependency optional. This also deals (cheaply!) with ifdefs covering
> huge portions of code, removing a placement minefield.
>
> Cc: Tvrtko Ursulin
> Cc: Chris Wilson
> Sig
Quoting Mika Kuoppala (2017-12-01 14:16:39)
> Add option to specify engine for register read/write operation.
> If engine is specified, use MI_LOAD_REGISTER_IMM and MI_STORE_REGISTER_IMM
> to write and read register using a batch targeted at that engine.
>
> v2: no MI_NOOP after BBE (Chris)
>
> C
Quoting Michal Wajdeczko (2017-12-01 14:09:31)
> On Fri, 01 Dec 2017 13:36:06 +0100, Chris Wilson
> wrote:
>
> > Quoting Michal Wajdeczko (2017-12-01 10:33:15)
> >> We currently have two module parameters that control GuC:
> >> "enable_guc_loading" and "enable_guc_submission". Whenever
> >> we
== Series Details ==
Series: tools/intel_reg: Add reading and writing registers through engine
URL : https://patchwork.freedesktop.org/series/34755/
State : failure
== Summary ==
IGT patchset build failed on latest successful build
476c4b462e0453c70ee81664c0227fdddc26cbd0 igt/gem_eio: Increase
Add option to specify engine for register read/write operation.
If engine is specified, use MI_LOAD_REGISTER_IMM and MI_STORE_REGISTER_IMM
to write and read register using a batch targeted at that engine.
v2: no MI_NOOP after BBE (Chris)
Cc: Jani Nikula
Cc: Chris Wilson
CC: Joonas Lahtinen
Sig
On Fri, Dec 1, 2017 at 2:36 AM, Daniel Vetter wrote:
> On Fri, Dec 01, 2017 at 12:53:31PM +0530, Ramalingam C wrote:
>> Sean,
>>
>> IMHO, it will good if we can have all generic hdcp1.4 authentication flow in
>> drm helpers and all interested display drivers to use them.
>>
>> This Design will mak
On Fri, Dec 1, 2017 at 3:36 AM, Ramalingam C wrote:
>
>
>
> On Friday 01 December 2017 01:06 PM, Daniel Vetter wrote:
>>
>> On Fri, Dec 01, 2017 at 12:53:31PM +0530, Ramalingam C wrote:
>>>
>>> Sean,
>>>
>>> IMHO, it will good if we can have all generic hdcp1.4 authentication flow in
>>> drm helpe
On Fri, Dec 1, 2017 at 2:36 AM, Daniel Vetter wrote:
> On Fri, Dec 01, 2017 at 12:53:31PM +0530, Ramalingam C wrote:
> > Sean,
> >
> > IMHO, it will good if we can have all generic hdcp1.4 authentication
> flow in
> > drm helpers and all interested display drivers to use them.
> >
> > This Design
On Fri, 01 Dec 2017 13:36:06 +0100, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2017-12-01 10:33:15)
We currently have two module parameters that control GuC:
"enable_guc_loading" and "enable_guc_submission". Whenever
we need submission=1, we also need loading=1. We also need
loading=1 whe
== Series Details ==
Series: drm/i915: Sleep and retry a GPU reset if at first we don't succeed
(rev2)
URL : https://patchwork.freedesktop.org/series/34747/
State : success
== Summary ==
Test drv_selftest:
Subgroup mock_sanitycheck:
pass -> DMESG-WARN (shard-snb)
== Series Details ==
Series: igt: Make dependency on libunwind mandatory
URL : https://patchwork.freedesktop.org/series/34752/
State : success
== Summary ==
IGT patchset tested on top of latest successful build
476c4b462e0453c70ee81664c0227fdddc26cbd0 igt/gem_eio: Increase wakeup delay for
in
Quoting Arkadiusz Hiler (2017-12-01 13:19:54)
> With Android support gone there is not much reason for keeping libunwind
> dependency optional. This also deals (cheaply!) with ifdefs covering
> huge portions of code, removing a placement minefield.
Could also force building with frame-pointers? I'
== Series Details ==
Series: igt/gem_ctx_isolation: Check isolation of registers between contexts
(rev9)
URL : https://patchwork.freedesktop.org/series/32531/
State : failure
== Summary ==
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-indfb-pgflip-blt:
skip
Quoting Mika Kuoppala (2017-12-01 13:20:29)
> Chris Wilson writes:
>
> > As we declare the GPU wedged if the reset fails, such a failure is quite
> > terminal. Before taking that drastic action, let's sleep first and try
> > active, in the hope that the hardware has quietened down and is then
> >
On Thu, Nov 30, 2017 at 04:18:53PM +0100, Maarten Lankhorst wrote:
> Normally this is called on a modeset, but the call is missing when
> we inherit the mode from the BIOS, so make sure it's called somewhere
> in hardware readout.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915
== Series Details ==
Series: drm/i915: Remove unsafe i915.enable_rc6 (rev4)
URL : https://patchwork.freedesktop.org/series/21884/
State : success
== Summary ==
Test pm_rc6_residency:
Subgroup rc6p-accuracy:
skip -> PASS (shard-snb)
Test kms_flip:
Sub
Chris Wilson writes:
> As we declare the GPU wedged if the reset fails, such a failure is quite
> terminal. Before taking that drastic action, let's sleep first and try
> active, in the hope that the hardware has quietened down and is then
> able to reset. After a few such attempts, it is fair to
With Android support gone there is not much reason for keeping libunwind
dependency optional. This also deals (cheaply!) with ifdefs covering
huge portions of code, removing a placement minefield.
Cc: Tvrtko Ursulin
Cc: Chris Wilson
Signed-off-by: Arkadiusz Hiler
---
configure.ac | 12 ++
== Series Details ==
Series: test/kms_plane_lowres: Fix display_commit_mode() so it returns the crc
URL : https://patchwork.freedesktop.org/series/34749/
State : warning
== Summary ==
IGT patchset tested on top of latest successful build
476c4b462e0453c70ee81664c0227fdddc26cbd0 igt/gem_eio: In
Quoting Michal Wajdeczko (2017-12-01 10:33:15)
> We currently have two module parameters that control GuC:
> "enable_guc_loading" and "enable_guc_submission". Whenever
> we need submission=1, we also need loading=1. We also need
> loading=1 when we want to want to load and verify the HuC.
>
> Lets
Compiler complained on crc_lowres and crc_hires2 being uninitialized
and indeed, display_commit_mode() seems to have intention of retruning
the value through the parameter that is only a single pointer.
This couses only the local copy of the pointer, the one inside
display_commit_mode(), to be ove
== Series Details ==
Series: drm/i915: Sleep and retry a GPU reset if at first we don't succeed
(rev2)
URL : https://patchwork.freedesktop.org/series/34747/
State : success
== Summary ==
Series 34747v2 drm/i915: Sleep and retry a GPU reset if at first we don't
succeed
https://patchwork.freed
Quoting Michal Wajdeczko (2017-12-01 10:33:16)
> Our new "enable_guc" modparam allows to control whenever HuC
> should be loaded. However existing code will try load and
> authenticate HuC always when we use the GuC. This patch is
> trying to enforce modparam selection.
>
> Signed-off-by: Michal W
Quoting Michal Wajdeczko (2017-12-01 10:33:14)
> -EIO has special meaning and is used when we want to allow
> engine initialization to fail and mark GPU as wedged.
> Missing firmware does not fit into this scenario as this is
> permanent error not related to GPU condition.
>
> Signed-off-by: Micha
Quoting Michal Wajdeczko (2017-12-01 10:33:13)
> In the upcoming patch we will change the way how to recognize
> when GuC is in use. Using helper macros will minimize scope
> of that changes. While here, update dev_info message.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Chris Wilson
> Cc: Joonas
Quoting Michal Wajdeczko (2017-12-01 10:33:12)
> Doing GuC firmware path selection from sanitize_options function
> is not perfect, while there is no problem with doing so during
> early init stage as we already have all needed data.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Chris Wilson
> Cc: J
== Series Details ==
Series: igt/gem_ctx_isolation: Check isolation of registers between contexts
(rev9)
URL : https://patchwork.freedesktop.org/series/32531/
State : success
== Summary ==
IGT patchset tested on top of latest successful build
476c4b462e0453c70ee81664c0227fdddc26cbd0 igt/gem_e
Quoting Michal Wajdeczko (2017-12-01 10:33:11)
> Doing HuC firmware path selection from sanitize_options function
> is not perfect, while there is no problem with doing so during
> early init stage as we already have all needed data.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Chris Wilson
> Cc: J
As we declare the GPU wedged if the reset fails, such a failure is quite
terminal. Before taking that drastic action, let's sleep first and try
active, in the hope that the hardware has quietened down and is then
able to reset. After a few such attempts, it is fair to say that the HW
is truly wedge
Quoting Chris Wilson (2017-12-01 12:12:40)
> As we declare the GPU wedged if the reset fails, such a failure is quite
> terminal. Before taking that drastic action, let's sleep first and try
> active, in the hope that the hardware has quietened down and is then
> able to reset. After a few such att
As we declare the GPU wedged if the reset fails, such a failure is quite
terminal. Before taking that drastic action, let's sleep first and try
active, in the hope that the hardware has quietened down and is then
able to reset. After a few such attempts, it is fair to say that the HW
is truly wedge
== Series Details ==
Series: igt/gem_eio: Increase wakeup delay for in-flight-suspend (rev2)
URL : https://patchwork.freedesktop.org/series/34691/
State : failure
== Summary ==
Series 34691 revision 2 was fully merged or fully failed: no git log
___
== Series Details ==
Series: drm/i915: Remove unsafe i915.enable_rc6 (rev4)
URL : https://patchwork.freedesktop.org/series/21884/
State : success
== Summary ==
Series 21884v4 drm/i915: Remove unsafe i915.enable_rc6
https://patchwork.freedesktop.org/api/1.0/series/21884/revisions/4/mbox/
fi-bd
It has been many years since the last confirmed sighting (and fix) of an
RC6 related bug (usually a system hang). Remove the parameter to stop
users from setting dangerous values, as they often set it during triage
and end up disabling the entire runtime pm instead (the option is not a
fine scalpel
A new context assumes that all of its registers are in the default state
when it is created. What may happen is that a register written by one
context may leak into the second, causing mass confusion.
v2: Extend back to Sandybridge (etc)
v3: Check context preserves registers across suspend/hiberna
== Series Details ==
Series: series starting with [v2,1/7] drm/i915/huc: Move firmware selection to
init_early
URL : https://patchwork.freedesktop.org/series/34738/
State : warning
== Summary ==
Series 34738v1 series starting with [v2,1/7] drm/i915/huc: Move firmware
selection to init_early
Quoting Mika Kuoppala (2017-12-01 10:40:24)
> Chris Wilson writes:
>
> > To execute a requests requires us to have first woken the device, using
> > the rpm wakeref (as the request needs to write to hardware to setup the
> > context/ppGTT and execute on the GPU). So call intel_runtime_pm_get()
>
Chris Wilson writes:
> To execute a requests requires us to have first woken the device, using
> the rpm wakeref (as the request needs to write to hardware to setup the
> context/ppGTT and execute on the GPU). So call intel_runtime_pm_get()
> around queuing the request; the request itself will th
For in-flight-suspend, we need to wait for the GPU hang within
i915_gem_suspend(). This will take 10-20s, which means that the standard
wakeup delay of around 15s may occur before we complete the suspend.
This causes a pm_system_wakeup(), causing dpm_suspend() to return
-EBUSY.
Signed-off-by: Chri
We currently have two module parameters that control GuC:
"enable_guc_loading" and "enable_guc_submission". Whenever
we need submission=1, we also need loading=1. We also need
loading=1 when we want to want to load and verify the HuC.
Lets combine above module parameters into one "enable_guc"
modp
-EIO has special meaning and is used when we want to allow
engine initialization to fail and mark GPU as wedged.
Missing firmware does not fit into this scenario as this is
permanent error not related to GPU condition.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Sag
Chris Wilson writes:
> For in-flight-suspend, we need to wait for the GPU hang within
> i915_gem_suspend(). This will take 10-20s, which means that the standard
> wakeup delay of around 15s may occur before we complete the suspend.
> This causes a pm_system_wakeup(), causing dpm_suspend() to retu
Doing HuC firmware path selection from sanitize_options function
is not perfect, while there is no problem with doing so during
early init stage as we already have all needed data.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Sagar Arun Kamble
---
drivers/gpu/drm/i
Also revert ("drm/i915/guc: Assert that we switch between
known ggtt->invalidate functions")
v2: don't enable GuC on GLK
Signed-off-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 8 ++--
drivers/gpu/drm/i915/i915_params.h | 2 +-
drivers/gpu/drm/i915/intel_uc.c | 2 ++
In the upcoming patch we will change the way how to recognize
when GuC is in use. Using helper macros will minimize scope
of that changes. While here, update dev_info message.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i
1 - 100 of 110 matches
Mail list logo
