Hi Ramalingam,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20190215]
[cannot apply to v5.0-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system
== Series Details ==
Series: drm/i915: Reduce the RPS shock
URL : https://patchwork.freedesktop.org/series/56740/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5611_full -> Patchwork_12228_full
Summary
---
**SUCCESS*
Hi Ramalingam,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[cannot apply to v5.0-rc4 next-20190215]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
== Series Details ==
Series: drm/i915/fbdev: Actually configure untiled displays
URL : https://patchwork.freedesktop.org/series/56728/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5611_full -> Patchwork_12227_full
Summary
Hi Ramalingam,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20190215]
[cannot apply to v5.0-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system
On 2/14/19 1:45 PM, Sujaritha Sundaresan wrote:
This aim of this patch is to call guc_disable_communication in all
suspend paths. The reason to introduce this is to resolve a bug that
occured due to suspend late not being called in the hibernate devices
path.
And we shouldn't anyway talk to
On 2/15/19 2:48 PM, Chris Wilson wrote:
Preemption via GuC submission quickly degrades into confused firmware
and misordered requests. It is not being supported with no intention of
being fixed in its current incarnation, so remove the unstable code. By
removing the workqueue from the GuC submi
== Series Details ==
Series: drm/i915: Restore interrupt enabling after a reset (rev3)
URL : https://patchwork.freedesktop.org/series/56761/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5612 -> Patchwork_12234
Summary
== Series Details ==
Series: drm/i915/icl: Fix checks for userspace ctm + ycbcr output
URL : https://patchwork.freedesktop.org/series/56770/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5612 -> Patchwork_12233
Summary
== Series Details ==
Series: drm/i915/guc: Remove preemption support for current fw
URL : https://patchwork.freedesktop.org/series/56767/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5612 -> Patchwork_12232
Summary
---
On Fri, 2019-02-15 at 00:17 +, Souza, Jose wrote:
> On Thu, 2019-02-14 at 16:10 -0800, Pandiyan, Dhinakaran wrote:
> > On Thu, 2019-02-14 at 15:19 -0800, Souza, Jose wrote:
> > > On Thu, 2019-02-14 at 11:00 -0800, Dhinakaran Pandiyan wrote:
> > > > On Wed, 2019-02-13 at 18:02 -0800, José Robert
== Series Details ==
Series: drm/i915: Restore interrupt enabling after a reset (rev2)
URL : https://patchwork.freedesktop.org/series/56761/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5612 -> Patchwork_12231
Summary
== Series Details ==
Series: drm/i915/guc: Remove preemption support for current fw
URL : https://patchwork.freedesktop.org/series/56767/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/guc: Remove preemption support for current fw
-drivers/gpu
At least on i965g and i965gm, performing a device reset clobbers the IER
resulting in loss of interrupts thereafter. So, run the irq_postinstall
hook to restore them.
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reset.c | 2 ++
1 file changed, 2 insertions(+)
dif
We recently added support for gen11's new "output csc" which can be used
independently of the regular pipe CSC. The idea is that this new output
csc allows us to use a userspace-provided color transformation matrix at
the same time we drive a YCBCR display mode requiring RGB->YUV
conversion. Howe
== Series Details ==
Series: drm/i915: Implement HDCP2.2
URL : https://patchwork.freedesktop.org/series/56757/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
DESCEND objtool
CHK include/generated/compile.h
CC [M] drivers/gpu/drm/i915/intel_hdcp.o
In file included fr
Preemption via GuC submission quickly degrades into confused firmware
and misordered requests. It is not being supported with no intention of
being fixed in its current incarnation, so remove the unstable code. By
removing the workqueue from the GuC submission path, we can now do
direct engine-rese
At least on i965g and i965gm, performing a device reset clobbers the IER
resulting in loss of interrupts thereafter. So, run the irq_postinstall
hook to restore them.
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
---
Put it back to restoring the GMCH first. Hmm, maybe that's the key as to
which
At least on i965g and i965gm, performing a device reset clobbers the IER
resulting in loss of interrupts thereafter. So, run the irq_postinstall
hook to restore them.
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
---
This feels a bit hairy, so maybe limit it to
INTEL_INFO()->reset_clobbers_displ
== Series Details ==
Series: drm/i915/selftests: Fix resource leak in __sseu_prepare (rev2)
URL : https://patchwork.freedesktop.org/series/56755/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5611 -> Patchwork_12229
Summary
Quoting Chris Wilson (2019-02-15 17:00:30)
> Limit deboosting and boosting to keep ourselves at the extremes
> when in the respective power modes (i.e. slowly decrease frequencies
> while in the HIGH_POWER zone and slowly increase frequencies while
> in the LOW_POWER zone). On idle, we will hit the
On Fri, 2019-02-15 at 23:34 +0200, Ville Syrjälä wrote:
> On Fri, Feb 15, 2019 at 01:06:32PM -0800, Dhinakaran Pandiyan wrote:
> > On Fri, 2019-02-15 at 14:47 +0200, Ville Syrjälä wrote:
> > > On Thu, Feb 14, 2019 at 06:26:29PM -0800, Dhinakaran Pandiyan
> > > wrote:
> > > > On Thu, 2019-02-14 at 2
On Fri, Feb 15, 2019 at 01:06:32PM -0800, Dhinakaran Pandiyan wrote:
> On Fri, 2019-02-15 at 14:47 +0200, Ville Syrjälä wrote:
> > On Thu, Feb 14, 2019 at 06:26:29PM -0800, Dhinakaran Pandiyan wrote:
> > > On Thu, 2019-02-14 at 21:22 +0200, Ville Syrjala wrote:
> > > > From: Ville Syrjälä
> > > >
On Fri, 2019-02-15 at 14:47 +0200, Ville Syrjälä wrote:
> On Thu, Feb 14, 2019 at 06:26:29PM -0800, Dhinakaran Pandiyan wrote:
> > On Thu, 2019-02-14 at 21:22 +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > DP CRCs don't really work on g4x. If you want any CRCs on DP you
> > > m
Provides Pairing info to ME to store.
Pairing is a process to fast track the subsequent authentication
with the same HDCP sink.
On Success, received HDCP pairing info is stored in non-volatile
memory of ME.
v2: Rebased.
v3:
cldev is passed as first parameter [Tomas]
Redundant comments and ca
From: Tomas Winkler
Export to_mei_cl_device macro, it is needed also in mei client drivers.
Signed-off-by: Tomas Winkler
Signed-off-by: Ramalingam C
---
drivers/misc/mei/bus.c | 1 -
include/linux/mei_cl_bus.h | 2 ++
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/m
Requests for the verification of AKE_Send_H_prime.
ME will calculate the H and comparing it with received H_Prime.
The result will be returned as status.
Here AKE_Send_H_prime is a HDCP2.2 Authentication msg.
v2: Rebased.
v3:
cldev is passed as first parameter [Tomas]
Redundant comments and
Requests for verification for receiver certification and also the
preparation for next AKE auth message with km.
On Success ME FW validate the HDCP2.2 receivers certificate and do the
revocation check on the receiver ID. AKE_Stored_Km will be prepared if
the receiver is already paired, else AKE_No
ME FW contributes a vital role in HDCP2.2 authentication.
HDCP2.2 driver needs to communicate to ME FW for each step of the
HDCP2.2 authentication.
ME FW prepare and HDCP2.2 authentication parameters and encrypt them
as per spec. With such parameter Driver prepares HDCP2.2 auth messages
and commu
Request to ME to prepare the encrypted session key.
On Success, ME provides Encrypted session key. Function populates
the HDCP2.2 authentication msg SKE_Send_Eks.
v2: Rebased.
v3:
cldev is passed as first parameter [Tomas]
Redundant comments and cast are removed [Tomas]
v4:
%zd for ssize_t
Request to ME to verify the M_Prime received from the HDCP sink.
ME FW will calculate the M and compare with M_prime received
as part of RepeaterAuth_Stream_Ready, which is HDCP2.2 protocol msg.
On successful completion of this stage, downstream propagation of
the stream management info is comple
Mei hdcp driver is designed as component slave for the I915 component
master.
v2: Rebased.
v3:
Notifier chain is adopted for cldev state update [Tomas]
v4:
Made static dummy functions as inline in mei_hdcp.h
API for polling client device status
IS_ENABLED used in header, for config status
Requests ME to start the second stage of HDCP2.2 authentication,
called Locality Check.
On Success, ME FW will provide LC_Init message to send to hdcp sink.
v2: Rebased.
v3:
cldev is passed as first parameter [Tomas]
Redundant comments and cast are removed [Tomas]
v4:
%zd used for ssize_t [
FOR TESTING PURPOSE ONLY.
By default INTEL_MEI_HDCP is set to y. This patch is created to
test the interface between I915 and MEI_HDCP.
Signed-off-by: Ramalingam C
---
drivers/misc/mei/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/misc/mei/Kconfig b/drivers/misc/mei/Kconfi
Defines the HDCP specific ME FW interfaces such as Request CMDs,
payload structure for CMDs and their response status codes.
This patch defines payload size(Excluding the Header)for each WIRED
HDCP2.2 CMDs.
v2: Rebased.
v3:
Extra comments are removed.
v4:
%s/\/\*\*/\/\*
v5:
Extra lines are
Request the ME to terminate the HDCP2.2 session for a port.
On Success, ME FW will mark the intel port as Deauthenticated and
terminate the wired HDCP2.2 Tx session started due to the cmd
WIRED_INITIATE_HDCP2_SESSION.
v2: Rebased.
v3:
cldev is passed as first parameter [Tomas]
Redundant comme
Implements the
Waitqueue is created to wait for CP_IRQ
Signaling the CP_IRQ arrival through atomic variable.
For applicable DP HDCP2.2 msgs read wait for CP_IRQ.
As per HDCP2.2 spec "HDCP Transmitters must process CP_IRQ interrupts
when they are received from HDCP Receivers
Implements the DP adaptation specific HDCP2.2 functions.
These functions perform the DPCD read and write for communicating the
HDCP2.2 auth message back and forth.
v2:
wait for cp_irq is merged with this patch. Rebased.
v3:
wait_queue is used for wait for cp_irq [Chris Wilson]
v4:
Style fix
When repeater notifies a downstream topology change, this patch
reauthenticate the repeater alone without disabling the hdcp
encryption. If that fails then complete reauthentication is executed.
v2:
Rebased.
v3:
Typo in commit msg is fixed [Uma]
v4:
Rebased as part of patch reordering.
Min
From: Tomas Winkler
Whitelist HDCP client for in kernel drm use
v2:
Rebased.
Signed-off-by: Tomas Winkler
Signed-off-by: Ramalingam C
---
drivers/misc/mei/bus-fixup.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/misc/mei/bus-fixup.c b/drivers/misc/mei/bus-f
Time period for HDCP2.2 link check.
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
Reviewed-by: Uma Shankar
---
include/drm/drm_hdcp.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index 7260b31af276..d4e98b11b4aa 100644
--- a/inclu
Since DP ERRATA message is not defined at spec, those structure
definition is removed from drm_hdcp.h
Signed-off-by: Ramalingam C
Suggested-by: Daniel Vetter
Reviewed-by: Daniel Vetter
Reviewed-by: Uma Shankar
---
include/drm/drm_hdcp.h | 6 --
1 file changed, 6 deletions(-)
diff --git a
HDCP transmitter is supposed to indicate the HDCP encryption status of
the link through enc_en signals in a window of time called "window of
opportunity" defined by HDCP HDMI spec.
But on KBL this timing of signalling has an issue. To fix the issue this
WA of resetting the signalling is required.
Request ME FW to start the HDCP2.2 session for an intel port.
Prepares payloads for command WIRED_INITIATE_HDCP2_SESSION and sends
to ME FW.
On Success, ME FW will start a HDCP2.2 session for the port and
provides the content for HDCP2.2 AKE_Init message.
v2: Rebased.
v3:
cldev is add as a sepa
Implements the HDMI adaptation specific HDCP2.2 operations.
Basically these are DDC read and write for authenticating through
HDCP2.2 messages.
v2: Rebased.
v3:
No more special handling of Gmbus burst read for AKE_SEND_CERT.
Style fixed with few naming. [Uma]
%s/PARING/PAIRING
v4:
msg_sz
Request to ME to configure a port as authenticated.
On Success, ME FW will mark the port as authenticated and provides
HDCP cipher with the encryption keys.
Enabling the Authentication can be requested once all stages of
HDCP2.2 authentication is completed by interacting with ME FW.
Only after t
Request to ME to verify the LPrime received from HDCP sink.
On Success, ME FW will verify the received Lprime by calculating and
comparing with L.
This represents the completion of Locality Check.
v2: Rebased.
v3:
cldev is passed as first parameter [Tomas]
Redundant comments and cast are rem
Request ME to verify the downstream topology information received.
ME FW will validate the Repeaters receiver id list and
downstream topology.
On Success ME FW will provide the Least Significant
128bits of VPrime, which forms the repeater ack.
v2: Rebased.
v3:
cldev is passed as first paramete
Implements the HDCP2.2 repeaters authentication steps such as verifying
the downstream topology and sending stream management information.
v2: Rebased.
v3:
-EINVAL is returned for topology error and rollover scenario.
Endianness conversion func from drm_hdcp.h is used [Uma]
v4:
Rebased as pa
This series enables the HDCP2.2 Type 0 for I915. The sequence for
HDCP2.2 authentication and encryption is implemented as a generic flow
between HDMI and DP. Encoder specific implementations are moved
into hdcp_shim.
Intel HWs supports HDCP2.2 through ME FW. Hence this series
introduces a client d
"hdcp_encrypted" flag is defined to denote the HDCP1.4 encryption status.
This SW tracking is used to determine the need for real hdcp1.4 disable
and hdcp_check_link upon CP_IRQ.
On CP_IRQ we filter the CP_IRQ related to the states like Link failure
and reauthentication req etc and handle them in
Implements HDCP2.2 authentication for hdcp2.2 receivers, with
following steps:
Authentication and Key exchange (AKE).
Locality Check (LC).
Session Key Exchange(SKE).
DP Errata for stream type configuration for receivers.
At AKE, the HDCP Receiver’s public key certif
Add the HDCP2.2 initialization to the existing HDCP1.4 stack.
v2:
mei interface handle is protected with mutex. [Chris Wilson]
v3:
Notifiers are used for the mei interface state.
v4:
Poll for mei client device state
Error msg for out of mem [Uma]
Inline req for init function removed [Uma
All HDCP1.4 routines are gathered together, followed by the generic
functions those can be extended for HDCP2.2 too.
Signed-off-by: Ramalingam C
Acked-by: Daniel Vetter
Reviewed-by: Uma Shankar
Reviewed-by: Tomas Winkler
---
drivers/gpu/drm/i915/intel_hdcp.c | 118 +++-
Considering that HDCP2.2 is more secure than HDCP1.4, When a setup
supports HDCP2.2 and HDCP1.4, HDCP2.2 will be enabled.
When HDCP2.2 enabling fails and HDCP1.4 is supported, HDCP1.4 is
enabled.
This change implements a sequence of enabling and disabling of
HDCP2.2 authentication and HDCP2.2 por
Implements the link integrity check once in 500mSec.
Once encryption is enabled, an ongoing Link Integrity Check is
performed by the HDCP Receiver to check that cipher synchronization
is maintained between the HDCP Transmitter and the HDCP Receiver.
On the detection of synchronization lost, the H
Defining the mei-i915 interface functions and initialization of
the interface.
v2:
Adjust to the new interface changes. [Tomas]
Added further debug logs for the failures at MEI i/f.
port in hdcp_port data is equipped to handle -ve values.
v3:
mei comp is matched for global i915 comp master
== Series Details ==
Series: drm/i915: Reduce the RPS shock
URL : https://patchwork.freedesktop.org/series/56740/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5611 -> Patchwork_12228
Summary
---
**SUCCESS**
No re
== Series Details ==
Series: drm/i915: Reduce the RPS shock
URL : https://patchwork.freedesktop.org/series/56740/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
df5adf51e321 drm/i915: Reduce the RPS shock
-:32: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit
== Series Details ==
Series: drm/i915/fbdev: Actually configure untiled displays
URL : https://patchwork.freedesktop.org/series/56728/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5611 -> Patchwork_12227
Summary
---
== Series Details ==
Series: drm/i915/fbdev: Actually configure untiled displays
URL : https://patchwork.freedesktop.org/series/56728/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/fbdev: Actually configure untiled displays
-O:drivers/gpu/drm
Prepare a nice little onion unwind to ensure that we always free the
spinner if we __sseu_prepare fails.
Fixes: c06ee6ff2cbc ("drm/i915/selftests: Context SSEU reconfiguration tests")
Reported-by: Radhakrishna Sripada
Signed-off-by: Chris Wilson
Cc: Radhakrishna Sripada
Cc: Tvrtko Ursulin
Cc:
Quoting Chris Wilson (2019-02-15 19:40:06)
> Quoting Radhakrishna Sripada (2019-02-15 19:35:54)
> > Fix the resource leak reported by static code checker.
>
> The caller already frees spin on error, so you just need to set the
> output and report the error.
Nah, doesn't look at tidy as a proper o
On Fri, 2019-02-08 at 13:49 -0800, Kevin Strasser wrote:
> This series defines new formats and adds implementation to the i915 driver.
> Since posting v1 I have removed the pixel normalize property, as it's not
> needed
> for basic functionality. Also, I have been working on adding support to
> us
Quoting Radhakrishna Sripada (2019-02-15 19:35:54)
> Fix the resource leak reported by static code checker.
The caller already frees spin on error, so you just need to set the
output and report the error.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists
Fix the resource leak reported by static code checker.
Cc: Tvrtko Ursulin
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/selftests/i915_gem_context.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
Quoting Patchwork (2019-02-15 18:11:23)
> == Series Details ==
>
> Series: series starting with [1/2] drm/i915/selftests: Exercise resetting
> during non-user payloads
> URL : https://patchwork.freedesktop.org/series/56716/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_
== Series Details ==
Series: series starting with [1/2] drm/i915/selftests: Exercise resetting
during non-user payloads
URL : https://patchwork.freedesktop.org/series/56716/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5608 -> Patchwork_12226
On Fri, Feb 15, 2019 at 02:05:04PM +0530, Ramalingam C wrote:
> Library functions for endianness are aligned for 16/32/64 bits.
> But hdcp sequence numbers are 24bits(big endian).
> So for their conversion to and from u32 helper functions are developed.
>
> v2:
> Comment is updated. [Daniel]
>
On Fri, Feb 15, 2019 at 02:05:00PM +0530, Ramalingam C wrote:
> Defining the mei-i915 interface functions and initialization of
> the interface.
>
> v2:
> Adjust to the new interface changes. [Tomas]
> Added further debug logs for the failures at MEI i/f.
> port in hdcp_port data is equipped
On Fri, Feb 15, 2019 at 02:04:58PM +0530, Ramalingam C wrote:
> Header defines the interface for the I915 and MEI_HDCP drivers.
> This interface is specific to the usage of mei_hdcp from gen9+
> platforms for ME FW based HDCP2.2 services.
>
> And Generic HDCP2.2 protocol specific definitions
> are
On Fri, Feb 15, 2019 at 02:04:57PM +0530, Ramalingam C wrote:
> For the reusability of the enum port in other driver modules
> (like mei_hdcp), enum port definition is moved from I915 local header
> intel_display.h to drm/i915_drm.h
>
> Signed-off-by: Ramalingam C
> Acked-by: Daniel Vetter
Appl
== Series Details ==
Series: series starting with [1/2] drm/i915/selftests: Exercise resetting
during non-user payloads
URL : https://patchwork.freedesktop.org/series/56716/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3473db45d1ed drm/i915/selftests: Exercise resetting durin
The DP 1.4 spec defines the SDP header and SDP contents for
a Picture Parameter Set (PPS) that must be sent in advance
of DSC transmission to define the encoding characteristics.
This was done in one struct, drm_dsc_pps_infoframe, which
conatined the SDP header and PPS. Because the PPS is
a prope
drm_dsc could use some work so that drm drivers other than
i915 can make use of it their own DSC implementations
Move rc compute, a function that forms part of the DSC spec,
into drm. Update it to DSC 1.2. Also split the PPS packing and
SDP header init functions, to allow for drivers with
their ow
The function intel_compute_rc_parameters is part of the dsc spec
and is not driver-specific. Other drm drivers might like to use
it. The function is not changed; just moved and renamed.
Reviewed-by: Harry Wentland
Signed-off-by: David Francis
---
drivers/gpu/drm/drm_dsc.c | 135 +++
Limit deboosting and boosting to keep ourselves at the extremes
when in the respective power modes (i.e. slowly decrease frequencies
while in the HIGH_POWER zone and slowly increase frequencies while
in the LOW_POWER zone). On idle, we will hit the timeout and drop
to the next level quickly, and co
Quoting Maarten Lankhorst (2019-02-15 16:02:40)
> Op 15-02-2019 om 13:30 schreef Chris Wilson:
> > If we skipped all the connectors that were not part of a tile, we would
> > leave conn_seq=0 and conn_configured=0, convincing ourselves that we
> > had stagnated in our configuration attempts. Avoid
Op 15-02-2019 om 13:30 schreef Chris Wilson:
> If we skipped all the connectors that were not part of a tile, we would
> leave conn_seq=0 and conn_configured=0, convincing ourselves that we
> had stagnated in our configuration attempts. Avoid this situation by
> starting conn_seq=ALL_CONNECTORS, an
Op 15-02-2019 om 13:30 schreef Chris Wilson:
> If we skipped all the connectors that were not part of a tile, we would
> leave conn_seq=0 and conn_configured=0, convincing ourselves that we
> had stagnated in our configuration attempts. Avoid this situation by
> starting conn_seq=ALL_CONNECTORS, an
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-02-15 15:21:11)
>> Chris Wilson writes:
>>
>> > Since we no longer need to hold struct_mutex to perform a global device
>> > reset, don't do so for igt_reset_wedge().
>> >
>>
>> Oh but the interesting question is not about need, but should =)
Quoting Mika Kuoppala (2019-02-15 15:18:08)
> Chris Wilson writes:
>
> > In selftests/live_hangcheck, we have a lot of tests for resetting simple
> > spinners, but nothing quite prepared us for how the GPU reacted to
> > triggering a reset outside of the safe spinner. These two subtests fill
> >
Quoting Mika Kuoppala (2019-02-15 15:21:11)
> Chris Wilson writes:
>
> > Since we no longer need to hold struct_mutex to perform a global device
> > reset, don't do so for igt_reset_wedge().
> >
>
> Oh but the interesting question is not about need, but should =)
> Do it both ways?
Just doing i
Chris Wilson writes:
> Since we no longer need to hold struct_mutex to perform a global device
> reset, don't do so for igt_reset_wedge().
>
Oh but the interesting question is not about need, but should =)
Do it both ways?
-Mika
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> driv
Chris Wilson writes:
> In selftests/live_hangcheck, we have a lot of tests for resetting simple
> spinners, but nothing quite prepared us for how the GPU reacted to
> triggering a reset outside of the safe spinner. These two subtests fill
> the ring with plain old empty, non-spinning requests, an
Quoting Jani Nikula (2019-02-15 12:34:02)
> Please replace the above with
>
> // SPDX-License-Identifier: MIT
> /*
> * Copyright © 2019 Intel Corporation
> */
>
> Ditto for all new files being added. (Except .h which will need to have
> old style /* ... */ comments around the first line.)
Rebe
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-02-15 14:40:30)
>> Chris Wilson writes:
>>
>> > As we have moved to rcu/srcu to serialise the resets, individual resets
>> > are subject to small variations in system grace periods. Allow for this
>> > by only expecting the median reset time to
Quoting Mika Kuoppala (2019-02-15 14:40:30)
> Chris Wilson writes:
>
> > As we have moved to rcu/srcu to serialise the resets, individual resets
> > are subject to small variations in system grace periods. Allow for this
> > by only expecting the median reset time to be within our target, thereby
On Thu, Feb 14, 2019 at 06:26:29PM -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2019-02-14 at 21:22 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > DP CRCs don't really work on g4x. If you want any CRCs on DP you must
> > select the CRC source before the port is enabled, otherwise the
On Fri, 15 Feb 2019 05:32:14 +0100, Srivatsa, Anusha
wrote:
Resending this again, didn’t get Delivered the last time I sent.
Sending PR for latest Guc v31.3.0 for ICL and Gen9 platforms.
The following changes since commit
710963fe53ee3f227556d36839df3858daf6e232:
Merge https://github
On Thu, Feb 14, 2019 at 05:45:31PM -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2019-02-14 at 17:32 -0800, Dhinakaran Pandiyan wrote:
> > On Thu, 2019-02-14 at 21:22 +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > The "pipe" and "pf" crc sources are in fact the same thing.
> > >
Chris Wilson writes:
> As we currently do not check on submission whether the context is banned
> in a timely manner it is possible for some requests to escape
> cancellation after their parent context is banned. By moving the ban
> into the request submission under the engine->timeline.lock, we
Quoting Petri Latvala (2019-02-15 10:47:09)
> On Fri, Feb 15, 2019 at 10:41:58AM +, Chris Wilson wrote:
> > We don't need to waste time running perf-only test cases when we are not
> > manually checking results. ezbench is that away!
> >
> > References: https://bugs.freedesktop.org/show_bug.cg
On Fri, Feb 15, 2019 at 10:41:58AM +, Chris Wilson wrote:
> We don't need to waste time running perf-only test cases when we are not
> manually checking results. ezbench is that away!
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=109640
> Signed-off-by: Chris Wilson
> ---
Remo
Chris Wilson writes:
> Older platforms need to clobber the display around a reset (incl. a
> modeset to off, and a modeset back on), which can be much slower than
> the reset itself. Give these platforms (gen2-4) some leniency and allow
> them a higher limit before declaring them a failure.
>
> S
On Thu, 14 Feb 2019, Matthew Auld wrote:
> Really simply buddy allocator.
>
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Abdiel Janulgue
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> drivers/gpu/drm/i915/i915_gem_buddy.c | 206 +
> driver
We force a reset on test exit so that we can rapidly cleanup after a
naughty test, it is not unknown for us to leave a queue of hanging
batches around. However, if we have also fiddled with the i915.reset
parameter in the meantime, this can leave the kernel unable to fulfil
our request (and those n
Chris Wilson writes:
> Currently, we only try to reset a live engine for checking the whitelist
> retention across a per-engine reset. For safety, it appears we need to
> prime the system with a hanging spinner before performing a full-device
> reset. (Figuring out the root cause behind the insta
Since we no longer need to hold struct_mutex to perform a global device
reset, don't do so for igt_reset_wedge().
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftest
Chris Wilson writes:
> As we have moved to rcu/srcu to serialise the resets, individual resets
> are subject to small variations in system grace periods. Allow for this
> by only expecting the median reset time to be within our target, thereby
> excluding noisy outliers from perturbing our result
1 - 100 of 152 matches
Mail list logo
