Hi Masahiro
On Tue, Aug 06, 2019 at 03:39:18PM +0900, Masahiro Yamada wrote:
>
> Recently, Jani Nikula requests a better build system support
> for drivers spanning multiple directories.
> (better kbuild support for drivers spanning multiple directories?)
>
> I implemented it, so please take a l
Hi Anshuman,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[cannot apply to v5.3-rc3 next-20190809]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
== Series Details ==
Series: series starting with [1/4] dma-buf: add reservation_object_fences helper
URL : https://patchwork.freedesktop.org/series/64955/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6667_full -> Patchwork_13941_full
=
Hi Anshuman,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[cannot apply to v5.3-rc3 next-20190809]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
On Fri, 9 Aug 2019, Sedat Dilek wrote:
> On Fri, Aug 9, 2019 at 1:03 AM Nick Desaulniers
> wrote:
> >
> > On Thu, Aug 8, 2019 at 1:22 PM Thomas Gleixner wrote:
> > > > tglx just picked up 2 other patches of mine, bumping just in case he's
> > > > not picking up patches while on vacation. ;)
> >
== Series Details ==
Series: put_user_pages(): miscellaneous call sites
URL : https://patchwork.freedesktop.org/series/64950/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6667_full -> Patchwork_13939_full
Summary
---
== Series Details ==
Series: dma-buf: make dma_fence structure a bit smaller (rev3)
URL : https://patchwork.freedesktop.org/series/64953/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6667_full -> Patchwork_13938_full
Summa
== Series Details ==
Series: drm/i915: Check for a second VCS engine more carefully (rev2)
URL : https://patchwork.freedesktop.org/series/64938/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6667_full -> Patchwork_13935_full
== Series Details ==
Series: drm/i915: Replace global bsd_dispatch_index with random seed (rev2)
URL : https://patchwork.freedesktop.org/series/64891/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6665_full -> Patchwork_13933_full
==
== Series Details ==
Series: Introduce memory region concept (including device local memory) (rev3)
URL : https://patchwork.freedesktop.org/series/56683/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6670 -> Patchwork_13957
Quoting Chris Wilson (2019-08-06 14:47:25)
> Normally, we rely on our hangcheck to prevent persistent batches from
> hogging the GPU. However, if the user disables hangcheck, this mechanism
> breaks down. Despite our insistence that this is unsafe, the users are
> equally insistent that they want t
== Series Details ==
Series: Introduce memory region concept (including device local memory) (rev3)
URL : https://patchwork.freedesktop.org/series/56683/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: buddy allocator
+drivers/gpu/drm/i915/sel
== Series Details ==
Series: Introduce memory region concept (including device local memory) (rev3)
URL : https://patchwork.freedesktop.org/series/56683/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
45cebf7cea76 drm/i915: buddy allocator
-:29: WARNING:FILE_PATH_CHANGES: added,
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 scenarios so I
didn't consider the display case. Do we still
From: Abdiel Janulgue
Returns the available memory region areas supported by the HW.
Signed-off-by: Abdiel Janulgue
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_query.c | 57 +++
include/uapi/drm/i915_drm.h | 39 +
2 files changed, 96
From: Daniele Ceraolo Spurio
If the aperture is not available in HW we can't use a ggtt slot and wc
copy, so fall back to regular kmap.
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Abdiel Janulgue
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 19
drivers/gpu/drm/i915/i915_gpu_e
From: Abdiel Janulgue
If there is no aperture we can't use map_gtt to map dumb buffers, so we
need a cpu-map based path to do it. We prefer map_gtt on platforms that
do have aperture.
Signed-off-by: Abdiel Janulgue
Cc: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Matthew Auld
---
drivers/g
Intended for upstream testing so that we can still exercise the LMEM
plumbing and !HAS_MAPPABLE_APERTURE paths. Smoke tested on Skull Canyon
device. This works by allocating an intel_memory_region for a reserved
portion of system memory, which we treat like LMEM. For the LMEMBAR we
steal the apertu
We are going want to able to move objects between different regions
like system memory and local memory. In the future everything should
be just another region.
Signed-off-by: Matthew Auld
Signed-off-by: Abdiel Janulgue
Signed-off-by: CQ Tang
Cc: Joonas Lahtinen
Cc: Abdiel Janulgue
---
drive
From: CQ Tang
Signed-off-by: CQ Tang
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2aa4fbe7edc0..af63d1a0af14 100644
--- a/drivers/gpu/drm/i915/i915_
From: Abdiel Janulgue
This call will specify which memory region an object should be placed.
Note that changing the object's backing storage should be immediately
done after an object is created or if it's not yet in use, otherwise
this will fail on a busy object.
Signed-off-by: Abdiel Janulgue
From: Michal Wajdeczko
HWS placement restrictions can't just rely on HAS_LLC flag.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
---
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_
From: Abdiel Janulgue
This enables us to store extra data within vma->vm_private_data and assign
the pagefault ops for each mmap instance.
We replace the core drm_gem_mmap implementation to overcome the limitation
in having only a single offset node per gem object, allowing us to have
multiple o
From: Abdiel Janulgue
LMEM can be accessed by the CPU through a BAR. The mapping itself should
be 1:1.
Signed-off-by: Abdiel Janulgue
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 16
drivers/gpu/drm/i915/gem/i915_gem_lmem.h |
From: Daniele Ceraolo Spurio
We can't fence anything without aperture.
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Stuart Summers
Cc: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_fence_reg.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/
From: Abdiel Janulgue
Fault handler to handle missing pages to be filled depending on an
object's backing storage. Handle also changes needed to refault pages
depending on fault handler usage.
Signed-off-by: Abdiel Janulgue
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
---
drivers/gpu/drm/
From: Abdiel Janulgue
Add a new CPU mmap implementation that allows multiple fault handlers
that depends on the object's backing pages.
Note that we multiplex mmap_gtt and mmap_offset through the same ioctl,
and use the zero extending behaviour of drm to differentiate between
them, when we inspe
Using the gpu to write to some dword over a number of pages is rather
useful, and we already have two copies of such a thing, and we don't
want a third so move it to utils. There is probably some other stuff
also...
Signed-off-by: Matthew Auld
---
.../gpu/drm/i915/gem/selftests/huge_pages.c |
Signed-off-by: Matthew Auld
---
.../gpu/drm/i915/gem/selftests/huge_pages.c | 121 +-
1 file changed, 120 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index c36cef61ce3c..4bac1536302
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Abdiel Janulgue
---
drivers/gpu/drm/i915/gem/i915_gem_phys.c | 6 +-
drivers/gpu/drm/i915/gem/i915_gem_region.c| 14 +++-
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 68 ++-
drivers/gpu/drm/i915/i915_drv.c
We may be missing support for the mappable aperture on some platforms.
Signed-off-by: Matthew Auld
Cc: Daniele Ceraolo Spurio
---
.../drm/i915/gem/selftests/i915_gem_coherency.c| 5 -
drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 3 +++
drivers/gpu/drm/i915/gt/selftest_hangchec
Reported-by: Chris Wilson
Signed-off-by: Matthew Auld
---
.../gpu/drm/i915/gem/i915_gem_client_blt.c| 31 +++-
.../gpu/drm/i915/gem/i915_gem_object_blt.c| 139 ++
.../gpu/drm/i915/gem/i915_gem_object_blt.h| 9 +-
.../i915/gem/selftests/i915_gem_client_blt.c | 16
We can already clear an object with the blt, so try to do the same to
support copying from one object backing store to another. Really this is
just object -> object, which is not that useful yet, what we really want
is two backing stores, but that will require some vma rework first,
otherwise we ar
Simple test writing to dwords across an object, using various engines in
a randomized order, checking that our writes land from the cpu.
Signed-off-by: Matthew Auld
---
.../drm/i915/selftests/intel_memory_region.c | 179 ++
1 file changed, 179 insertions(+)
diff --git a/drivers
We need to add support for pread'ing an LMEM object.
Signed-off-by: Matthew Auld
Signed-off-by: Steve Hampson
Cc: Joonas Lahtinen
Cc: Abdiel Janulgue
---
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 88 +++
.../gpu/drm/i915/gem/i915_gem_object_types.h | 2 +
drivers/gpu/d
From: Daniele Ceraolo Spurio
The following patches in the series will use it to avoid certain
operations when aperture is not available in HW.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Matthew Auld
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drive
From: Daniele Ceraolo Spurio
Skip both setup and cleanup of the aperture mapping if the HW doesn't
have an aperture bar.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 36 ++---
1 file changed, 22 insertions(+), 14 dele
From: Abdiel Janulgue
Nothing to enumerate yet...
Signed-off-by: Abdiel Janulgue
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h | 3 +
drivers/gpu/drm/i915/i915_gem_gtt.c | 70 +--
.../gpu/drm/i915/selftests/mock_g
Convert stolen memory over to a region object. Still leaves open the
question with what to do with pre-allocated objects...
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Abdiel Janulgue
---
drivers/gpu/drm/i915/gem/i915_gem_region.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 7
We need to add support for pwrite'ing an LMEM object.
Signed-off-by: Matthew Auld
Signed-off-by: Steve Hampson
Cc: Joonas Lahtinen
Cc: Abdiel Janulgue
---
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 87
1 file changed, 87 insertions(+)
diff --git a/drivers/gpu/drm/i91
Add LMEM support for the CPU reloc path. When doing relocations we have
both a GPU and CPU reloc path, as well as some debugging options to force a
particular path. The GPU reloc path is preferred when the object
is not currently idle, otherwise we use the CPU reloc path. Since we
can't kmap the ob
Currently we just pass in bcs0->engine_context so it matters not, but in
the future we may want to pass in something that is not a
kernel_context, so try to be a bit more generic.
Suggested-by: Chris Wilson
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_client_blt.c | 3 ++-
From: Abdiel Janulgue
Signed-off-by: Abdiel Janulgue
Cc: Matthew Auld
---
drivers/gpu/drm/i915/intel_region_lmem.c | 28 ++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_region_lmem.c
b/drivers/gpu/drm/i915/intel_region_lmem.c
From: Abdiel Janulgue
We can create LMEM objects, but we also need to support mapping them
into kernel space for internal use.
Signed-off-by: Abdiel Janulgue
Signed-off-by: Matthew Auld
Signed-off-by: Steve Hampson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 4 +
Some objects may need to be allocated as a continuous block, thinking
ahead the various kernel io_mapping interfaces seem to expect it.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Abdiel Janulgue
---
.../gpu/drm/i915/gem/i915_gem_object_types.h | 4 +
drivers/gpu/drm/i915/gem/i915_g
Support basic eviction for regions.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Abdiel Janulgue
---
.../gpu/drm/i915/gem/i915_gem_object_types.h | 7 ++
drivers/gpu/drm/i915/gem/i915_gem_region.c| 11 +++
drivers/gpu/drm/i915/gem/i915_gem_region.h| 1 +
drivers/gpu/drm/i915/
Support memory regions, as defined by a given (start, end), and allow
creating GEM objects which are backed by said region. The immediate goal
here is to have something to represent our device memory, but later on
we also want to represent every memory domain with a region, so stolen,
shmem, and of
From: Abdiel Janulgue
Exposes available regions for the platform. Shared memory will
always be available.
Signed-off-by: Abdiel Janulgue
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_device_info.h | 2 ++
2 files changed, 4 inserti
We currently define LMEM, or local memory, as just another memory
region, like system memory or stolen, which we can expose to userspace
and can be mapped to the CPU via some BAR.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Abdiel Janulgue
---
drivers/gpu/drm/i915/Makefile
Simple buddy allocator. We want to allocate properly aligned
power-of-two blocks to promote usage of huge-pages for the GTT, so 64K,
2M and possibly even 1G. While we do support allocating stuff at a
specific offset, it is more intended for preallocating portions of the
address space, say for an in
== Series Details ==
Series: series starting with [1/2] drm/i915: Push the wakeref->count deferral
to the backend
URL : https://patchwork.freedesktop.org/series/64995/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6670 -> Patchwork_13956
==
Volatile objects are marked as DONTNEED while pinned, therefore once
unpinned the backing store can be discarded.
Signed-off-by: Matthew Auld
Signed-off-by: CQ Tang
Cc: Joonas Lahtinen
Cc: Abdiel Janulgue
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 17 +++---
drivers/gpu/drm/i915/gem/
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 TTM, which is
a fair criticism, so trying to get better alignment
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Tang, CQ
> Sent: Friday, August 9, 2019 3:21 PM
> To: Chris Wilson ; Auld, Matthew
> ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 3/3] drm/i915/blt: bump the size
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Chris Wilson
> Sent: Friday, August 9, 2019 2:18 PM
> To: Auld, Matthew ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 3/3] drm/i915/blt: bump the size restricti
== Series Details ==
Series: drm/i915/execlists: Backtrack along timeline
URL : https://patchwork.freedesktop.org/series/64942/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6663_full -> Patchwork_13932_full
Summary
---
== Series Details ==
Series: Some bits from the LMEM series
URL : https://patchwork.freedesktop.org/series/64994/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6670 -> Patchwork_13955
Summary
---
**SUCCESS**
No re
== Series Details ==
Series: drm/i915/guc: Keep the engine awake until the tasklet is idle
URL : https://patchwork.freedesktop.org/series/64992/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6670 -> Patchwork_13954
Summary
== Series Details ==
Series: Some bits from the LMEM series
URL : https://patchwork.freedesktop.org/series/64994/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: buddy allocator
+drivers/gpu/drm/i915/selftests/i915_buddy.c:292:13: warning: exp
== Series Details ==
Series: series starting with [1/2] drm/i915/gtt: enable GTT cache by default
URL : https://patchwork.freedesktop.org/series/64988/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6670 -> Patchwork_13953
S
== Series Details ==
Series: Some bits from the LMEM series
URL : https://patchwork.freedesktop.org/series/64994/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
94ffded7068a drm/i915: buddy allocator
-:30: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAI
Quoting Matthew Auld (2019-08-09 21:29:24)
> +int i915_buddy_alloc_range(struct i915_buddy_mm *mm,
> + struct list_head *blocks,
> + u64 start, u64 size)
> +{
> + struct i915_buddy_block *block;
> + struct i915_buddy_block *buddy;
> +
Quoting Matthew Auld (2019-08-09 21:29:26)
> As pointed out by Chris, with our current approach we are actually
> limited to S16_MAX * PAGE_SIZE for our size when using the blt to clear
> pages. Keeping things simple try to fix this by reducing the copy to a
> sequence of S16_MAX * PAGE_SIZE blocks
Quoting Matthew Auld (2019-08-09 21:29:25)
> Currently we just pass in bcs0->engine_context so it matters not, but in
> the future we may want to pass in something that is not a
> kernel_context, so try to be a bit more generic.
>
> Suggested-by: Chris Wilson
> Signed-off-by: Matthew Auld
> Cc:
For the guc, we need to keep the engine awake (and not parked) and not
just the gt. If we let the engine park, we disable the irq and stop
processing the tasklet, leaving state outstanding inside the tasklet.
Reported-by: Daniele Ceraolo Spurio
Signed-off-by: Chris Wilson
Cc: Daniele Ceraolo Spu
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 c
A bit fragile, perhaps?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Currently we just pass in bcs0->engine_context so it matters not, but in
the future we may want to pass in something that is not a
kernel_context, so try to be a bit more generic.
Suggested-by: Chris Wilson
Signed-off-by: Matthew Auld
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_clie
We are going to want the blt improvements and they can go in without everything
else. Also the buddy allocator is fairly standalone at this point, and includes
a set of selftests(some donated by Chris) and is unlikely to change much.
Matthew Auld (3):
drm/i915: buddy allocator
drm/i915/blt: do
Simple buddy allocator. We want to allocate properly aligned
power-of-two blocks to promote usage of huge-pages for the GTT, so 64K,
2M and possibly even 1G. While we do support allocating stuff at a
specific offset, it is more intended for preallocating portions of the
address space, say for an in
As pointed out by Chris, with our current approach we are actually
limited to S16_MAX * PAGE_SIZE for our size when using the blt to clear
pages. Keeping things simple try to fix this by reducing the copy to a
sequence of S16_MAX * PAGE_SIZE blocks.
Reported-by: Chris Wilson
Signed-off-by: Matthe
On Fri, Aug 9, 2019 at 1:03 AM Nick Desaulniers wrote:
>
> On Thu, Aug 8, 2019 at 1:22 PM Thomas Gleixner wrote:
> > > tglx just picked up 2 other patches of mine, bumping just in case he's
> > > not picking up patches while on vacation. ;)
> >
> > I'm only half on vacation :)
> >
> > So I can pi
On Fri, Aug 9, 2019 at 8:52 PM Chris Wilson wrote:
>
> Quoting Matthew Auld (2019-08-09 19:47:02)
> > On Thu, 8 Aug 2019 at 18:23, Chris Wilson wrote:
> > >
> > > The filesystem reconfigure API is undergoing a transition, breaking our
> > > current code. As we only set the default options, we can
For the guc, we need to keep the engine awake (and not parked) and not
just the gt. If we let the engine park, we disable the irq and stop
processing the tasklet, leaving state outstanding inside the tasklet.
Reported-by: Daniele Ceraolo Spurio
Signed-off-by: Chris Wilson
Cc: Daniele Ceraolo Spu
Quoting Matthew Auld (2019-08-09 20:34:56)
> We currently disable THP(Transparent-Huge-Pages) for our shmem objects
> due to a performance regression with read BW in some internal
> benchmarks. Given that this is our main source of 2M pages, there really
> isn't much point in enabling 2M GTT pages,
Quoting Matthew Auld (2019-08-09 20:34:55)
> For some platforms the GTT cache is by default not enabled, and
> currently where we explicitly enable it, we make it conditional on 2M GTT
> page support, since the BSpec states that we must disable it if we
> enable 2M/1G pages. To make this more consi
We currently disable THP(Transparent-Huge-Pages) for our shmem objects
due to a performance regression with read BW in some internal
benchmarks. Given that this is our main source of 2M pages, there really
isn't much point in enabling 2M GTT pages, especially this that comes at
the cost of disablin
For some platforms the GTT cache is by default not enabled, and
currently where we explicitly enable it, we make it conditional on 2M GTT
page support, since the BSpec states that we must disable it if we
enable 2M/1G pages. To make this more consistent opt for blanket
enabling the GTT cache for al
== Series Details ==
Series: DC3CO Support for TGL (rev2)
URL : https://patchwork.freedesktop.org/series/64923/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6668 -> Patchwork_13952
Summary
---
**SUCCESS**
No regr
== Series Details ==
Series: drm/i915: split out uncore_mmio_debug
URL : https://patchwork.freedesktop.org/series/64941/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6661_full -> Patchwork_13931_full
Summary
---
**F
== Series Details ==
Series: DC3CO Support for TGL (rev2)
URL : https://patchwork.freedesktop.org/series/64923/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/tgl: Add DC3CO required register and bits
Okay!
Commit: drm/i915/tgl: Add DC3CO mas
== Series Details ==
Series: DC3CO Support for TGL (rev2)
URL : https://patchwork.freedesktop.org/series/64923/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
15a54f3bbd2d drm/i915/tgl: Add DC3CO required register and bits
fdc2aa531791 drm/i915/tgl: Add DC3CO mask to allowed_dc_
== Series Details ==
Series: series starting with [CI,1/4] drm/i915: Remove
i915_gem_context_create_gvt()
URL : https://patchwork.freedesktop.org/series/64985/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6668 -> Patchwork_13951
==
Quoting Matthew Auld (2019-08-09 19:47:02)
> On Thu, 8 Aug 2019 at 18:23, Chris Wilson wrote:
> >
> > The filesystem reconfigure API is undergoing a transition, breaking our
> > current code. As we only set the default options, we can simply remove
> > the call to s_op->remount_fs(). In the future
On Thu, 8 Aug 2019 at 18:23, Chris Wilson wrote:
>
> The filesystem reconfigure API is undergoing a transition, breaking our
> current code. As we only set the default options, we can simply remove
> the call to s_op->remount_fs(). In the future, when HW permits, we can
> try re-enabling huge page
Adding DC3CO counter in i915_dmc_info debugfs will be
useful for DC3CO validation.
DMC firmware uses DMC_DEBUG3 register as DC3CO counter
register on TGL, as per B.Specs DMC_DEBUG3 is general
purpose register.
Cc: Jani Nikula
Cc: Imre Deak
Cc: Animesh Manna
Signed-off-by: Anshuman Gupta
---
d
This revision is rebased on latest drm-tip as earlier v4 series had
CI failures due to merge conflicts, there are no functional changes
with this v5 series.
one patch of this series "tgl-DC3CO-PSR2-helper"
will require rebase after https://patchwork.freedesktop.org/series/62416/
series will merged
Enable dc3co state in enable_dc module param and add dc3co
enable mask to allowed_dc_mask and gen9_dc_mask.
v1: Adding enable_dc=3,4 options to enable DC3CO with DC5 and DC6
independently.
Cc: Jani Nikula
Cc: Imre Deak
Cc: Animesh Manna
Signed-off-by: Anshuman Gupta
---
.../drm/i915/disp
DC3CO is useful power state, when DMC detects PSR2 idle frame
while an active video playback, playing 30fps video on 60hz panel
is the classic example of this use case.
DC5 and DC6 saves more power, but can't be entered during video
playback because there are not enough idle frames in a row to meet
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
Cc: Animesh Manna
Cc: José Roberto de Souza
Signed-off-by: Anshuman Gupta
"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 well to "DC5 Off" power well.
v2: commit log improvement.
v3: Used intel_
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 program DC3CO PSR2 transcoder
early exitline event.
Cc: Jani Nikula
Cc:
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: Jani Nikula
Cc: Imre Deak
Cc: Animesh Manna
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/i915_reg.h | 8
1 file cha
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 exclusive.
Cc: Jani Nikula
Cc: Imre Deak
Cc: Animesh Manna
Cc: Rodri
The Power domain name VIDEO is inspired from the fact that
DC3CO should be enabled only during VIDEO playback.
POWER_DOMAIN_VIDEO is a hook to "DC5 Off" power well,
which can disallow DC5/6 and allow DC3CO.
Cc: Jani Nikula
Cc: Imre Deak
Cc: Animesh Manna
Signed-off-by: Anshuman Gupta
---
driv
Move the timeline from being inside the intel_ring to intel_context
itself. This saves much pointer dancing and makes the relations of the
context to its timeline much clearer.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 35 -
As we are phasing out using the GEM context for internal clients that
need to manipulate logical context state directly, remove the
constructor for the GVT context. We are not using it for anything other
than default setup and allocation of an i915_ppgtt.
Signed-off-by: Chris Wilson
---
drivers/
Refactor the backends to handle the deferred context allocation in a
consistent manner, and allow calling it as an explicit first step in
pinning a context for the first time. This should make it easier for
backends to keep track of partially constructed contexts from
initialisation.
Signed-off-by
Push the ring creation flags from the outer GEM context to the inner
intel_context to avoid an unsightly back-reference from inside the
backend.
Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 38 ---
.../gpu/drm/i915/gem/i
== Series Details ==
Series: series starting with [1/4] drm/i915: Remove
i915_gem_context_create_gvt() (rev2)
URL : https://patchwork.freedesktop.org/series/64979/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6668 -> Patchwork_13950
==
1 - 100 of 342 matches
Mail list logo
