If set, force the allocation to be placed in the mappable portion of
LMEM. One big restriction here is that system memory must be given as a
potential placement for the object, that way we can always spill the
object into system memory if we can't make space.
XXX: Still very much WIP and needs
The end goal is to have userspace tell the kernel what buffers will
require CPU access, however if we ever reach the CPU fault handler, and
the current resource is not mappable, then we should attempt to migrate
the buffer to the mappable portion of LMEM, or even system memory, if the
allowable
Starting from DG2+, when dealing with LMEM, we assume that by default
all userspace allocations should be placed in the non-mappable portion
of LMEM. Note that dumb buffers are not included here, since these are
not "GPU accelerated" and likely need CPU access.
In a later patch userspace will be
Just pass along the probed io_size. The backend should be able to
utilize the entire range here, even if some of it is non-mappable.
It does leave open with what to do with stolen local-memory.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gt/intel_region_lmem.c |
If we have to contend with non-mappable LMEM, then we need to ensure the
object fits within the mappable portion, like in the selftests, where we
later try to CPU access the pages. However if it can't then we need to
gracefully handle this, without throwing an error.
Also it looks like TTM will
On platforms where there might be non-mappable LMEM, force userspace to
mark the buffers with the correct hint. When dumping the BO contents
during capture we need CPU access. Note this only applies to buffers
that can be placed in LMEM, and also doesn't impact DG1.
Signed-off-by: Matthew Auld
Exercise each of the migration scenarios, verifying that the final
placement and buffer contents match our expectations.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
.../drm/i915/gem/selftests/i915_gem_mman.c| 306 ++
1 file changed, 306 insertions(+)
diff --git
Otherwise we get -EINVAL, instead of the more useful -E2BIG if the
allocation doesn't fit within the pfn range, like with mappable lmem.
The hugepages selftest, for example, needs this to know if a smaller
size is needed.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
If we need to make room for some some mappable object, then we should
only victimize objects that have one or pages that occupy the visible
portion of LMEM. Let's also create a new priority hint for objects that
are placed in mappable memory, where we know that CPU access was
requested, that way
Differentiate between mappable vs non-mappable resources, also if this
is an actual range allocation ensure we set res->start as the starting
pfn. Later when we need to do non-mappable -> mappable moves then we
want TTM to see that the current placement is not compatible, which
should result in an
For some reason we are selecting PRIO_HAS_PAGES when we don't have
mm.pages, and vice versa. Perhaps something else is going on here.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff
Check that mappable vs non-mappable matches our expectations.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
.../drm/i915/selftests/intel_memory_region.c | 143 ++
1 file changed, 143 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/intel_memory_region.c
With small LMEM-BAR we need to be able to differentiate between the
total size of LMEM, and how much of it is CPU mappable. The end goal is
to be able to utilize the entire range, even if part of is it not CPU
accessible.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
If the user doesn't require CPU access for the buffer, then
ALLOC_TOPDOWN should be used, in order to prioritise allocating in the
non-mappable portion of LMEM.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 15 +++
Track the total amount of available visible memory, and also track
per-resource the amount of used visible memory. For now this is useful
for our debug output, and deciding if it is even worth calling into the
buddy allocator. In the future tracking the per-resource visible usage
will be useful
On devices with non-mappable LMEM ensure we always allocate the pages
within the mappable portion. For now we assume that all LMEM buffers
will require CPU access, which is also inline with pretty much all
current kernel internal users. In the next patch we will introduce a new
flag to override
From: Arunpravin
On contiguous allocation, we round up the size
to the *next* power of 2, implement a function
to free the unused pages after the newly allocate block.
v2(Matthew Auld):
- replace function name 'drm_buddy_free_unused_pages' with
drm_buddy_block_trim
- replace input
From: Arunpravin
Implemented a function which walk through the order list,
compares the offset and returns the maximum offset block,
this method is unpredictable in obtaining the high range
address blocks which depends on allocation and deallocation.
for instance, if driver requests address at a
From: Arunpravin
- Make drm_buddy_alloc a single function to handle
range allocation and non-range allocation demands
- Implemented a new function alloc_range() which allocates
the requested power-of-two block comply with range limitations
- Moved order computation and memory alignment
Starting from DG2 we will have resizable BAR support for device local-memory,
but in some cases the final BAR size might still be smaller than the total
local-memory size. In such cases only part of local-memory will be CPU
accessible, while the remainder is only accessible via the GPU. This
On Wed, 26 Jan 2022, Lucas De Marchi wrote:
> linux/string_helpers.h provides a helper to return "yes"/"no" strings.
> Replace the open coded versions with str_yes_no(). The places were
> identified with the following semantic patch:
>
> @@
> expression b;
> @@
>
> - b ?
On Wed, 26 Jan 2022, Lucas De Marchi wrote:
> Sort includes alphabetically so it's easier to add/remove includes and
> know when that is needed.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_gem.c | 20 ++--
> 1 file changed, 10
On Wed, 26 Jan 2022, Lucas De Marchi wrote:
> Remove the trailing semicolon, as correctly warned by checkpatch:
>
> -:1189: WARNING:TRAILING_SEMICOLON: macros should not use a trailing
> semicolon
> #1189: FILE: drivers/gpu/drm/i915/intel_device_info.c:119:
> +#define
On Thu, 09 Dec 2021, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use pixel_rate rather than crtc_clock in the watermark calculations.
> These are actually identical on gmch platforms for now since
> we don't adjust the pixel rate based on pfit downscaling. But
> pixel_rate is the thing we are
On Fri, 12 Nov 2021, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use REG_GENMASK() & co. when dealing with PIPESRC.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/i9xx_plane.c| 4 ++--
> drivers/gpu/drm/i915/display/intel_display.c | 7 ---
>
On Fri, 12 Nov 2021, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use REG_BIT & co. for PCH_TRANSCONF/TRANS_DP_CTL bits, and
> adjust the naming a some bits to be more consistent.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
>
On Fri, 12 Nov 2021, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use REG_BIT() & co. for PIPEMISC* bits, and while at it
> fill in the missing dithering bits since we already had some
> of them defined.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
>
On Fri, 19 Nov 2021, Ville Syrjälä wrote:
> On Mon, Nov 15, 2021 at 02:05:00PM -0500, Rodrigo Vivi wrote:
>> On Fri, Nov 12, 2021 at 09:38:05PM +0200, Ville Syrjala wrote:
>> > From: Ville Syrjälä
>> >
>> > Since tgl PIPE_DSL has 20 bits for the scanline. Let's bump our
>> > definition to
On Fri, 12 Nov 2021, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use REG_BIT() & co. for PIPECONF bits, and adjust the
> naming of various bits to be more consistent.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/icl_dsi.c| 4 +-
On Fri, 12 Nov 2021, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use REG_BIT() for SKL_BOTTOM_COLOR.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_reg.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
On 1/25/22 20:35, Robert Beckett wrote:
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
On 1/25/22 20:35, Robert Beckett wrote:
add test to check handling of misaligned offsets and sizes
v4:
* remove spurious blank lines
* explicitly cast intel_region_id to intel_memory_type in misaligned_pin
Reported-by: kernel test robot
Signed-off-by: Robert Beckett
---
On 1/25/22 20:35, Robert Beckett wrote:
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
On Wed, 2022-01-26 at 12:43 +0200, Imre Deak wrote:
> The TCSS_DDI_STATUS register is indexed by tc_port not by the FIA port
> index, fix this up. This only caused an issue on TC#3/4 ports in legacy
> mode, as in all other cases the two indices either match (on TC#1/2) or
> the
== Series Details ==
Series: series starting with [1/2] drm/i915: Fix oops due to missing stack depot
URL : https://patchwork.freedesktop.org/series/99353/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11141 -> Patchwork_22109
We should now rely on userspace doing dirtyfb. There is no
need to have separate frontbuffer tracking hooks in gem code.
This patch is removing all frontbuffer tracking calls from the gem
code.
Cc: Ville Syrjälä
Cc: Jani Nikula
Cc: Daniel Vetter
Signed-off-by: Jouni Högander
---
On 1/26/22 9:37 AM, Maarten Lankhorst wrote:
set_cache_level may unbind the object, which will result in the below
lockdep splat:
<6> [184.578145] [IGT] kms_addfb_basic: starting subtest
addfb25-framebuffer-vs-set-tiling
<4> [184.578220] [ cut here ]
<4> [184.578221]
On Wed, Jan 26, 2022 at 10:15:39AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Don't see why we should skip the wakeref tracking when the
> platform doesn't support runtime pm. We still want all the
> code to be 100% leak free so let's track this unconditionally.
>
> Cc: Vlastimil
On Wed, Jan 26, 2022 at 10:15:38AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We call __save_depot_stack() unconditionally so the stack depot
> must always be initialized or else we'll oops on platforms without
> runtime pm support.
>
> Presumably we've not seen this in CI due to
On Wed, Jan 26, 2022 at 02:43:45AM -0800, Lucas De Marchi wrote:
> On Wed, Jan 26, 2022 at 12:12:50PM +0200, Andy Shevchenko wrote:
> > On Wed, Jan 26, 2022 at 11:39 AM Lucas De Marchi
> > wrote:
...
> > > 411986 104906176 428652 68a6c drm.ko.old
> > > 411986 104906176 428652
Abstract out a Gen9 register list as the default for all other
platforms we don't yet formally support GuC submission on.
Signed-off-by: Alan Previn
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 74 +++
1 file changed, 58 insertions(+), 16 deletions(-)
diff --git
Add a flags parameter through all of the coredump creation
functions. Add a bitmask flag to indicate if the top
level gpu_coredump event is triggered in response to
a GuC context reset notification.
Using that flag, ensure all coredump functions that
read or print mmio-register values related to
GuC log buffer regions for debug-log-events, crash-dumps and
error-state-capture are all a single bo allocation that includes
the guc_log_buffer_state structures.
Since the error-capture region is accessed with high priority at non-
deterministic times (as part of gpu coredump) while the
Print the GuC captured error state register list (string names
and values) when gpu_coredump_state printout is invoked via
the i915 debugfs for flushing the gpu error-state that was
captured prior.
Since GuC could have reported multiple engine register dumps
in a single notification event, parse
Add GuC's error capture output structures and definitions as how
they would appear in GuC log buffer's error capture subregion after
an error state capture G2H event notification.
Signed-off-by: Alan Previn
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h | 35
- Upon the G2H Notify-Err-Capture event, parse through the
GuC Log Buffer (error-capture-region) and dynamically allocate
capture-nodes, A single node represents a single "engine-
instance-capture-dump" and contains at least 3 register lists:
global, engine-class and engine-instance. An
Before we print the GuC provided register dumps, modify the
register tables to use string names as per the legacy error
capture execlist codes.
Signed-off-by: Alan Previn
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 70 +--
1 file changed, 35 insertions(+), 35
This series:
1. Enables support of GuC to execute error-
state-capture based on a list of MMIO
registers the driver registers and GuC will
dump and report back right before a GuC
triggered engine-reset event.
2. Updates the ADS blob creation to register lists
of global
Add device specific tables and register lists to cover different engines
class types for GuC error state capture for XE_LP products.
Also, add runtime allocation and freeing of extended register lists
for registers that need steering identifiers that depend on
the detected HW config.
Add additional DG2 registers for GuC error state capture.
Signed-off-by: Alan Previn
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 64 ++-
1 file changed, 49 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
Update GuC ADS size allocation to include space for
the lists of error state capture register descriptors.
Also, populate the lists of registers we want GuC to report back to
Host on engine reset events. This list should include global,
engine-class and engine-instance registers for every
The TCSS_DDI_STATUS register is indexed by tc_port not by the FIA port
index, fix this up. This only caused an issue on TC#3/4 ports in legacy
mode, as in all other cases the two indices either match (on TC#1/2) or
the TCSS_DDI_STATUS_READY flag is set regardless of something being
connected or
On Wed, Jan 26, 2022 at 12:12:50PM +0200, Andy Shevchenko wrote:
On Wed, Jan 26, 2022 at 11:39 AM Lucas De Marchi
wrote:
linux/string_helpers.h provides a helper to return "yes"/"no" strings.
Replace the open coded versions with str_yes_no(). The places were
oops, I replaced yesno() here
On 25/01/2022 16:32, Matthew Brost wrote:
On Tue, Jan 25, 2022 at 03:27:31PM +, Tvrtko Ursulin wrote:
On 24/01/2022 15:01, Matthew Brost wrote:
More than 1 request can be submitted to a single ELSP at a time if
multiple requests are ready run to on the same context. When a request
is
On 25/01/2022 16:39, Matthew Brost wrote:
On Tue, Jan 25, 2022 at 12:27:43PM +, Tvrtko Ursulin wrote:
On 24/01/2022 15:01, Matthew Brost wrote:
Add request cancel trace point guarded by
CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINT.
Okay-ish I guess (There is pr_notice with the only real
On Wed, Jan 26, 2022 at 11:39 AM Lucas De Marchi
wrote:
>
> Add some helpers under lib/string_helpers.h so they can be used
> throughout the kernel. When I started doing this there were 2 other
> previous attempts I know of, not counting the iterations each of them
> had:
>
> 1)
On 25/01/2022 05:47, Jani Nikula wrote:
On Mon, 24 Jan 2022, Umesh Nerlige Ramappa
wrote:
All timestamps returned by GuC for GuC PMU busyness are captured from
GUC PM TIMESTAMP. Since this timestamp does not tick when GuC goes idle,
kmd uses RING_TIMESTAMP to measure busyness of an engine
On Wed, Jan 26, 2022 at 11:39 AM Lucas De Marchi
wrote:
>
> linux/string_helpers.h provides a helper to return "yes"/"no" strings.
> Replace the open coded versions with str_yes_no(). The places were
> identified with the following semantic patch:
>
> @@
> expression b;
>
On 25/01/2022 18:07, Gustavo A. R. Silva wrote:
Make use of the struct_size() helper instead of an open-coded version,
in order to avoid any potential type mistakes or integer overflows that,
in the worst scenario, could lead to heap overflows.
Also, address the following sparse warnings:
== Series Details ==
Series: series starting with [1/5] drm/i915: Skip dsc readout if the transcoder
is disabled (rev3)
URL : https://patchwork.freedesktop.org/series/99276/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11137_full -> Patchwork_22107_full
On 25/01/2022 18:16, Yury Norov wrote:
On Tue, Jan 25, 2022 at 1:28 AM Tvrtko Ursulin
wrote:
On 23/01/2022 18:38, Yury Norov wrote:
i915_pmu_cpu_online() calls cpumask_weight() to check if any bit of a
given cpumask is set. We can do it more efficiently with cpumask_empty()
because
Remove the local yesno() implementation and adopt the str_yes_no() from
linux/string_helpers.h.
Signed-off-by: Lucas De Marchi
Reviewed-by: Sakari Ailus
---
security/tomoyo/audit.c | 2 +-
security/tomoyo/common.c | 19 +--
security/tomoyo/common.h | 1 -
3 files changed, 6
Remove the local yesno() implementation and adopt the str_yes_no() from
linux/string_helpers.h.
Signed-off-by: Lucas De Marchi
---
.../ethernet/chelsio/cxgb4/cxgb4_debugfs.c| 249 ++
1 file changed, 137 insertions(+), 112 deletions(-)
diff --git
Sort includes alphabetically so it's easier to add/remove includes and
know when that is needed.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/drm_gem.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c
Remove the local onoff() implementation and adopt the
str_on_off() from linux/string_helpers.h.
Signed-off-by: Lucas De Marchi
Acked-by: Daniel Vetter
Acked-by: Jani Nikula
---
drivers/gpu/drm/i915/display/g4x_dp.c | 6 --
drivers/gpu/drm/i915/display/intel_display.c |
Remove the local yesno() implementation and adopt the str_yes_no() from
linux/string_helpers.h.
Signed-off-by: Lucas De Marchi
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git
Remove the local enableddisabled() implementation and adopt the
str_enabled_disabled() from linux/string_helpers.h.
Signed-off-by: Lucas De Marchi
Acked-by: Daniel Vetter
Acked-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_backlight.c | 3 ++-
Add some helpers under lib/string_helpers.h so they can be used
throughout the kernel. When I started doing this there were 2 other
previous attempts I know of, not counting the iterations each of them
had:
1) https://lore.kernel.org/all/20191023131308.9420-1-jani.nik...@intel.com/
2)
There are a few implementations of string helpers in the tree like yesno()
that just returns "yes" or "no" depending on a boolean argument. Those
are helpful to output strings to the user or log.
In order to consolidate them, prefix all of them str_ prefix to make it
clear what they are about and
Remove the trailing semicolon, as correctly warned by checkpatch:
-:1189: WARNING:TRAILING_SEMICOLON: macros should not use a trailing
semicolon
#1189: FILE: drivers/gpu/drm/i915/intel_device_info.c:119:
+#define PRINT_FLAG(name) drm_printf(p, "%s: %s\n", #name,
linux/string_helpers.h provides a helper to return "yes"/"no" strings.
Replace the open coded versions with str_yes_no(). The places were
identified with the following semantic patch:
@@
expression b;
@@
- b ? "yes" : "no"
+ str_yes_no(b)
Then the
Remove the local enabledisable() implementation and adopt the
str_enable_disable() from linux/string_helpers.h.
Signed-off-by: Lucas De Marchi
Acked-by: Daniel Vetter
Acked-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_ddi.c | 4 +++-
Remove the local yesno() implementation and adopt the str_yes_no() from
linux/string_helpers.h.
Signed-off-by: Lucas De Marchi
Acked-by: Daniel Vetter
Acked-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 23 +++
.../drm/i915/display/intel_display_debugfs.c | 66
On 1/26/22 09:15, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We call __save_depot_stack() unconditionally so the stack depot
Ah, in __untrack_all_wakerefs()? Looks like I missed it, sorry.
> must always be initialized or else we'll oops on platforms without
> runtime pm support.
>
>
On Wed, Jan 19, 2022 at 09:30:47PM +0200, Andy Shevchenko wrote:
On Tue, Jan 18, 2022 at 11:24:50PM -0800, Lucas De Marchi wrote:
linux/string_helpers.h provides a helper to return "yes"/"no"
strings. Replace the open coded versions with yesno(). The places were
identified with the following
== Series Details ==
Series: drm/i915: Lock dpt_obj around set_cache_level, v2.
URL : https://patchwork.freedesktop.org/series/99350/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11137 -> Patchwork_22108
Summary
---
== Series Details ==
Series: drm/i915: Lock dpt_obj around set_cache_level, v2.
URL : https://patchwork.freedesktop.org/series/99350/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6d1423b45148 drm/i915: Lock dpt_obj around set_cache_level, v2.
-:8:
From: Ville Syrjälä
We call __save_depot_stack() unconditionally so the stack depot
must always be initialized or else we'll oops on platforms without
runtime pm support.
Presumably we've not seen this in CI due to stack_depot_init()
already getting called via drm_mm_init()+CONFIG_DRM_DEBUG_MM.
From: Ville Syrjälä
Don't see why we should skip the wakeref tracking when the
platform doesn't support runtime pm. We still want all the
code to be 100% leak free so let's track this unconditionally.
Cc: Vlastimil Babka
Cc: Dmitry Vyukov
Cc: Marco Elver # stackdepot
Cc: Chris Wilson
Cc:
101 - 179 of 179 matches
Mail list logo
