== Series Details ==
Series: series starting with [CI,1/2] drm/i915/selftests: Remove accidental
serialization between gpu_fill (rev2)
URL : https://patchwork.freedesktop.org/series/65888/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6794 -> Patchwork_14207
On 8/24/19 4:03 PM, a...@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2019-08-24-16-02 has been uploaded to
>
>http://www.ozlabs.org/~akpm/mmotm/
>
> mmotm-readme.txt says
>
> README for mm-of-the-moment:
>
> http://www.ozlabs.org/~akpm/mmotm/
>
> This is a snapshot of my
Hi Janusz,
On 8/27/19 5:35 PM, Janusz Krzysztofik wrote:
Hi Lu,
On Monday, August 26, 2019 10:29:12 AM CEST Lu Baolu wrote:
Hi Janusz,
On 8/26/19 4:15 PM, Janusz Krzysztofik wrote:
Hi Lu,
On Friday, August 23, 2019 3:51:11 AM CEST Lu Baolu wrote:
Hi,
On 8/22/19 10:29 PM, Janusz
The third patch in the series attempts to downgrade the check for
is_guc_running to is_fw_available within intel_uc_fini_hw. We cannot
rely on is_guc_running because we will completely skip our attempt to
fini uC hw during unload. However, this exposes a new set of problems due
to the driver being
During normal driver unload we attempt to disable GuC communication
while it is currently stopped. This results in a nop'd call to
intel_guc_ct_disable within guc_disable_communication because
stop/disable rely on the same flag to prevent further comms with CT.
We can avoid the call to disable
It is not enough to check that uc supports GuC submission now
that we can continue to load the driver after GuC initialization
failure (support != enabled). Instead we should explicitly check
that we enabled GuC submission.
Signed-off-by: Fernando Pacheco
Cc: Michal Wajdeczko
Cc: Daniele
We should not be skipping uc_fini_hw on finding GuC
is no longer running. There is plenty of hw and internal
state that can be cleaned up without having to communicate
with GuC.
v2: better to check if fw is available (Michal)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110943
== Series Details ==
Series: Add module parameter to reduce engine instances
URL : https://patchwork.freedesktop.org/series/65900/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7377558e7eee drm/i915: WARN rather than BUG with unexpected media engines
43af249229a9 drm/i915: Add
Add a new module parameter, ring_mask, to allow users to
disable certain engines for a platform. By default this
mask is set to all engines enabled. Bits in the mask are
aligned with the intel_engine_id enums.
As a prerequisite to the patch which adds the module parameter,
change the BUG_ON to a
Instead of preventing driver load when media engines enabled
for a platform do not match the fuse values for those media
engines, WARN_ON to indicate the observation but continue
with driver load.
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/intel_device_info.c | 4 ++--
1 file
Add a new module parameter, ring_mask, to allow for disabling
engines during i915 load. This mask follows the intel_engine_id
enum and can be used to hide specified engines from i915 and
from userspace.
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/i915_params.c | 3 +++
This series renames some functions to match the drm function definitions
and also refactors some functions out of intel_atomic_commit_tail() as a prep
for adding newer hooks required for transcoder port sync enable series
The renaming is done as suggested by Daniel Vetter.
There is no functional
Create a new hook commit_modeset_disables() consistent with the naming
in drm atomic helpers and similar to the commit_modeset_enables() hook.
This helps better organize the disable sequence in atomic_commit_tail()
and move that to this disable hook.
No functional change
v3:
* Rebase (Manasi)
This patch has no functional changes. This just renames the update_crtcs()
hooks to commit_modeset_enables() to match the drm_atomic helper naming
conventions.
v2:
* Rebase on drm-tip
Suggested-by: Daniel Vetter
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Matt Roper
Cc: Jani Nikula
>
> On 2019-08-27 at 20:03:21 +0530, Winkler, Tomas wrote:
> > > On gen12+ platforms, HDCP HW is associated to the transcoder.
> > > Hence on every modeset update associated transcoder into the
> > > intel_hdcp of the port.
> > >
> > > v2:
> > > s/trans/cpu_transcoder [Jani]
> > > v3:
> > >
== Series Details ==
Series: DSB enablement. (rev3)
URL : https://patchwork.freedesktop.org/series/63013/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6794 -> Patchwork_14206
Summary
---
**SUCCESS**
No
== Series Details ==
Series: drm/i915: use a separate context for gpu relocs (rev2)
URL : https://patchwork.freedesktop.org/series/65729/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6794 -> Patchwork_14205
Summary
Quoting Daniele Ceraolo Spurio (2019-08-27 19:58:05)
> The CS pre-parser can pre-fetch commands across memory sync points and
> starting from gen12 it is able to pre-fetch across BB_START and BB_END
> boundaries as well, so when we emit gpu relocs the pre-parser might
> fetch the target location
== Series Details ==
Series: DSB enablement. (rev3)
URL : https://patchwork.freedesktop.org/series/63013/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915/dsb: feature flag added for display state buffer.
Okay!
== Series Details ==
Series: DSB enablement. (rev3)
URL : https://patchwork.freedesktop.org/series/63013/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
da32d51f5b17 drm/i915/dsb: feature flag added for display state buffer.
3b8233fa3574 drm/i915/dsb: DSB context creation.
Enabling DSB by setting 1 to has_dsb flag for gen12.
Cc: Jani Nikula
Cc: Rodrigo Vivi
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/i915_pci.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index
From gen12 onwards Display State Buffer(DSB) is hardware capability
added which allows driver to batch submit display HW programming.
Feature flag has_dsb added to identify the driver/platform support
at runtime.
Cc: Jani Nikula
Cc: Rodrigo Vivi
Signed-off-by: Animesh Manna
---
Display State Buffer (DSB) is hardware capability which allows driver
to batch submit HW programming.
As part of initial enablement common api created which currently used
to program gamma lut proramming.
Going forwad DSB support can be added for HDR and flip related operation.
HSDES:
Batch buffer will be created through dsb-reg-write function which can have
single/multiple request based on usecase and once the buffer is ready
commit function will trigger the execution of the batch buffer. All
the registers will be updated simultaneously.
v1: Initial version.
v2: Optimized
DSB can program large set of data through indexed register write
(opcode 0x9) in one shot. Will be using for bulk register programming
e.g. gamma lut programming, HDR meta data programming.
v1: Initial version.
v2: simplified code by using ALIGN(). (Chris)
Cc: Shashank Sharma
Cc: Imre Deak
Gamma lut programming can be programmed using DSB
where bulk register programming can be done using indexed
register write which takes number of data and the mmio offset
to be written.
v1: Initial version.
v2: Directly call dsb-api at callsites. (Jani)
Cc: Jani Nikula
Cc: Rodrigo Vivi
DSB support single register write through opcode 0x1. Generic
api created which accumulate all single register write in a batch
buffer and once DSB is triggered, it will program all the registers
at the same time.
Cc: Jani Nikula
Cc: Rodrigo Vivi
Signed-off-by: Animesh Manna
---
DSB will be used for performance improvement for some special scenario.
DSB engine will be enabled based on need and after completion of its work
will be disabled. Api added for enable/disable operation by using DSB_CTRL
register.
Cc: Michel Thierry
Cc: Jani Nikula
Cc: Rodrigo Vivi
As per bspec check for DSB status before programming any
of its register. Inline function added to check the dsb status.
Cc: Michel Thierry
Cc: Jani Nikula
Cc: Rodrigo Vivi
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_dsb.c | 9 +
1 file changed, 9
Added docbook info regarding Display State Buffer(DSB) which
is added from gen12 onwards to batch submit display HW programming.
v1: Initial version as RFC.
Cc: Jani Nikula
Cc: Rodrigo Vivi
Acked-by: Rodrigo Vivi
Signed-off-by: Animesh Manna
---
Documentation/gpu/i915.rst | 9
The function will internally get the gem buffer from global GTT
which is mapped in cpu domain to feed the data + opcode for DSB engine.
v1: initial version.
v2:
- removed some unwanted code. (Chris)
- Used i915_gem_object_create_internal instead of _shmem. (Chris)
- cmd_buf_tail removed and can
Added key register definitions of DSB.
dsb-ctrl register is required to enable dsb-engine.
head-ptr register hold the head of buffer address from where the
execution will start.
Programming tail-ptr register is a trigger point to start execution.
Cc: Uma Shankar
Cc: Jani Nikula
Cc: Rodrigo
The CS pre-parser can pre-fetch commands across memory sync points and
starting from gen12 it is able to pre-fetch across BB_START and BB_END
boundaries as well, so when we emit gpu relocs the pre-parser might
fetch the target location of the reloc before the memory write lands.
The parser can't
== Series Details ==
Series: drm/i915: Prune 2560x2880 mode for 5K tiled dual DP monitors
URL : https://patchwork.freedesktop.org/series/65845/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6787_full -> Patchwork_14195_full
== Series Details ==
Series: drm/i915/selftests: Remove accidental serialization between gpu_fill
URL : https://patchwork.freedesktop.org/series/65886/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6794 -> Patchwork_14203
On Tue, 2019-08-27 at 09:36 -0700, Lucas De Marchi wrote:
> On Mon, Aug 26, 2019 at 10:43:36AM -0700, Runyan, Arthur J wrote:
> > > -Original Message-
> > > From: Imre Deak
> > > Sent: Monday, 26 August, 2019 6:42 AM
> > > To: Souza, Jose ; De Marchi, Lucas
> > > ; Runyan, Arthur J <
> >
On Tue, Aug 27, 2019 at 01:34:15PM +0300, Jani Nikula wrote:
> On Tue, 27 Aug 2019, "Nautiyal, Ankit K" wrote:
> > From: Ankit Nautiyal
> >
> > Currently, the transcoder port sync feature is not available, due to
> > which the 5K-tiled dual DP monitors experience corruption when
> > 2560x2880
On Mon, Aug 26, 2019 at 08:28:33PM +0300, Imre Deak wrote:
On Fri, Aug 23, 2019 at 01:20:35AM -0700, Lucas De Marchi wrote:
From: José Roberto de Souza
It was enabling and checking PSR interruptions in every transcoder
while it should keep the interruptions on the non-used transcoders
masked.
On Mon, Aug 26, 2019 at 10:43:36AM -0700, Runyan, Arthur J wrote:
-Original Message-
From: Imre Deak
Sent: Monday, 26 August, 2019 6:42 AM
To: Souza, Jose ; De Marchi, Lucas
; Runyan, Arthur J
Cc: intel-gfx@lists.freedesktop.org; Pandiyan, Dhinakaran
Subject: Re: [Intel-gfx] [PATCH v3
On 8/27/2019 6:50 PM, Imre Deak wrote:
On Tue, Aug 27, 2019 at 06:31:31PM +0530, Gupta, Anshuman wrote:
On 8/13/2019 8:16 PM, Imre Deak wrote:
On Sat, Aug 10, 2019 at 12:02:17AM +0530, Anshuman Gupta wrote:
"DC3CO Off" power well inherits its power domains from
"DC Off" power well, these
Upon object creation for live_gem_contexts, we fill the object with
known scratch and flush it out of the CPU cache. Before performing the
GPU fill, we don't need to flush it again and so avoid serialising with
previous fills.
However, we do need some throttling on the internal interfaces if we
igt_ctx_exec allocates a new context for each iteration, keeping them
all allocated until the end. Instead, release the local ctx reference at
the end of each iteration, allowing ourselves to reap those if under
mempressure.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
e.g. benchmarks/gem_wsim.c:2936:4: warning: absolute value function ‘abs’ given
an argument of type ‘long int’ but has parameter of type ‘int’ which may cause
truncation of value [-Wabsolute-value]
Signed-off-by: Chris Wilson
---
benchmarks/gem_syslatency.c | 2 +-
benchmarks/gem_wsim.c
On Mon, 26 Aug 2019 at 08:23, Chris Wilson wrote:
>
> igt_ctx_exec allocates a new context for each iteration, keeping them
> all allocated until the end. Instead, release the local ctx reference at
> the end of each iteration, allowing ourselves to reap those if under
> mempressure.
>
>
Upon object creation for live_gem_contexts, we fill the object with
known scratch and flush it out of the CPU cache. Before performing the
GPU fill, we don't need to flush it again and so avoid serialising with
previous fills.
However, we do need some throttling on the internal interfaces if we
On Mon, 26 Aug 2019 at 08:24, Chris Wilson wrote:
>
> Upon object creation for live_gem_contexts, we fill the object with
> known scratch and flush it out of the CPU cache. Before performing the
> GPU fill, we don't need to flush it again and so avoid serialising with
> previous fills.
>
>
On 27/08/2019 14:59, Chris Wilson wrote:
A virtual engine itself does not have a batch pool, but we can gleefully
use any of its siblings instead.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Quoting Matthew Auld (2019-08-27 16:30:40)
> On 27/08/2019 14:26, Chris Wilson wrote:
> > The point of debug_object_activate is to mark we first, only the first,
> > acquisition.
> -eparse
It was meant to be "the first, and only the first,"
-Chris
___
On 27/08/2019 14:26, Chris Wilson wrote:
The point of debug_object_activate is to mark we first, only the first,
acquisition.
-eparse
The object then remains active until the last release.
However, we marked up all successful first acquires even though we
allowed concurrent parties to try
If we are writing the relocations using the GPU they will not be written
into the batch immediately. Instead there will be a write-fence while
the relocation is being performed, giving us something to conveniently
wait upon.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_big.c | 10
== Series Details ==
Series: drm/i915: Make engine batch pool's safe for use with virtual engines
URL : https://patchwork.freedesktop.org/series/65875/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6792 -> Patchwork_14202
On 2019-08-27 at 20:03:21 +0530, Winkler, Tomas wrote:
> > On gen12+ platforms, HDCP HW is associated to the transcoder.
> > Hence on every modeset update associated transcoder into the intel_hdcp of
> > the port.
> >
> > v2:
> > s/trans/cpu_transcoder [Jani]
> > v3:
> > comment is added for
On Tue, Aug 27, 2019 at 03:35:14PM +0100, Chris Wilson wrote:
> Quoting Kumar Valsan, Prathap (2019-08-27 15:17:51)
> > We want to support this on Gen11 as well, where these registers
> > are context saved and restored and we prime the register values of new
> > contexts
> > from recorded
On 2019-08-27 at 20:07:04 +0530, Winkler, Tomas wrote:
>
> >
> > On 2019-08-27 at 19:49:19 +0530, Winkler, Tomas wrote:
> > > > For gen12+ platform we need to pass the transcoder info as part of
> > > > the port info into ME FW.
> > > >
> > > > This change fills the payload for ME FW from
>
> On 2019-08-27 at 19:49:19 +0530, Winkler, Tomas wrote:
> > > For gen12+ platform we need to pass the transcoder info as part of
> > > the port info into ME FW.
> > >
> > > This change fills the payload for ME FW from hdcp_port_data.
> > >
> > > Signed-off-by: Ramalingam C
> > > Acked-by:
Quoting Kumar Valsan, Prathap (2019-08-27 15:17:51)
> We want to support this on Gen11 as well, where these registers
> are context saved and restored and we prime the register values of new
> contexts
> from recorded defaults. What could be the correct way to handle this, write
> to the
>
> On gen12+ platforms, HDCP HW is associated to the transcoder.
> Hence on every modeset update associated transcoder into the intel_hdcp of
> the port.
>
> v2:
> s/trans/cpu_transcoder [Jani]
> v3:
> comment is added for fw_ddi init for gen12+ [Shashank]
> only hdcp capable transcoder is
On 2019-08-27 at 19:49:19 +0530, Winkler, Tomas wrote:
> > For gen12+ platform we need to pass the transcoder info as part of the port
> > info into ME FW.
> >
> > This change fills the payload for ME FW from hdcp_port_data.
> >
> > Signed-off-by: Ramalingam C
> > Acked-by: Jani Nikula
> >
On 2019-08-26 3:25 p.m., Andrzej Pietrasiewicz wrote:
> Use the ddc pointer provided by the generic connector.
>
> Signed-off-by: Andrzej Pietrasiewicz
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +++--
> 1 file changed, 3 insertions(+), 2
On 2019-08-26 2:05 p.m., David Francis wrote:
> With DSC, bpp can be fractional in multiples of 1/16.
>
> Change drm_dp_calc_pbn_mode to reflect this, adding a new
> parameter bool dsc. When this parameter is true, treat the
> bpp parameter as having units not of bits per pixel, but
> 1/16 of a
On 2019-08-27 at 19:30:23 +0530, Winkler, Tomas wrote:
> >
> > I915 needs to send the index of the transcoder as per ME FW.
> >
> > To support this, define enum mei_fw_tc and add as a member into the struct
> > hdcp_port_data.
> >
> > v2:
> > Typo in commit msg is fixed [Shashank]
> >
> >
== Series Details ==
Series: drm/i915: Only activate i915_active debugobject once
URL : https://patchwork.freedesktop.org/series/65874/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6792 -> Patchwork_14201
Summary
---
> For gen12+ platform we need to pass the transcoder info as part of the port
> info into ME FW.
>
> This change fills the payload for ME FW from hdcp_port_data.
>
> Signed-off-by: Ramalingam C
> Acked-by: Jani Nikula
> Reviewed-by: Shashank Sharma
> ---
> drivers/misc/mei/hdcp/mei_hdcp.c |
On Fri, 2019-08-23 at 13:07 +0300, Imre Deak wrote:
> There is a difference in BSpec's and the driver's designation of DDI
> ports. BSpec uses the following names:
> - before GEN11:
> BSpec/driver:
> port A/B/C/D etc
> - GEN11:
> BSpec/driver:
> port A-F
> - GEN12:
> BSpec:
>
With DSC, bpp can be fractional in multiples of 1/16.
Change drm_dp_calc_pbn_mode to reflect this, adding a new
parameter bool dsc. When this parameter is true, treat the
bpp parameter as having units not of bits per pixel, but
1/16 of a bit per pixel
v2: Don't add separate function for this
On Mon, Aug 26, 2019 at 3:26 PM Andrzej Pietrasiewicz
wrote:
>
> Use the ddc pointer provided by the generic connector.
>
> Signed-off-by: Andrzej Pietrasiewicz
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/radeon_connectors.c | 143 +++--
> 1 file changed, 107
On Mon, Aug 26, 2019 at 10:17:55AM +0100, Chris Wilson wrote:
> Quoting Prathap Kumar Valsan (2019-08-26 00:35:27)
> > To provide shared last-level-cache isolation to cpu workloads running
> > concurrently with gpu workloads, the gpu allocation of cache lines needs
> > to be restricted to certain
On Mon, Aug 26, 2019 at 09:39:48AM +0100, Chris Wilson wrote:
> Quoting Prathap Kumar Valsan (2019-08-26 00:35:27)
> > To provide shared last-level-cache isolation to cpu workloads running
> > concurrently with gpu workloads, the gpu allocation of cache lines needs
> > to be restricted to certain
>
> I915 needs to send the index of the transcoder as per ME FW.
>
> To support this, define enum mei_fw_tc and add as a member into the struct
> hdcp_port_data.
>
> v2:
> Typo in commit msg is fixed [Shashank]
>
> Signed-off-by: Ramalingam C
> Acked-by: Jani Nikula
> ---
>
A virtual engine itself does not have a batch pool, but we can gleefully
use any of its siblings instead.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 ++--
drivers/gpu/drm/i915/gem/i915_gem_object_blt.c | 4 ++--
On Tue, Aug 27, 2019 at 04:42:12PM +0300, Lisovskiy, Stanislav wrote:
> On Fri, 2019-08-23 at 13:07 +0300, Imre Deak wrote:
> > There is a difference in BSpec's and the driver's designation of DDI
> > ports. BSpec uses the following names:
> > - before GEN11:
> > BSpec/driver:
> > port
On Mon, Aug 26, 2019 at 03:55:39PM -0700, Matt Roper wrote:
> The bspec has just recently been updated with new cdclk values that
> require the use of a /2 CD2X divider rather than a /1 divider. Once we
> add the divider selection logic to ICL+ cdclk programming, we have
> pretty much the same
On Fri, 2019-08-23 at 13:07 +0300, Imre Deak wrote:
> There is a difference in BSpec's and the driver's designation of DDI
> ports. BSpec uses the following names:
> - before GEN11:
> BSpec/driver:
> port A/B/C/D etc
> - GEN11:
> BSpec/driver:
> port A-F
> - GEN12:
> BSpec:
>
== Series Details ==
Series: drm/i915/execlists: Flush the post-sync breadcrumb write harder
URL : https://patchwork.freedesktop.org/series/65871/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6792 -> Patchwork_14200
== Series Details ==
Series: New cdclk values for gen11+
URL : https://patchwork.freedesktop.org/series/65838/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6787_full -> Patchwork_14194_full
Summary
---
**SUCCESS**
Only files are that are modified in this year should be updated.
For example.
include/drm/i915_mei_hdcp_interface.h
- * Copyright © 2017-2018 Intel Corporation
+ * Copyright © 2017-2019 Intel Corporation
> -Original Message-
> From: C, Ramalingam
> Sent: Tuesday, August 27, 2019 16:23
The point of debug_object_activate is to mark we first, only the first,
acquisition. The object then remains active until the last release.
However, we marked up all successful first acquires even though we
allowed concurrent parties to try and acquire the i915_active
simultaneously (serialised by
On 2019-08-27 at 18:32:13 +0530, Winkler, Tomas wrote:
>
> > Enabling the HDCP1.4 and 2.2 on TGL by supporting the HW block movement
> > from DDI into transcoder.
>
> In some files needs to bump the copyright to 2019.
Tomas,
I am not aware when a copyright year needs to be bumped, as
On Tue, Aug 27, 2019 at 06:31:31PM +0530, Gupta, Anshuman wrote:
>
>
> On 8/13/2019 8:16 PM, Imre Deak wrote:
> > On Sat, Aug 10, 2019 at 12:02:17AM +0530, Anshuman Gupta wrote:
> > > "DC3CO Off" power well inherits its power domains from
> > > "DC Off" power well, these power domains will
> Enabling the HDCP1.4 and 2.2 on TGL by supporting the HW block movement
> from DDI into transcoder.
In some files needs to bump the copyright to 2019.
>
> v10:
> Review comments from shashank addressed
>
> Ramalingam C (6):
> drm/i915: mei_hdcp: I915 sends ddi index as per ME FW
>
On 8/13/2019 8:16 PM, Imre Deak wrote:
On Sat, Aug 10, 2019 at 12:02:17AM +0530, Anshuman Gupta wrote:
"DC3CO Off" power well inherits its power domains from
"DC Off" power well, these power domains will disallow
DC3CO when any external displays are connected and at
time of modeset and aux
== Series Details ==
Series: drm/i915/execlists: stall on render flush before writing seqno
URL : https://patchwork.freedesktop.org/series/65869/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6791 -> Patchwork_14199
== Series Details ==
Series: drm/i915: Enable HDCP 1.4 and 2.2 on Gen12+ (rev8)
URL : https://patchwork.freedesktop.org/series/63432/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6791 -> Patchwork_14198
Summary
---
== Series Details ==
Series: drm/i915/selftests: Markup impossible error pointers
URL : https://patchwork.freedesktop.org/series/65862/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6791 -> Patchwork_14197
Summary
---
== Series Details ==
Series: series starting with [CI,1/8] drm/i915/tgl: Guard and warn if more than
one eDP panel is present
URL : https://patchwork.freedesktop.org/series/65835/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6787_full -> Patchwork_14193_full
Quite rarely we see that the CS completion event fires before the
breadcrumb is coherent, which presumably is a result of the CS_STALL not
waiting for the post-sync operation. Try following in a DC_FLUSH into
the following pipecontrol to see if that makes any difference.
Signed-off-by: Chris
Quoting Chris Wilson (2019-08-27 12:54:13)
> Quite rarely we see that the CS completion event fires before the
> breadcrumb is coherent. Try rearranging the breadcrumb write sequence
> such that the CS_STALL is on the post-sync write pipecontrol.
>
> Signed-off-by: Chris Wilson
> Cc: Mika
Quite rarely we see that the CS completion event fires before the
breadcrumb is coherent. Try rearranging the breadcrumb write sequence
such that the CS_STALL is on the post-sync write pipecontrol.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 17
== Series Details ==
Series: drm/i915/tgl: Gen-12 display loses Yf tiling and legacy CCS support
URL : https://patchwork.freedesktop.org/series/65858/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6790 -> Patchwork_14196
>From Gen12 onwards, HDCP HW block is implemented within transcoders.
Till Gen11 HDCP HW block was part of DDI.
Hence required changes in HW programming is handled here.
As ME FW needs the transcoder detail on which HDCP is enabled
on Gen12+ platform, we are populating the detail in
I915 converts it's port value into ddi index defiend by ME FW
and pass it as a member of hdcp_port_data structure.
Hence expose the enum mei_fw_ddi to I915 through
i915_mei_interface.h.
Signed-off-by: Ramalingam C
Acked-by: Jani Nikula
Reviewed-by: Shashank Sharma
---
I915 needs to send the index of the transcoder as per ME FW.
To support this, define enum mei_fw_tc and add as a member into
the struct hdcp_port_data.
v2:
Typo in commit msg is fixed [Shashank]
Signed-off-by: Ramalingam C
Acked-by: Jani Nikula
---
include/drm/i915_mei_hdcp_interface.h |
For gen12+ platform we need to pass the transcoder info
as part of the port info into ME FW.
This change fills the payload for ME FW from hdcp_port_data.
Signed-off-by: Ramalingam C
Acked-by: Jani Nikula
Reviewed-by: Shashank Sharma
---
drivers/misc/mei/hdcp/mei_hdcp.c | 11 +++
On gen12+ platforms, HDCP HW is associated to the transcoder.
Hence on every modeset update associated transcoder into the
intel_hdcp of the port.
v2:
s/trans/cpu_transcoder [Jani]
v3:
comment is added for fw_ddi init for gen12+ [Shashank]
only hdcp capable transcoder is translated into
We dont need the definition of the enum port outside I915, anymore.
Hence move enum port definition into I915 driver itself.
v2:
intel_display.h is included in intel_hdcp.h
v3:
enum port is declared in headers.
v4:
commit msg is rephrased.
Signed-off-by: Ramalingam C
Reviewed-by: Jani
Enabling the HDCP1.4 and 2.2 on TGL by supporting the HW block movement
from DDI into transcoder.
v10:
Review comments from shashank addressed
Ramalingam C (6):
drm/i915: mei_hdcp: I915 sends ddi index as per ME FW
drm: Move port definition back to i915 header
drm: Extend I915 mei
On Tue, 27 Aug 2019, "Nautiyal, Ankit K" wrote:
> From: Ankit Nautiyal
>
> Currently, the transcoder port sync feature is not available, due to
> which the 5K-tiled dual DP monitors experience corruption when
> 2560x2880 mode is applied for both of the tiled DP connectors.
> Bugzilla:
Regards
Shashank
On 8/22/2019 8:49 PM, Ramalingam C wrote:
From Gen12 onwards, HDCP HW block is implemented within transcoders.
Till Gen11 HDCP HW block was part of DDI.
Hence required changes in HW programming is handled here.
As ME FW needs the transcoder detail on which HDCP is enabled
On 27/08/2019 10:49, Chris Wilson wrote:
If we create a new live_context() we should have a mapping for each
engine. Document that assumption with an assertion.
Reported-by: Dan Carpenter
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Reviewed-by: Matthew Auld
== Series Details ==
Series: drm/i915: Prune 2560x2880 mode for 5K tiled dual DP monitors
URL : https://patchwork.freedesktop.org/series/65845/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6787 -> Patchwork_14195
Summary
1 - 100 of 116 matches
Mail list logo
