[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use a bitmask for bigjoiner state tracking (rev3)

== Series Details == Series: drm/i915: Use a bitmask for bigjoiner state tracking (rev3) URL : https://patchwork.freedesktop.org/series/99680/ State : success == Summary == CI Bug Log - changes from CI_DRM_11188 -> Patchwork_22174 Summary -

Re: [Intel-gfx] [PATCH 21/21] fbdev: Make registered_fb[] private to fbmem.c

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. Can't the actual frame buffer driver (which one?) used on olpc export a pointer to its fb_i

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Disable unused power wells left enabled by BIOS (rev2)

== Series Details == Series: drm/i915: Disable unused power wells left enabled by BIOS (rev2) URL : https://patchwork.freedesktop.org/series/99615/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11180_full -> Patchwork_22160_full

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915: Move PIPE_CHICKEN RMW out from the vblank evade critical section (rev3)

== Series Details == Series: series starting with [1/4] drm/i915: Move PIPE_CHICKEN RMW out from the vblank evade critical section (rev3) URL : https://patchwork.freedesktop.org/series/99616/ State : success == Summary == CI Bug Log - changes from CI_DRM_11188 -> Patchwork_22175 =

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Use a bitmask for bigjoiner state tracking (rev3)

== Series Details == Series: drm/i915: Use a bitmask for bigjoiner state tracking (rev3) URL : https://patchwork.freedesktop.org/series/99680/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11188_full -> Patchwork_22174_full

Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/uapi: Add query for hwconfig table

On Wed, Jan 19, 2022 at 9:35 PM wrote: > > From: Rodrigo Vivi > > GuC contains a consolidated table with a bunch of information about the > current device. > > Previously, this information was spread and hardcoded to all the components > including GuC, i915 and various UMDs. The goal here is to c

Re: [Intel-gfx] [PATCH 04/21] fbcon: delete a few unneeded forward decl

On Tue, Feb 1, 2022 at 9:50 PM Daniel Vetter wrote: > I didn't bother with any code movement to fix the others, these just > got a bit in the way. > > Signed-off-by: Daniel Vetter Reviewed-by: Geert Uytterhoeven Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There'

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/4] drm/i915: Move PIPE_CHICKEN RMW out from the vblank evade critical section (rev3)

== Series Details == Series: series starting with [1/4] drm/i915: Move PIPE_CHICKEN RMW out from the vblank evade critical section (rev3) URL : https://patchwork.freedesktop.org/series/99616/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11188_full -> Patchwork_22175_full ===

Re: [Intel-gfx] [PATCH 1/6] dma-buf: consolidate dma_fence subclass checking

On Fri, 2022-02-04 at 11:04 +0100, Christian König wrote: > Consolidate the wrapper functions to check for dma_fence > subclasses in the dma_fence header. > > This makes it easier to document and also check the different > requirements for fence containers in the subclasses. > > Signed-off-by: Ch

Re: [Intel-gfx] [PATCH 5/6] dma-buf: add dma_fence_chain_contained helper

On Fri, 2022-02-04 at 11:04 +0100, Christian König wrote: > It's a reoccurring pattern that we need to extract the fence > from a dma_fence_chain object. Add a helper for this. > > Signed-off-by: Christian König I thought I'd reviewed this one already, but in case I didn't Reviewed-by: Thomas H

Re: [Intel-gfx] Add warning for nesting dma_fence containers

On Fri, 2022-02-04 at 11:04 +0100, Christian König wrote: > Hi everyone, > > Since some operations can then lead to recursive handling nesting > dma_fence containers into each other is only allowed under some > restrictions. > > dma_fence_array containers can be attached to dma_fence_chain > cont

Re: [Intel-gfx] [PATCH v2 5/8] drm/i915/dp: rewrite DP 2.0 128b/132b link training based on errata

On Thu, Feb 03, 2022 at 11:03:54AM +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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Disable unused power wells left enabled by BIOS (rev2)

== Series Details == Series: drm/i915: Disable unused power wells left enabled by BIOS (rev2) URL : https://patchwork.freedesktop.org/series/99615/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11180_full -> Patchwork_22160_full

[Intel-gfx] [PATCH 1/6] dma-buf: consolidate dma_fence subclass checking

