On 2018-03-12 03:37 PM, Daniel Vetter wrote:
> On Mon, Mar 12, 2018 at 7:17 PM, Felix Kuehling
> wrote:
>> 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
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
I must have added that accidentally when cherry-picking an internal
patch for upstreaming. Thanks for catching it.
Reviewed-by: Felix Kuehling
Regards,
Felix
On 2017-08-23 09:17 AM, Colin King wrote:
> From: Colin Ian King
>
> Remove a redundant identical return statement, it h
_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 tha
in them should probably do a proper review. They
are Acked-by: Felix Kuehling
The rest of the series is Reviewed-by: Felix Kuehling
As a possible follow up, I think ttm_vm_bo.c would need more work to do
proper huge-page mappings for CPU access.
Regards,
Felix
On 2017-09-22 08:13 AM, Christ
gd_dev *kgd, uint32_t pipe_id);
> e28740ece Oded Gabbay 2014-07-15 115 static int kgd_hqd_load(struct
> kgd_dev *kgd, void *mqd, uint32_t pipe_id,
> 3d1e75101 Jay Cornwall2016-10-24 116 uint32_t
> queue_id, uint32_t __user *wptr,
> 3d1e75
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:
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
---
drivers/gpu/drm/ttm/ttm_bo.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drive
Check page_flags instead of swap_storage
Signed-off-by: Felix Kuehling
---
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/gpu/drm/ttm/ttm_bo.c
+++ b/dr
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 swappin
Looks good. This change is Reviewed-by: Felix Kuehling
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.
>
> Signed-off-by: Gust
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?
>>
>> Ye
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 100644
> --- a/drivers/gp
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 8cf89da7030d..4e85c32fea26 100
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
> b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
>
The series is Reviewed-by: Felix Kuehling
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 either coding style fixes or
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
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 66 -
include/drm/ttm/ttm_bo_driver.h | 12
2
Allows gdb to access contents of user mode mapped VRAM BOs.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 59 +
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 2 ++
2 files changed, 61 insertions(+)
diff --git a/drivers/gpu/drm/amd
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
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
>> ---
>> drivers/gpu
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
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
* document callback return value
* WARN_ON -> WARN_ON_ONCE
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 79 -
include/drm/ttm/ttm_bo_driver.h | 17 +
2 files changed, 95 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/
Allows gdb to access contents of user mode mapped VRAM BOs.
v2: return error for non-VRAM pools
Signed-off-by: Felix Kuehling
Reviewed-by: Michel Dänzer
Acked-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 62 +
1 file changed, 62 insertions
m GEM 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_disp
v2: Use the new helper in drm_gem_prime_import
Signed-off-by: Felix Kuehling
Reviewed-by: Christian König
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_prime.c | 43 +--
include/drm/drmP.h | 2 ++
2 files changed, 35 insertions(+), 10
From: Christian König
Signed-off-by: Christian König
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 44ec11d
From: Christian König
We should be able to handle BOs from other instances as well.
v2:
* Add a module option that is off-by-default
* Use new DRM helper function to check the exporting driver
Signed-off-by: Christian König
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu
in (1):
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 Kuehli
From: Christian König
This allows us to have multiple GEM objects for one BO.
Signed-off-by: Christian König
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 12 +++--
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 41 +++---
drivers/gpu
From: Amber Lin
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
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 17 +
1 file changed, 13 insertions(+), 4 deletions
From: Christian König
Pinning them in other devices VRAM would obviously not work.
v2: Add checks to DC code paths
Signed-off-by: Christian König
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 ++
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
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.p2
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
ue stuff 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,
n 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
>> the queue size. The EOP buffer is a separate buffer used by the firmware
>> to handle command complet
queue. 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:
&
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?
B execution is finished.
Regards,
Felix
>
> 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
This commit is Reviewed-by: Felix Kuehling
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 warning:
>
> drivers/gpu
Hi Gustavo,
Thanks for catching that. When returning a fault, I think you also need
to srcu_read_unlock(&kfd_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 s
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 :
>
>> Hi Gustavo,
>>
>> Thanks for catching that. When returning a fault, I think you also need
>> to srcu_
On 2024-01-07 08:07, Dafna Hirschfeld wrote:
Fix err return value and reset pgmap->type after checking it.
Fixes: c83dee9b6394 ("drm/amdkfd: add SPM support for SVM")
Reviewed-by: Felix Kuehling
Signed-off-by: Dafna Hirschfeld
---
v2: remove unrelated DOC fix and add 'F
t could be generalized later if there is interest then.
Regards,
Felix
On 2023-12-06 16:23, Felix Kuehling wrote:
Executive Summary: We need to add CRIU support to DRM render nodes in
order to maintain CRIU support for ROCm application once they start
relying on render nodes for more GPU memory
ection via ras_ctrl debugfs
Charlene Liu (1):
drm/amd/display: Update z8 latency
Dafna Hirschfeld (1):
drm/amdkfd: fixes for HMM mem allocation
Daniel Miess (1):
Revert "drm/amd/display: Fix conversions between bytes and KB"
Felix Kuehling (4):
drm/amdkfd:
On 2024-01-23 14:37, Zeng, Oak wrote:
Thanks Christian. I have some comment inline below.
Danilo, can you also take a look and give your feedback? Thanks.
Sorry, just catching up with this thread now. I'm also not familiar with
drm_gpuvm.
Some general observations based on my experience wit
On 2024-01-23 5:21, Dan Carpenter wrote:
Hello Felix Kuehling,
The patch 1819200166ce: "drm/amdkfd: Export DMABufs from KFD using
GEM handles" from Aug 24, 2023 (linux-next), leads to the following
Smatch static checker warning:
drivers/dma-buf/dma-buf.c:729 dma_buf_get()
h in reality all those gpuvm shares a same virtual
address space.
See one more comment inline
*From:*Christian König
*Sent:* Wednesday, January 24, 2024 3:33 AM
*To:* Zeng, Oak ; Danilo Krummrich
; Dave Airlie ; Daniel Vetter
; Felix Kuehling
*Cc:* Welty, Brian ;
dri-devel@lists.freedeskto
Executive Summary: We need to add CRIU support to DRM render nodes in
order to maintain CRIU support for ROCm application once they start
relying on render nodes for more GPU memory management. In this email
I'm providing some background why we are doing this, and outlining some
of the problems
On 2023-12-11 04:50, Christian König wrote:
Am 08.12.23 um 20:53 schrieb Alex Deucher:
[SNIP]
You also need a functionality which resets all cleared blocks to
uncleared after suspend/resume.
No idea how to do this, maybe Alex knows of hand.
Since the buffers are cleared on creation, is ther
On 2023-12-13 9:20, Christian König wrote:
Am 12.12.23 um 00:32 schrieb Felix Kuehling:
On 2023-12-11 04:50, Christian König wrote:
Am 08.12.23 um 20:53 schrieb Alex Deucher:
[SNIP]
You also need a functionality which resets all cleared blocks to
uncleared after suspend/resume.
No idea how
On 2023-12-07 13:02, Alex Deucher wrote:
Show buffers as shared if they are shared via dma-buf as well
(e.g., shared with v4l or some other subsystem).
You can add KFD to that list. With the in-progress CUDA11 VM changes and
improved interop between KFD and render nodes, sharing DMABufs betwee
ng to set
the DRM_BUDDY_CLEARED flag.
- Remove ! from amdgpu_res_cleared(&cursor) check.
Signed-off-by: Arunpravin Paneer Selvam
Suggested-by: Christian König
Acked-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 22 ---
.../gpu/drm/amd/amdgpu/amdgpu
/* Disable SVM support capability */
+ pgmap->type = 0;
Ooff, thanks for catching that. For the KFD driver changes you can add
Fixes: c83dee9b6394 ("drm/amdkfd: add SPM support for SVM")
Reviewed-by: Felix Kuehling
return PTR_ERR(r);
elper
and leave the descriptor table alone.
Signed-off-by: Al Viro
This patch looks good to me on the amdgpu side. For the DRM side I'm
adding dri-devel.
Acked-by: Felix Kuehling
---
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_
i Jul 28 12:20:12 2023 -0400
drm/amdkfd: drop IOMMUv2 support
Now that we use the dGPU path for all APUs, drop the
IOMMUv2 support.
v2: drop the now unused queue manager functions for gfx7/8 APUs
Reviewed-by: Felix Kuehling
Acked-by: Christian König
Tested-by:
On 2024-06-05 05:14, Christian König wrote:
Am 04.06.24 um 20:08 schrieb Felix Kuehling:
On 2024-06-03 22:13, Al Viro wrote:
Using drm_gem_prime_handle_to_fd() to set dmabuf up and insert it into
descriptor table, only to have it looked up by file descriptor and
remove it from descriptor
creen 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.
/|_| |
these 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
|__/ \|
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,
>
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
?
I'll ask 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
___
dri-devel mai
creen 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.
/|_| |
these 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
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,
>
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
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
?
I'll ask 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
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 throu
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
realiz
Cc: Philip Yang
Cc: Felix Kuehling
Cc: Christian König
Cc: Andrew Morton
Suggessted-by: Simona Vetter
Signed-off-by: Matthew Brost
---
mm/memory.c | 13 +++---
mm/migrate_device.c | 60 +++--
2 files changed, 50 insertions(+), 23 deleti
On 2024-09-20 17:23, Matthew Brost wrote:
On Fri, Sep 20, 2024 at 04:26:50PM -0400, Felix Kuehling wrote:
On 2024-09-18 11:10, Alistair Popple wrote:
Matthew Brost writes:
On Wed, Sep 11, 2024 at 02:53:31PM +1000, Alistair Popple wrote:
Matthew Brost writes:
I haven't seen the sa
801 - 872 of 872 matches
Mail list logo
