== Series Details ==
Series: drm/i915/adlp: Fix TypeC PHY-ready status readout
URL : https://patchwork.freedesktop.org/series/99359/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11145 -> Patchwork_22111
Summary
---
Hi Lucas,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[also build test ERROR on next-20220125]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
drm/drm-next tegra-drm/drm/tegra/for-next linus/master airlied/drm-next
On Tue, Jan 25, 2022 at 07:03:41PM +0200, Jani Nikula wrote:
> Add some of the new additions from DP 2.0 E11.
>
> Cc: Uma Shankar
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> include/drm/dp/drm_dp_helper.h | 2 ++
> 1 file changed, 2 insertions(+)
>
On Thu, Jan 27, 2022 at 08:24:04AM +0100, Christian König wrote:
> Am 26.01.22 um 21:36 schrieb Lucas De Marchi:
> > In certain situations it's useful to be able to read or write to an
> > offset that is calculated by having the memory layout given by a struct
> > declaration. Usually we are going
On Thu, Jan 27, 2022 at 08:27:11AM +0100, Christian König wrote:
Am 26.01.22 um 21:36 schrieb Lucas De Marchi:
When dma_buf_map struct is passed around, it's useful to be able to
initialize a second map that takes care of reading/writing to an offset
of the original map.
Add a helper that
== Series Details ==
Series: series starting with [1/2] drm/i915/pmu: Fix KMD and GuC race on
accessing busyness
URL : https://patchwork.freedesktop.org/series/99388/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11148 -> Patchwork_22119
== Series Details ==
Series: drm/i915/guc: Refactor ADS access to use dma_buf_map
URL : https://patchwork.freedesktop.org/series/99378/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11147_full -> Patchwork_22116_full
As per the rev 5 CI results between this patch and patch7, i have introduced a
lockdep splat bug, i shall fix that in
the next rev.
...alan
On Wed, 2022-01-26 at 02:48 -0800, Alan Previn wrote:
> GuC log buffer regions for debug-log-events, crash-dumps and
> error-state-capture are all a single
Hi Umesh,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[cannot apply to linus/master drm-intel/for-linux-next v5.17-rc1 next-20220125]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to
== Series Details ==
Series: series starting with [v10,1/5] drm: improve drm_buddy_alloc function
URL : https://patchwork.freedesktop.org/series/99382/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11147_full -> Patchwork_22117_full
On Tue, Jan 25, 2022 at 07:03:44PM +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 Tue, Jan 25, 2022 at 07:03:43PM +0200, Jani Nikula wrote:
> +static bool
> +intel_dp_128b132b_lane_cds(struct intel_dp *intel_dp,
> +const struct intel_crtc_state *crtc_state,
> +int lttpr_count)
> +{
> + struct intel_encoder *encoder =
On 1/26/22 21:04, a...@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2022-01-26-21-04 has been uploaded to
>
>https://www.ozlabs.org/~akpm/mmotm/
>
> mmotm-readme.txt says
>
> README for mm-of-the-moment:
>
> https://www.ozlabs.org/~akpm/mmotm/
>
> This is a snapshot of
On Tue, Jan 25, 2022 at 07:03:39PM +0200, Jani Nikula wrote:
> The DP 2.0 errata changes DP_128B132B_TRAINING_AUX_RD_INTERVAL (DPCD
> 0x2216) completely. Add a new function to read that. Follow-up will need
> to clean up existing functions.
>
> v2: fix reversed interpretation of bit 7 meaning
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 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 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 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 ---
>
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
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
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
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
---
== 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
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
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 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 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 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 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 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 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 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
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 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 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
> ---
>
Use dma_buf_map to read fields from the dma_blob so access to IO and
system memory is abstracted away.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
---
Currently guc_mmio_reg_add() relies on having enough memory available in
the array to add a new slot. It uses
`GEM_BUG_ON(count >= regset->size);` to protect going above the
threshold.
In order to allow guc_mmio_reg_add() to handle the memory allocation by
itself, it must return an error in case
Use dma_buf_map to write the fields ads.capture_*.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 10 +-
1 file changed, 5
Use dma_buf_map to write the policies update so access to IO and system
memory is abstracted away.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
---
Use the saved ads_map to prepare the golden context. One difference from
the init context is that this function can be called before there is a
gem object (and thus the guc->ads_map) to calculare the size of the
golden context that should be allocated for that object.
So in this case the function
Now that the regset list is prepared, convert guc_mmio_reg_state_init()
to use dma_buf_map to copy the array to the final location and
initialize additional fields in ads.reg_state_list.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele
In the other places in this function, guc->ads_map is being protected
from access when it's not yet set. However the last check is actually
about guc->ads_golden_ctxt_size been set before. These checks should
always match as the size is initialized on the first call to
guc_prep_golden_context(),
Now we have the access to content of GuC ADS either using dma_buf_map
API or using a temporary buffer. Remove guc->ads_blob as there shouldn't
be updates using the bare pointer anymore.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele
Use dma_buf_map_memset() to zero the private data as ADS may be either
on system or IO memory.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
Add a variant of shmem_read() that takes a dma_buf_map pointer rather
than a plain pointer as argument. It's mostly a copy __shmem_rw() but
adapting the api and removing the write support since there's currently
only need to use dma_buf_map as destination.
Reworking __shmem_rw() to share the
When dma_buf_map struct is passed around, it's useful to be able to
initialize a second map that takes care of reading/writing to an offset
of the original map.
Add a helper that copies the struct and add the offset to the proper
address.
Cc: Sumit Semwal
Cc: Christian König
Cc:
Use dma_buf_map to write the fields system_info.mapping_table[][].
Since we already have the info_map around where needed, just use it
instead of going through guc->ads_map.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
In certain situations it's useful to be able to read or write to an
offset that is calculated by having the memory layout given by a struct
declaration. Usually we are going to read/write a u8, u16, u32 or u64.
Add a pair of macros dma_buf_map_read_field()/dma_buf_map_write_field()
to calculate
Add helpers on top of dma_buf_map_read_field() /
dma_buf_map_write_field() functions so they always use the right
arguments and make code easier to read.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas
Now the map is saved during creation, so use it to initialize the
golden context, reading from shmem and writing to either system or IO
memory.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
While porting i915 to arm64 we noticed some issues accessing lmem.
Some writes were getting corrupted and the final state of the buffer
didn't have exactly what we wrote. This became evident when enabling
GuC submission: depending on the number of engines the ADS struct was
being corrupted and GuC
Convert intel_guc_ads_create() and initialization to use dma_buf_map
rather than plain pointer and save it in the guc struct. This will help
with additional updates to the ads_blob after the
creation/initialization by abstracting the IO vs system memory.
Cc: Matt Roper
Cc: Thomas Hellström
Cc:
Just like memcpy_toio(), there is also need to write a direct value to a
memory block. Add dma_buf_map_memset() to abstract memset() vs memset_io()
Cc: Matt Roper
Cc: Sumit Semwal
Cc: Christian König
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc:
== Series Details ==
Series: Initial support for small BAR recovery
URL : https://patchwork.freedesktop.org/series/99370/
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: Initial support for small BAR recovery
URL : https://patchwork.freedesktop.org/series/99370/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8c8317fbf210 drm: improve drm_buddy_alloc function
-:399: WARNING:AVOID_BUG: Avoid crashing the kernel - try
On Wed, Jan 26, 2022 at 04:42:52PM +0200, Jani Nikula wrote:
> 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 ++--
> >
== Series Details ==
Series: Initial support for small BAR recovery
URL : https://patchwork.freedesktop.org/series/99370/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11146 -> Patchwork_22114
Summary
---
On Mon, Jan 24, 2022 at 06:08:21PM -0800, Matt Roper wrote:
The OA unit registers are only used by the perf code; move them to their
own header file.
Cc: Jani Nikula
Cc: Umesh Nerlige Ramappa
Cc: Lionel Landwerlin
Signed-off-by: Matt Roper
I checked the output from git show --color-moved
The ADS initialitazion was using 2 passes to calculate the regset sent
to GuC to initialize each engine: the first pass to just have the final
object size and the second to set each register in place in the final
gem object.
However in order to maintain an ordered set of registers to pass to guc,
Now that all the called functions from __guc_ads_init() are converted to
use ads_map, stop using ads_blob in __guc_ads_init().
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
---
Thanks Jani for taking the time to review...
1. apologies on the const issue, this is my bad, i think it was
one of the comments from earlier rev not sure how i missed it.
Will fix this on next rev.
2. I do have a question below on the const for one of specific types
of tables. Need your
On Mon, Jan 24, 2022 at 06:08:22PM -0800, Matt Roper wrote:
Let's use 'struct i915_range' to express sets of b-counter and mux
registers in the perf code. This makes the code more similar to how we
handle things like multicast register ranges, forcewake tables, shadow
tables, etc. and also lets
On Mon, Jan 24, 2022 at 06:08:23PM -0800, Matt Roper wrote:
At the moment we only use R_PWR_CLK_STATE in the context of the RCS
engine, but upcoming support for compute engines will start using
instances relative to the CCS engine base offsets. Let's parameterize
the register and move it to the
On Mon, Jan 24, 2022 at 06:08:24PM -0800, Matt Roper wrote:
The various MI_PREDICATE registers have per-engine instances. Today we
only utilize the RCS0 instance of each, but that will likely change in
the future; switch to parameterized register definitions to make these
easier to work with
On Mon, Jan 24, 2022 at 06:08:25PM -0800, Matt Roper wrote:
+#define MEMSWCTL _MMIO(0x11170) /* Ironlake only */
+#define MEMCTL_CMD_MASK 0xe000
+#define MEMCTL_CMD_SHIFT 13
+#define MEMCTL_CMD_RCLK_OFF 0
+#define MEMCTL_CMD_RCLK_ON 1
+#define
On Mon, Jan 24, 2022 at 06:08:26PM -0800, Matt Roper wrote:
Several of our i915 header files, have been including i915_reg.h. This
means that any change to i915_reg.h will trigger a full rebuild of
pretty much every file of the driver, even those that don't have any
kind of register access.
== Series Details ==
Series: drm/i915/display/vrr: Reset VRR capable property on a long hpd (rev2)
URL : https://patchwork.freedesktop.org/series/98801/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
071c4ebbb036 drm/i915/display/vrr: Reset VRR capable property on a long hpd
On Wed, Jan 26, 2022 at 02:48:13AM -0800, Alan Previn wrote:
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
== Series Details ==
Series: drm/i915/display/vrr: Reset VRR capable property on a long hpd (rev2)
URL : https://patchwork.freedesktop.org/series/98801/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11147 -> Patchwork_22115
== Series Details ==
Series: drm/i915/guc: Refactor ADS access to use dma_buf_map
URL : https://patchwork.freedesktop.org/series/99378/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
65454816ee9c dma-buf-map: Add read/write helpers
-:105: CHECK:MACRO_ARG_PRECEDENCE: Macro
== Series Details ==
Series: drm/i915/guc: Refactor ADS access to use dma_buf_map
URL : https://patchwork.freedesktop.org/series/99378/
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, Dec 14, 2021 at 3:03 PM Sebastian Andrzej Siewior <
bige...@linutronix.de> wrote:
> From: Mike Galbraith
>
> Mario Kleiner suggest in commit
> ad3543ede630f ("drm/intel: Push get_scanout_position() timestamping into
> kms driver.")
>
> a spots where preemption should be disabled on
== Series Details ==
Series: drm/i915/guc: Refactor ADS access to use dma_buf_map
URL : https://patchwork.freedesktop.org/series/99378/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11147 -> Patchwork_22116
Summary
---
== Series Details ==
Series: drm/i915/guc: Refactor ADS access to use dma_buf_map
URL : https://patchwork.freedesktop.org/series/99378/
State : warning
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
CHK include/generated/compile.h
CC [M]
== Series Details ==
Series: series starting with [v10,1/5] drm: improve drm_buddy_alloc function
URL : https://patchwork.freedesktop.org/series/99382/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c9a375384fb3 drm: improve drm_buddy_alloc function
-:383: WARNING:AVOID_BUG:
== Series Details ==
Series: lib/string_helpers: Add a few string helpers (rev2)
URL : https://patchwork.freedesktop.org/series/99030/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11145_full -> Patchwork_22110_full
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
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:
> 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 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 ?
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
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
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
- 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
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
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
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
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
---
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
---
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
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
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
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
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 |
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
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
1 - 100 of 179 matches
Mail list logo