Consolidate the wrapper functions to check for dma_fence subclasses in the dma_fence header. This makes it easier to document and also check the different requirements for fence containers in the subclasses. Signed-off-by: Christian König --- include/linux/dma-fence-array.h | 15 +

Re: [Intel-gfx] Add warning for nesting dma_fence containers

Am 04.02.22 um 11:40 schrieb Thomas Hellström: On Fri, 2022-02-04 at 11:04 +0100, Christian König wrote: Hi everyone, Since some operations can then lead to recursive handling nesting dma_fence containers into each other is only allowed under some restrictions. dma_fence_array containers ca

[Intel-gfx] [PATCH 6/6] drm/amdgpu: use dma_fence_chain_contained

Instead of manually extracting the fence. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c index f7d8487799b2..

[Intel-gfx] [PATCH 4/6] dma-buf: warn about containers in dma_resv object

Drivers should not add containers as shared fences to the dma_resv object, instead each fence should be added individually. Signed-off-by: Christian König Reviewed-by: Daniel Vetter Reviewed-by: Thomas Hellström --- drivers/dma-buf/dma-resv.c | 5 + 1 file changed, 5 insertions(+) diff --

[Intel-gfx] [PATCH 5/6] dma-buf: add dma_fence_chain_contained helper

It's a reoccurring pattern that we need to extract the fence from a dma_fence_chain object. Add a helper for this. Signed-off-by: Christian König --- drivers/dma-buf/dma-fence-chain.c | 6 ++ include/linux/dma-fence-chain.h | 15 +++ 2 files changed, 17 insertions(+), 4 deleti

[Intel-gfx] Add warning for nesting dma_fence containers

Hi everyone, Since some operations can then lead to recursive handling nesting dma_fence containers into each other is only allowed under some restrictions. dma_fence_array containers can be attached to dma_fence_chain containers and dma_fence_chain containers by chaining them together. In all o

[Intel-gfx] [PATCH 3/6] dma-buf: Warn about dma_fence_chain container rules v2

Chaining of dma_fence_chain objects is only allowed through the prev fence and not through the contained fence. Warn about that when we create a dma_fence_chain. v2: fix comment style Signed-off-by: Christian König Reviewed-by: Daniel Vetter Reviewed-by: Thomas Hellström --- drivers/dma-buf/

Re: [Intel-gfx] [PATCH v11 5/5] drm/amdgpu: add drm buddy support to amdgpu

Am 04.02.22 um 12:22 schrieb Arunpravin: On 28/01/22 7:48 pm, Matthew Auld wrote: On Thu, 27 Jan 2022 at 14:11, Arunpravin wrote: - Remove drm_mm references and replace with drm buddy functionalities - Add res cursor support for drm buddy v2(Matthew Auld): - replace spinlock with mutex as

[Intel-gfx] [PATCH 2/6] dma-buf: warn about dma_fence_array container rules v2

It's not allowed to nest another dma_fence container into a dma_fence_array or otherwise we can run into recursion. Warn about that when we create a dma_fence_array. v2: fix comment style and typo in the warning pointed out by Thomas Signed-off-by: Christian König Reviewed-by: Daniel Vetter Re

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/6] dma-buf: consolidate dma_fence subclass checking

== Series Details == Series: series starting with [1/6] dma-buf: consolidate dma_fence subclass checking URL : https://patchwork.freedesktop.org/series/99700/ State : warning == Summary == $ dim checkpatch origin/drm-tip 45d3d4ee83aa dma-buf: consolidate dma_fence subclass checking -:117: WAR

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/6] dma-buf: consolidate dma_fence subclass checking

== Series Details == Series: series starting with [1/6] dma-buf: consolidate dma_fence subclass checking URL : https://patchwork.freedesktop.org/series/99700/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked s

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/6] dma-buf: consolidate dma_fence subclass checking

== Series Details == Series: series starting with [1/6] dma-buf: consolidate dma_fence subclass checking URL : https://patchwork.freedesktop.org/series/99700/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11189 -> Patchwork_22176 ==

[Intel-gfx] [PATCH 3/3] drm/i915: Workaround broken BIOS DBUF configuration on TGL/RKL

From: Ville Syrjälä On TGL/RKL the BIOS likes to use some kind of bogus DBUF layout that doesn't match what the spec recommends. With a single active pipe that is not going to be a problem, but with multiple pipes active skl_commit_modeset_enables() goes into an infinite loop since it can't figur

