On Thu, Jan 31, 2019 at 12:29:23PM +0530, Ramalingam C wrote:
> "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
On Thu, Jan 31, 2019 at 12:29:17PM +0530, Ramalingam C wrote:
> +void component_match_add_typed(struct device *master,
> + struct component_match **matchptr,
> + int (*compare_typed)(struct device *, int, void *), void *compare_data)
> +{
> + __component_match_add(master, matchptr,
On Wed, Jan 30, 2019 at 05:24:07PM -0800, Lucas De Marchi wrote:
> On Wed, Jan 30, 2019 at 08:13:59PM +0200, Ville Syrjälä wrote:
> >From: Ville Syrjälä
> >
> >commit 5b0bd14dcc6b ("drm/i915/icl: keep track of unused pll while
> >looping") inadvertently (I presume) changed the code to pick the
>
From: Ville Syrjälä
We are mistakenly skipping transition watermarks on glk. Fix
up the condition for glk, and toss in the w/a name from
the database.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git
From: Ville Syrjälä
Display w/a #1140 tells us we have to program the transition
watermark to the minimum value on glk/cnl. Let's do that.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git
From: Ville Syrjälä
Drop WaIncreaseLatencyIPCEnabled/Display w/a #1140 for
early cnl steppings. Also switch the kbl/cfl case to check
for IS_GEN9_BC() for brevity. It ends up being the same thing
because IPC is disabled on SKL due to w/a #0477.
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Display w/a #1141 is also known as WaIncreaseLatencyIPCEnabled.
Add that to the comment.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c
== Series Details ==
Series: drm/i915: Implement HDCP2.2 (rev13)
URL : https://patchwork.freedesktop.org/series/38254/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7b8109241bdc components: multiple components for a device
-:33: WARNING:FUNCTION_ARGUMENTS: function definition
Quoting Tvrtko Ursulin (2019-01-31 07:25:36)
> On 30/01/2019 20:51, Patchwork wrote:
> > Participating hosts (7 -> 5)
> > --
> >
> >Missing(2): shard-skl shard-iclb
>
> Just my luck, re-test...
icl is not enabled for pw testing atm, as it's down to 50%
On 30/01/2019 20:51, Patchwork wrote:
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev26)
URL : https://patchwork.freedesktop.org/series/48194/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5509_full -> Patchwork_12091_full
Implement the required WA sequence for KBL to fix the
incorrect positioning of the window of oppurtunity and enc_en
signalling.
v2:
WA is moved into the toggle_signalling [Daniel]
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdmi.c | 42 +++
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
Just excluding the LSPCon HDMI ports from the HDCP1.4 testing.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_debugfs.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index
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
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
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
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
Commits the content protection change of a connector,
without crtc modeset. This improves the user experience.
Originally proposed by Sean Paul at v3 of HDCP1.4 framework
https://patchwork.freedesktop.org/patch/191759/. For some
reason this was dropped, but needed for the proper functionality
of
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
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 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
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 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
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
From: Tomas Winkler
Export to_mei_cl_device macro, it is needed also in mei client drivers.
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/bus.c | 1 -
include/linux/mei_cl_bus.h | 2 ++
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/bus.c
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
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
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
From: Tomas Winkler
Whitelist HDCP client for in kernel drm use
v2:
Rebased.
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 b/drivers/misc/mei/bus-fixup.c
index
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.
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
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
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
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
On HDMI connector init, intel_hdcp_init is passed with a flag for hdcp2.2
support based on the platform capability.
v2:
Rebased.
v3:
Collected the reviewed-by received.
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_hdmi.c | 3 ++-
1 file changed, 2
On DP connector init, intel_hdcp_init is passed with a flag for hdcp2.2
support based on the platform capability.
v2:
Rebased.
v3:
Collected the reviewed-by received.
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_dp.c | 2 +-
1 file changed, 1
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
---
include/drm/drm_hdcp.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
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
Time period for HDCP2.2 link check.
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
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/include/drm/drm_hdcp.h
+++
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
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
---
drivers/gpu/drm/i915/intel_hdcp.c | 118 +++---
1 file changed, 59 insertions(+), 59
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
From: Daniel Vetter
Component framework is extended to support multiple components for
a struct device. These will be matched with different masters based on
its sub component value.
We are introducing this, as I915 needs two different components
with different subcomponent value, which will be
From: Daniel Vetter
Since we need multiple components for I915 for different purposes
(Audio & Mei_hdcp), we adopt the subcomponents methodology introduced
by the previous patch (mentioned below).
Author: Daniel Vetter
Date: Mon Jan 28 17:08:20 2019 +0530
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
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]
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
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
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 added at drm/drm_hdcp.h.
v2: Commit msg is enhanced [Daniel]
v3:
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
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
"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
== Series Details ==
Series: drm: prefix header search paths with $(srctree)/
URL : https://patchwork.freedesktop.org/series/56020/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5516 -> Patchwork_12100
Summary
---
== Series Details ==
Series: drm: prefix header search paths with $(srctree)/
URL : https://patchwork.freedesktop.org/series/56020/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm: prefix header search paths with $(srctree)/
-
Currently, the Kbuild core manipulates header search paths in a crazy
way [1].
To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
the search paths in the srctree. Some Makefiles are already written in
that way, but not all. The goal of this work is to make the notation
LGTM...
Reviewed-by: Mahesh Kumar
On Wed, Jan 30, 2019 at 9:21 PM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> The code managing the dbuf slices is borked and needs some
> real work to fix. In the meantime let's just stop using the
> second slice.
>
> v2: Drop the change to
== Series Details ==
Series: drm/i915: permit zero valued dmap in for_each_sgt_dma
URL : https://patchwork.freedesktop.org/series/56006/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5512_full -> Patchwork_12097_full
== Series Details ==
Series: CRTC background color (rev5)
URL : https://patchwork.freedesktop.org/series/50834/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5512_full -> Patchwork_12096_full
Summary
---
**SUCCESS**
On Wed, Jan 30, 2019 at 11:01:25PM +0200, Ville Syrjälä wrote:
> On Wed, Jan 30, 2019 at 10:51:21AM -0800, Matt Roper wrote:
> > Some display controllers can be programmed to present non-black colors
> > for pixels not covered by any plane (or pixels covered by the
> > transparent regions of
== Series Details ==
Series: drm/i915: Pick the first unused PLL once again
URL : https://patchwork.freedesktop.org/series/56002/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5512_full -> Patchwork_12095_full
Summary
== Series Details ==
Series: drm/i915/psr: Execute the default PSR code path when setting
i915_edp_psr_debug (rev2)
URL : https://patchwork.freedesktop.org/series/56013/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5515 -> Patchwork_12099
== Series Details ==
Series: drm/i915: Apply LUT validation checks to platforms more accurately
(rev3)
URL : https://patchwork.freedesktop.org/series/55765/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5512_full -> Patchwork_12094_full
On Wed, Jan 30, 2019 at 08:13:59PM +0200, Ville Syrjälä wrote:
From: Ville Syrjälä
commit 5b0bd14dcc6b ("drm/i915/icl: keep track of unused pll while
looping") inadvertently (I presume) changed the code to pick the
last unused dpll rather than the first unused one like we did before.
While
On Wed, Jan 30, 2019 at 04:28:47PM +0200, Ville Syrjälä wrote:
> On Tue, Jan 29, 2019 at 04:49:28PM -0800, Matt Roper wrote:
> > Use of the new DRM_COLOR_LUT_NON_DECREASING test was a bit over-zealous;
> > it doesn't actually need to be applied to the degamma on "bdw-style"
> > platforms.
Changing the i915_edp_psr_debug was enabling, disabling or switching
PSR version by directly calling intel_psr_disable_locked() and
intel_psr_enable_locked(), what is not the default PSR path that will
be executed by real users.
So lets force a fastset in the PSR CRTC to trigger a pipe update and
Changing the i915_edp_psr_debug was enabling, disabling or switching
PSR version by directly calling intel_psr_disable_locked() and
intel_psr_enable_locked(), what is not the default PSR path that will
be executed by real users.
So lets force a fastset in the PSR CRTC to trigger a pipe update and
On Wed, Jan 30, 2019 at 11:03:33PM +0200, Ville Syrjälä wrote:
> On Wed, Jan 30, 2019 at 10:51:20AM -0800, Matt Roper wrote:
> > We don't yet allow userspace to control the CRTC background color, but
> > we should manually program the color to black to ensure the BIOS didn't
> > leave us with some
== Series Details ==
Series: drm/i915: Don't use the second dbuf slice on icl (rev2)
URL : https://patchwork.freedesktop.org/series/55517/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5511_full -> Patchwork_12092_full
CRTC background color kernel patches were written about 2.5 years ago
and floated on the upstream mailing list, but since no opensource
userspace materialized, we never actually merged them. However the
corresponding IGT test did get merged and has basically been dead code
ever since.
A couple
On Wed, Jan 30, 2019 at 09:57:10PM +0100, Daniel Vetter wrote:
> On Wed, Jan 30, 2019 at 10:56:26AM -0800, Matt Roper wrote:
> > On Wed, Jan 30, 2019 at 10:51:19AM -0800, Matt Roper wrote:
> > > Previous patch series was here:
> > >
> > >
== Series Details ==
Series: series starting with [1/3] drm/i915: Generalise GPU activity tracking
URL : https://patchwork.freedesktop.org/series/56010/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5514 -> Patchwork_12098
Em qua, 2019-01-30 às 20:13 +0200, Ville Syrjala escreveu:
> From: Ville Syrjälä
>
> commit 5b0bd14dcc6b ("drm/i915/icl: keep track of unused pll while
> looping") inadvertently (I presume) changed the code to pick the
> last unused dpll rather than the first unused one like we did before.
>
>
== Series Details ==
Series: series starting with [1/3] drm/i915: Generalise GPU activity tracking
URL : https://patchwork.freedesktop.org/series/56010/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Generalise GPU activity tracking
== Series Details ==
Series: series starting with [1/3] drm/i915: Generalise GPU activity tracking
URL : https://patchwork.freedesktop.org/series/56010/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
204bf30b25ef drm/i915: Generalise GPU activity tracking
-:31:
Quoting Chris Wilson (2019-01-30 16:08:59)
> Quoting Tvrtko Ursulin (2019-01-30 15:57:06)
> > Under what scenarios we end up not freeing active nodes sufficiently? It
> > would have to be some user which keeps many contexts around, having only
> > used them once?
>
> Never in a typical scenario
On Wed, Jan 30, 2019 at 10:59:04PM +0200, Ville Syrjälä wrote:
> On Wed, Jan 30, 2019 at 08:01:21PM +0100, Daniel Vetter wrote:
> > On Thu, Jan 24, 2019 at 08:58:49PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > The display engine stride limits are getting in our way. On
We currently track GPU memory usage inside VMA, such that we never
release memory used by the GPU until after it has finished accessing it.
However, we may want to track other resources aside from VMA, or we may
want to split a VMA into multiple independent regions and track each
separately. For
On Wed, Jan 30, 2019 at 10:51:22AM -0800, Matt Roper wrote:
> Gen9+ platforms allow CRTC's to be programmed with a background/canvas
> color below the programmable planes. Let's expose this for use by
> compositors.
>
> v2:
> - Split out bgcolor sanitization and programming of csc/gamma bits to
On Wed, Jan 30, 2019 at 10:51:21AM -0800, Matt Roper wrote:
> Some display controllers can be programmed to present non-black colors
> for pixels not covered by any plane (or pixels covered by the
> transparent regions of higher planes). Compositors that want a UI with
> a solid color background
On Wed, Jan 30, 2019 at 10:51:20AM -0800, Matt Roper wrote:
> We don't yet allow userspace to control the CRTC background color, but
> we should manually program the color to black to ensure the BIOS didn't
> leave us with some other color. We should also set the pipe gamma and
> pipe CSC bits so
On Wed, Jan 30, 2019 at 08:01:21PM +0100, Daniel Vetter wrote:
> On Thu, Jan 24, 2019 at 08:58:49PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > The display engine stride limits are getting in our way. On SKL+
> > we are limited to 8k pixels, which is easily exceeded with three
>
On Wed, Jan 30, 2019 at 10:56:26AM -0800, Matt Roper wrote:
> On Wed, Jan 30, 2019 at 10:51:19AM -0800, Matt Roper wrote:
> > Previous patch series was here:
> > https://lists.freedesktop.org/archives/dri-devel/2018-December/201949.html
> >
> > I'm told the ChromeOS userspace code to make use
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev26)
URL : https://patchwork.freedesktop.org/series/48194/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5509_full -> Patchwork_12091_full
Summary
As soon as we detect that the active tracker is idle and we prepare to
call the retire callback, release the storage for our tree of
per-timeline nodes. We expect these to be infrequently usage and quick
to allocate, so there is little benefit in keeping the tree cached and
we would prefer to
Wrap the active tracking for a GPU references in a slabcache for faster
allocations, and hopefully better fragmentation reduction.
v3: Nothing device specific left, it's just a slabcache that we can
make global.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_active.c | 31
== Series Details ==
Series: drm/i915: permit zero valued dmap in for_each_sgt_dma
URL : https://patchwork.freedesktop.org/series/56006/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5512 -> Patchwork_12097
Summary
---
Quoting Patchwork (2019-01-30 20:31:57)
> Possible regressions
>
> * igt@gem_eio@unwedge-stress:
> - shard-glk: PASS -> FAIL +8
> - shard-apl: PASS -> FAIL +2
> - shard-kbl: PASS -> FAIL
At least now they are not timing issues, just that we fail
== Series Details ==
Series: series starting with [1/2] drm/i915: Revoke mmaps and prevent access to
fence registers across reset
URL : https://patchwork.freedesktop.org/series/55988/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5509_full -> Patchwork_12090_full
Quoting Matthew Auld (2019-01-30 19:18:25)
> Break on NULL iter.sgp, rather than dmap == 0, on the off chance that we
> have some hypothetical selftest or similar in the future that considers
> dmap = 0 to be perfectly valid.
0 == DMA_MAPPING_ERROR
It wouldn't be a dma iterator at that point.
== Series Details ==
Series: CRTC background color (rev5)
URL : https://patchwork.freedesktop.org/series/50834/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5512 -> Patchwork_12096
Summary
---
**SUCCESS**
No
== Series Details ==
Series: CRTC background color (rev5)
URL : https://patchwork.freedesktop.org/series/50834/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a9fc702b09d5 drm/i915: Force background color to black for gen9+ (v2)
3f404502f7a1 drm: Add CRTC background color
== Series Details ==
Series: drm/i915: Pick the first unused PLL once again
URL : https://patchwork.freedesktop.org/series/56002/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5512 -> Patchwork_12095
Summary
---
On Wed, Jan 30, 2019 at 10:25:22AM -0800, Matt Roper wrote:
> On Tue, Jan 29, 2019 at 04:49:19PM +0200, Ville Syrjälä wrote:
> > On Tue, Jan 29, 2019 at 04:33:15PM +0200, Ville Syrjälä wrote:
> > > On Fri, Jan 25, 2019 at 01:54:47PM -0800, Matt Roper wrote:
> > > > On Fri, Jan 25, 2019 at
Break on NULL iter.sgp, rather than dmap == 0, on the off chance that we
have some hypothetical selftest or similar in the future that considers
dmap = 0 to be perfectly valid.
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
== Series Details ==
Series: drm/i915: Apply LUT validation checks to platforms more accurately
(rev3)
URL : https://patchwork.freedesktop.org/series/55765/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5512 -> Patchwork_12094
On Fri, Jan 18, 2019 at 05:27:13PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> To overcome display engine stride limits we'll want to remap the
> pages in the GTT. To that end we need a new gtt_view type which
> is just like the "rotated" type except not rotated.
>
> v2: Use
On Thu, Jan 24, 2019 at 08:58:49PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The display engine stride limits are getting in our way. On SKL+
> we are limited to 8k pixels, which is easily exceeded with three
> 4k displays. To overcome this limitation we can remap the pages
> in the
On Wed, Jan 30, 2019 at 10:51:19AM -0800, Matt Roper wrote:
> Previous patch series was here:
> https://lists.freedesktop.org/archives/dri-devel/2018-December/201949.html
>
> I'm told the ChromeOS userspace code to make use of the background color
> has been reviewed and is ready for use:
> *
Some display controllers can be programmed to present non-black colors
for pixels not covered by any plane (or pixels covered by the
transparent regions of higher planes). Compositors that want a UI with
a solid color background can potentially save memory bandwidth by
setting the CRTC background
Gen9+ platforms allow CRTC's to be programmed with a background/canvas
color below the programmable planes. Let's expose this for use by
compositors.
v2:
- Split out bgcolor sanitization and programming of csc/gamma bits to a
separate patch that we can land before the ABI changes are ready
Previous patch series was here:
https://lists.freedesktop.org/archives/dri-devel/2018-December/201949.html
I'm told the ChromeOS userspace code to make use of the background color
has been reviewed and is ready for use:
* https://chromium-review.googlesource.com/c/chromium/src/+/1278858
*
1 - 100 of 210 matches
Mail list logo
