From: Matthew Auld
On discrete platforms like DG2, we need to support a minimum page size
of 64K when dealing with device local-memory. This is quite tricky for
various reasons, so try to document the new implicit uapi for this.
v3: fix typos and less emphasis
v2: Fixed suggestions on
From: Matthew Auld
discrete cards optimise 64K GTT pages for local-memory, since everything
should be allocated at 64K granularity. We say goodbye to sparse
entries, and instead get a compact 256B page-table for 64K pages,
which should be more cache friendly. 4K pages for local-memory
are no
From: Ramalingam C
Add a new platform flag, needs_compact_pt, to mark the requirement of
compact pt layout support for the ppGTT when using 64K GTT pages.
With this flag has_64k_pages will only indicate requirement of 64K
GTT page sizes or larger for device local memory access.
v6:
*
From: Matthew Auld
For local-memory objects we need to align the GTT addresses
to 64K, both for the ppgtt and ggtt.
We need to support vm->min_alignment > 4K, depending
on the vm itself and the type of object we are inserting.
With this in mind update the GTT selftests to take this
into
This series continues support for 64K pages for discrete cards.
It supersedes the 64K patches from
https://patchwork.freedesktop.org/series/95686/#rev4
Changes since that series:
- set min alignment for DG2 to 2MB in i915_address_space_init
- replace coloring with simpler 2MB VA alignment for
== Series Details ==
Series: drm/i915: move the DRIVER_* macros to i915_driver.[ch] (rev2)
URL : https://patchwork.freedesktop.org/series/99671/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11203_full -> Patchwork_22210_full
== Series Details ==
Series: drm/dp, drm/i915: 128b/132b updates (rev6)
URL : https://patchwork.freedesktop.org/series/99324/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11203 -> Patchwork_22212
Summary
---
== Series Details ==
Series: drm/dp, drm/i915: 128b/132b updates (rev6)
URL : https://patchwork.freedesktop.org/series/99324/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
On Tue, Feb 08, 2022 at 07:24:03PM +0100, Sam Ravnborg wrote:
> Hi Daniel,
>
> On Tue, Feb 08, 2022 at 02:48:29PM +0100, Daniel Vetter wrote:
> > On Thu, Feb 03, 2022 at 10:15:14PM +0100, Sam Ravnborg wrote:
> > > Hi Daniel,
> > >
> > > On Mon, Jan 31, 2022 at 10:05:42PM +0100, Daniel Vetter
== Series Details ==
Series: drm/dp, drm/i915: 128b/132b updates (rev6)
URL : https://patchwork.freedesktop.org/series/99324/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b1c38d738be2 drm/dp: add drm_dp_128b132b_read_aux_rd_interval()
2b74cd3aa4a7 drm/dp: add 128b/132b link
== Series Details ==
Series: drm/i915: move intel_hws_csb_write_index() out of i915_drv.h
URL : https://patchwork.freedesktop.org/series/99853/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11203 -> Patchwork_22211
Summary
With upcoming lock tracepoints config, it'd define some of lockdep
functions without enabling CONFIG_LOCKDEP actually. The existing code
assumes those functions will be removed by the preprocessor but it's
not the case anymore. Let's protect the code with #ifdef's explicitly.
Cc: Jani Nikula
Hello,
(Resending with Paul's correct email address, sorry!)
There have been some requests for low-overhead kernel lock contention
monitoring. The kernel has CONFIG_LOCK_STAT to provide such an infra
either via /proc/lock_stat or tracepoints directly.
However it's not light-weight and hard to
Hi Matt, thank you for taking the time to review the codes.
Answering your question inline below.
On Fri, 2022-02-04 at 10:19 -0800, Matthew Brost wrote:
> On Wed, Jan 26, 2022 at 02:48:18AM -0800, Alan Previn wrote:
> > GuC log buffer regions for debug-log-events, crash-dumps and
> >
Hello,
On Tue, Feb 8, 2022 at 10:51 AM Jani Nikula wrote:
>
> On Tue, 08 Feb 2022, Namhyung Kim wrote:
> > With upcoming lock tracepoints config, it'd define some of lockdep
> > functions without enabling CONFIG_LOCKDEP actually. The existing code
> > assumes those functions will be removed by
== Series Details ==
Series: drm/i915: move intel_hws_csb_write_index() out of i915_drv.h
URL : https://patchwork.freedesktop.org/series/99853/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm/i915: move intel_hws_csb_write_index() out of i915_drv.h
URL : https://patchwork.freedesktop.org/series/99853/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8ed7bbe053b5 drm/i915: move intel_hws_csb_write_index() out of i915_drv.h
-:51:
Oops, I used the wrong email address of Paul. Sorry about that!
I'll resend with a new address soon.
Thanks,
Namhyung
On Tue, Feb 8, 2022 at 10:42 AM Namhyung Kim wrote:
>
> Hello,
>
> There have been some requests for low-overhead kernel lock contention
> monitoring. The kernel has
On Mon, Feb 07, 2022 at 09:43:08PM +0530, Balasubramani Vivekanandan wrote:
memcpy_from_wc functions can fail if SSE4.1 is not supported or the
supplied addresses are not 16-byte aligned. It was then upto to the
caller to use memcpy as fallback.
Now fallback to memcpy is implemented inside
== Series Details ==
Series: drm/i915: move the DRIVER_* macros to i915_driver.[ch] (rev2)
URL : https://patchwork.freedesktop.org/series/99671/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11203 -> Patchwork_22210
Hi Daniel,
On Mon, Jan 31, 2022 at 10:05:52PM +0100, Daniel Vetter wrote:
> Well except when the olpc dcon fbdev driver is enabled, that thing
> digs around in there in rather unfixable ways.
>
> Cc oldc_dcon maintainers as fyi.
>
> Cc: Jens Frederich
> Cc: Jon Nettleton
> Cc: Greg
Hi Daniel,
On Tue, Feb 08, 2022 at 03:03:28PM +0100, Daniel Vetter wrote:
> On Fri, Feb 04, 2022 at 09:15:40PM +0100, Sam Ravnborg wrote:
> > Hi Daniel,
> >
> > On Mon, Jan 31, 2022 at 10:05:50PM +0100, Daniel Vetter wrote:
> > > Accessing the one in fbmem.c without taking the right locks is a
On 2/8/2022 01:39, Tvrtko Ursulin wrote:
On 08/02/2022 02:07, john.c.harri...@intel.com wrote:
From: John Harrison
A flag query helper was actually writing to the flags word rather than
just reading. Fix that. Also update the function's comment as it was
out of date.
Fixes: 0f7976506de61
On Tue, 08 Feb 2022, Namhyung Kim wrote:
> With upcoming lock tracepoints config, it'd define some of lockdep
> functions without enabling CONFIG_LOCKDEP actually. The existing code
> assumes those functions will be removed by the preprocessor but it's
> not the case anymore. Let's protect the
With upcoming lock tracepoints config, it'd define some of lockdep
functions without enabling CONFIG_LOCKDEP actually. The existing code
assumes those functions will be removed by the preprocessor but it's
not the case anymore. Let's protect the code with #ifdef's explicitly.
Cc: Jani Nikula
== Series Details ==
Series: drm/i915: move the DRIVER_* macros to i915_driver.[ch] (rev2)
URL : https://patchwork.freedesktop.org/series/99671/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
Hello,
There have been some requests for low-overhead kernel lock contention
monitoring. The kernel has CONFIG_LOCK_STAT to provide such an infra
either via /proc/lock_stat or tracepoints directly.
However it's not light-weight and hard to be used in production. So
I'm trying to separate out
== Series Details ==
Series: drm/i915: split out intel_vtd.[ch] from i915_drv.h
URL : https://patchwork.freedesktop.org/series/99852/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11203 -> Patchwork_22209
Summary
---
On Tue, Feb 08, 2022 at 02:58:21PM +0100, Daniel Vetter wrote:
> On Fri, Feb 04, 2022 at 09:06:38PM +0100, Sam Ravnborg wrote:
> > Hi Daniel,
> >
> > On Mon, Jan 31, 2022 at 10:05:49PM +0100, Daniel Vetter wrote:
> > > There's a bunch of confusions going on here:
> > > - The deferred fbcon setup
On Tue, Feb 08, 2022 at 02:53:59PM +0100, Daniel Vetter wrote:
> On Fri, Feb 04, 2022 at 08:35:31PM +0100, Sam Ravnborg wrote:
> > On Mon, Jan 31, 2022 at 10:05:44PM +0100, Daniel Vetter wrote:
> > > No idea why con2fb_acquire_newinfo() initializes much less than
> > > fbcon_startup(), but so be
Hi Daniel,
On Tue, Feb 08, 2022 at 02:48:29PM +0100, Daniel Vetter wrote:
> On Thu, Feb 03, 2022 at 10:15:14PM +0100, Sam Ravnborg wrote:
> > Hi Daniel,
> >
> > On Mon, Jan 31, 2022 at 10:05:42PM +0100, Daniel Vetter wrote:
> > > There's two minor behaviour changes in here:
> > > - in error
Hi Daniel,
On Tue, Feb 08, 2022 at 02:46:33PM +0100, Daniel Vetter wrote:
> On Thu, Feb 03, 2022 at 10:31:00PM +0100, Sam Ravnborg wrote:
> > On Mon, Jan 31, 2022 at 10:05:41PM +0100, Daniel Vetter wrote:
> > > It was only used by fbcon, and that now switched to its own,
> > > private work.
> > >
On Tue, 2022-02-08 at 13:06 +, Souza, Jose wrote:
> On Mon, 2022-02-07 at 16:38 -0500, Lyude Paul wrote:
> > As we've unfortunately started to come to expect from PSR on Intel
> > platforms, PSR2 selective fetch is not at all ready to be enabled on
> > Tigerlake as it results in severe
Hi Daniel,
On Tue, Feb 08, 2022 at 02:42:25PM +0100, Daniel Vetter wrote:
> On Thu, Feb 03, 2022 at 09:45:29PM +0100, Sam Ravnborg wrote:
> > Hi Daniel,
> >
> > On Mon, Jan 31, 2022 at 10:05:37PM +0100, Daniel Vetter wrote:
> > > Before
> > >
> > > commit
== Series Details ==
Series: drm/i915: split out intel_vtd.[ch] from i915_drv.h
URL : https://patchwork.freedesktop.org/series/99852/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm/i915: split out intel_vtd.[ch] from i915_drv.h
URL : https://patchwork.freedesktop.org/series/99852/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
019a148267a5 drm/i915: split out intel_vtd.[ch] from i915_drv.h
-:321: WARNING:FILE_PATH_CHANGES:
On 2021-12-14 11:58:37 [-0500], Steven Rostedt wrote:
> On Tue, 14 Dec 2021 18:34:50 +0200
> Ville Syrjälä wrote:
>
> > Looks lightly tedious. Can't we have "slow" (or whatever) versions of
> > the trace macros so we could just declare these the same was as before
> > without having to manually
== Series Details ==
Series: drm/dp, drm/i915: 128b/132b updates (rev5)
URL : https://patchwork.freedesktop.org/series/99324/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11202 -> Patchwork_22208
Summary
---
Underscore prefix the index macros, and place
INTEL_HWS_CSB_WRITE_INDEX() as a macro next to them, to declutter
i915_drv.h.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/gt/intel_engine.h | 6 --
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 2 +-
== Series Details ==
Series: drm/dp, drm/i915: 128b/132b updates (rev5)
URL : https://patchwork.freedesktop.org/series/99324/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm/dp, drm/i915: 128b/132b updates (rev5)
URL : https://patchwork.freedesktop.org/series/99324/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
20e6f540b666 drm/dp: add drm_dp_128b132b_read_aux_rd_interval()
33af01e431af drm/dp: add 128b/132b link
The prefix should tell where the function is to be found and where it
belongs.
Cc: Daniel Vetter
Cc: Ville Syrjälä
Cc: Tvrtko Ursulin
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_fb_pin.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 +-
Perhaps a bit contrived, but we need to reduce the size of i915_drv.h
from all the accumulated cruft.
v4: Rebase
v3: Rebase
v2: Turns out asm/hypervisor.h is not self-contained
Cc: Daniel Vetter
Cc: Ville Syrjälä
Cc: Tvrtko Ursulin
Signed-off-by: Jani Nikula
---
Another rebase & resend of [1].
[1] https://patchwork.freedesktop.org/series/98789/
Jani Nikula (2):
drm/i915: split out intel_vtd.[ch] from i915_drv.h
drm/i915/vtd: rename functions to have the usual prefix
drivers/gpu/drm/i915/Makefile| 1 +
== Series Details ==
Series: drm/doc: pull in drm_buddy.c
URL : https://patchwork.freedesktop.org/series/99849/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11201 -> Patchwork_22207
Summary
---
**FAILURE**
== Series Details ==
Series: drm/buddy: fixup potential uaf
URL : https://patchwork.freedesktop.org/series/99842/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11201_full -> Patchwork_22205_full
Summary
---
Ah, thanks for asking this question. It seems like I was not thinking
correctly. We are trying to flush dcache lines within this function and
not the tlb.
On 2022-02-08 2:20 a.m., Tvrtko Ursulin wrote:
On 07/02/2022 20:11, Michael Cheng wrote:
Use flush_tlb_kernel_range when invoking
128b/132b supports using 64 slots starting from 0, while 8b/10b reserves
slot 0 for metadata.
Commit d6c6a76f80a1 ("drm: Update MST First Link Slot Information Based
on Encoding Format") added support for updating the topology state
accordingly, and commit 41724ea273cd ("drm/amd/display: Add DP
== Series Details ==
Series: drm/dp, drm/i915: 128b/132b updates (rev4)
URL : https://patchwork.freedesktop.org/series/99324/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11201 -> Patchwork_22206
Summary
---
On Tue, 08 Feb 2022, Zhi Wang wrote:
> From: Zhi Wang
>
> To support the new mdev interfaces and the re-factor patches from
> Christoph, which moves the GVT-g code into a dedicated module, the GVT-g
> initialization path has to be separated into two phases:
>
> a) Early initialization.
>
> The
Make sure we pull in the kernel-doc for this.
Reported-by: Daniel Vetter
Signed-off-by: Matthew Auld
Cc: Arunpravin
Cc: Christian König
---
Documentation/gpu/drm-mm.rst | 9 +
1 file changed, 9 insertions(+)
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
On Thu, Feb 03, 2022 at 11:03:55AM +0200, Jani Nikula wrote:
> Abstract link status check to a function that takes 128b/132b and 8b/10b
> into account, and use it. Also dump link status on failures.
>
> Cc: Uma Shankar
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
>
On Thu, Feb 03, 2022 at 11:03:56AM +0200, Jani Nikula wrote:
> 128b/132b supports using 64 slots starting from 0, while 8b/10b reserves
> slot 0 for metadata.
>
> Commit d6c6a76f80a1 ("drm: Update MST First Link Slot Information Based
> on Encoding Format") added support for updating the topology
Hi Dave and Daniel,
Here goes the first and probably biggest request towards 5.18.
Another request will come in about 2 weeks.
drm-intel-next-2022-02-08:
Cross-subsystem Changes:
dma-buf:
- dma-buf-map: Rename to iosys-map (Lucas)
Core Changes:
-
drm:
-
== Series Details ==
Series: drm/dp, drm/i915: 128b/132b updates (rev4)
URL : https://patchwork.freedesktop.org/series/99324/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm/dp, drm/i915: 128b/132b updates (rev4)
URL : https://patchwork.freedesktop.org/series/99324/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
dda5c759f6bc drm/dp: add drm_dp_128b132b_read_aux_rd_interval()
0053fa9bdcc3 drm/dp: add 128b/132b link
Hi Zhi,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on next-20220208]
[cannot apply to drm-intel/for-linux-next v5.17-rc3]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch
On Tue, Feb 08, 2022 at 04:32:09PM +0200, Jani Nikula wrote:
> The DP 2.0 errata completely overhauls the 128b/132b link training, with
> no provisions for backward compatibility with the original DP 2.0
> specification.
>
> The changes are too intrusive to consider reusing the same code for both
== Series Details ==
Series: drm/buddy: fixup potential uaf
URL : https://patchwork.freedesktop.org/series/99842/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11201 -> Patchwork_22205
Summary
---
**SUCCESS**
No
The DP 2.0 errata completely overhauls the 128b/132b link training, with
no provisions for backward compatibility with the original DP 2.0
specification.
The changes are too intrusive to consider reusing the same code for both
8b/10b and 128b/132b, mainly because the LTTPR channel equalisation is
On Mon, Jan 31, 2022 at 10:05:32PM +0100, Daniel Vetter wrote:
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns
On Mon, 07 Feb 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The bogus loop from compute_dbuf_slices() was copied into
> check_mbus_joined() as well. So this lookup is wrong as well.
> Fix it.
>
> Cc: sta...@vger.kernel.org
> Fixes: f4dc00863226 ("drm/i915/adl_p: MBUS programming")
>
On Mon, 07 Feb 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Apparently I totally fumbled the loop condition when I
> removed the ARRAY_SIZE() stuff from the dbuf slice config
> lookup. Comparing the loop index with the active_pipes bitmask
> is utter nonsense, what we want to do is check
On Fri, Feb 04, 2022 at 09:30:56AM +0100, Geert Uytterhoeven wrote:
> Hi Daniel,
>
> Thanks for your patch!
>
> On Tue, Feb 1, 2022 at 9:50 PM Daniel Vetter wrote:
> > Well except when the olpc dcon fbdev driver is enabled, that thing
> > digs around in there in rather unfixable ways.
>
>
== Series Details ==
Series: GuC HWCONFIG with documentation (rev2)
URL : https://patchwork.freedesktop.org/series/99787/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11200_full -> Patchwork_22202_full
Summary
---
On Fri, Feb 04, 2022 at 09:15:40PM +0100, Sam Ravnborg wrote:
> Hi Daniel,
>
> On Mon, Jan 31, 2022 at 10:05:50PM +0100, Daniel Vetter wrote:
> > Accessing the one in fbmem.c without taking the right locks is a bad
> > idea. Instead maintain our own private copy, which is fully protected
> > by
On Fri, Feb 04, 2022 at 09:06:38PM +0100, Sam Ravnborg wrote:
> Hi Daniel,
>
> On Mon, Jan 31, 2022 at 10:05:49PM +0100, Daniel Vetter wrote:
> > There's a bunch of confusions going on here:
> > - The deferred fbcon setup notifier should only be cleaned up from
> > fb_console_exit(), to be
On Fri, Feb 04, 2022 at 08:54:24PM +0100, Sam Ravnborg wrote:
> Hi Daniel.
>
> On Mon, Jan 31, 2022 at 10:05:47PM +0100, Daniel Vetter wrote:
> > Ideally console_lock becomes an implementation detail of fbcon.c and
> > doesn't show up anywhere in fbmem.c. We're still pretty far from that,
> > but
On Fri, Feb 04, 2022 at 08:35:31PM +0100, Sam Ravnborg wrote:
> On Mon, Jan 31, 2022 at 10:05:44PM +0100, Daniel Vetter wrote:
> > No idea why con2fb_acquire_newinfo() initializes much less than
> > fbcon_startup(), but so be it. From a quick look most of the
> > un-initialized stuff should be
On Thu, Feb 03, 2022 at 10:15:14PM +0100, Sam Ravnborg wrote:
> Hi Daniel,
>
> On Mon, Jan 31, 2022 at 10:05:42PM +0100, Daniel Vetter wrote:
> > There's two minor behaviour changes in here:
> > - in error paths we now consistently call fb_ops->fb_release
> > - fb_release really can't fail
On Thu, Feb 03, 2022 at 10:31:00PM +0100, Sam Ravnborg wrote:
> On Mon, Jan 31, 2022 at 10:05:41PM +0100, Daniel Vetter wrote:
> > It was only used by fbcon, and that now switched to its own,
> > private work.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Helge Deller
> > Cc:
On Thu, Feb 03, 2022 at 09:45:29PM +0100, Sam Ravnborg wrote:
> Hi Daniel,
>
> On Mon, Jan 31, 2022 at 10:05:37PM +0100, Daniel Vetter wrote:
> > Before
> >
> > commit 6104c37094e729f3d4ce65797002112735d49cd1
> > Author: Daniel Vetter
> > Date: Tue Aug 1 17:32:07 2017 +0200
> >
> >
On Tue, 08 Feb 2022, Ville Syrjälä wrote:
> On Tue, Feb 08, 2022 at 02:12:33PM +0200, Jani Nikula wrote:
>> On Tue, 08 Feb 2022, Ville Syrjälä wrote:
>> > On Tue, Feb 08, 2022 at 11:17:22AM +0200, Jani Nikula wrote:
>> >> On Fri, 04 Feb 2022, Ville Syrjälä wrote:
>> >> > On Thu, Feb 03, 2022 at
The DP 2.0 errata completely overhauls the 128b/132b link training, with
no provisions for backward compatibility with the original DP 2.0
specification.
The changes are too intrusive to consider reusing the same code for both
8b/10b and 128b/132b, mainly because the LTTPR channel equalisation is
On 2/4/22 18:05, Lucas De Marchi wrote:
> Rename struct dma_buf_map to struct iosys_map and corresponding APIs.
> Over time dma-buf-map grew up to more functionality than the one used by
> dma-buf: in fact it's just a shim layer to abstract system memory, that
> can be accessed via regular load
On Tue, Feb 08, 2022 at 11:38:15AM +, Matthew Auld wrote:
> If we are unlucky and somehow can't allocate enough memory when
> splitting blocks, where we temporarily end up with the given block and
> its buddy on the respective free list, then we need to ensure we delete
> both blocks, and not
On Thu, Feb 03, 2022 at 12:56:14AM -0800, Lucas De Marchi wrote:
> Rename struct dma_buf_map to struct iosys_map and corresponding APIs.
> Over time dma-buf-map grew up to more functionality than the one used by
> dma-buf: in fact it's just a shim layer to abstract system memory, that
> can be
== Series Details ==
Series: drm/i915/guc: Refactor ADS access to use iosys_map (rev2)
URL : https://patchwork.freedesktop.org/series/99711/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11200_full -> Patchwork_22201_full
On Mon, 2022-02-07 at 16:38 -0500, Lyude Paul wrote:
> As we've unfortunately started to come to expect from PSR on Intel
> platforms, PSR2 selective fetch is not at all ready to be enabled on
> Tigerlake as it results in severe flickering issues - at least on this
> ThinkPad X1 Carbon 9th
== Series Details ==
Series: drm/i915: Refactor the display power domain mappings (rev2)
URL : https://patchwork.freedesktop.org/series/99476/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11200 -> Patchwork_22204
Summary
On Tue, Feb 08, 2022 at 02:12:33PM +0200, Jani Nikula wrote:
> On Tue, 08 Feb 2022, Ville Syrjälä wrote:
> > On Tue, Feb 08, 2022 at 11:17:22AM +0200, Jani Nikula wrote:
> >> On Fri, 04 Feb 2022, Ville Syrjälä wrote:
> >> > On Thu, Feb 03, 2022 at 11:03:54AM +0200, Jani Nikula wrote:
> >> >> +
>
== Series Details ==
Series: drm/i915: Refactor the display power domain mappings (rev2)
URL : https://patchwork.freedesktop.org/series/99476/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm/i915: Refactor the display power domain mappings (rev2)
URL : https://patchwork.freedesktop.org/series/99476/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
fa34bdc13d82 drm/i915: Fix the VDSC_PW2 power domain enum value
69200c39d539 drm/i915:
== Series Details ==
Series: GuC HWCONFIG with documentation (rev2)
URL : https://patchwork.freedesktop.org/series/99787/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11200 -> Patchwork_22202
Summary
---
== Series Details ==
Series: series starting with [v6,1/3] i915/gvt: Introduce the mmio table to
support VFIO new mdev API
URL : https://patchwork.freedesktop.org/series/99838/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND
On Tue, 08 Feb 2022, Ville Syrjälä wrote:
> On Tue, Feb 08, 2022 at 11:17:22AM +0200, Jani Nikula wrote:
>> On Fri, 04 Feb 2022, Ville Syrjälä wrote:
>> > On Thu, Feb 03, 2022 at 11:03:54AM +0200, Jani Nikula wrote:
>> >> +
>> >> + if (timeout) {
>> >> +
== Series Details ==
Series: GuC HWCONFIG with documentation (rev2)
URL : https://patchwork.freedesktop.org/series/99787/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: GuC HWCONFIG with documentation (rev2)
URL : https://patchwork.freedesktop.org/series/99787/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
0d55eb6c8da5 drm/i915/guc: Add fetch of hwconfig table
-:78: WARNING:FILE_PATH_CHANGES: added, moved or
== Series Details ==
Series: drm/i915/guc: Refactor ADS access to use iosys_map (rev2)
URL : https://patchwork.freedesktop.org/series/99711/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11200 -> Patchwork_22201
Summary
If we are unlucky and somehow can't allocate enough memory when
splitting blocks, where we temporarily end up with the given block and
its buddy on the respective free list, then we need to ensure we delete
both blocks, and not just the buddy, before potentially freeing them.
v2: rebase on
Instead of the skip_mask special casing of the ADL-S power well
descriptors, add a power well descriptor list for ADL-S as well reusing
the TGL descriptors, w/o the TC-cold power well. ADL-S doesn't have
TypeC PHYs, so a better way would be having ADL-S specific AUX
descriptors, but I left
The spec calls the XELPD_D/E ports just D/E, the platform prefix in the
domain names was only needed by the port->domain mapping relying on
matching enum values for the whole port/domain range (and the
corresponding aliasing between the platform specific domain enums).
Since a previous patch we
Aliasing the intel_display_power_domain enum values was required because
of the u64 power domain mask size limit. This makes the dmesg/debugfs
printouts of the domain names somewhat unclear, for instance domain
names for port D are shown on D12+ platforms where the corresponding
port is called
The spec calls the ICL TBT AUX power well instances TBT1-4 (similarly to
all later platforms), align the power domain names with the spec.
Signed-off-by: Imre Deak
---
.../gpu/drm/i915/display/intel_display_power.c | 10 +-
.../gpu/drm/i915/display/intel_display_power.h | 4
Atm the port -> DDI and AUX power domain mapping is specified by relying
on the aliasing of the platform specific intel_display_power_domain enum
values. For instance D12+ platforms refer to the 'D' port and power
domain instances, which doesn't match the bspec terminology, on these
platforms the
Some power wells - like always-on and skl+/icl+ PW_1 - with the same
name, domain list, flags, ops are used by multiple platforms, so allow
platforms to reuse the descriptors of such power wells.
This change also lets the follow up patches to simplify the DG1/RKL
power well definitions, and
Simplify the definition of DG1 power wells by reusing the identical
RKL DDI/AUX descriptors.
This reorders the DG1 DDI/AUX vs. PW4/5 power wells, but this shouldn't
make a difference (it is the order on RKL and the DDI/AUX power wells
don't have a dependency on PW4/5).
Signed-off-by: Imre Deak
The DDI and AUX domain -> power well mappings are identical for a few
platforms/power well instances, reuse the mappings of earlier platforms
for these removing the duplicate mapping of new platforms.
Signed-off-by: Imre Deak
---
.../i915/display/intel_display_power_map.c| 89
All the port specific AUX/DDI_IO power wells share the same power well
ops struct and flags, so we can save some space and simplify the
definition of these by listing for all such power wells only the params
specific to them (name, domains, power well register index, id). Move
these params to a
To remove the aliasing of the power domain enum values in a follow-up
patch in this patchset (requiring a bigger mask) and allow for defining
additional power domains in the future (at least some upcoming TypeC
changes requires this) convert the u64 i915_power_well_desc::domains
mask to a bitmap.
101 - 200 of 280 matches
Mail list logo