[Intel-gfx] [PATCH 1/3] drm/i915: Allow !join_mbus cases for adlp+ dbuf configuration

From: Ville Syrjälä Reintroduce the !join_mbus single pipe cases for adlp+. Due to the mbus relative dbuf offsets in PLANE_BUF_CFG we need to know the actual slices used by the pipe when doing readout, even when mbus joining isn't enabled. Accurate readout will be needed to properly sanitize inv

[Intel-gfx] [PATCH 2/3] drm/i915: Populate pipe dbuf slices more accurately during readout

From: Ville Syrjälä During readout we cannot assume the planes are actually using the slices they are supposed to use. The BIOS may have misprogrammed things and put the planes onto the wrong dbuf slices. So let's do the readout more carefully to make sure we really know which dbuf slices are act

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915: Allow !join_mbus cases for adlp+ dbuf configuration

== Series Details == Series: series starting with [1/3] drm/i915: Allow !join_mbus cases for adlp+ dbuf configuration URL : https://patchwork.freedesktop.org/series/99702/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11189 -> Patchwork_22177 =

Re: [Intel-gfx] [PATCH v4 0/5] Add driver for GSC controller

On Thu, Jan 27, 2022 at 01:20:58PM +0200, Alexander Usyskin wrote: > GSC is a graphics system controller, it provides > a chassis controller for graphics discrete cards. > > There are two MEI interfaces in GSC: HECI1 and HECI2. > > This series includes instantiation of the auxiliary devices for H

Re: [Intel-gfx] [PATCH 6/6] drm/amdgpu: use dma_fence_chain_contained

On Fri, Feb 4, 2022 at 5:04 AM Christian König wrote: > > Instead of manually extracting the fence. > > Signed-off-by: Christian König Reviewed-by: Alex Deucher > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/drive

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915: Allow !join_mbus cases for adlp+ dbuf configuration

== Series Details == Series: series starting with [1/3] drm/i915: Allow !join_mbus cases for adlp+ dbuf configuration URL : https://patchwork.freedesktop.org/series/99702/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11189_full -> Patchwork_22177_full ===

[Intel-gfx] [PATCH v5 2/5] drm/i915/gt: Drop invalidate_csb_entries

Drop invalidate_csb_entries and directly call drm_clflush_virt_range. This allows for one less function call, and prevent complier errors when building for non-x86 architectures. v2(Michael Cheng): Drop invalidate_csb_entries function and directly invoke drm_clflush_virt_range.

[Intel-gfx] [PATCH v5 0/5] Use drm_clflush* instead of clflush

This patch series re-work a few i915 functions to use drm_clflush_virt_range instead of calling clflush or clflushopt directly. This will prevent errors when building for non-x86 architectures. v2: s/PAGE_SIZE/sizeof(value) for Re-work intel_write_status_page and added more patches to convert addi

[Intel-gfx] [PATCH v5 3/5] drm/i915/gt: Re-work reset_csb

Use drm_clflush_virt_range instead of directly invoking clflush. This will prevent compiler errors when building for non-x86 architectures. v2(Michael Cheng): Remove extra clflush v3(Michael Cheng): Remove memory barrier since drm_clflush_virt_range takes care of it. Signed-of

[Intel-gfx] [PATCH v5 1/5] drm/i915/gt: Re-work intel_write_status_page

Re-work intel_write_status_page to use drm_clflush_virt_range. This will prevent compiler errors when building for non-x86 architectures. Signed-off-by: Michael Cheng --- drivers/gpu/drm/i915/gt/intel_engine.h | 13 - 1 file changed, 4 insertions(+), 9 deletions(-) diff --git a/driv

[Intel-gfx] [PATCH v5 5/5] drm/i915/gt: replace cache_clflush_range

Replace all occurance of cache_clflush_range with drm_clflush_virt_range. This will prevent compile errors on non-x86 platforms. Signed-off-by: Michael Cheng --- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 12 ++-- drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 2 +-

[Intel-gfx] [PATCH v5 4/5] drm/i915/: Re-work clflush_write32

Use drm_clflush_virt_range instead of clflushopt and remove the memory barrier, since drm_clflush_virt_range takes care of that. Signed-off-by: Michael Cheng --- drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/gpu

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Use drm_clflush* instead of clflush (rev4)

