On 2/23/2018 7:40 PM, Michal Wajdeczko wrote:
We want to use higher level 'uc' functions as the main entry points to
the GuC/HuC code to hide some details and keep code layered.
Signed-off-by: Michal Wajdeczko
Cc: Sagar Arun Kamble
Cc: Chris Wilson
Reviewed-by: Sagar Arun Kamble
Couple o
On Thursday 22 February 2018 08:09 PM, Sean Paul wrote:
On Wed, Feb 14, 2018 at 07:43:37PM +0530, Ramalingam C wrote:
Each HDCP authentication, could take upto 5.1Sec, based on the
downstream HDCP topology.
Hence to avoid this much delay in the atomic_commit path, this patch
schedules the HDC
On 2/23/2018 10:31 PM, Daniele Ceraolo Spurio wrote:
On 23/02/18 06:04, Michal Wajdeczko wrote:
Right after GPU reset there will be a small window of time during which
some of GuC/HuC fields will still show state before reset. Let's start
to fix that by sanitizing firmware status as we will
On Thursday 22 February 2018 08:17 PM, Sean Paul wrote:
On Wed, Feb 14, 2018 at 07:43:38PM +0530, Ramalingam C wrote:
Considering the upcoming significant no HDCP2.2 variables, it will
be clean to have separate struct fo HDCP.
New structure called intel_hdcp is introduced.
Signed-off-by: Ram
On Thursday 22 February 2018 09:16 PM, Sean Paul wrote:
On Wed, Feb 14, 2018 at 07:43:39PM +0530, Ramalingam C wrote:
DP HDCP asserts the CP_IRQ to indicate the msg availability and
auth state change at the panel.
Implements a completion structure to communicate the cp_irq
assertion and provi
On Thursday 22 February 2018 08:29 PM, Sean Paul wrote:
On Wed, Feb 14, 2018 at 07:43:40PM +0530, Ramalingam C wrote:
For upcoming implementation of HDCP2.2 in I915, all variable required
for HDCP2.2 are defined.
This includes a translation layer called hdcp2_shim for encoder
specific HDCP2.2
On Thursday 22 February 2018 09:13 PM, Sean Paul wrote:
On Wed, Feb 14, 2018 at 07:43:41PM +0530, Ramalingam C wrote:
Intel HDCP2.2 registers are defined with addr offsets and bit details.
Macros are defined for referencing the register offsets based on the
port index.
Signed-off-by: Ramalin
On 2/23/2018 4:35 AM, Oscar Mateo wrote:
+ * We might have detected that some engines are fused off after we
initialized
+ * the forcewake domains. Prune them, to make sure they only
reference existing
+ * engines.
+ */
+void intel_uncore_prune(struct drm_i915_private *dev_priv)
+{
+
Hi Gaurav,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on next-20180223]
[cannot apply to drm-intel/for-linux-next drm/drm-next v4.16-rc3 v4.16-rc2
v4.16-rc1 v4.16-rc3]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the
Hi Rodrigo,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20180223]
[cannot apply to v4.16-rc3]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://g
== Series Details ==
Series: igt/gem_busy: Fix extended-bsd aliasing checks
URL : https://patchwork.freedesktop.org/series/38920/
State : warning
== Summary ==
Test drv_suspend:
Subgroup fence-restore-tiled2untiled:
skip -> PASS (shard-hsw)
Test kms_plane:
== Series Details ==
Series: igt/gem_exec_schedule: Exercise "deep" preemption
URL : https://patchwork.freedesktop.org/series/38914/
State : warning
== Summary ==
Test drv_suspend:
Subgroup fence-restore-tiled2untiled:
skip -> PASS (shard-hsw)
Test kms_chv_c
== Series Details ==
Series: igt/gem_busy: Fix extended-bsd aliasing checks
URL : https://patchwork.freedesktop.org/series/38920/
State : success
== Summary ==
IGT patchset tested on top of latest successful build
305ebcedc36e98f3118ac27a5bbde0ce7cd71a74 Iterate over physical engines
with lat
== Series Details ==
Series: igt/gem_exec_schedule: Exercise "deep" preemption
URL : https://patchwork.freedesktop.org/series/38914/
State : success
== Summary ==
IGT patchset tested on top of latest successful build
305ebcedc36e98f3118ac27a5bbde0ce7cd71a74 Iterate over physical engines
with
Although we want to specify exactly which physical engine to run on, the
busy ioctl can only return the I915_EXEC_RING identifier, i.e. the
aliased I915_EXEC_BSD for vcs0/vcs1. Horrors.
Signed-off-by: Chris Wilson
---
tests/gem_busy.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
DRM drivers need to tell vga_switcheroo whether they use runtime PM.
If they do use it, vga_switcheroo lets them autosuspend at their own
discretion. If on the other hand they do not use it, vga_switcheroo
allows the user to suspend and resume the GPU manually via the
->set_gpu_state hook.
i915 c
If the specified object can not fit into the GTT due to overlap with a
neighbouring pinned object (not part of the execobjects[]), we expect to
fail with ENOSPC (as we cannot evict, rather than EINVAL for the user
error in a badly constructed execobjects[]). To prevent the tests
causing overlap wit
-ci/linux/commits/Claudiu-Beznea/extend-PWM-framework-to-support-PWM-modes/20180225-024011
base:
https://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git
for-next
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 7.2.0
reproduce:
wget
Quoting Chris Wilson (2018-02-24 19:14:00)
> Although we want to specify exactly which physical engine to run on, the
> busy ioctl can only return the I915_EXEC_RING identifier, i.e. the
> aliased I915_EXEC_BSD for vcs0/vcs1. Horrors.
Fixes: 305ebcedc36e ("Iterate over physical engines")
> Signed-
In investigating the issue with having to force preemption within the
executing ELSP[], we want to trigger preemption between all elements of
that array. To that end, we issue a series of requests with different
priorities to fill the in-flight ELSP[] and then demand preemption into
the middle of t
I will check it with latest GCC version and fix it in next version.
Thank you,
Claudiu Beznea
On 22.02.2018 23:00, Patchwork wrote:
> == Series Details ==
>
> Series: extend PWM framework to support PWM modes
> URL : https://patchwork.freedesktop.org/series/38809/
> State : failure
>
> == Sum
21 matches
Mail list logo
