> Hi Gerd,
>
> I've been seeing a regression on Nouveau with recent linux-next releases
> and git bisect points at this commit as the first bad one. If I revert
> it (there's a tiny conflict with a patch that was merged subsequently),
> things are back to normal.
>
> I think the reason for this
== Series Details ==
Series: i915/gem_mocs_settings: Fudge gen11:vcs2 mocs register base
URL : https://patchwork.freedesktop.org/series/65138/
State : success
== Summary ==
CI Bug Log - changes from IGT_5132_full -> IGTPW_3342_full
Summary
Hi all,
Today's linux-next merge of the etnaviv tree got a conflict in:
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
between commit:
52791eeec1d9 ("dma-buf: rename reservation_object to dma_resv")
from the drm-misc tree and commit:
6eae41fea750 ("drm/etnaviv: drop use of drmP.h")
== Series Details ==
Series: linux-next: manual merge of the drm-misc tree with the drm and
drm-intel trees
URL : https://patchwork.freedesktop.org/series/65162/
State : failure
== Summary ==
Applying: linux-next: manual merge of the drm-misc tree with the drm and
drm-intel trees
Using
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
drivers/gpu/drm/i915/i915_vma.c
drivers/gpu/drm/i915/i915_gem_batch_pool.c
drivers/gpu/drm/i915/gem/i915_gem_object.c
drivers/gpu/drm/i915/gt/intel_engine_pool.c
between
== Series Details ==
Series: drm/i915: Remove i915 ggtt WA since GT E0
URL : https://patchwork.freedesktop.org/series/65160/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6700 -> Patchwork_14006
Summary
---
== Series Details ==
Series: drm/i915/guc: Remove client->submissions
URL : https://patchwork.freedesktop.org/series/65159/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6700 -> Patchwork_14005
Summary
---
comments updated, please review again.
-Original Message-
From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
Sent: Tuesday, August 13, 2019 8:47 PM
To: Yang, Dong ; intel-gfx@lists.freedesktop.org
Cc: y...@freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Remove i915
From: "Yang, Dong"
Broxton steppings starting from GT E0 have fixed the bug, remove
WA since stepping GT E0.
Signed-off-by: Yang, Dong
---
drivers/gpu/drm/i915/i915_drv.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
== Series Details ==
Series: drm/i915/guc: Remove client->submissions
URL : https://patchwork.freedesktop.org/series/65159/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3accf6a089e8 drm/i915/guc: Remove client->submissions
-:89: CHECK:PARENTHESIS_ALIGNMENT: Alignment should
The engine->guc_id is GuC FW defined and it is not guaranteed to be
below I915_NUM_ENGINES, so we shouldn't use it with the i915-defined
client->submissions, as we might overflow.
Instead of fixing it, just get rid of client->submissions, because the
information we get from it is not interesting
> -Original Message-
> From: Chris Wilson
> Sent: Tuesday, August 13, 2019 11:21 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Chris Wilson ; Daniel Vetter
> ; Maarten Lankhorst
> ; Srivatsa, Anusha
>
> Subject: [PATCH v2] drm/i915: Disregard drm_mode_config.fb_base
>
> The fb_base
Patches 1 and 2 pushed to dinq as both are reviewed and are just moving
code with no behavior changes.
On Tue, 2019-08-06 at 16:31 -0700, Lucas De Marchi wrote:
> On Tue, Jul 30, 2019 at 03:47:51PM -0700, Jose Souza wrote:
> > A new macro that is going to be added in a further patch will need
> >
On Tue, 2019-08-13 at 22:57 +0100, Chris Wilson wrote:
> Some IGT would like to know the mmio address of each engine so make
> it
> available.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Stuart Summers
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 1 +
> 1 file changed, 1 insertion(+)
== Series Details ==
Series: drm/i915: Include engine->mmio_base in the debug duump
URL : https://patchwork.freedesktop.org/series/65157/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6699 -> Patchwork_14004
Summary
Some IGT would like to know the mmio address of each engine so make it
available.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
On 8/9/19 3:46 PM, Daniele Ceraolo Spurio wrote:
On 8/9/19 3:26 PM, Matthew Auld wrote:
From: Daniele Ceraolo Spurio
We can't fence anything without aperture.
When I wrote this patch (before LMEM was in the picture) mappable
aperture was supposed to only be missing in headless
I'm dropping this series as Clint is working on this and may have a
different implementation.
Lucas De Marchi
On Thu, Jul 25, 2019 at 4:57 PM Lucas De Marchi
wrote:
>
> Mostly the same patches as https://patchwork.freedesktop.org/series/63670/.
> Rebased.
>
> Lucas De Marchi (2):
>
== Series Details ==
Series: drm/i915: Serialise read/write of the barrier's engine
URL : https://patchwork.freedesktop.org/series/65152/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6698 -> Patchwork_14003
Summary
== Series Details ==
Series: series starting with [1/2] drm/i915: Push the wakeref->count deferral
to the backend
URL : https://patchwork.freedesktop.org/series/65129/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6695_full -> Patchwork_13997_full
On Tue, Aug 13, 2019 at 06:06:04PM +0800, Zhenyu Wang wrote:
>
> Hi,
>
> Here's gvt-next stuff for next kernel which include several enhancement
> for cmd parser and batch buffer shadow, remove extra debugfs function
> return check, and with other misc changes like typo, static check fix,
> etc.
On Tue, 13 Aug 2019 18:26:28 +0200, Fernando Pacheco
wrote:
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.
Signed-off-by: Fernando Pacheco
Cc: Daniele Ceraolo
On 8/13/19 9:26 AM, Fernando Pacheco wrote:
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.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110943
We use the request pointer inside the i915_active_node as the indicator
of the barrier's status; we mark it as used during
i915_request_add_active_barriers(), and search for an available barrier
in reuse_idle_barrier(). That check must be carefully serialised to
ensure we do use an engine for the
== Series Details ==
Series: series starting with [v3] drm/i915: Push the wakeref->count deferral to
the backend (rev3)
URL : https://patchwork.freedesktop.org/series/65129/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6697 -> Patchwork_14002
== Series Details ==
Series: drm/i915: Disregard drm_mode_config.fb_base (rev2)
URL : https://patchwork.freedesktop.org/series/65144/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6697 -> Patchwork_14001
Summary
---
== Series Details ==
Series: series starting with [v3] drm/i915: Push the wakeref->count deferral to
the backend (rev3)
URL : https://patchwork.freedesktop.org/series/65129/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
54a4779b40e5 drm/i915: Push the wakeref->count deferral
On Sat, 10 Aug 2019 at 08:26, Matthew Auld wrote:
>
> In preparation for upcoming devices with device local memory, introduce the
> concept of different memory regions, and a simple buddy allocator to manage
> them in i915.
>
> One of the concerns raised from v1 was around not using enough of
On Fri, Aug 09, 2019 at 11:26:10PM +0100, Matthew Auld wrote:
> Some objects may need to be allocated as a continuous block, thinking
> ahead the various kernel io_mapping interfaces seem to expect it.
Not really, we can vmalloc for iomappings too.
-Daniel
>
> Signed-off-by: Matthew Auld
> Cc:
If the backend wishes to defer the wakeref parking, make it responsible
for unlocking the wakeref (i.e. bumping the counter). This allows it to
time the unlock much more carefully in case it happens to needs the
wakeref to be active during its deferral.
For instance, during engine parking we may
== Series Details ==
Series: series starting with [1/3] drm/i915: Use render class for MI_SET_CONTEXT
URL : https://patchwork.freedesktop.org/series/65143/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6697 -> Patchwork_14000
== Series Details ==
Series: series starting with [1/3] drm/i915: Use render class for MI_SET_CONTEXT
URL : https://patchwork.freedesktop.org/series/65143/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5b350dea3606 drm/i915: Use render class for MI_SET_CONTEXT
413c907ef6c0
== Series Details ==
Series: drm/i915/uc: Fini hw even if GuC is not running
URL : https://patchwork.freedesktop.org/series/65140/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6697 -> Patchwork_13999
Summary
---
The fb_base is only used for communicating the GTT BAR from one piece of
the display code (kms setup) to another (fbdev). What is required in the
fbdev is just the aperture address which should be derived from the
bo we allocate for the framebuffer directly.
The same appears true for drm/; it is
== Series Details ==
Series: series starting with [v2] drm/i915: Push the wakeref->count deferral to
the backend (rev2)
URL : https://patchwork.freedesktop.org/series/65129/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6697 -> Patchwork_13998
Quoting Chris Wilson (2019-08-13 19:03:38)
> Quoting Stuart Summers (2019-08-13 18:41:21)
> > In some debug scenarios, it might be interesting to load
> > a platform without support for the render command streamer.
> > Add a module parameter to allow this platform configuration.
> >
> >
Quoting Chris Wilson (2019-08-13 18:47:35)
> diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
> b/drivers/gpu/drm/i915/display/intel_fbdev.c
> index 5e7cc5a6ac7f..8eb220e9e58f 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
> @@
On Thu, Jul 25, 2019 at 05:02:24PM -0700, Lucas De Marchi wrote:
> From: Michel Thierry
>
> Inherit workarounds from previous platforms that are still valid for
> Tigerlake.
>
> WaPipelineFlushCoherentLines:tgl (changed register but has same name)
> WaSendPushConstantsFromMMIO:tgl
>
Quoting Stuart Summers (2019-08-13 19:00:18)
> On Tue, 2019-08-13 at 18:54 +0100, Chris Wilson wrote:
> > Quoting Stuart Summers (2019-08-13 18:41:19)
> > > Replace GEM_BUG_ON with explicit check for render class
> > > when doing the kernel context switch.
> > >
> > > Signed-off-by: Stuart
Quoting Stuart Summers (2019-08-13 18:41:21)
> In some debug scenarios, it might be interesting to load
> a platform without support for the render command streamer.
> Add a module parameter to allow this platform configuration.
>
> Signed-off-by: Stuart Summers
Interesting, aside from that we
On Tue, 2019-08-13 at 18:54 +0100, Chris Wilson wrote:
> Quoting Stuart Summers (2019-08-13 18:41:19)
> > Replace GEM_BUG_ON with explicit check for render class
> > when doing the kernel context switch.
> >
> > Signed-off-by: Stuart Summers
> > ---
> >
Quoting Stuart Summers (2019-08-13 18:41:20)
> Use render class instead of RCS0 when printing CCID.
>
> Signed-off-by: Stuart Summers
One day, one day, this will be using some lists of registers.
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx
Quoting Stuart Summers (2019-08-13 18:41:19)
> Replace GEM_BUG_ON with explicit check for render class
> when doing the kernel context switch.
>
> Signed-off-by: Stuart Summers
> ---
> drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
>
The fb_base is only used for communicating the GTT BAR from one piece of
the display code (kms setup) to another (fbdev). What is required in the
fbdev is just the aperture address which should be derived from the
bo we allocate for the framebuffer directly.
The same appears true for drm/; it is
== Series Details ==
Series: series starting with [v2] drm/i915: Push the wakeref->count deferral to
the backend (rev2)
URL : https://patchwork.freedesktop.org/series/65129/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3385f5b3d187 drm/i915: Push the wakeref->count deferral
In some debug scenarios, it might be interesting to load
a platform without support for the render command streamer.
Add a module parameter to allow this platform configuration.
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/i915_params.c | 3 +++
Use render class instead of RCS0 when printing CCID.
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index
Replace GEM_BUG_ON with explicit check for render class
when doing the kernel context switch.
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
On Tue, 2019-08-13 at 04:45 +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/tgl: Fix missing parentheses on
> TGL_TRANS_DDI_FUNC_CTL_VAL_TO_PORT
> URL : https://patchwork.freedesktop.org/series/65097/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from
== Series Details ==
Series: i915/gem_mocs_settings: Fudge gen11:vcs2 mocs register base
URL : https://patchwork.freedesktop.org/series/65138/
State : success
== Summary ==
CI Bug Log - changes from IGT_5132 -> IGTPW_3342
Summary
---
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.
Signed-off-by: Fernando Pacheco
Cc: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
---
On gen11 CI, we have vcs2 available which has a different base to gen9
vcs1. Gloss over the discrepancy while a proper fix is sought.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111330
Signed-off-by: Chris Wilson
---
tests/i915/gem_mocs_settings.c | 28 ++--
1
On gen11 CI, we have vcs2 available which has a different base to gen9
vcs1. Gloss over the discrepancy while a proper fix is sought.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111330
Signed-off-by: Chris Wilson
---
tests/i915/gem_mocs_settings.c | 28 ++--
1
On Sat, Aug 10, 2019 at 12:02:21AM +0530, Anshuman Gupta wrote:
> Add dc3co helper functions to enable/disable psr2 deep sleep.
> Disallow DC3CO state before PSR2 exit, it essentially does
> that by putting a reference to POWER_DOMAIN_VIDEO before
> PSR2 exit.
>
> Cc: Jani Nikula
> Cc: Imre Deak
On Sat, Aug 10, 2019 at 12:02:19AM +0530, Anshuman Gupta wrote:
> We need to have a S/W flag based upon which driver can switch to DC3CO.
> If it is only edp display connected and it has psr2 capability,
> then set a prefer_dc3co flag to true, which will be used to
> switch to dc3co as well as to
Hi Chris,
On Tue, Aug 13, 2019 at 07:20:12AM +0100, Chris Wilson wrote:
> Still trying to hit a deadlock with userptr from kcompatcd.
>
> Signed-off-by: Chris Wilson
This looks all right, as well.
Reveiwed-by: Andi Shyti
Andi
___
Intel-gfx mailing
Hi Chris,
On Tue, Aug 13, 2019 at 07:20:16AM +0100, Chris Wilson wrote:
> The intent of the test is to exercise that each channel in the engine[]
> is an independent context/ring/timeline. It setups 64 channels pointing
> to rcs0 and then submits one request to each in turn waiting on a
>
Hi Chris,
On Tue, Aug 13, 2019 at 07:20:11AM +0100, Chris Wilson wrote:
> Trying to hit a deadlock for invalidating dirty userptr pages (via
> kcompactd).
>
> Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
Andi
___
Intel-gfx mailing list
== Series Details ==
Series: drm/i915/uc: Log fw status changes only under debug config (rev2)
URL : https://patchwork.freedesktop.org/series/65101/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6691_full -> Patchwork_13996_full
On Mon, Aug 05, 2019 at 04:01:10PM +0200, Gerd Hoffmann wrote:
> Drop vma_node from ttm_buffer_object, use the gem struct
> (base.vma_node) instead.
>
> Signed-off-by: Gerd Hoffmann
> Reviewed-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
>
On 8/13/2019 3:57 AM, Anusha Srivatsa wrote:
The BSpec has added three new IDS for CML.
Update the IDs in accordance to the Spec.
Cc: Lucas De Marchi
Cc: José Roberto de Souza
Signed-off-by: Anusha Srivatsa
---
include/drm/i915_pciids.h | 5 -
1 file changed, 4 insertions(+), 1
On Sat, Aug 10, 2019 at 12:02:18AM +0530, Anshuman Gupta wrote:
> As per B.Specs DC5 and DC6 not allowed when DC3CO is enabled
> and DC3CO should be enabled only during VIDEO playback.
> Which essentially means both can DC5 and DC3CO can not be
> enabled at same time, it makes DC3CO and DC5 mutual
If the backend wishes to defer the wakeref parking, make it responsible
for unlocking the wakeref (i.e. bumping the counter). This allows it to
time the unlock much more carefully in case it happens to needs the
wakeref to be active during its deferral.
For instance, during engine parking we may
Chris Wilson writes:
> Stop assuming we only get called with irqs-on for disarming the
> breadcrumbs, and do a full save/restore spin_lock_irq.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
perf timer, drop ref, engine_unpark, disable_breadcrumbs
with irqs off.
Well, the trace on
Chris Wilson writes:
> If the backend wishes to defer the wakeref parking, make it responsible
> for unlocking the wakeref (i.e. bumping the counter). This allows it to
> time the unlock much more carefully in case it happens to needs the
> wakeref to be active during its deferral.
>
> For
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 programming.
> Renaming "DC Off" power
Hi Chris,
On Tue, Aug 13, 2019 at 07:20:08AM +0100, Chris Wilson wrote:
> If we are not running with a scheduler, we are using a global ringbuffer
> which may not accommodate 16 extra batches. Fortunately, we only need
> one such batch to block the submission queue as without a scheduler, it
> is
Hi Chris,
On Tue, Aug 13, 2019 at 07:20:09AM +0100, Chris Wilson wrote:
> Make sure we don't block while setting up the stress case before the
> reset by only submitting less batches than would fill the ring.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=111379
> Signed-off-by:
== Series Details ==
Series: series starting with [1/2] drm/i915: Push the wakeref->count deferral
to the backend
URL : https://patchwork.freedesktop.org/series/65129/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6695 -> Patchwork_13997
== Series Details ==
Series: series starting with [1/2] drm/i915: Push the wakeref->count deferral
to the backend
URL : https://patchwork.freedesktop.org/series/65129/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2be90d21860a drm/i915: Push the wakeref->count deferral to the
On Tue, 13 Aug 2019, Zhenyu Wang wrote:
> Hi,
>
> Here's one gvt fix for 5.3-rc, to fix one use-after-free issue
> introduced in last fixes pull.
Thanks, pulled.
BR,
Jani.
>
> Thanks
> --
> The following changes since commit 4187414808095f645ca0661f8dde77617e2e7cb3:
>
> drm/i915/gvt: Adding
If the backend wishes to defer the wakeref parking, make it responsible
for unlocking the wakeref (i.e. bumping the counter). This allows it to
time the unlock much more carefully in case it happens to needs the
wakeref to be active during its deferral.
For instance, during engine parking we may
Stop assuming we only get called with irqs-on for disarming the
breadcrumbs, and do a full save/restore spin_lock_irq.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
Quoting Dong Yang (2019-08-12 05:36:16)
> From: "Yang, Dong"
>
> The APL already fixed this bug since GT E, bug exist from
> 0 to D, apply WA according GT stepping.
"Broxton steppings starting from E0 have fixed the bug."
> Signed-off-by: Yang, Dong
You probably want to use "" here too. Or
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/guc: keep breadcrumb irq always
enabled
URL : https://patchwork.freedesktop.org/series/65105/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6690_full -> Patchwork_13995_full
== Series Details ==
Series: drm/i915/cml: Add Missing PCI IDs
URL : https://patchwork.freedesktop.org/series/65104/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6690_full -> Patchwork_13994_full
Summary
---
== Series Details ==
Series: drm/i915/guc: keep breadcrumb irq always enabled
URL : https://patchwork.freedesktop.org/series/65103/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6690_full -> Patchwork_13993_full
Summary
On 10/08/2019 15.38, Chris Wilson wrote:
> Closing the object on another file should not affect the local
> mmap_offset.
>
Thanks for this! It helped squeezed the bug out of mmap_offset.
Reviewed-by: Abdiel Janulgue
> Signed-off-by: Chris Wilson
> Cc: Abdiel Janulgue
> ---
>
Hi,
Here's gvt-next stuff for next kernel which include several enhancement
for cmd parser and batch buffer shadow, remove extra debugfs function
return check, and with other misc changes like typo, static check fix,
etc.
Thanks
--
The following changes since commit
Hi,
Here's one gvt fix for 5.3-rc, to fix one use-after-free issue
introduced in last fixes pull.
Thanks
--
The following changes since commit 4187414808095f645ca0661f8dde77617e2e7cb3:
drm/i915/gvt: Adding ppgtt to GVT GEM context after shadow pdps settled.
(2019-07-30 14:30:56 +0800)
are
Quoting Patchwork (2019-08-13 09:53:21)
> == Series Details ==
>
> Series: drm/i915/uc: Log fw status changes only under debug config (rev2)
> URL : https://patchwork.freedesktop.org/series/65101/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_6691 -> Patchwork_13996
On Fri, Mar 29, 2019 at 01:45:59AM +0530, Uma Shankar wrote:
> Existing LUT precision structure is having only 16 bit
> precision. This is not enough for upcoming enhanced hardwares
> and advance usecases like HDR processing. Hence added a new
> structure with 32 bit precision values. Also added
Hi Günter,
On Thu, Aug 8, 2019 at 5:42 AM Guenter Roeck wrote:
> On Fri, Jul 26, 2019 at 07:23:13PM +0200, Andrzej Pietrasiewicz wrote:
> > Use the ddc pointer provided by the generic connector.
> >
> > Signed-off-by: Andrzej Pietrasiewicz
> > Reviewed-by: Neil Armstrong
>
> This patch results
On 05.08.19 00:48, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page() or
> release_pages().
>
> This is part a tree-wide conversion, as described in
== Series Details ==
Series: drm/i915/uc: Log fw status changes only under debug config (rev2)
URL : https://patchwork.freedesktop.org/series/65101/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6691 -> Patchwork_13996
Am 13.08.19 um 10:25 schrieb Chris Wilson:
> Quoting Koenig, Christian (2019-08-13 07:59:28)
>> Am 12.08.19 um 16:53 schrieb Chris Wilson:
>>> Quoting Koenig, Christian (2019-08-12 15:50:59)
Am 12.08.19 um 16:43 schrieb Chris Wilson:
> Quoting Koenig, Christian (2019-08-12 15:34:32)
Quoting Koenig, Christian (2019-08-13 07:59:28)
> Am 12.08.19 um 16:53 schrieb Chris Wilson:
> > Quoting Koenig, Christian (2019-08-12 15:50:59)
> >> Am 12.08.19 um 16:43 schrieb Chris Wilson:
> >>> Quoting Koenig, Christian (2019-08-12 15:34:32)
> Am 10.08.19 um 17:34 schrieb Chris Wilson:
>
Quoting Michal Wajdeczko (2019-08-13 09:15:59)
> We don't care about internal firmware status changes unless
> we are doing some real debugging. Note that our CI is not
> using DRM_I915_DEBUG_GUC config by default so use it.
>
> v2: protect against accidental overwrites (Chris)
>
>
On Mon, 29 Jul 2019, Jani Nikula wrote:
> The following commits have been marked as Cc: stable or fixing something
> in v5.3-rc2 or earlier, but failed to cherry-pick to
> drm-intel-fixes. Please see if they are worth backporting, and please do
> so if they are.
>
> Failed to cherry-pick:
>
We don't care about internal firmware status changes unless
we are doing some real debugging. Note that our CI is not
using DRM_I915_DEBUG_GUC config by default so use it.
v2: protect against accidental overwrites (Chris)
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris
Quoting Jani Nikula (2019-08-13 09:06:45)
> This is a new one:
>
> d8af05ff38ae ("drm/i915: Allow sharing the idle-barrier from other kernel
> requests")
That requires a slew of dependencies.
-Chris
___
Intel-gfx mailing list
Quoting Mika Kuoppala (2019-08-13 08:57:51)
> Chris Wilson writes:
>
> > Quoting Mika Kuoppala (2019-08-12 17:01:07)
> >> @@ -2829,7 +2887,10 @@ int intel_execlists_submission_setup(struct
> >> intel_engine_cs *engine)
> >> logical_ring_default_irqs(engine);
> >>
> >> if
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-08-12 17:01:07)
>> Add tile cache flushing for gen11. To relive us from the
>> burden of previous obsolete workarounds, make a dedicated
>> flush/invalidate callback for gen11.
>>
>> To fortify an independent single flush, do post
>> sync op as
== Series Details ==
Series: drm/i915/uc: Log fw status changes only under debug config
URL : https://patchwork.freedesktop.org/series/65101/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6689_full -> Patchwork_13991_full
Quoting Daniele Ceraolo Spurio (2019-08-13 00:31:50)
> We rely on the tasklet to update the GT PM refcount, so we can't disable
> it even if we've processed all the requests for the engine because we
> might have detected the request completion before the interrupt arrived.
>
> Since on all
Am 12.08.19 um 16:53 schrieb Chris Wilson:
> Quoting Koenig, Christian (2019-08-12 15:50:59)
>> Am 12.08.19 um 16:43 schrieb Chris Wilson:
>>> Quoting Koenig, Christian (2019-08-12 15:34:32)
Am 10.08.19 um 17:34 schrieb Chris Wilson:
> Move the duplicated code within dma-fence.c into the
Quoting Daniele Ceraolo Spurio (2019-08-13 00:31:51)
> The last user has been removed, so drop the functions.
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Chris Wilson
If this sticks, we can remove the b->irq_enabled counter (iirc). For the
moment, keep it simple in case we need to revive
Closing the object on another file should not affect the local
mmap_offset.
Signed-off-by: Chris Wilson
Cc: Abdiel Janulgue
---
tests/i915/gem_mmap_gtt.c | 40 +++
1 file changed, 40 insertions(+)
diff --git a/tests/i915/gem_mmap_gtt.c
Check that we can run a second request even if an equal priority spinner
is hogging the engine.
Signed-off-by: Chris Wilson
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
---
tests/i915/gem_exec_schedule.c | 36 ++
1 file changed, 36 insertions(+)
diff --git
Runtime suspend kicks in quicker if we flush any idle work that may been
accrued.
Signed-off-by: Chris Wilson
---
tests/perf_pmu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index d392a67d4..351090710 100644
--- a/tests/perf_pmu.c
+++
1 - 100 of 107 matches
Mail list logo
