Hi,
On 7/30/2019 7:20 PM, Anshuman Gupta wrote:
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 296452f9efe4..7a46dc957660 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -46,7 +46,8 @@
On 7/30/2019 7:20 PM, Anshuman Gupta wrote:
Adding following definition to i915_reg.h
1. DC_STATE_EN register DC3CO bit fields and masks.
2. Transcoder EXITLINE register and its bit fields and mask.
Cc: Nikula, Jani
Cc: Deak, Imre
Cc: Manna, Animesh
Should be like below,
Cc: Animesh
y")
I have used the drm-misc tree from next-20190731 for today.
--
Cheers,
Stephen Rothwell
pgpmYX829_tMF.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
uC is a subcomponent of GT, so initialize/clean it as part of it. The
wopcm_init_early doesn't have to be happen before the uC one, but since
in other parts of the code we consider WOPCM first do the same for
consistency.
v2: s/cleanup_early/late_release to match the caller
v3:
To be called from the top level runtime functions, to hide the
gt-specific bits (mainly related to intel_uc).
v2: rebased
Signed-off-by: Daniele Ceraolo Spurio
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 12
We don't call the init_early function from within the gem code, so we
shouldn't do it for the cleanup either.
v2: while at it, s/gt_cleanup_early/gt_late_release (Chris)
v3: s/late_release/driver_late_release/ (Chris)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Thanks Maarten for your review comments, please see my responses/questions
below:
On Tue, Jul 30, 2019 at 12:53:30PM +0200, Maarten Lankhorst wrote:
> Op 24-06-2019 om 23:08 schreef Manasi Navare:
> > As per the display enable sequence, we need to follow the enable sequence
> > for slaves first
Rename intel_uc_is_using* into intel_uc_supports* to make clear
distinction from actual state (compare intel_uc_fw_is_running)
Suggested-by: Chris Wilson
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 8 ++---
As we already track GuC/HuC uses by other means than modparam
there is no point in sanitizing it. Just scan modparam for
major discrepancies between what was requested vs actual.
v2: rebased, reworded info messages
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
We can use value of enable_guc modparam during firmware path selection
and start using firmware status to see if GuC/HuC is being used.
This is first step to make enable_guc modparam read-only.
v2: rebased, don't care about <0 (Chris)
v3: oops
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo
v3: oops
Michal Wajdeczko (4):
drm/i915/uc: Rename intel_uc_is_using* into intel_uc_supports*
drm/i915/uc: Consider enable_guc modparam during fw selection
drm/i915/guc: Use dedicated flag to track submission mode
drm/i915/uc: Stop sanitizing enable_guc modparam
Instead of relying on enable_guc modparam to represent actual
GuC submission mode, use dedicated flag and look at modparam
only to check if submission was explicitly disabled by the user.
v2: rebased, simplified condition (Chris)
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc:
On Wed, 31 Jul 2019 22:49:57 +0200, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2019-07-31 15:38:53)
@@ -365,12 +365,12 @@ void intel_uc_fini(struct intel_uc *uc)
{
struct intel_guc *guc = >guc;
- if (!intel_uc_is_using_guc(uc))
+ if (!intel_uc_supports_guc(uc))
Quoting Lionel Landwerlin (2019-07-31 15:07:32)
> +/*
> + * Setting I915_EXEC_EXT implies that drm_i915_gem_execbuffer2.cliprects_ptr
> + * is treated as a pointer to an linked list of i915_user_extension. Each
> + * i915_user_extension node is the base of a larger structure. The list of
> + *
Quoting Michal Wajdeczko (2019-07-31 15:38:56)
> - /* Make sure that sanitization was done */
> - GEM_BUG_ON(i915_modparams.enable_guc < 0);
> + if (i915_modparams.enable_guc & ~(ENABLE_GUC_SUBMISSION ||
> + ENABLE_GUC_LOAD_HUC))
> +
Quoting Michal Wajdeczko (2019-07-31 15:38:55)
> Instead of relying on enable_guc modparam to represent actual
> GuC submission mode, use dedicated flag and look at modparam
> only to check if submission was explicitly disabled by the user.
>
> v2: rebased, simplified condition (Chris)
>
>
Quoting Michal Wajdeczko (2019-07-31 18:50:23)
> On Wed, 31 Jul 2019 19:47:27 +0200, Chris Wilson
> wrote:
>
> > Quoting Michal Wajdeczko (2019-07-31 15:38:54)
> >> +static const char *__override_guc_firmware_path(void)
> >> +{
> >> + if (i915_modparams.enable_guc &
Quoting Michal Wajdeczko (2019-07-31 15:38:53)
> @@ -365,12 +365,12 @@ void intel_uc_fini(struct intel_uc *uc)
> {
> struct intel_guc *guc = >guc;
>
> - if (!intel_uc_is_using_guc(uc))
> + if (!intel_uc_supports_guc(uc))
> return;
Note by this point we
Quoting Michal Wajdeczko (2019-07-31 15:38:53)
> Rename intel_uc_is_using* into intel_uc_supports* to make clear
> distinction from actual state (compare intel_uc_fw_is_running)
>
> Suggested-by: Chris Wilson
> Signed-off-by: Michal Wajdeczko
> Cc: Chris Wilson
I think that reads quite
Changes in the configuration could cause PSR to be compatible and
enabled so driver must also be able to disable DRRS when doing
fastsets.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109263
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108341
Bugzilla:
DRRS and PSR can't be enable together, so giving preference to PSR
as it allows more power-savings by complete shutting down display,
so to guarantee this, it should compute DRRS state after compute PSR.
Cc: Dhinakaran Pandiyan
Cc: Maarten Lankhorst
Signed-off-by: José Roberto de Souza
---
On 7/31/19 12:33 AM, Chris Wilson wrote:
Quoting Daniele Ceraolo Spurio (2019-07-31 01:49:01)
@@ -1401,7 +1453,7 @@ static void process_csb(struct intel_engine_cs *engine)
engine->name, head,
buf[2 * head + 0], buf[2 * head + 1]);
-
Quoting Lionel Landwerlin (2019-07-31 15:07:33)
> -static struct drm_syncobj **
> -get_fence_array(struct drm_i915_gem_execbuffer2 *args,
> - struct drm_file *file)
> +static struct i915_eb_fences *
> +get_timeline_fence_array(struct i915_execbuffer *eb, int *out_n_fences)
> +{
> +
Hi,
I'm glad to see this work moving forward!
On Wed, 2019-07-24 at 10:01 +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 23.07.19 um 14:44 schrieb Andrzej Pietrasiewicz:
> > Hi Sam,
> >
> > W dniu 23.07.2019 o 11:05, Sam Ravnborg pisze:
> > > Hi Andrzej
> > >
> > > On Thu, Jul 11, 2019 at
On Wed, Jul 31, 2019 at 05:14:38PM +, Vivi, Rodrigo wrote:
On Jul 30, 2019, at 2:48 PM, Sasha Levin wrote:
rather
than a few weeks later when Greg sends his "FAILED:" mails and gets
ignored because said folks have moved on.
however this could potentially cause extra work and confusion
Quoting Michal Wajdeczko (2019-07-31 18:48:33)
> We don't have to immediately fail on WOPCM partitioning, we can wait
> until we will start programming WOPCM registers. This should give us
> more options if we decide to restore fallback in case of GuC failures.
>
> v2: rebased
>
> Signed-off-by:
Quoting Michal Wajdeczko (2019-07-31 18:48:32)
> Inject probe errors into intel_uc_init_hw to make sure we
> correctly handle any uC initialization failure.
>
> To avoid complains from CI about injected errors use
> i915_probe_error to lower message level.
>
> Signed-off-by: Michal Wajdeczko
>
Quoting Michal Wajdeczko (2019-07-31 18:48:31)
> With i915 added to i915_inject_probe_failure we can use dedicated
> printk when injecting artificial load failure.
>
> Also make this function look like other i915 functions that return
> error code and make it more flexible to return any provided
Quoting Michal Wajdeczko (2019-07-31 19:00:35)
> We can use value of enable_guc modparam during firmware path selection
> and start using firmware status to see if GuC/HuC is being used.
> This is first step to make enable_guc modparam read-only.
>
> v2: rebased, don't care about <0 (Chris)
> v3:
Quoting Vinay Belgaumkar (2019-07-31 19:31:38)
>
>
> On 07/29/2019 12:19 PM, Chris Wilson wrote:
> > Check for viability of store-dword before use.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > tests/i915/gem_exec_schedule.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
>
On 07/29/2019 12:19 PM, Chris Wilson wrote:
Check for viability of store-dword before use.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_schedule.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tests/i915/gem_exec_schedule.c
We can use value of enable_guc modparam during firmware path selection
and start using firmware status to see if GuC/HuC is being used.
This is first step to make enable_guc modparam read-only.
v2: rebased, don't care about <0 (Chris)
v3: oops
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo
On Wed, 2019-07-31 at 08:01 +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/ehl: Ungate DDIC and DDID
> URL : https://patchwork.freedesktop.org/series/64443/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_6583_full -> Patchwork_13806_full
>
On Wed, 31 Jul 2019 19:47:27 +0200, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2019-07-31 15:38:54)
+static const char *__override_guc_firmware_path(void)
+{
+ if (i915_modparams.enable_guc & (ENABLE_GUC_SUBMISSION ||
+ENABLE_GUC_LOAD_HUC))
With i915 added to i915_inject_probe_failure we can use dedicated
printk when injecting artificial load failure.
Also make this function look like other i915 functions that return
error code and make it more flexible to return any provided error
code instead of previously assumed -ENODEV.
Inject probe errors into intel_uc_init_hw to make sure we
correctly handle any uC initialization failure.
To avoid complains from CI about injected errors use
i915_probe_error to lower message level.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
We don't have to immediately fail on WOPCM partitioning, we can wait
until we will start programming WOPCM registers. This should give us
more options if we decide to restore fallback in case of GuC failures.
v2: rebased
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris
v2: rebased
Michal Wajdeczko (3):
drm/i915: Add i915 to i915_inject_probe_failure
drm/i915/uc: Inject probe errors into intel_uc_init_hw
drm/i915/wopcm: Don't fail on WOPCM partitioning failure
.../gpu/drm/i915/display/intel_connector.c| 2 +-
Quoting Michal Wajdeczko (2019-07-31 15:38:54)
> +static const char *__override_guc_firmware_path(void)
> +{
> + if (i915_modparams.enable_guc & (ENABLE_GUC_SUBMISSION ||
> +ENABLE_GUC_LOAD_HUC))
|| ?
-Chris
On 7/30/19 11:29 PM, Tvrtko Ursulin wrote:
On 31/07/2019 01:49, Daniele Ceraolo Spurio wrote:
The CSB format has been reworked for Gen12 to include information on
both the context we're switching away from and the context we're
switching to. After the change, some of the events don't have
== Series Details ==
Series: series starting with [01/13] drm/amdgpu: Provide ddc symlink in dm
connector's sysfs directory
URL : https://patchwork.freedesktop.org/series/64510/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/amdgpu: Provide ddc
== Series Details ==
Series: series starting with [01/13] drm/amdgpu: Provide ddc symlink in dm
connector's sysfs directory
URL : https://patchwork.freedesktop.org/series/64510/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
100b63028226 drm/amdgpu: Provide ddc symlink in dm
> On Jul 30, 2019, at 2:48 PM, Sasha Levin wrote:
>
> On Tue, Jul 30, 2019 at 01:42:45PM -0700, Rodrigo Vivi wrote:
>> Hi Sasha,
>
> Hello!
>
>> On Thu, Jul 18, 2019 at 5:45 PM Sasha Levin wrote:
>>>
>>> Hi,
>>>
>>> [This is an automated email]
>>
>> Where did you get this patch from?
On 7/30/19 10:59 PM, Tvrtko Ursulin wrote:
On 31/07/2019 01:49, Daniele Ceraolo Spurio wrote:
From: Michel Thierry
In Gen11, only even numbered "logical" VDBoxes are hooked up to a SFC
(Scaler & Format Converter) unit. This is not the case in Tigerlake,
where each VDBox can access a SFC.
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
Acked-by: Sam Ravnborg
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/zte/zx_vga.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/zte/zx_vga.c
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
Acked-by: Sam Ravnborg
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/zte/zx_hdmi.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/zte/zx_hdmi.c
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
Acked-by: Sam Ravnborg
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
Acked-by: Sam Ravnborg
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
Acked-by: Sam Ravnborg
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
Acked-by: Sam Ravnborg
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/tegra/hdmi.c | 7 ---
drivers/gpu/drm/tegra/sor.c | 7 ---
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
Acked-by: Sam Ravnborg
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
Acked-by: Sam Ravnborg
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
Acked-by: Sam Ravnborg
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
Acked-by: Sam Ravnborg
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/rockchip/rk3066_hdmi.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git
Switch to using the ddc provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
Acked-by: Sam Ravnborg
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
ddc local variable is passed to drm_connector_init_with_ddc() and should
be NULL if no ddc is available.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/radeon/radeon_connectors.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
Now that some of the patches of the previous v6 series are applied,
I'm resending the remaining ones (patches 3-13) with Acked-by and
Reviewed-by added.
I'm also taking this opportunity to provide the symlink for another
connector in amdgpu (patch 1), and to fix a small but nasty bug
which can
== Series Details ==
Series: mm/i915: i915_gemfs_init() NULL dereference (rev2)
URL : https://patchwork.freedesktop.org/series/63977/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3523bd66d7d7 mm/i915: i915_gemfs_init() NULL dereference
-:103: ERROR:MISSING_SIGN_OFF: Missing
On (07/21/19 23:29), Sergey Senozhatsky wrote:
>
> BUG: kernel NULL pointer dereference, address:
> #PF: supervisor instruction fetch in kernel mode
> #PF: error_code(0x0010) - not-present page
> PGD 0 P4D 0
> Oops: 0010 [#1] PREEMPT SMP PTI
> RIP: 0010:0x0
> Code: Bad
Hi Andrzej,
On 31/07/2019 16:22, Neil Armstrong wrote:
> On 31/07/2019 15:10, Andrzej Pietrasiewicz wrote:
>> W dniu 31.07.2019 o 12:40, Sam Ravnborg pisze:
>>> Hi Neil.
>>>
>>> On Wed, Jul 31, 2019 at 10:00:14AM +0200, Neil Armstrong wrote:
Hi Sam,
On 26/07/2019 20:55, Sam
We can use value of enable_guc modparam during firmware path selection
and start using firmware status to see if GuC/HuC is being used.
This is first step to make enable_guc modparam read-only.
v2: rebased, don't care about <0 (Chris)
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
v2: rename + don't care about undocumented values <0
changes in IGT to stop using enable_guc modparam to detect
guc_submission mode will follow shortly
Michal Wajdeczko (4):
drm/i915/uc: Rename intel_uc_is_using* into intel_uc_supports*
drm/i915/uc: Consider enable_guc modparam during fw
As we already track GuC/HuC uses by other means than modparam
there is no point in sanitizing it. Just scan modparam for
major discrepancies between what was requested vs actual.
v2: rebased, reworded info messages
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
Rename intel_uc_is_using* into intel_uc_supports* to make clear
distinction from actual state (compare intel_uc_fw_is_running)
Suggested-by: Chris Wilson
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 8 ++---
Instead of relying on enable_guc modparam to represent actual
GuC submission mode, use dedicated flag and look at modparam
only to check if submission was explicitly disabled by the user.
v2: rebased, simplified condition (Chris)
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc:
== Series Details ==
Series: drm/i915: timeline semaphore support (rev3)
URL : https://patchwork.freedesktop.org/series/61032/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: introduce a mechanism to extend execbuf2
Okay!
Commit: drm/i915:
== Series Details ==
Series: drm/i915: timeline semaphore support (rev3)
URL : https://patchwork.freedesktop.org/series/61032/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a226f06ee52a drm/i915: introduce a mechanism to extend execbuf2
-:137: CHECK:SPACING: spaces preferred
On 31/07/2019 15:10, Andrzej Pietrasiewicz wrote:
> W dniu 31.07.2019 o 12:40, Sam Ravnborg pisze:
>> Hi Neil.
>>
>> On Wed, Jul 31, 2019 at 10:00:14AM +0200, Neil Armstrong wrote:
>>> Hi Sam,
>>>
>>> On 26/07/2019 20:55, Sam Ravnborg wrote:
Hi all.
Andrzej have done a good job
We're planning to use this for a couple of new feature where we need
to provide additional parameters to execbuf.
v2: Check for invalid flags in execbuffer2 (Lionel)
Signed-off-by: Lionel Landwerlin
Reviewed-by: Chris Wilson (v1)
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 38
Introduces a new parameters to execbuf so that we can specify syncobj
handles as well as timeline points.
v2: Reuse i915_user_extension_fn
v3: Check that the chained extension is only present once (Chris)
v4: Check that dma_fence_chain_find_seqno returns a non NULL fence (Lionel)
v5: Use
Hi all,
This is the timeline semaphore support extracted from the vulkan
performance query support series.
We're hoping to get this in so we can support timeline semaphore as
soon as possible.
The mesa MR make use of this series (although not all the features) is
at :
Hi -
The drm/i915 [1][2] driver has grown quite big over the years: 400+
files with a total sloccount of 175k lines. A flat directory structure
just wasn't manageable anymore, and we opted to add subdirectories,
despite the general recommendation [3] not to do this.
Mostly, it works all right,
Quoting Michal Wajdeczko (2019-07-31 14:19:06)
> On Tue, 30 Jul 2019 21:07:28 +0200, Chris Wilson
> wrote:
>
> >> +static const char* __override_huc_firmware_path(void)
> >> +{
> >> + if ((i915_modparams.enable_guc < 0) ||
> >> + (i915_modparams.enable_guc &
On Tue, 30 Jul 2019 21:07:28 +0200, Chris Wilson
wrote:
+static const char* __override_huc_firmware_path(void)
+{
+ if ((i915_modparams.enable_guc < 0) ||
+ (i915_modparams.enable_guc & ENABLE_GUC_LOAD_HUC))
+ return i915_modparams.huc_firmware_path;
We can
W dniu 31.07.2019 o 12:40, Sam Ravnborg pisze:
Hi Neil.
On Wed, Jul 31, 2019 at 10:00:14AM +0200, Neil Armstrong wrote:
Hi Sam,
On 26/07/2019 20:55, Sam Ravnborg wrote:
Hi all.
Andrzej have done a good job following up on feedback and this series is
now ready.
We need ack on the patches
== Series Details ==
Series: Force spin-batch to cause a hang as required
URL : https://patchwork.freedesktop.org/series/64495/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6590 -> IGTPW_3311
Summary
---
== Series Details ==
Series: drm/i915: make i915_selftest.h self-contained
URL : https://patchwork.freedesktop.org/series/64445/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6585_full -> Patchwork_13808_full
Summary
On Wed, Jul 31, 2019 at 1:19 PM Christian König
wrote:
>
> Am 31.07.19 um 12:39 schrieb Daniel Vetter:
> > On Wed, Jul 31, 2019 at 11:44 AM Christian König
> > wrote:
> >> Am 31.07.19 um 11:12 schrieb Daniel Vetter:
> >>> [SNIP]
> >>> I think I brought this up before, but new top-post for a
Quoting Daniele Ceraolo Spurio (2019-07-31 00:07:40)
> The register we write are not WOPCM regs but uC ones related to how
> GuC and HuC are going to use the WOPCM, so it makes logical sense
> for them to be programmed as part of uc_init_hw. The WOPCM map on the
> other side is not uC-specific
When using a spinner to trigger a hang, make it unpreemptable so that it
appears like a true hang.
References: https://bugs.freedesktop.org/show_bug.cgi?id=109661
Signed-off-by: Chris Wilson
---
tests/i915/gem_eio.c| 4 +++-
tests/i915/gem_exec_fence.c | 3 ++-
tests/kms_busy.c
On Fri, Jul 26, 2019 at 9:30 PM Chris Wilson wrote:
>
> Quoting Thomas Gleixner (2019-07-26 20:18:32)
> > On Fri, 26 Jul 2019, Chris Wilson wrote:
> > > Quoting Thomas Gleixner (2019-07-25 22:55:45)
> > > > On Thu, 25 Jul 2019, Josh Poimboeuf wrote:
> > > >
> > > > > Objtool reports:
> > > > >
>
== Series Details ==
Series: Tiger Lake: MOCS table handling (rev3)
URL : https://patchwork.freedesktop.org/series/64275/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6585_full -> Patchwork_13807_full
Summary
---
Hi Neil.
On Wed, Jul 31, 2019 at 10:00:14AM +0200, Neil Armstrong wrote:
> Hi Sam,
>
> On 26/07/2019 20:55, Sam Ravnborg wrote:
> > Hi all.
> >
> > Andrzej have done a good job following up on feedback and this series is
> > now ready.
> >
> > We need ack on the patches touching the individual
On Wed, Jul 31, 2019 at 11:44 AM Christian König
wrote:
>
> Am 31.07.19 um 11:12 schrieb Daniel Vetter:
> > [SNIP]
> > I think I brought this up before, but new top-post for a clean start.
> >
> > Use-case I have in mind is something like amdkfd's model, where you have a
> > list of buffers (per
On Wed, Jun 26, 2019 at 02:23:05PM +0200, Christian König wrote:
> On the exporter side we add optional explicit pinning callbacks. If those
> callbacks are implemented the framework no longer caches sg tables and the
> map/unmap callbacks are always called with the lock of the reservation object
Quoting Michal Wajdeczko (2019-07-31 10:00:57)
> On Wed, 31 Jul 2019 01:07:40 +0200, Daniele Ceraolo Spurio
> wrote:
>
> > The register we write are not WOPCM regs but uC ones related to how
> > GuC and HuC are going to use the WOPCM, so it makes logical sense
> > for them to be programmed as
== Series Details ==
Series: drm/i915/selftests: Pass intel_context to igt_spinner (rev3)
URL : https://patchwork.freedesktop.org/series/64440/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6587 -> Patchwork_13818
Summary
On Wed, 31 Jul 2019 01:07:40 +0200, Daniele Ceraolo Spurio
wrote:
The register we write are not WOPCM regs but uC ones related to how
GuC and HuC are going to use the WOPCM, so it makes logical sense
for them to be programmed as part of uc_init_hw. The WOPCM map on the
other side is not
== Series Details ==
Series: tests/i915/gem_exec_async: Update with engine discovery (rev2)
URL : https://patchwork.freedesktop.org/series/64425/
State : warning
== Summary ==
Pipeline status: FAILED.
See https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags/pipelines/52430 for more
details.
On Thu, Jun 27, 2019 at 09:28:11AM +0200, Christian König wrote:
> Hi Daniel,
>
> those fails look like something random to me and not related to my patch
> set. Correct?
First one I looked at has the reservation_obj all over:
On Wed, 31 Jul 2019 01:07:39 +0200, Daniele Ceraolo Spurio
wrote:
When coming out of S3/S4 we sanitize and re-init the HW, which includes
enabling communication during uc_init_hw. We therefore don't want to do
that again in uc_resume and can just tell GuC to reload its state.
v2: split
Quoting Chris Wilson (2019-07-31 09:05:25)
> + /* First up, check the legacy engine selector ABI for independence */
> + igt_subtest_group {
> + struct intel_execution_engine2 engines[64];
> + unsigned int num_engines = 0;
> +
> + igt_fixture {
== Series Details ==
Series: tests/i915/gem_exec_async: Update with engine discovery (rev2)
URL : https://patchwork.freedesktop.org/series/64425/
State : failure
== Summary ==
IGT patchset build failed on latest successful build
d2e6dd2f789596da5bd06efc2e9448e3160583b6 README: Add missing
On Wed, Jul 31, 2019 at 10:25:15AM +0200, Christian König wrote:
> Am 31.07.19 um 10:05 schrieb Daniel Vetter:
> > [SNIP]
> > > > Okay, I see now I was far off the mark with what I thought TTM_PL_SYSTEM
> > > > was. The discussion helped clear up several bits of confusion on my
> > > > part.
> >
On 31/07/2019 09:11, Chris Wilson wrote:
Teach igt_spinner to only use our internal structs, decoupling the
interface from the GEM contexts. This makes it easier to avoid
requiring ce->gem_context back references for kernel_context that may
have them in future.
v2: Lift engine lock to
Teach igt_spinner to only use our internal structs, decoupling the
interface from the GEM contexts. This makes it easier to avoid
requiring ce->gem_context back references for kernel_context that may
have them in future.
v2: Lift engine lock to verify_wa() caller.
v3: Less than v2, but more so
Quoting Tvrtko Ursulin (2019-07-31 08:37:44)
>
> On 31/07/2019 08:00, Chris Wilson wrote:
> > @@ -1183,11 +1191,16 @@ live_engine_reset_workarounds(void *arg)
> > goto err;
> > }
> >
> > - ret = igt_spinner_init(, i915);
> > - if
On Wed, Jul 31, 2019 at 8:54 AM Koenig, Christian
wrote:
>
> Am 31.07.19 um 02:51 schrieb Brian Welty:
> [SNIP]
> >> +/*
> >> + * Memory types for drm_mem_region
> >> + */
> > #define DRM_MEM_SWAP?
> btw what did you have in mind for this? Since we use shmem we kinda
Quoting Tvrtko Ursulin (2019-07-31 07:12:35)
>
> On 30/07/2019 18:07, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-07-30 16:20:08)
> >>
> >> On 30/07/2019 09:04, Ramalingam C wrote:
> >>> On 2019-07-30 at 13:05:27 +0100, Tvrtko Ursulin wrote:
>
> On 30/07/2019 04:58, Ramalingam
1 - 100 of 118 matches
Mail list logo