== Series Details == Series: Use drm_clflush* instead of clflush (rev4) URL : https://patchwork.freedesktop.org/series/99450/ State : warning == Summary == $ dim checkpatch origin/drm-tip 09b1c8ee43ad drm/i915/gt: Re-work intel_write_status_page 3f38f2a1e91d drm/i915/gt: Drop invalidate_csb_en

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Use drm_clflush* instead of clflush (rev4)

== Series Details == Series: Use drm_clflush* instead of clflush (rev4) URL : https://patchwork.freedesktop.org/series/99450/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

[Intel-gfx] [PATCH v4] dma-buf-map: Rename to iosys-map

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 and store, from IO memory that needs to be acessed

[Intel-gfx] [PATCH] drm/i915/selftests: Disable runtime pm wakeref tracking for the mock device

From: Ville Syrjälä commit c50df701d49e ("drm/i915: Enable rpm wakeref tracking whether runtime pm is enabled or not") enabled wakeref tracking even for the mock device. Turns out that has somewhat significant overhead, and on the glacial Core m3's we have in CI the vma selftests are now exceedin

[Intel-gfx] ✓ Fi.CI.BAT: success for Use drm_clflush* instead of clflush (rev4)

== Series Details == Series: Use drm_clflush* instead of clflush (rev4) URL : https://patchwork.freedesktop.org/series/99450/ State : success == Summary == CI Bug Log - changes from CI_DRM_11189 -> Patchwork_22178 Summary --- **SUCCE

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for dma-buf-map: Rename to iosys-map (rev3)

== Series Details == Series: dma-buf-map: Rename to iosys-map (rev3) URL : https://patchwork.freedesktop.org/series/99612/ State : warning == Summary == $ dim checkpatch origin/drm-tip 22c409c1748c dma-buf-map: Rename to iosys-map -:237: WARNING:AVOID_BUG: Avoid crashing the kernel - try using

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for dma-buf-map: Rename to iosys-map (rev3)

== Series Details == Series: dma-buf-map: Rename to iosys-map (rev3) URL : https://patchwork.freedesktop.org/series/99612/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

[Intel-gfx] [Important!] 2022 X.Org Foundation Membership deadline for voting in the election

The 2022 X.Org Foundation elections are rapidly approaching. We will be forwarding instructions on the nomination process to membership in the near future. Please note that only current members can vote in the upcoming election, and that the deadline for new memberships or renewals to vote in the

[Intel-gfx] [PATCH 00/19] drm/i915/guc: Refactor ADS access to use iosys_map

2nd version of https://patchwork.freedesktop.org/series/99378/ As first patch I'm including the dma-buf-map rename to iosys-map for completeness and to allow the other patches to be reviewed. However the first patch was also sent by itself. I think all the feedback from v1 was incorporated in thi

[Intel-gfx] [PATCH 02/19] iosys-map: Add offset to iosys_map_memcpy_to()

In certain situations it's useful to be able to write to an offset of the mapping. Add a dst_offset to iosys_map_memcpy_to(). Cc: Sumit Semwal Cc: Christian König Cc: Thomas Zimmermann Cc: dri-de...@lists.freedesktop.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Lucas De Marchi --- driv

[Intel-gfx] [PATCH 07/19] drm/i915/guc: Convert golden context init to iosys_map

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

[Intel-gfx] [PATCH 09/19] drm/i915/guc: Convert engine record to iosys_map

Use iosys_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 --- drivers/gpu/drm/i915/gt/uc/intel_guc_

[Intel-gfx] [PATCH 06/19] drm/i915/guc: Add read/write helpers for ADS blob

Add helpers on top of iosys_map_read_field() / iosys_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 De M

[Intel-gfx] [PATCH 05/19] drm/i915/guc: Keep iosys_map of ads_blob around

Convert intel_guc_ads_create() and initialization to use iosys_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: Dan

[Intel-gfx] [PATCH 10/19] drm/i915/guc: Convert guc_ads_private_data_reset to iosys_map

Use iosys_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 |

[Intel-gfx] [PATCH 01/19] dma-buf-map: Rename to iosys-map

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 and store, from IO memory that needs to be acessed

[Intel-gfx] [PATCH 08/19] drm/i915/guc: Convert policies update to iosys_map

