Flickering with page-flipping on Acer Iconia W500 (AMD C-50 APU)

refresh. My conclusion is that on this particular hardware the condition that predicts page flip completion must be modified in order to avoid notifying user space of completed page flips prematurely. Regards, Felix -- _Felix Kuehling \ _ | MTS Software Development Eng. /|_| | SW

Re: Flickering with page-flipping on Acer Iconia W500 (AMD C-50 APU)

like that. Thanks for the feedback, Felix thanks, -mario -- _Felix Kuehling \ _ | MTS Software Development Eng. /|_| | SW-Linux Base Gfx | AMD |__/ \| T 905.882.2600 x8928 ___ dri-devel mailing list dri-devel

Re: Flickering with page-flipping on Acer Iconia W500 (AMD C-50 APU)

On 12-02-22 11:20 AM, Felix Kuehling wrote: On 12-02-21 07:49 PM, Mario Kleiner wrote: On 02/21/2012 09:07 PM, Alex Deucher wrote: [snip] The fix looks ok to me. Mario any thoughts? Reviewed-by: Alex Deucheralexdeuc...@gmail.com Hi, the fix looks ok to me for that device, but could we

Re: Flickering with page-flipping on Acer Iconia W500 (AMD C-50 APU)

On 12-02-24 11:38 PM, Mario Kleiner wrote: On Feb 24, 2012, at 10:20 PM, Felix Kuehling wrote: On 12-02-22 11:20 AM, Felix Kuehling wrote: On 12-02-21 07:49 PM, Mario Kleiner wrote: On 02/21/2012 09:07 PM, Alex Deucher wrote: [snip] The fix looks ok to me. Mario any thoughts? Reviewed

Re: Flickering with page-flipping on Acer Iconia W500 (AMD C-50 APU)

, Felix best, -mario -- _Felix Kuehling \ _ | MTS Software Development Eng. /|_| | SW-Linux Base Gfx | AMD |__/ \| T 905.882.2600 x8928 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org

Enabling peer to peer device transactions for PCIe devices

On 16-11-25 03:40 PM, Christian König wrote: > Am 25.11.2016 um 20:32 schrieb Jason Gunthorpe: >> This assumes the commands are fairly short lived of course, the >> expectation of the mmu notifiers is that a flush is reasonably prompt > > Correct, this is another problem. GFX command submissions

Enabling peer to peer device transactions for PCIe devices

On 16-11-25 12:20 PM, Serguei Sagalovitch wrote: > >> A white list may end up being rather complicated if it has to cover >> different CPU generations and system architectures. I feel this is a >> decision user space could easily make. >> >> Logan > I agreed that it is better to leave up to user

[PATCH 01/12] drm/amdgpu: add amd_gnb_bus support

Hi, To elaborate more on Alex's explanation ... AMD SOCs have audio (and in the future potentially also camera image signal processors) IPs built into the GNB (graphics north bridge). These IPs are programmed through MMIO registers in the graphics MMIO aperture. They send events to the host

[PATCH 01/12] drm/amdgpu: add amd_gnb_bus support

On 15-08-07 02:24 PM, Mark Brown wrote: > Like I say this just sounds like exactly the sort of thing we handle > with an MFD, it's a very common pattern. OK, the MFD documentation in Documentation/devicetree/bindings/mfd/ seemed to imply a dependency on a devicetree. It took me a moment to

[PATCH] drm/ttm: Fix TTM BO accounting

n 16-04-12 12:21 PM, Thomas Hellstrom wrote: > On 04/12/2016 05:57 PM, Alex Deucher wrote: >> From: Felix Kuehling >> >> TTM BO accounting is out of sync with how memory is really allocated >> in ttm[_dma]_tt_alloc_page_directory. This resulted in excessive >

Flickering with page-flipping on Acer Iconia W500 (AMD C-50 APU)

refresh. My conclusion is that on this particular hardware the condition that predicts page flip completion must be modified in order to avoid notifying user space of completed page flips prematurely. Regards, Felix -- _Felix Kuehling \ _ | MTS Software Development Eng. /|_| | SW

Flickering with page-flipping on Acer Iconia W500 (AMD C-50 APU)

kind of devices? From Felix > description is sounds as if it is only 2 scanlines? It looks like that. Thanks for the feedback, Felix > > thanks, > -mario > -- _Felix Kuehling \ _ | MTS Software Development Eng. /|_| | SW-Linux Base Gfx | AMD |__/ \| T 905.882.2600 x8928

Flickering with page-flipping on Acer Iconia W500 (AMD C-50 APU)

