== Series Details ==
Series: drm/i915: Implement HDCP2.2 (rev8)
URL : https://patchwork.freedesktop.org/series/38254/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4488 -> Patchwork_9656 =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_9656 absolut
== Series Details ==
Series: drm/i915: Implement HDCP2.2 (rev8)
URL : https://patchwork.freedesktop.org/series/38254/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm: hdcp2.2 authentication msg definitions
Okay!
Commit: drm: HDMI and DP specific HDCP2.2 defines
Okay!
Co
== Series Details ==
Series: drm/i915: Implement HDCP2.2 (rev8)
URL : https://patchwork.freedesktop.org/series/38254/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1656b0942fab drm: hdcp2.2 authentication msg definitions
ffcfc502c0d2 drm: HDMI and DP specific HDCP2.2 defines
b6
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 parame
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_
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 r
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 com
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
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 ar
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
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
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 se
ME FW is 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 co
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
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 an
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.
Note: Chris Wilson suggested alternate method for waiting for CP_IRQ,
than completions concept. WIP to understand and implement that,
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 Changes.
v4:
No more special handling of Gmbus burst read for AKE_SEND_CERT.
Style fixed with few naming. [Uma]
%s/PARING/P
On HDMI connector init, intel_hdcp_init is passed with a flag for hdcp2.2
support based on the platform capability.
v2:
Rebased.
v3:
No Changes.
v4:
Collected the reviewed-by received.
v5:
No change.
v6:
No change.
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/gpu/
On DP connector init, intel_hdcp_init is passed with a flag for hdcp2.2
support based on the platform capability.
v2:
Rebased.
v3:
No Changes.
v4:
Collected the reviewed-by received.
v5:
No change.
v6:
No change.
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/gpu/dr
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 statu
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
HDCP check link is invoked only on CP_IRQ detection, instead of all
short pulses.
v3:
No Changes.
v4:
Added sean in cc and collected the reviewed-by received.
v5:
No Change.
v6:
No Change.
Signed-off-by: Ramalingam C
cc: Sean Paul
Reviewed-by: Uma Shankar
Reviewed-by: Sean Paul
---
d
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:
No Changes.
v4:
Typo in commit msg is fixed [Uma]
v5:
Rebased as part of patch
On DP HDCP1.4 and 2.2, when CP_IRQ is received, start the link
integrity check for the HDCP version that is enabled.
v2:
Rebased. Function name is changed.
v3:
No Changes.
v4:
No Changes.
v5:
No Changes.
v6:
%s/_in_force/_in_use [Sean Paul]
Signed-off-by: Ramalingam C
cc: Sean Paul
Re
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
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
For reusability purpose, this patch implements the hdcp1.4 bksv's
read and validation as a functions.
For detecting the HDMI panel's HDCP capability this fucntions will be
used.
v2:
Rebased.
v3:
No Changes.
v4:
inline tag is removed with modified error msg.
v5:
No Changes.
v6:
No Change
Implements the HDCP2.2 repeaters authentication steps such as verifying
the downstream topology and sending stream management information.
v2:
Rebased.
v3:
No Changes.
v4:
-EINVAL is returned for topology error and rollover scenario.
Endianness conversion func from drm_hdcp.h is used [Uma]
Intel HDCP2.2 registers are defined with addr offsets and bit details.
v2:
Replaced the arith calc with _PICK [Sean Paul]
v3:
No changes.
v4:
%s/HDCP2_CTR_DDI/HDCP2_CTL_DDI [Uma]
v5:
Added parentheses for the parameters of macro.
v6:
No changes
Signed-off-by: Ramalingam C
Reviewed-by:
If all the components associated to a component master is not added
to the component framework due to the HW capability or Kconfig
selection, component_match will be NULL at
component_master_add_with_match().
To avoid this, component_match_alloc() is added to the framework,
to allcoate the struct
Initialize HDCP2.2 support. This includes the mei interface
initialization along with required component registration.
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
This patch defines the hdcp2.2 protocol messages for authentication.
v2:
bit_fields are removed. Instead bitmasking used. [Tomas and Jani]
prefix HDCP_2_2_ is added to the macros. [Tomas]
v3:
No Changes.
v4:
Style and spellings are fixed [Uma]
v5:
Fix for macros.
v6:
comment for Type i
A generic component master is added to hold the i915 registration
until all required kernel modules are up and active.
This is achieved through following steps:
- moving the i915 driver registration to the component master's
bind call
- all required kernel modules w
The sequence for HDCP2.2 authentication and encryption is implemented
in I915. Encoder specific implementations are moved into hdcp_shim.
Intel HWs supports HDCP2.2 through ME FW. Hence this series
introduces a client driver for mei bus, so that for HDCP2.2
authentication, HDCP2.2 stack in I915 ca
From: Tomas Winkler
Whitelist HDCP client for in kernel drm use
v2:
Rebased.
v3:
No changes.
v4:
No changes.
v5:
No changes.
v6:
No changes
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/bus-fixup.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/mis
Data structures and Enum for the I915-MEI_HDCP interface are defined
at
v2:
Rebased.
v3:
mei_cl_device is removed from mei_hdcp_data [Tomas]
v4:
Comment style and typo fixed [Uma]
v5:
Rebased.
v6:
No changes.
Signed-off-by: Ramalingam C
---
include/linux/mei_hdcp.h | 100
This patch adds HDCP register definitions for HDMI and DP HDCP
adaptations.
HDMI specific HDCP2.2 register definitions are added into drm_hdcp.h,
where as HDCP2.2 register offsets in DPCD offsets are defined at
drm_dp_helper.h.
v2:
bit_field definitions are replaced by macros. [Tomas and Jani]
Considering significant number of HDCP specific variables, it will
be clean to have separate struct for HDCP.
New structure called intel_hdcp is added within intel_connector.
v2:
struct hdcp statically allocated. [Sean Paul]
enable and disable function parameters are retained.[Sean Paul]
v3:
== Series Details ==
Series: drm/i915/dp: Give up link training clock recovery after 10 failed
attempts (rev2)
URL : https://patchwork.freedesktop.org/series/46506/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4488 -> Patchwork_9655 =
== Summary - SUCCESS ==
No regress
Limit the link training clock recovery loop to 10 failed attempts at
LANEx_CR_DONE per DP 1.4 spec section 3.5.1.2.2. Some USB-C MST hubs
cause us to get stuck in this loop indefinitely requesting
voltage swing: 0, pre-emphasis level: 2
voltage swing: 1, pre-emphasis level: 2
voltage s
On 7/13/2018 2:56 AM, Tvrtko Ursulin wrote:
From: John Harrison
Improve the timeline legend to show actual context colours.
v2: (Tvrtko Ursulin)
* Commit msg.
* Tweak layout for more compactness and more readability.
v3:
* Limit number of shown contexts in the legend. (John Harrison)
S
On 07/13/2018 04:37 PM, NeilBrown wrote:
> On Wed, Jul 11 2018, Andrew Morton wrote:
>
>> On Wed, 11 Jul 2018 13:51:08 +0200 Daniel Vetter wrote:
>>
>>> But I still have the situation that a bunch of maintainers acked this
>>> and Andrew Morton defacto nacked it, which I guess means I'll keep the
On Fri, Jul 13, 2018 at 03:18:32PM -0700, Manasi Navare wrote:
> On Fri, Jul 13, 2018 at 03:23:41PM -0700, Dhinakaran Pandiyan wrote:
> > On Fri, 2018-07-13 at 14:22 -0700, Rodrigo Vivi wrote:
> > > On Fri, Jul 13, 2018 at 10:32:15AM -0700, Nathan Ciobanu wrote:
> > > >
> > > > Limit the link trai
Em Sex, 2018-07-13 às 14:08 -0700, Rodrigo Vivi escreveu:
> On Wed, Jul 11, 2018 at 02:59:02PM -0700, Paulo Zanoni wrote:
> > Use the hardcoded tables provided by our spec.
> >
> > v2:
> > - SSC stays disabled.
> > - Use intel_port_is_tc().
> >
> > Cc: Anusha Srivatsa
> > Signed-off-by: Paul
On Fri, Jul 13, 2018 at 02:22:03PM -0700, Rodrigo Vivi wrote:
> On Fri, Jul 13, 2018 at 10:32:15AM -0700, Nathan Ciobanu wrote:
> > Limit the link training clock recovery loop to 10 failed attempts at
> > LANEx_CR_DONE per DP 1.4 spec.
>
> Where exactly in the spec?
I'll add the section number to
Hi Dave,
This is probably the last pull request for 4.19 from our side.
Please remind about the gvt-fixes vs gvt-next conflict that I mentioned
yesterday on drm-intel-fixes pull request.
Here goes drm-intel-next-2018-07-12:
On GVT there's the addition of vGPU huge page support for guest,
with on
On Fri, Jul 13, 2018 at 03:23:41PM -0700, Dhinakaran Pandiyan wrote:
> On Fri, 2018-07-13 at 14:22 -0700, Rodrigo Vivi wrote:
> > On Fri, Jul 13, 2018 at 10:32:15AM -0700, Nathan Ciobanu wrote:
> > >
> > > Limit the link training clock recovery loop to 10 failed attempts
> > > at
> > > LANEx_CR_DO
On Fri, 2018-07-13 at 14:22 -0700, Rodrigo Vivi wrote:
> On Fri, Jul 13, 2018 at 10:32:15AM -0700, Nathan Ciobanu wrote:
> >
> > Limit the link training clock recovery loop to 10 failed attempts
> > at
> > LANEx_CR_DONE per DP 1.4 spec.
> Where exactly in the spec?
>
> >
> > Some USB-C MST hubs
On Fri, Jul 13, 2018 at 10:32:15AM -0700, Nathan Ciobanu wrote:
> Limit the link training clock recovery loop to 10 failed attempts at
> LANEx_CR_DONE per DP 1.4 spec.
Where exactly in the spec?
> Some USB-C MST hubs cause us to get
> stuck in this loop on hot-plugging indefinitely as
> drm_dp_cl
== Series Details ==
Series: series starting with [1/3] drm/i915/selftests: Include the start of
each subtest in the GEM trace
URL : https://patchwork.freedesktop.org/series/46514/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4488 -> Patchwork_9654 =
== Summary - SUCCESS
On Wed, Jul 11, 2018 at 02:59:02PM -0700, Paulo Zanoni wrote:
> Use the hardcoded tables provided by our spec.
>
> v2:
> - SSC stays disabled.
> - Use intel_port_is_tc().
>
> Cc: Anusha Srivatsa
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_dpll_mgr.c | 22 ++
On Fri, Jul 13, 2018 at 11:43:47AM -0700, Paulo Zanoni wrote:
> Em Sex, 2018-07-13 às 11:04 -0700, Rodrigo Vivi escreveu:
> > On Fri, Jul 13, 2018 at 10:20:27AM -0700, Paulo Zanoni wrote:
> > > Em Qui, 2018-07-12 às 17:16 -0700, Rodrigo Vivi escreveu:
> > > > On Wed, Jul 11, 2018 at 02:59:02PM -070
== Series Details ==
Series: series starting with [1/3] drm/i915/selftests: Include the start of
each subtest in the GEM trace
URL : https://patchwork.freedesktop.org/series/46514/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
94e02a131d36 drm/i915/selftests: Include the start
== Series Details ==
Series: series starting with [1/4] drm/i915/execlists: Check reset_in_progress()
URL : https://patchwork.freedesktop.org/series/46513/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4488 -> Patchwork_9653 =
== Summary - FAILURE ==
Serious unknown chan
On 7/13/2018 1:41 PM, Chris Wilson wrote:
Quoting Chris Wilson (2018-07-13 21:35:28)
Inside intel_engine_is_idle(), we flush the tasklet to ensure that is
being run in a timely fashion (ksoftirqd has taught us to expect the
worst). However, if we are in the middle of reset, the HW may not yet be
Quoting Chris Wilson (2018-07-13 21:35:28)
> Inside intel_engine_is_idle(), we flush the tasklet to ensure that is
> being run in a timely fashion (ksoftirqd has taught us to expect the
> worst). However, if we are in the middle of reset, the HW may not yet be
> ready to execute the submission task
On 7/13/2018 1:35 PM, Chris Wilson wrote:
Inside intel_engine_is_idle(), we flush the tasklet to ensure that is
being run in a timely fashion (ksoftirqd has taught us to expect the
worst). However, if we are in the middle of reset, the HW may not yet be
ready to execute the submission tasklet and
Quoting Chris Wilson (2018-07-13 21:35:27)
> Knowing the boundary of each subtest can be instrumental in digesting
> the voluminous trace output and finding the critical piece of
> information.
>
> Signed-off-by: Chris Wilson
From the other thread,
Reviewed-by: Michel Thierry
-Chris
== Series Details ==
Series: series starting with [1/4] drm/i915/execlists: Check reset_in_progress()
URL : https://patchwork.freedesktop.org/series/46513/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
05763b37e58a drm/i915/execlists: Check reset_in_progress()
6ca6d5421808 drm/
Inside intel_engine_is_idle(), we flush the tasklet to ensure that is
being run in a timely fashion (ksoftirqd has taught us to expect the
worst). However, if we are in the middle of reset, the HW may not yet be
ready to execute the submission tasklet and so we must respect the
disable flag.
Fixes
With the new CSB processing code, we are not vulnerable to delayed
delivery of a pre-reset interrupt as we use the CSB status pointers in
the HWSP to decide if we need to parse any CSB events and no longer need
to wait for the first post-reset interrupt to be assured that the CSB
mmio registers are
Knowing the boundary of each subtest can be instrumental in digesting
the voluminous trace output and finding the critical piece of
information.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/i915_selftest.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i9
Quoting Chris Wilson (2018-07-13 21:18:45)
> Check that reset_in_progress() is true when we process the reset.
Grr called from sanitize, so this is fatal across suspend.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.free
On 7/13/2018 1:18 PM, Chris Wilson wrote:
Knowing the boundary of each subtest can be instrumental in digesting
the voluminous trace output and finding the critical piece of
information.
Signed-off-by: Chris Wilson
Reviewed-by: Michel Thierry
---
drivers/gpu/drm/i915/selftests/i915_selfte
On 7/13/2018 1:18 PM, Chris Wilson wrote:
Check that reset_in_progress() is true when we process the reset.
Signed-off-by: Chris Wilson
Reviewed-by: Michel Thierry
---
drivers/gpu/drm/i915/intel_lrc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b
Check that reset_in_progress() is true when we process the reset.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 35d37af0cb9a..dd9f9219d7f1 100644
--- a
Inside intel_engine_is_idle(), we flush the tasklet to ensure that is
being run in a timely fashion (ksoftirqd has taught us to expect the
worst). However, if we are in the middle of reset, the HW may not yet be
ready to execute the submission tasklet and so we must respect the
disable flag.
Fixes
With the new CSB processing code, we are not vulnerable to delayed
delivery of a pre-reset interrupt as we use the CSB status pointers in
the HWSP to decide if we need to parse any CSB events and no longer need
to wait for the first post-reset interrupt to be assured that the CSB
mmio registers are
Knowing the boundary of each subtest can be instrumental in digesting
the voluminous trace output and finding the critical piece of
information.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/i915_selftest.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i9
== Series Details ==
Series: series starting with [v3] drm/i915/icl: Add remaining registers and
bitfields for MG PHY DDI (rev3)
URL : https://patchwork.freedesktop.org/series/45623/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4488 -> Patchwork_9652 =
== Summary - SUCCES
== Series Details ==
Series: series starting with [v3] drm/i915/icl: Add remaining registers and
bitfields for MG PHY DDI (rev3)
URL : https://patchwork.freedesktop.org/series/45623/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ce48abb9636a drm/i915/icl: Add remaining registe
This patch adds the remaining register definitions and bit fields
required for MG PHy DDI buffer initializations and voltage
swing programming for MG PHy DDI ports.
While at it this patch also fixes the naming for previously defined
MG PHY registers in original commit id (c92f47b5ec977a "drm/i915/
Em Sex, 2018-07-13 às 11:04 -0700, Rodrigo Vivi escreveu:
> On Fri, Jul 13, 2018 at 10:20:27AM -0700, Paulo Zanoni wrote:
> > Em Qui, 2018-07-12 às 17:16 -0700, Rodrigo Vivi escreveu:
> > > On Wed, Jul 11, 2018 at 02:59:02PM -0700, Paulo Zanoni wrote:
> > > > Use the hardcoded tables provided by ou
Thanks for the review comments.
On Thu, Jul 12, 2018 at 05:00:42PM -0700, Paulo Zanoni wrote:
> Em Qui, 2018-06-28 às 15:35 -0700, Manasi Navare escreveu:
> > This patch adds the remaining register definitions and bit fields
> > required for MG PHy DDI buffer initializations and voltage
> > swing
Quoting Antonio Argenziano (2018-07-13 19:22:41)
>
>
> On 13/07/18 03:06, Chris Wilson wrote:
> > From: Antonio Argenziano
> >
> > An hanging batch is nothing more than a spinning batch that never gets
> > stopped, so re-use the routines implemented in dummyload.c.
> >
> > v2: Let caller decid
== Series Details ==
Series: drm/i915/dp: Give up link training clock recovery after 10 failed
attempts
URL : https://patchwork.freedesktop.org/series/46506/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4487 -> Patchwork_9651 =
== Summary - SUCCESS ==
No regressions fo
Quoting Michal Wajdeczko (2018-07-13 18:57:33)
> On Fri, 13 Jul 2018 19:52:09 +0200, Chris Wilson
> wrote:
>
> > Quoting Michal Wajdeczko (2018-07-13 18:48:05)
> >> On Fri, 13 Jul 2018 19:26:58 +0200, Chris Wilson
> >> wrote:
> >>
> >> > Hopefully the final hack to get guc fault-injection happ
On 13/07/18 03:06, Chris Wilson wrote:
From: Antonio Argenziano
An hanging batch is nothing more than a spinning batch that never gets
stopped, so re-use the routines implemented in dummyload.c.
v2: Let caller decide spin loop size
v3: Only use loose loops for hangs (Chris)
v4: No requires
v
On Fri, Jul 13, 2018 at 10:20:27AM -0700, Paulo Zanoni wrote:
> Em Qui, 2018-07-12 às 17:16 -0700, Rodrigo Vivi escreveu:
> > On Wed, Jul 11, 2018 at 02:59:02PM -0700, Paulo Zanoni wrote:
> > > Use the hardcoded tables provided by our spec.
> > >
> > > v2:
> > > - SSC stays disabled.
> > > - U
== Series Details ==
Series: drm/i915/guc: Protect against no desc-pool on premature shutdown
URL : https://patchwork.freedesktop.org/series/46503/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4487 -> Patchwork_9650 =
== Summary - SUCCESS ==
No regressions found.
Ext
On Fri, 13 Jul 2018 19:52:09 +0200, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2018-07-13 18:48:05)
On Fri, 13 Jul 2018 19:26:58 +0200, Chris Wilson
wrote:
> Hopefully the final hack to get guc fault-injection happy before we
can
> clean it up again, starting from a known good baseli
This was always a placeholder for GVT stakeholders to provide some
better tests. 2 years later and none have been put forward so stop
wasting CI's time running a placeholder.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106989
Signed-off-by: Chris Wilson
Cc: Zhi Wang
---
tests/Makefil
On Fri, Jul 13, 2018 at 06:26:58PM +0100, Chris Wilson wrote:
> Hopefully the final hack to get guc fault-injection happy before we can
> clean it up again, starting from a known good baseline...
>
> [ 383.017530] BUG: unable to handle kernel NULL pointer dereference at
> 00a0
> [ 3
Quoting Michal Wajdeczko (2018-07-13 18:48:05)
> On Fri, 13 Jul 2018 19:26:58 +0200, Chris Wilson
> wrote:
>
> > Hopefully the final hack to get guc fault-injection happy before we can
> > clean it up again, starting from a known good baseline...
> >
> > [ 383.017530] BUG: unable to handle ker
On Fri, 13 Jul 2018 19:26:58 +0200, Chris Wilson
wrote:
Hopefully the final hack to get guc fault-injection happy before we can
clean it up again, starting from a known good baseline...
[ 383.017530] BUG: unable to handle kernel NULL pointer dereference at
00a0
[ 383.017556]
On 2018-07-13 12:40, Tvrtko Ursulin wrote:
On 12/07/2018 16:10, Tomasz Lis wrote:
The patch adds a parameter to control the data port coherency
functionality
on a per-context level. When the IOCTL is called, a command to switch
data
port coherency state is added to the ordered list. All prio
Limit the link training clock recovery loop to 10 failed attempts at
LANEx_CR_DONE per DP 1.4 spec. Some USB-C MST hubs cause us to get
stuck in this loop on hot-plugging indefinitely as
drm_dp_clock_recovery_ok() never returns true and none of the
other conditions occur.
Signed-off-by: Nathan Cio
As we try to blit into the buffer to check CPU<->GPU snooping, we have
to check we have a functional GPU first.
Signed-off-by: Chris Wilson
---
tests/gem_pwrite_snooped.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tests/gem_pwrite_snooped.c b/tests/gem_pwrite_snooped.c
index b19339560
Hopefully the final hack to get guc fault-injection happy before we can
clean it up again, starting from a known good baseline...
[ 383.017530] BUG: unable to handle kernel NULL pointer dereference at
00a0
[ 383.017556] Oops: [#1] PREEMPT SMP PTI
[ 383.017566] CPU: 7 PID: 4725
Em Qui, 2018-07-12 às 17:16 -0700, Rodrigo Vivi escreveu:
> On Wed, Jul 11, 2018 at 02:59:02PM -0700, Paulo Zanoni wrote:
> > Use the hardcoded tables provided by our spec.
> >
> > v2:
> > - SSC stays disabled.
> > - Use intel_port_is_tc().
> >
> > Cc: Anusha Srivatsa
> > Signed-off-by: Paul
== Series Details ==
Series: series starting with [1/4] drm: Move page_flip fb lookup earlier
URL : https://patchwork.freedesktop.org/series/46494/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4486 -> Patchwork_9649 =
== Summary - SUCCESS ==
No regressions found.
Ext
== Series Details ==
Series: series starting with [1/4] drm: Move page_flip fb lookup earlier
URL : https://patchwork.freedesktop.org/series/46494/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
01d1f2a2abaa drm: Move page_flip fb lookup earlier
7f5dae95e6b4 drm: Allocate the pa
== Series Details ==
Series: series starting with [v3,1/2] drm/i915: remove confusing GPIO vs
PCH_GPIO
URL : https://patchwork.freedesktop.org/series/46493/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4486 -> Patchwork_9648 =
== Summary - SUCCESS ==
No regressions fou
On Fri, Jul 13, 2018 at 08:42:11AM -0700, Lucas De Marchi wrote:
> Instead of defining all registers twice, define just a PCH_GPIO_BASE
> that has the same address as PCH_GPIO_A and use that to calculate all
> the others. This also brings VLV and !HAS_GMCH_DISPLAY in line, doing
> the same thing.
>
== Series Details ==
Series: series starting with [v3,1/2] drm/i915: remove confusing GPIO vs
PCH_GPIO
URL : https://patchwork.freedesktop.org/series/46493/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: remove confusing GPIO vs PCH_GPIO
-drivers/gpu/drm/i915/self
From: Ville Syrjälä
Can't see why we need to delay the page flip event allocation until the
last moment. Move it earlier to simplify error handling.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_plane.c | 45 +++--
1 file changed, 23 insertions(+)
From: Ville Syrjälä
Instead of doing the things in a convoluted way with the failure and
success paths mixed up let's just clear old_fb when we encounter an
error and bail out immediately.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_plane.c | 32 +---
1 fil
From: Ville Syrjälä
Yank out the code for the plane->fb/old_fb/crtc handling from
the page flip path into page_flip_internal(), and provide a
simpler variant for atomic drivers.
We'll also move the fb vs. src viewport checks into the new
functions as they are slightly different between the two p
From: Ville Syrjälä
No reason that I can see to delay the fb lookup this late. Moving it
earlier allows us to keep it outside of the lock retry loop. This
makes error handling and whatnot simpler.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_plane.c | 29 +++--
1 - 100 of 163 matches
Mail list logo