Use iosys_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 --- drivers/gpu/drm/i915/gt/uc/intel_guc_ads.

[Intel-gfx] [PATCH 03/19] iosys-map: Add a few more helpers

First the simplest ones: - iosys_map_memset(): when abstracting system and I/O memory, just like the memcpy() use case, memset() also has dedicated functions to be called for using IO memory. - iosys_map_memcpy_from(): we may need to copy data from I/O

[Intel-gfx] [PATCH 04/19] drm/i915/gt: Add helper for shmem copy to iosys_map

Add a variant of shmem_read() that takes a iosys_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 iosys_map as destination. Reworking __shmem_rw() to share the implement

[Intel-gfx] [PATCH 11/19] drm/i915/guc: Convert golden context prep to iosys_map

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

[Intel-gfx] [PATCH 18/19] drm/i915/guc: Convert __guc_ads_init to iosys_map

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 --- drivers/gpu

[Intel-gfx] [PATCH 12/19] drm/i915/guc: Replace check for golden context size

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(), b

[Intel-gfx] [PATCH 13/19] drm/i915/guc: Convert mapping table to iosys_map

Use iosys_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 Sig

[Intel-gfx] [PATCH 14/19] drm/i915/guc: Convert capture list to iosys_map

Use iosys_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 insertions(

[Intel-gfx] [PATCH 16/19] drm/i915/guc: Use a single pass to calculate regset

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,

[Intel-gfx] [PATCH 17/19] drm/i915/guc: Convert guc_mmio_reg_state_init to iosys_map

Now that the regset list is prepared, convert guc_mmio_reg_state_init() to use iosys_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 Ceraol

[Intel-gfx] [PATCH 15/19] drm/i915/guc: Prepare for error propagation

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 o

[Intel-gfx] [PATCH 19/19] drm/i915/guc: Remove plain ads_blob pointer

Now we have the access to content of GuC ADS either using iosys_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 Ceraolo

Re: [Intel-gfx] [PATCH] drm/i915/selftests: fix some error codes in __cancel_reset()

Hi Dan, > There were two error paths in __cancel_reset() which return success > instead of a negative error code as expected. > > Fixes: 4e6835466771 ("drm/i915/selftests: Add a cancel request selftest that > triggers a reset") > Signed-off-by: Dan Carpenter > --- > >From static analysis. I am

[Intel-gfx] [RFC PATCH 1/3] drm: Extract amdgpu_sa.c as a generic suballocation helper

Suballocating a buffer object is something that is not driver generic, and is useful for other drivers as well. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/Makefile | 4 +- drivers/gpu/drm/drm_suballoc.c | 424 + include/drm/drm_suballoc.h |

[Intel-gfx] [RFC PATCH 3/3] drm/radeon: Use the drm suballocation manager implementation.

Use the generic suballocation helper lifted from amdgpu. Note that the generic suballocator only allows a single alignment, so we may waste a few more bytes for radeon_semaphore, shouldn't be a big deal, could be re-added if needed. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/radeon/rad

[Intel-gfx] [RFC PATCH 0/3] drm/helpers: Make the suballocation manager drm generic.

The suballocation manager itself is not dependent on any implementation detail, and can be made generic. I want to potentially use it inside i915, as it looks like a clean implementation to do so. :) Looking for feedback and some testing, as I don't have a amdgpu/radeon myself. Only compile tested

[Intel-gfx] [RFC PATCH 2/3] drm/amd: Convert amdgpu to use suballocation helper.

Now that the suballocation helper is generic, we can use it in amdgpu. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/amd/amdgpu/amdgpu.h| 29 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 5 +- drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 21 +- drivers/gpu/drm/amd/amdgpu/am

[Intel-gfx] ✗ Fi.CI.BAT: failure for dma-buf-map: Rename to iosys-map (rev3)

== Series Details == Series: dma-buf-map: Rename to iosys-map (rev3) URL : https://patchwork.freedesktop.org/series/99612/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11189 -> Patchwork_22179 Summary --- **FAILURE*

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/selftests: Disable runtime pm wakeref tracking for the mock device

== Series Details == Series: drm/i915/selftests: Disable runtime pm wakeref tracking for the mock device URL : https://patchwork.freedesktop.org/series/99708/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked s

