On Tue, Jun 26, 2018 at 10:47:14PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use drm_crtc_mask() where appropriate.
>
> Cc: Maxime Ripard
> Signed-off-by: Ville Syrjälä
Acked-by: Maxime Ripard
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel
This is the v2 of RFC based on the feedback I've received so far. The
code even compiles as a bonus ;) I haven't runtime tested it yet, mostly
because I have no idea how.
Any further feedback is highly appreciated of course.
---
From ec9a7241bf422b908532c4c33953b0da2655ad05 Mon Sep 17 00:00:00 200
On Tue, 2018-06-26 at 22:47 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use drm_plane_mask() where appropriate.
>
> Cc: Philipp Zabel
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/imx/ipuv3-crtc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/dri
From: Vathsala Nagaraju
Prints live state of psr1.Extending the existing
PSR2 live state function to cover psr1.
Tested on KBL with psr2 and psr1 panel.
v2: rebase
v3: DK
Rename psr2_live_status to psr_source_status.
v4: DK
Move EDP_PSR_STATUS_STATE_SHIFT below EDP_PSR_STATUS_STATE_MASK
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
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]
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.
Signed-off-by: Ramaling
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.
Signed-off-by: Ramalingam C
---
include/linux/mei_hdcp.h | 100 ++
For upcoming implementation of HDCP2.2 in I915, important variable
required for HDCP2.2 are defined.
HDCP_shim is extended to support encoder specific HDCP2.2 flows.
v2:
1.4 shim is extended to support hdcp2.2. [Sean Paul]
platform's/panel's hdcp ver capability is removed. [Sean Paul]
mei r
== Series Details ==
Series: ALSA: hda - Handle pm failure during hotplug
URL : https://patchwork.freedesktop.org/series/45463/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c8ac3d11b058 ALSA: hda - Handle pm failure during hotplug
-:13: WARNING:COMMIT_LOG_LONG_LINE: Possible u
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.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915
From: Tomas Winkler
Whitelist HDCP client for in kernel drm use
v2:
Rebased.
v3:
No changes.
v4:
No changes.
v5:
No changes.
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/bus-fixup.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/misc/mei/bus-fixup.c
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
As a preparation for making the intel_hdcp_enable as common function
for both HDCP1.4 and HDCP2.2, HDCP1.4 check_link scheduling is moved
into _intel_hdcp_enable() function.
v3:
No Changes.
v4:
Style fix.
v5:
No Change.
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/gpu
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:
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.
Signed-off-by:
When HDCP2.2 enabling fails and HDCP1.4 is supported, HDCP1.4 is
enabled.
v2:
Rebased.
v3:
No Changes.
v4:
Reviewed-by is collected.
v5:
No Change.
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_hdcp.c | 4 +++-
1 file changed, 3 insertions(+), 1 de
Considering that HDCP2.2 is more secure than HDCP1.4, When a setup
supports HDCP2.2 and HDCP1.4, HDCP2.2 will be enabled.
v2:
Included few optimization suggestions [Chris Wilson]
Commit message is updated as per the rebased version.
v3:
No changes.
v4:
Extra comment added and Style issue f
Implements a sequence of enabling and disabling the HDCP2.2
(auth and encryption).
v2:
Rebased.
v3:
No Changes.
v4:
No Changes.
v5:
Rebased as part of the patch reordering.
HDCP2 encryption status is tracked.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 105
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.
Signed-off-by: Ramalingam C
cc: Sean Paul
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_dp.c | 9 --
Implements the enable and disable functions for HDCP2.2 encryption
of the PORT.
v2:
intel_wait_for_register is used instead of wait_for. [Chris Wilson]
v3:
No Changes.
v4:
Debug msg is added for timeout at Disable of Encryption [Uma]
%s/HDCP2_CTL/HDCP2_CTL
v5:
Rebased as part of patch re
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
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
GMBUS HW supports 511Bytes as Max Bytes per single RD/WR op. Instead of
enabling the 511Bytes per RD/WR cycle on legacy platforms for no
absolute ROIs, this change allows the max bytes per op upto 511Bytes
from Gen9 onwards.
v2:
No Change.
v3:
Inline function for max_xfer_size and renaming of
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,
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
Support for Burst read in HW is added for HDCP2.2 compliance
requirement.
This patch enables the burst read for all the gmbus read of more than
511Bytes, on capable platforms.
v2:
Extra line is removed.
v3:
Macro is added for detecting the BURST_READ Support [Jani]
Runtime detection of the
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.
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_hd
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.
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_dp.c
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]
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
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
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
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.
Signed-off-by: Ramalingam C
cc: Sean Paul
---
drivers/gpu/drm/i915/intel_dp.c |
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
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
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
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
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 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 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 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
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 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
On Tue, Jun 26, 2018 at 11:41:44PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Update drm_atomic_helper_commit_planes_on_crtc() to use explicit old/new
> states instead of relying on obj->state.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/dr
On Tue, Jun 26, 2018 at 08:47:07PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Instead of using the .best_encoder() hook to figure out whether a given
> connector+crtc combo will work, let's instead do what userspace does and
> just iterate over all the encoders for the connector, and t
On Tue, Jun 26, 2018 at 08:47:08PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> With the fb-helper no longer relying on the non-atomic .best_encoder()
> we can eliminate the hook from the MST encoder.
>
> Cc: Dhinakaran Pandiyan
> Signed-off-by: Ville Syrjälä
Yay!
Reviewed-by: Danie
== Series Details ==
Series: mm, oom: distinguish blockable mode for mmu notifiers (rev5)
URL : https://patchwork.freedesktop.org/series/45263/
State : failure
== Summary ==
Applying: mm, oom: distinguish blockable mode for mmu notifiers
Using index info to reconstruct a base tree...
M a
== Series Details ==
Series: ALSA: hda - Handle pm failure during hotplug
URL : https://patchwork.freedesktop.org/series/45463/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4383 -> Patchwork_9435 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://
On Tue, Jun 26, 2018 at 08:47:09PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add a convenience macro for iterating connector->encoder_ids[].
> Isolates the users from the implementation details.
>
> Also use ARRAY_SIZE() when populating the array to avoid spreading
> knowledge about
On Wed, Jun 27, 2018 at 11:08:48AM +0200, Daniel Vetter wrote:
> On Tue, Jun 26, 2018 at 08:47:09PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Add a convenience macro for iterating connector->encoder_ids[].
> > Isolates the users from the implementation details.
> >
> > Also use
== Series Details ==
Series: drm/i915/psr: Add psr1 live status (rev3)
URL : https://patchwork.freedesktop.org/series/45143/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4383 -> Patchwork_9437 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://pat
On Tue, 26 Jun 2018, "Gustavo A. R. Silva" wrote:
> Hi Jani,
>
> On 06/21/2018 03:03 AM, Jani Nikula wrote:
>> On Wed, 20 Jun 2018, "Gustavo A. R. Silva" wrote:
>>> On 06/20/2018 02:06 PM, Rodrigo Vivi wrote:
On Wed, Jun 20, 2018 at 08:31:00AM -0500, Gustavo A. R. Silva wrote:
> In prepa
On 26/06/2018 12:50, Chris Wilson wrote:
In the following patch, we will process the CSB events under the
timeline.lock and not serialised by the tasklet. This also means that we
will need to protect access to common variables such as
execlists->csb_head with the timeline.lock during reset.
v2:
On 25/06/2018 10:48, Chris Wilson wrote:
In the next patch, we will process the CSB events directly from the
submission path, rather than only after a CS interrupt. Hence, we will
no longer have the need for a loop until the has-interrupt bit is clear,
and in the meantime can remove that small o
== Series Details ==
Series: drm/i915: Implement HDCP2.2 (rev6)
URL : https://patchwork.freedesktop.org/series/38254/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5492406c5fd4 drm: hdcp2.2 authentication msg definitions
141f5ef87658 drm: HDMI and DP specific HDCP2.2 defines
c2
On 25/06/2018 10:48, Chris Wilson wrote:
Following the removal of the last workarounds, the only CSB mmio access
is for the old vGPU interface. The mmio registers presented by vGPU do
not require forcewake and can be treated as ordinary volatile memory,
i.e. they behave just like the HWSP access
== Series Details ==
Series: drm/i915: Implement HDCP2.2 (rev6)
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 (rev6)
URL : https://patchwork.freedesktop.org/series/38254/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4383 -> Patchwork_9438 =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_9438 absolut
== Series Details ==
Series: ALSA: hda - Handle pm failure during hotplug
URL : https://patchwork.freedesktop.org/series/45463/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4383_full -> Patchwork_9435_full =
== Summary - WARNING ==
Minor unknown changes coming with Patc
Quoting Tvrtko Ursulin (2018-06-27 10:46:37)
>
> On 25/06/2018 10:48, Chris Wilson wrote:
> > In the next patch, we will process the CSB events directly from the
> > submission path, rather than only after a CS interrupt. Hence, we will
> > no longer have the need for a loop until the has-interrup
Quoting Tvrtko Ursulin (2018-06-27 10:52:45)
>
> On 25/06/2018 10:48, Chris Wilson wrote:
> > @@ -1109,16 +1089,11 @@ static void process_csb(struct intel_engine_cs
> > *engine)
> > } else {
> > port_set(port, port_pack(rq, count));
> > }
> > -
On 25/06/2018 10:48, Chris Wilson wrote:
Back in commit 27af5eea54d1 ("drm/i915: Move execlists irq handler to a
bottom half"), we came to the conclusion that running our CSB processing
and ELSP submission from inside the irq handler was a bad idea. A really
bad idea as we could impose nearly 1s
In the next patch, we will process the CSB events directly from the
submission path, rather than only after a CS interrupt. Hence, we will
no longer have the need for a loop until the has-interrupt bit is clear,
and in the meantime can remove that small optimisation.
v2: Tvrtko pointed out it was
On 25/06/2018 10:48, Chris Wilson wrote:
Our long standing defense against a single client from flooding the
system with requests (causing mempressure and stalls across the whole
system) is to retire the old request on every allocation. (By retiring
the oldest, we try to keep returning requests
Quoting Tvrtko Ursulin (2018-06-27 11:40:32)
>
> On 25/06/2018 10:48, Chris Wilson wrote:
> > Back in commit 27af5eea54d1 ("drm/i915: Move execlists irq handler to a
> > bottom half"), we came to the conclusion that running our CSB processing
> > and ELSP submission from inside the irq handler was
== Series Details ==
Series: series starting with [01/31] drm/i915: Defer modeset cleanup to a
secondary task (rev3)
URL : https://patchwork.freedesktop.org/series/45325/
State : failure
== Summary ==
Applying: drm/i915: Defer modeset cleanup to a secondary task
Using index info to reconstruc
== Series Details ==
Series: drm/i915/psr: Add psr1 live status (rev3)
URL : https://patchwork.freedesktop.org/series/45143/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4383_full -> Patchwork_9437_full =
== Summary - WARNING ==
Minor unknown changes coming with Patchwo
Quoting Tvrtko Ursulin (2018-06-27 11:57:39)
>
> On 25/06/2018 10:48, Chris Wilson wrote:
> > Our long standing defense against a single client from flooding the
> > system with requests (causing mempressure and stalls across the whole
> > system) is to retire the old request on every allocation.
---
drivers/gpu/drm/i915/i915_drv.c | 8
drivers/gpu/drm/i915/i915_drv.h | 12
drivers/gpu/drm/i915/i915_request.c | 7 +--
3 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 5b
On HW reset, the HW clears the write pointer (to 0). But since it also
writes its first CSB entry to slot 0, we need to reset the write pointer
back to the element before (so the first entry we read is 0).
This is required for the next patch, where we trust the CSB completely!
Signed-off-by: Chri
I really must remember to proof read git send-email.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On 25/06/2018 10:48, Chris Wilson wrote:
In the next patch, we will start to defer retiring the request from the
engine list if it is still active on the submission backend. To preserve
the semantics that after wait-for-idle completes the system is idle and
fully retired, we need to therefore wa
In the next patch, we will process the CSB events directly from the
submission path, rather than only after a CS interrupt. Hence, we will
no longer have the need for a loop until the has-interrupt bit is clear,
and in the meantime can remove that small optimisation.
v2: Tvrtko pointed out it was
Following the removal of the last workarounds, the only CSB mmio access
is for the old vGPU interface. The mmio registers presented by vGPU do
not require forcewake and can be treated as ordinary volatile memory,
i.e. they behave just like the HWSP access just at a different location.
We can reduce
Back in commit 27af5eea54d1 ("drm/i915: Move execlists irq handler to a
bottom half"), we came to the conclusion that running our CSB processing
and ELSP submission from inside the irq handler was a bad idea. A really
bad idea as we could impose nearly 1s latency on other users of the
system, on av
In the following patch, we will process the CSB events under the
timeline.lock and not serialised by the tasklet. This also means that we
will need to protect access to common variables such as
execlists->csb_head with the timeline.lock during reset.
v2: Move sync_irq to avoid deadlocks between ta
In the next patch, we will begin processing the CSB from inside the
submission path (underneath an irqsoff section, and even from inside
interrupt handlers). This means that updating the execlists->port[] will
no longer be serialised by the tasklet but needs to be locked by the
engine->timeline.loc
On HW reset, the HW clears the write pointer (to 0). But since it also
writes its first CSB entry to slot 0, we need to reset the write pointer
back to the element before (so the first entry we read is 0).
This is required for the next patch, where we trust the CSB completely!
Signed-off-by: Chri
Quoting Tvrtko Ursulin (2018-06-27 12:32:35)
>
> To me this order makes more sense in general.
Apart from the cries of struct_mutex, no! I feel a chill go up my spline
for every i915_retire_requests(). (How on earth are we going to dig
ourselves out of this one? One hopes the globals can be const
Op 26-06-18 om 19:59 schreef Ville Syrjälä:
> On Mon, Jun 25, 2018 at 06:37:58PM +0200, Maarten Lankhorst wrote:
>> The only time we should start FBC is when we have waited a vblank
>> after the atomic update.
> What about front buffer tracking? Is this going to leave FBC permanently
> disabled unl
On Thu, 21 Jun 2018, Ville Syrjälä wrote:
> On Thu, Jun 21, 2018 at 04:03:30PM +0300, Jani Nikula wrote:
>> Commit 9504a8924759 ("drm/i915/vlv: Reset the ADPA in
>> vlv_display_power_well_init()") started calling intel_crt_reset()
>> directly, while we could just as well use the hooks and keep the
In the next^W forthcoming patch, we will start to defer retiring the
request from the engine list if it is still active on the submission
backend. To preserve the semantics that after wait-for-idle completes
the system is idle and fully retired, we need to therefore wait for the
backends to idle be
On Tue, Jun 26, 2018 at 05:28:06PM -0700, Paulo Zanoni wrote:
> Em Ter, 2018-06-26 às 17:22 +0300, Imre Deak escreveu:
> > Add the definition for ICL power wells and their mapping to power
> > domains. On ICL there are 3 power well control registers, we'll
> > select
> > the correct one based on hi
On Tue, 26 Jun 2018, Mahesh Kumar wrote:
> This patch implements "verify_crc_source" callback function for
> rockchip drm driver.
>
> Signed-off-by: Mahesh Kumar
> Cc: dri-de...@lists.freedesktop.org
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 21 +
> 1 file changed
Hello,
Beginning with 4.18, when I lock my X server using the `xlock` command,
and close the lid, upon reopening the lid I am not presented with the
xlock UI.
The system is not hung. If I blindly enter the password, I get an
intact and functional pointer but none of the desktop is displayed. I
On Wed, Jun 27, 2018 at 11:03:31AM +0200, Daniel Vetter wrote:
> On Tue, Jun 26, 2018 at 08:47:07PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Instead of using the .best_encoder() hook to figure out whether a given
> > connector+crtc combo will work, let's instead do what userspa
== Series Details ==
Series: horror
URL : https://patchwork.freedesktop.org/series/45480/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c0c89f80325f horror
-:17: ERROR:TRAILING_WHITESPACE: trailing whitespace
#17: FILE: drivers/gpu/drm/i915/i915_drv.c:1473:
+^Istruct drm_i915_p
== Series Details ==
Series: horror
URL : https://patchwork.freedesktop.org/series/45480/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4383 -> Patchwork_9440 =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_9440 absolutely need to be
verified ma
== Series Details ==
Series: series starting with [01/31] drm/i915: Defer modeset cleanup to a
secondary task (rev4)
URL : https://patchwork.freedesktop.org/series/45325/
State : failure
== Summary ==
Applying: drm/i915: Defer modeset cleanup to a secondary task
Using index info to reconstruc
On Tue, 26 Jun 2018, Vito Caputo wrote:
> Beginning with 4.18, when I lock my X server using the `xlock` command,
> and close the lid, upon reopening the lid I am not presented with the
> xlock UI.
Please file a bug report at [1]. Please include Xorg.0.log and dmesg
with drm.debug=14 reproducing
== Series Details ==
Series: series starting with [1/6] drm/i915/execlists: Pull submit after
dequeue under timeline lock
URL : https://patchwork.freedesktop.org/series/45482/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2f29c7874491 drm/i915/execlists: Pull submit after dequ
On Wed, 27 Jun 2018, Chris Wilson wrote:
> I really must remember to proof read git send-email.
I did like the subsequent "warning for horror" and "failure for horror"
messages from CI though.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
_
== Series Details ==
Series: series starting with [1/6] drm/i915/execlists: Pull submit after
dequeue under timeline lock
URL : https://patchwork.freedesktop.org/series/45482/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4383 -> Patchwork_9442 =
== Summary - FAILURE ==
On 27/06/2018 12:38, Chris Wilson wrote:
In the next patch, we will process the CSB events directly from the
submission path, rather than only after a CS interrupt. Hence, we will
no longer have the need for a loop until the has-interrupt bit is clear,
and in the meantime can remove that small o
On 27/06/2018 11:35, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-06-27 10:52:45)
On 25/06/2018 10:48, Chris Wilson wrote:
@@ -1109,16 +1089,11 @@ static void process_csb(struct intel_engine_cs *engine)
} else {
port_set(port, port_pack(rq, count));
Chris Wilson writes:
> By taking advantage of the RCU protection of the task struct, we can find
> the appropriate signaler under the spinlock and then release the spinlock
> before waking the task and signaling the fence.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_irq.c
These are needed for pl111 to use the generic fbdev emulation.
Cc: Eric Anholt
Signed-off-by: Noralf Trønnes
Reviewed-by: Eric Anholt
---
drivers/gpu/drm/pl111/pl111_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/pl111/pl111_drv.c
b/drivers/gpu/drm/pl111/pl111_drv
1 - 100 of 234 matches
Mail list logo