On 12-02-22 11:20 AM, Felix Kuehling wrote: > On 12-02-21 07:49 PM, Mario Kleiner wrote: >> On 02/21/2012 09:07 PM, Alex Deucher wrote: > [snip] >>> The fix looks ok to me. Mario any thoughts? >>> >>> Reviewed-by: Alex Deucher >>> >> Hi, >

[PATCH] Fix deferred page-flip detection logic on Avivo-based ASICs

before the start of the next frame. Therefore I left the behaviour unchanged for pre-AVIVO ASICs for performance reasons, although this may result in flickering in rare cases. This change also makes the logic a little easier to understand. Signed-off-by: Felix Kuehling --- drivers/gpu/drm/radeon

Flickering with page-flipping on Acer Iconia W500 (AMD C-50 APU)

On 12-02-24 11:38 PM, Mario Kleiner wrote: > On Feb 24, 2012, at 10:20 PM, Felix Kuehling wrote: > >> On 12-02-22 11:20 AM, Felix Kuehling wrote: >>> On 12-02-21 07:49 PM, Mario Kleiner wrote: >>>> On 02/21/2012 09:07 PM, Alex Deucher wrote: >>> [snip

Flickering with page-flipping on Acer Iconia W500 (AMD C-50 APU)

k our display team for advice. Regards, Felix > > best, > -mario > > -- _Felix Kuehling \ _ | MTS Software Development Eng. /|_| | SW-Linux Base Gfx | AMD |__/ \| T 905.882.2600 x8928

[PATCH 4/6] drm/amdgpu: separate BO from GEM object

From: Christian König <christian.koe...@amd.com> This allows us to have multiple GEM objects for one BO. Signed-off-by: Christian König <christian.koe...@amd.com> Reviewed-by: Felix Kuehling <felix.kuehl...@amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu.h| 12 +++-

[PATCH 5/6] drm/amdgpu: handle foreign BOs in the VM mapping

From: Amber Lin <amber@amd.com> Set the system bit for foreign BO mappings and use the remote VRAM BAR address as the VRAM base offset. Signed-off-by: Amber Lin <amber@amd.com> Reviewed-by: Felix Kuehling <felix.kuehl...@amd.com> --- drivers/gpu/drm/amd/amdgp

[PATCH 6/6] drm/amdgpu: enable foreign DMA-buf objects v2

; Signed-off-by: Felix Kuehling <felix.kuehl...@amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 4 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 6 +++- drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 60 +++ 3 files changed, 69 insertions(+), 1 deletion(-) di

[PATCH 2/6] drm/amdgpu: disallow foreign BOs for CS w/o GPUVM mapping

From: Christian König <christian.koe...@amd.com> Signed-off-by: Christian König <christian.koe...@amd.com> Reviewed-by: Felix Kuehling <felix.kuehl...@amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/d

[PATCH 0/6] Experimental P2P buffer sharing v2

): drm/amdgpu: handle foreign BOs in the VM mapping Christian König (4): drm/amdgpu: disallow foreign BOs for CS w/o GPUVM mapping drm/amdgpu: disallow foreign BOs in the display path v2 drm/amdgpu: separate BO from GEM object drm/amdgpu: enable foreign DMA-buf objects v2 Felix Kuehling (1

[PATCH 1/6] drm: Add helper to cast DMA-buf to GEM object

Signed-off-by: Felix Kuehling <felix.kuehl...@amd.com> --- drivers/gpu/drm/drm_prime.c | 25 + include/drm/drmP.h | 2 ++ 2 files changed, 27 insertions(+) diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 25aa455..b1f8445

[PATCH 3/6] drm/amdgpu: disallow foreign BOs in the display path v2

From: Christian König <christian.koe...@amd.com> Pinning them in other devices VRAM would obviously not work. v2: Add checks to DC code paths Signed-off-by: Christian König <christian.koe...@amd.com> Signed-off-by: Felix Kuehling <felix.kuehl...@amd.com> --- drivers/

[PATCH 1/2] drm: Implement vm_operations_struct.access

Allows gdb to access contents of user mode mapped BOs. VRAM access requires the driver to implement a new callback in ttm_bo_driver. Signed-off-by: Felix Kuehling <felix.kuehl...@amd.com> --- drivers/gpu/drm/ttm/ttm_bo_vm.c | 66 - include/d

[PATCH 2/2] drm/amdgpu: Implement ttm_bo_driver.access_vram callback

Allows gdb to access contents of user mode mapped VRAM BOs. Signed-off-by: Felix Kuehling <felix.kuehl...@amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 59 + drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 2 ++ 2 files changed, 61 insertions(+) diff

Re: [PATCH 2/2] drm/amdgpu: Implement ttm_bo_driver.access_vram callback

On 17-07-13 05:08 PM, Felix Kuehling wrote: > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h > @@ -78,6 +78,8 @@ int amdgpu_fill_buffer(struct amdgpu_bo *bo, > struct dma_fence **fence); > > int amdgpu_mmap

[PATCH 1/6] drm: Add helper to check exporting driver of a DMA-buf

This allows drivers to check if a DMA-buf contains a GEM object and whether it comes from the same driver. It may be from the same or a different device. Signed-off-by: Felix Kuehling <felix.kuehl...@amd.com> --- drivers/gpu/drm/drm_prime.c | 24 include/drm/

Re: [PATCH 01/12] drm/amdgpu: implement vm_operations_struct.access

On 17-07-12 04:01 AM, Michel Dänzer wrote: > On 12/07/17 02:37 PM, Felix Kuehling wrote: >> Any comments on this one? >> >> This was requested by the HSA runtime team a long time ago as a >> debugging feature. It allows gdb to access the content of CPU-mapped >>

Re: [PATCH 1/2] drm: Implement vm_operations_struct.access

On 17-07-13 11:26 PM, Michel Dänzer wrote: > On 14/07/17 06:08 AM, Felix Kuehling wrote: >> Allows gdb to access contents of user mode mapped BOs. VRAM access >> requires the driver to implement a new callback in ttm_bo_driver. > Thanks for doing this. Looks mostly good, but

Re: [PATCH 2/2] drm/amdgpu: Implement ttm_bo_driver.access_vram callback

On 17-07-14 06:08 AM, Christian König wrote: > Am 13.07.2017 um 23:08 schrieb Felix Kuehling: >> Allows gdb to access contents of user mode mapped VRAM BOs. >> >> Signed-off-by: Felix Kuehling <felix.kuehl...@amd.com> >> --- >> drive

Re: [PATCH 1/2] drm: Implement vm_operations_struct.access

On 17-07-14 06:06 AM, Christian König wrote: > Am 13.07.2017 um 23:08 schrieb Felix Kuehling: >> Allows gdb to access contents of user mode mapped BOs. VRAM access >> requires the driver to implement a new callback in ttm_bo_driver. > > One more comment additionally to what

[PATCH 2/2] drm/amdgpu: Implement ttm_bo_driver.access_memory callback v2

Allows gdb to access contents of user mode mapped VRAM BOs. v2: return error for non-VRAM pools Signed-off-by: Felix Kuehling <felix.kuehl...@amd.com> Reviewed-by: Michel Dänzer <michel.daen...@amd.com> Acked-by: Christian König <christian.koe...@amd.com> --- drivers/

[PATCH 1/2] drm/ttm: Implement vm_operations_struct.access v2

* document callback return value * WARN_ON -> WARN_ON_ONCE Signed-off-by: Felix Kuehling <felix.kuehl...@amd.com> --- drivers/gpu/drm/ttm/ttm_bo_vm.c | 79 - include/drm/ttm/ttm_bo_driver.h | 17 + 2 files changed, 95 insertions(+), 1 deletion

[PATCH 5/6] drm/amdgpu: handle foreign BOs in the VM mapping

From: Amber Lin <amber@amd.com> Set the system bit for foreign BO mappings and use the remote VRAM BAR address as the VRAM base offset. Signed-off-by: Amber Lin <amber@amd.com> Reviewed-by: Felix Kuehling <felix.kuehl...@amd.com> --- drivers/gpu/drm/amd/amdgp

[PATCH 3/6] drm/amdgpu: disallow foreign BOs in the display path v2

From: Christian König <christian.koe...@amd.com> Pinning them in other devices VRAM would obviously not work. v2: Add checks to DC code paths Signed-off-by: Christian König <christian.koe...@amd.com> Signed-off-by: Felix Kuehling <felix.kuehl...@amd.com> --- drivers/

[PATCH 0/6] Experimental P2P buffer sharing v2

): drm/amdgpu: handle foreign BOs in the VM mapping Christian König (4): drm/amdgpu: disallow foreign BOs for CS w/o GPUVM mapping drm/amdgpu: disallow foreign BOs in the display path v2 drm/amdgpu: separate BO from GEM object drm/amdgpu: enable foreign DMA-buf objects v2 Felix Kuehling (1

[PATCH 4/6] drm/amdgpu: separate BO from GEM object

From: Christian König <christian.koe...@amd.com> This allows us to have multiple GEM objects for one BO. Signed-off-by: Christian König <christian.koe...@amd.com> Reviewed-by: Felix Kuehling <felix.kuehl...@amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu.h| 12 +++-

Re: [PATCH 0/6] Experimental P2P buffer sharing v2

Sorry for the spam. The second (old) cover letter was sent by mistake. Please look at v3. Regards, Felix On 17-07-18 10:22 PM, Felix Kuehling wrote: > This patch series adds experimental P2P buffer sharing in amdgpu. It's > disabled by default and can be enabled with amdgpu.p2p_sha

[PATCH 6/6] drm/amdgpu: enable foreign DMA-buf objects v2

; Signed-off-by: Felix Kuehling <felix.kuehl...@amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 4 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 6 +++- drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 60 +++ 3 files changed, 69 insertions(+), 1 deletion(-) di

[PATCH 1/6] drm: Add helper to cast DMA-buf to GEM object v2

v2: Use the new helper in drm_gem_prime_import Signed-off-by: Felix Kuehling <felix.kuehl...@amd.com> Reviewed-by: Christian König <christian.koe...@amd.com> Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch> --- drivers/gpu/dr

[PATCH 2/6] drm/amdgpu: disallow foreign BOs for CS w/o GPUVM mapping

From: Christian König <christian.koe...@amd.com> Signed-off-by: Christian König <christian.koe...@amd.com> Reviewed-by: Felix Kuehling <felix.kuehl...@amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/d

[PATCH 0/6] Experimental P2P buffer sharing v3

object drm/amdgpu: enable foreign DMA-buf objects v2 Felix Kuehling (1): drm: Add helper to cast DMA-buf to GEM object v2 drivers/gpu/drm/amd/amdgpu/amdgpu.h| 16 - drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c

Re: [PATCH 1/6] drm: Add helper to cast DMA-buf to GEM object

Hi Daniel, On 17-07-12 04:11 AM, Daniel Vetter wrote: > On Wed, Jul 12, 2017 at 01:29:22AM -0400, Felix Kuehling wrote: >> Signed-off-by: Felix Kuehling <felix.kuehl...@amd.com> >> --- >> drivers/gpu/drm/drm_prime.c | 25 + >> include/

[PATCH 1/1] drm/amdgpu: implement vm_operations_struct.access v2

Allows gdb to access contents of user mode mapped BOs. v2: * Add range check * Map only the pages we're accessing rather than the entire BO Signed-off-by: Felix Kuehling <felix.kuehl...@amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 138 +++- drivers/g

Re: [PATCH 0/9] Visible VRAM Management Improvements

Hi John, I haven't read your patches. Just a question based on the cover letter. I understand that visible VRAM is the biggest pain point. But could the same reasoning make sense for invisible VRAM? That is, doing all the migrations to VRAM in a workqueue? Regards, Felix On 17-06-23 01:39

Re: [PATCH] drm/amdkfd: NULL dereference involving create_process()

Yeah, I saw this earlier. I'm on the amd-gfx list. The patch looks good to me. Feel free to add my R-b. Do you want to apply it to amd-staging-4.11 and drm-next? I can take care of amd-kfd-staging and the release branches. Thanks, Felix On 17-06-14 12:41 PM, Deucher, Alexander wrote: > >

Re: [PATCH 1/9] drm/ttm: remove unsued options from ttm_mem_global_alloc_page

probably do a proper review. They are Acked-by: Felix Kuehling <felix.kuehl...@amd.com> The rest of the series is Reviewed-by: Felix Kuehling <felix.kuehl...@amd.com> As a possible follow up, I think  ttm_vm_bo.c would need more work to do proper huge-page mappings for CPU access. Rega

Re: [radeon-alex:amd-staging-drm-next 1046/1053] drivers/gpu//drm/amd/lib/../include/linux/chash.h:286:50: error: '_BITOPS_LONG_SHIFT' undeclared

_BITOPS_LONG_SHIFT seems to be x86-specific. I'll get rid of it. I'm also looking into a separate problem with 64-bit divisions. I've reproduced that with a 32-bit build. As I understand it, u64 / u64 should be OK, but for some reason it's doing a signed division somewhere. I'm trying to track

Re: [PATCH][drm-next] drm/amdgpu: remove duplicate return statement

I must have added that accidentally when cherry-picking an internal patch for upstreaming. Thanks for catching it. Reviewed-by: Felix Kuehling <felix.kuehl...@amd.com> Regards, Felix On 2017-08-23 09:17 AM, Colin King wrote: > From: Colin Ian King <colin.k...@canonical.com

Re: [PATCH 1/1] drm/amdkfd: Do not ignore requested queue size during allocation

:43 PM, Jan Vesely wrote: > On Mon, 2017-11-20 at 14:22 -0500, Felix Kuehling wrote: >> I think this patch is not correct. The EOP-mem is not associated with >> the queue size. The EOP buffer is a separate buffer used by the firmware >> to handle command completion. As I under

Re: [PATCH 1/1] drm/amdkfd: Do not ignore requested queue size during allocation

ix > > thanks, > Jan > >> Regards, >> Felix >> >> >> On 2017-11-29 04:43 PM, Jan Vesely wrote: >>> On Mon, 2017-11-20 at 14:22 -0500, Felix Kuehling wrote: >>>> I think this patch is not correct. The EOP-mem is not associated with >>

Re: [PATCH 1/1] drm/amdkfd: Do not ignore requested queue size during allocation

is not advancing. Regards,   Felix On 2017-11-30 06:51 PM, Jan Vesely wrote: > On Wed, 2017-11-29 at 16:58 -0500, Felix Kuehling wrote: >> You can see the state of the queues in debugfs: >> /sys/kernel/debug/kfd/... You can look at MQDs and HQDs. > thanks. how do I decode the information?

Re: [PATCH 1/1] drm/amdkfd: Do not ignore requested queue size during allocation

I think this patch is not correct. The EOP-mem is not associated with the queue size. The EOP buffer is a separate buffer used by the firmware to handle command completion. As I understand it, this allows more concurrency, while still making it look like all commands in the queue are completing in

Re: [PATCH 1/1] drm/amdkfd: Do not ignore requested queue size during allocation

uff could be cleaned up a bit in general. IMO the hardware-independent functions don't really need to be called through function pointers. The ASIC-specific function pointers don't need to be in the kernel_queue structure, they could be in kfd_dev. Regards,   Felix > > On Mon, Nov 20, 2017 at

Re: [gabbayo:amdkfd-next 5/8] drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c:540:3: error: dereferencing pointer to incomplete type 'struct cik_sdma_rlc_registers'

I messed up while rebasing patches and didn't test every intermediate patch as I should have. The next patch in the series fixes this. If anyone wants to fix this before merging further upstream, remove the offending line in this commit and reintroduce it in the next commit in the series. At this

Re: [PATCH 1/3] drm/amdgpu/display: provide ASSERT macros unconditionally

On 2017-11-02 07:26 AM, Arnd Bergmann wrote: > It seems impossible to build this driver without setting either > CONFIG_DEBUG_KERNEL or CONFIG_DEBUG_DRIVER: > > drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h: In function > 'set_reg_field_value_ex': >

Re: [PATCH 1/1] drm/amdkfd: Do not ignore requested queue size during allocation

. It mostly gets updated when queues are unmapped. So you would need to correlate the MQD of the queue you're interested in with an HQD to see the current HW state. Regards,   Felix On 2017-11-30 06:51 PM, Jan Vesely wrote: > On Wed, 2017-11-29 at 16:58 -0500, Felix Kuehling wrote: >> Yo

Re: [gabbayo:amdkfd-next 6/28] drivers/gpu//drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c:632:3: error: implicit declaration of function 'release_pages'; did you mean 'release_task'?

We need to #include . On 2018-05-15 09:44 AM, kbuild test robot wrote: > tree: git://people.freedesktop.org/~gabbayo/linux amdkfd-next > head: 8feaccf71dd61f2201493068055e0d1d699014df > commit: 5ae0283e831a94c714fce61063e4724baf364ef3 [6/28] drm/amdgpu: Add > userptr support for KFD >

Re: [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

On 2018-06-22 11:24 AM, Michal Hocko wrote: > On Fri 22-06-18 17:13:02, Christian König wrote: >> Hi Michal, >> >> [Adding Felix as well] >> >> Well first of all you have a misconception why at least the AMD graphics >> driver need to be able to sleep in an MMU notifier: We need to sleep because

Re: [PATCH] drm/amdkfd: Fix potential NULL pointer dereferences

Hi Gustavo, Thanks for catching that. When returning a fault, I think you also need to srcu_read_unlock(_processes_srcu, idx). However, instead of returning an error, I think I'd prefer to skip PDDs that can't be found with continue statements. That way others would still suspend and resume

Re: [PATCH] drm/amdkfd: Fix potential NULL pointer dereferences

Yeah, this looks good to me. Regards,   Felix On 2018-01-10 04:58 PM, Gustavo A. R. Silva wrote: > Hi Felix, > > Quoting Felix Kuehling <felix.kuehl...@amd.com>: > >> Hi Gustavo, >> >> Thanks for catching that. When returning a fault, I think you also need &g

Re: [PATCH] drm/amdgpu: use %pap format string for phys_addr_t

This commit is Reviewed-by: Felix Kuehling <felix.kuehl...@amd.com> Thanks,   Felix On 2018-01-08 07:53 AM, Arnd Bergmann wrote: > The newly added get_local_mem_info() function prints a phys_addr_t > using 0x%llx, which is wrong on most 32-bit systems, as shown by > this warni

[PATCH 2/2] drm/ttm: Don't unreserve swapped BOs that were previously reserved

If ttm_bo_swapout doesn't own the lock, don't release it. Someone else probably depends on it still being locked. Signed-off-by: Felix Kuehling <felix.kuehl...@amd.com> --- drivers/gpu/drm/ttm/ttm_bo.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/d

[PATCH 1/2] drm/ttm: Don't add swapped BOs to swap-LRU list

page_flags instead of swap_storage Signed-off-by: Felix Kuehling <felix.kuehl...@amd.com> --- drivers/gpu/drm/ttm/ttm_bo.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index 2eb71ff..62518b6 100644 --- a/drivers/g

Re: [PATCH] drm/amdkfd: Use ARRAY_SIZE macro in kfd_build_sysfs_node_entry

Looks good. This change is Reviewed-by: Felix Kuehling <felix.kuehl...@amd.com> Regards,   Felix On 2018-01-18 07:39 PM, Gustavo A. R. Silva wrote: > Use ARRAY_SIZE instead of dividing sizeof array with sizeof an element. > > This issue was detected with the help of Coccinelle.

Re: [PATCH 1/2] drm/ttm: Don't add swapped BOs to swap-LRU list

On 2018-01-18 01:09 PM, Christian König wrote: > Am 18.01.2018 um 17:56 schrieb Felix Kuehling: >> A BO that's already swapped would be added back to the swap-LRU list >> for example if its validation failed under high memory pressure. This >> could later lead to swapping it

Re: 'buf' pointer in ttm_bo_vm_access_kmap()

On 2018-01-26 09:40 AM, Tom St Denis wrote: > On 26/01/18 09:38 AM, Christian König wrote: >> Am 26.01.2018 um 15:31 schrieb Tom St Denis: >>> Hi all, >>> >>> In the function ttm_bo_vm_access_kmap() it doesn't seem to me like >>> the 'buf' pointer is incremented.  That seems like a bug no? >> >>

Re: [PATCH 11/12] drm/ttm: Fix 'buf' pointer update in ttm_bo_vm_access_kmap()

On 2018-01-26 01:29 PM, Tom St Denis wrote: > Signed-off-by: Tom St Denis > --- > drivers/gpu/drm/ttm/ttm_bo_vm.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c > index 07b22f04b969..6311f8a481ea

Re: [PATCH 02/12] drm/ttm: Add a default BO destructor to simplify code

On 2018-01-26 01:29 PM, Tom St Denis wrote: > Signed-off-by: Tom St Denis > --- > drivers/gpu/drm/ttm/ttm_bo.c | 14 +- > 1 file changed, 9 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c > index

Re: [PATCH 07/12] drm/ttm: Simplify ttm_dma_find_pool()

On 2018-01-26 01:29 PM, Tom St Denis wrote: > Signed-off-by: Tom St Denis > --- > drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 12 +--- > 1 file changed, 5 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c >

[PATCH] drm/ttm: Don't add swapped BOs to swap-LRU list

A BO that's already swapped would be added back to the swap-LRU list for example if it validation failed under high memory pressure. This could later lead to swapping it out again and leaking previous swap storage. This commit adds a condition to prevent that from happening. Signed-off-by: Felix

Re: Various TTM cleanups (v2)

The series is Reviewed-by: Felix Kuehling <felix.kuehl...@amd.com> Regards,   Felix On 2018-01-29 08:55 AM, Tom St Denis wrote: > Various TTM cleanups (mostly no functional changes). > > Notably patch #1 fixes a bug in the access_kmap() function. > > The rest are eith

Re: [radeon-alex:amd-staging-dkms-4.13 3810/3830] drivers/gpu/drm/radeon/radeon_kfd.c:166:3: error: 'const struct kfd2kgd_calls' has no member named 'open_graphic_handle'

_dev *kgd, void *mqd, uint32_t pipe_id, > 3d1e75101 Jay Cornwall2016-10-24 116 uint32_t > queue_id, uint32_t __user *wptr, > 3d1e75101 Jay Cornwall2016-10-24 117 uint32_t > wptr_shift, uint32_t wptr_mask, > 3d1e75101 Ja

Re: Possible use_mm() mis-uses

Ok? >> >> Note that the lifetime rules are very important, because obviously >> use_mm() itself is never called in the context of the process that has >> the mm. By definition, we're in a kernel thread and it uses somebody >> elses mm. So it's important to show that that "

Proposal to merge KFD into amdgpu

Since KFD is only supported by a single GPU driver now (amdgpu), it makes sense to merge the two. This has been raised on the amd-gfx list before and I've been putting it off to avoid more churn while I was working on upstreaming KFD. Now seems a good time to pick this up again. At this stage

Re: New KFD ioctls: taking the skeletons out of the closet

Thanks for the feedback. I'm answering some of your questions inline. On 2018-03-06 06:09 PM, Dave Airlie wrote: > On 7 March 2018 at 08:44, Felix Kuehling <felix.kuehl...@amd.com> wrote: >> Hi all, >> >> Christian raised two potential issues in a recent KFD

Re: [PATCH 6/6] drm/amdgpu: explicit give BO type to amdgpu_bo_create

NAK. For KFD we need the ability to create a BO from an SG list that doesn't come from another BO. We use this for mapping pages from the doorbell aperture into GPUVM for GPU self-dispatch. If you remove this now, I'll need to add it back in some form in a month or two when I get to that part of

New KFD ioctls: taking the skeletons out of the closet

Hi all, Christian raised two potential issues in a recent KFD upstreaming code review that are related to the KFD ioctl APIs: 1. behaviour of -ERESTARTSYS 2. transactional nature of KFD ioctl definitions, or lack thereof I appreciate constructive feedback, but I also want to encourage an

Re: New KFD ioctls: taking the skeletons out of the closet

On 2018-03-07 03:34 PM, Felix Kuehling wrote: >> Again stop worrying about ioctl overhead, this isn't Windows. If you >> can show the overhead as being a problem then address it, but I >> think it's premature worrying about it at this stage. > I'd like syscall overhead to be s

Re: [RFC PATCH 00/13] SVM (share virtual memory) with HMM in nouveau

On 2018-03-10 10:01 AM, Christian König wrote: >> To accomodate those we need to >> create a "hole" inside the process address space. This patchset have >> a hack for that (patch 13 HACK FOR HMM AREA), it reserves a range of >> device file offset so that process can mmap this range with PROT_NONE

Re: New KFD ioctls: taking the skeletons out of the closet

On 2018-03-12 03:37 PM, Daniel Vetter wrote: > On Mon, Mar 12, 2018 at 7:17 PM, Felix Kuehling <felix.kuehl...@amd.com> > wrote: >> On 2018-03-07 03:34 PM, Felix Kuehling wrote: >>>> Again stop worrying about ioctl overhead, this isn't Windows. If you >>>>

Re: [RFC PATCH 00/13] SVM (share virtual memory) with HMM in nouveau

On 2018-03-13 10:28 AM, Jerome Glisse wrote: > On Mon, Mar 12, 2018 at 02:28:42PM -0400, Felix Kuehling wrote: >> On 2018-03-10 10:01 AM, Christian König wrote: >>>> To accomodate those we need to >>>> create a "hole" inside the process address space. Thi

Re: [PATCH 6/6] drm/amdgpu: explicit give BO type to amdgpu_bo_create

On 2018-03-07 04:16 AM, Christian König wrote: > Am 06.03.2018 um 22:29 schrieb Felix Kuehling: >> NAK. >> >> For KFD we need the ability to create a BO from an SG list that doesn't >> come from another BO. We use this for mapping pages from the doorbell >>

Re: [PATCH] drm/amdkfd: Remove vla

Thanks Christian for catching that. I'm working on a patch series to upstream Vega10 support, about 95% done. It will add this ASIC info for Vega10: static const struct kfd_device_info vega10_device_info = { .asic_family = CHIP_VEGA10, .max_pasid_bits = 16, .max_no_of_hqd

Re: [PATCHv2] drm/amdkfd: Remove vla

sizeof(uint32_t))]; > + if (dev->device_info->ih_ring_entry_size > (8 * sizeof(uint32_t))) { > + dev_err(kfd_chardev(), "Ring entry too small\n"); When the ring entry size really is too small, this will potentially flood the kernel log. Maybe a

Re: [PATCH] drm: Print unadorned pointers

On 2018-04-18 05:24 AM, Alexey Brodkin wrote: > After commit ad67b74 ("printk: hash addresses printed with %p") > pointers are being hashed when printed. However, this makes > debug output completely useless. Switch to %px in order to see the > unadorned kernel pointers. My understanding of the

Re: AMD graphics performance regression in 4.15 and later

[+Philip] On 2018-04-20 10:47 AM, Michel Dänzer wrote: > On 2018-04-11 11:37 AM, Christian König wrote: >> Am 11.04.2018 um 06:00 schrieb Gabriel C: >>> 2018-04-09 11:42 GMT+02:00 Christian König >>> : Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin: > Hi

Re: [PATCH] amdkfd: always select MMU_NOTIFIER

same patch [1] and its still required. > > Cheers, > Anders > [1] https://patchwork.kernel.org/patch/10340885/ Yes, looks good. I think this probably broke when we relaxed the dependency on iommuv2. Reviewed-by: Felix Kuehling <felix.kuehl...@amd.com> Regards,   Felix > >&

Re: [PATCH] drm/amdkfd: Integer overflows in ioctl

Reviewed-by: Felix Kuehling <felix.kuehl...@amd.com> We could probably add a sanity check for n_devices to avoid user mode causing excessive memory allocations in the kernel. There is no good reason for this to be bigger than the number of GPUs in the system. The maximum number of GPUs sup

Re: [PATCH] drm/amdkfd: fix typing in (*hqd_destroy)

the same. Anyway, this patch is Reviewed-by: Felix Kuehling <felix.kuehl...@amd.com> > --- > drivers/gpu/drm/amd/include/kgd_kfd_interface.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/include/kgd_kfd_interface.h > b/d

Re: [PATCH] drm/amdkfd: Integer overflows in ioctl

On 2018-04-25 05:21 AM, Dan Carpenter wrote: > On Tue, Apr 24, 2018 at 02:58:10PM -0400, Felix Kuehling wrote: >> Reviewed-by: Felix Kuehling <felix.kuehl...@amd.com> >> >> We could probably add a sanity check for n_devices to avoid user mode >> causing excessive

Re: [PATCH -next] drm/amdkfd: Fix the error return code in kfd_ioctl_unmap_memory_from_gpu()

Thanks for catching that. I'd use -ENODEV to match what is done a few lines below for peer_pdd. With that fixed, this patch is Reviewed-by: Felix Kuehling <felix.kuehl...@amd.com> Regards,   Felix On 2018-03-29 10:25 PM, Wei Yongjun wrote: > Passing NULL pointer to PTR_ERR will result

Re: [PATCH -next] drm/amdkfd: Make function kfd_dev_is_large_bar() static

This patch is Reviewed-by: Felix Kuehling <felix.kuehl...@amd.com> On 2018-03-29 10:25 PM, Wei Yongjun wrote: > Fixes the following sparse warning: > > drivers/gpu/drm/amd/amdkfd/kfd_chardev.c:1150:6: warning: > symbol 'kfd_dev_is_large_bar' was not declared. Should it be stat

Re: [PATCH] drm: amd: Use kmemdup instead of duplicating its function

Hi Zhong Jiang, Sorry for the late response. I just saw this while catching up with my backlog after travelling end of September. I applied your patch to amd-staging-drm-next. I only changed the headline slightly to use the "drm/admkfd: " prefix that we commonly use for KFD changes. Regards,  

Re: [PATCH] drm/amdkfd: remove set but not used variable 'top_dev'

-by: Hulk Robot Fixes: 1ae99eab34f9 ("drm/amdkfd: Initialize HSA_CAP_ATS_PRESENT capability in topology codes") Signed-off-by: zhengbin The patch is Reviewed-by: Felix Kuehling I'm applying it to amd-staging-drm-next. Thanks,   Felix --- drivers/gpu/drm/amd/amdkfd/kfd_iommu.c |

Re: [PATCH 2/4] drm/ttm: cleanup ttm_buffer_object_transfer

The subject doesn't match the change. This changes ttm_bo_cleanup_refs, not ttm_buffer_object_transfer. On 2019-11-11 9:58 a.m., Christian König wrote: The function is always called with deleted BOs. While at it cleanup the indentation as well. Signed-off-by: Christian König ---

Re: [PATCH 3/4] drm/ttm: rework BO delayed delete.

, to give a confident R-b. Acked-by: Felix Kuehling --- drivers/gpu/drm/ttm/ttm_bo.c | 215 +- drivers/gpu/drm/ttm/ttm_bo_util.c | 1 - include/drm/ttm/ttm_bo_api.h | 11 +- 3 files changed, 97 insertions(+), 130 deletions(-) diff --git a/drivers/gpu

Re: [PATCH RFC v4 14/16] drm, cgroup: Introduce lgpu as DRM cgroup resource

On 2019-10-11 1:12 p.m., t...@kernel.org wrote: Hello, Daniel. On Wed, Oct 09, 2019 at 06:06:52PM +0200, Daniel Vetter wrote: That's not the point I was making. For cpu cgroups there's a very well defined connection between the cpu bitmasks/numbers in cgroups and the cpu bitmasks you use in

Re: [PATCH -next 023/491] AMD KFD: Use fallthrough;

://lore.kernel.org/lkml/b56602fcf79f849e733e7b521bb0e17895d390fa.1582230379.git@perches.com/ Signed-off-by: Joe Perches Acked-by: Felix Kuehling --- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd

Re: [PATCH V2] amdgpu: optimization-- reduce noneed mutex_lock area

Hi Bernard, Thank you for the patch. Please see some comments inline. Am 2020-04-20 um 10:25 p.m. schrieb Bernard Zhao: > Maybe we could reduce the mutex_lock(>lock)`s protected code area, > and noneed to protect pr_debug. Typo: noneed -> no need > > Signed-off-by: Bernard Zhao > > Changes

  1   2   3   4   5   6   7   8   9   >