Re: [Intel-gfx] [PATCH v5 06/10] drm/i915/guc: Update GuC's log-buffer-state access for error capture.

On Wed, Jan 26, 2022 at 02:48:18AM -0800, Alan Previn wrote: > 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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Disable runtime pm wakeref tracking for the mock device

== Series Details == Series: drm/i915/selftests: Disable runtime pm wakeref tracking for the mock device URL : https://patchwork.freedesktop.org/series/99708/ State : success == Summary == CI Bug Log - changes from CI_DRM_11189 -> Patchwork_22180 ==

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/guc: Refactor ADS access to use iosys_map

== Series Details == Series: drm/i915/guc: Refactor ADS access to use iosys_map URL : https://patchwork.freedesktop.org/series/99711/ State : warning == Summary == $ dim checkpatch origin/drm-tip 28297417eba4 dma-buf-map: Rename to iosys-map -:237: WARNING:AVOID_BUG: Avoid crashing the kernel

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/guc: Refactor ADS access to use iosys_map

== Series Details == Series: drm/i915/guc: Refactor ADS access to use iosys_map URL : https://patchwork.freedesktop.org/series/99711/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

Re: [Intel-gfx] [PATCH 02/19] iosys-map: Add offset to iosys_map_memcpy_to()

Hi Am 04.02.22 um 18:44 schrieb Lucas De Marchi: In certain situations it's useful to be able to write to an offset of the mapping. Add a dst_offset to iosys_map_memcpy_to(). Cc: Sumit Semwal Cc: Christian König Cc: Thomas Zimmermann Cc: dri-de...@lists.freedesktop.org Cc: linux-ker...@vger.

Re: [Intel-gfx] [PATCH v5 09/10] drm/i915/guc: Follow legacy register names

Squash will be much easier if i also squash all the prior register table additions together Should i do that? Squash XeLP + DG2 + Gen9 and this together? On Thu, 2022-02-03 at 11:09 -0800, Matthew Brost wrote: > On Wed, Jan 26, 2022 at 02:48:21AM -0800, Alan Previn wrote: > > Before we print the

[Intel-gfx] ✗ Fi.CI.IGT: failure for Use drm_clflush* instead of clflush (rev4)

== Series Details == Series: Use drm_clflush* instead of clflush (rev4) URL : https://patchwork.freedesktop.org/series/99450/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11189_full -> Patchwork_22178_full Summary ---

Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/uapi: Add query for hwconfig table

On 2/4/2022 01:55, Daniel Vetter wrote: On Wed, Jan 19, 2022 at 9:35 PM wrote: From: Rodrigo Vivi GuC contains a consolidated table with a bunch of information about the current device. Previously, this information was spread and hardcoded to all the components including GuC, i915 and variou

Re: [Intel-gfx] [PATCH 03/19] iosys-map: Add a few more helpers

Hi Am 04.02.22 um 18:44 schrieb Lucas De Marchi: First the simplest ones: - iosys_map_memset(): when abstracting system and I/O memory, just like the memcpy() use case, memset() also has dedicated functions to be called for using IO memory. - iosys_map_memcpy

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/guc: Refactor ADS access to use iosys_map

== Series Details == Series: drm/i915/guc: Refactor ADS access to use iosys_map URL : https://patchwork.freedesktop.org/series/99711/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11189 -> Patchwork_22181 Summary ---

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/helpers: Make the suballocation manager drm generic.

== Series Details == Series: drm/helpers: Make the suballocation manager drm generic. URL : https://patchwork.freedesktop.org/series/99713/ State : warning == Summary == $ dim checkpatch origin/drm-tip aba5c02e4398 drm: Extract amdgpu_sa.c as a generic suballocation helper -:27: WARNING:FILE_P

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/helpers: Make the suballocation manager drm generic.

== Series Details == Series: drm/helpers: Make the suballocation manager drm generic. URL : https://patchwork.freedesktop.org/series/99713/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +./driv

Re: [Intel-gfx] [PATCH 04/19] drm/i915/gt: Add helper for shmem copy to iosys_map

Hi Am 04.02.22 um 18:44 schrieb Lucas De Marchi: Add a variant of shmem_read() that takes a iosys_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 iosys_map as destina

Re: [Intel-gfx] [PATCH 07/19] drm/i915/guc: Convert golden context init to iosys_map

Hi Am 04.02.22 um 18:44 schrieb Lucas De Marchi: 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: Dan

Re: [Intel-gfx] [PATCH 09/19] drm/i915/guc: Convert engine record to iosys_map

Hi Am 04.02.22 um 18:44 schrieb Lucas De Marchi: Use iosys_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 D

Re: [Intel-gfx] [PATCH 02/19] iosys-map: Add offset to iosys_map_memcpy_to()

On Fri, Feb 04, 2022 at 07:48:10PM +0100, Thomas Zimmermann wrote: Hi Am 04.02.22 um 18:44 schrieb Lucas De Marchi: In certain situations it's useful to be able to write to an offset of the mapping. Add a dst_offset to iosys_map_memcpy_to(). Cc: Sumit Semwal Cc: Christian König Cc: Thomas Zi

Re: [Intel-gfx] [PATCH 13/21] fbcon: move more common code into fb_open()

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 fairly harmless, but who knows. > > Signed-off-by: Daniel Vetter > Cc: D

Re: [Intel-gfx] [RFC PATCH 1/3] drm: Extract amdgpu_sa.c as a generic suballocation helper

Hi Am 04.02.22 um 19:29 schrieb Christian König: Oh, that's on my TODO list for years! Am 04.02.22 um 18:48 schrieb Maarten Lankhorst: Suballocating a buffer object is something that is not driver generic, and is useful for other drivers as well. Signed-off-by: Maarten Lankhorst ---   driver

Re: [Intel-gfx] [PATCH 14/21] fbcon: use lock_fb_info in fbcon_open/release

On Mon, Jan 31, 2022 at 10:05:45PM +0100, Daniel Vetter wrote: > Now we get to the real motiviation, because fbmem.c insists that > that's the right lock for these. > > Ofc fbcon.c has a lot more places where it probably should call > lock_fb_info(). But looking at fbmem.c at least most of these s

Re: [Intel-gfx] [PATCH 03/19] iosys-map: Add a few more helpers

On Fri, Feb 04, 2022 at 08:05:56PM +0100, Thomas Zimmermann wrote: Hi Am 04.02.22 um 18:44 schrieb Lucas De Marchi: First the simplest ones: - iosys_map_memset(): when abstracting system and I/O memory, just like the memcpy() use case, memset() also has dedicated fu

Re: [Intel-gfx] [PATCH 15/21] fbcon: Consistently protect deferred_takeover with console_lock()

On Mon, Jan 31, 2022 at 10:05:46PM +0100, Daniel Vetter wrote: > This shouldn't be a problem in practice since until we've actually > taken over the console there's nothing we've registered with the > console/vt subsystem, so the exit/unbind path that check this can't > do the wrong thing. But it's

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/helpers: Make the suballocation manager drm generic.

== Series Details == Series: drm/helpers: Make the suballocation manager drm generic. URL : https://patchwork.freedesktop.org/series/99713/ State : success == Summary == CI Bug Log - changes from CI_DRM_11189 -> Patchwork_22182 Summary

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Disable runtime pm wakeref tracking for the mock device

== Series Details == Series: drm/i915/selftests: Disable runtime pm wakeref tracking for the mock device URL : https://patchwork.freedesktop.org/series/99708/ State : success == Summary == CI Bug Log - changes from CI_DRM_11189_full -> Patchwork_22180_full

Re: [Intel-gfx] [PATCH 16/21] fbcon: Move console_lock for register/unlink/unregister

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 at least the register/unregister code is there now. > > With this the do_

Re: [Intel-gfx] [PATCH 17/21] fbcon: Move more code into fbcon_release

On Mon, Jan 31, 2022 at 10:05:48PM +0100, Daniel Vetter wrote: > con2fb_release_oldinfo() has a bunch more kfree() calls than > fbcon_exit(), but since kfree() on NULL is harmless doing that in both > places should be ok. This is also a bit more symmetric now again with > fbcon_open also allocating

Re: [Intel-gfx] [PATCH 18/21] fbcon: untangle fbcon_exit

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 symmetric with fb_console_init() > - We also need to make sure we don't race wi

Re: [Intel-gfx] [PATCH 19/21] fbcon: Maintain a private array of fb_info

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 console_lock() (like everything else in fbcon.c). That copy is > serialized

  1   2   >