Re: [PATCH] drm/amd/amdgpu: Add tracepoint for DMA page mapping

Because this is used by a debug tool, can we use a macro to conditionally compile this feature? On 2017-08-01 10:54 AM, Christian König wrote: Am 01.08.2017 um 16:26 schrieb Tom St Denis: On 01/08/17 10:10 AM, Christian König wrote: You need to cover multiple code path here: 1. The one you

Re: [PATCH] drm/amdgpu: Fix blocking in RCU critical section(v2)

Hi Emil, Sorry for late reply. I was so busy last week and this week. Your logic looks correct, smarter and shorter. I feel relatively more difficult to understand the logic, with two "!" and one "||" in the same if statement. Thanks for the advice always. On 2017-07-20 02:29 PM, Emil

Re: [PATCH] drm/amdgpu: Fix error RCU usage

I am working on v2 while you are point out this. Thanks. On 2017-07-19 10:33 PM, zhoucm1 wrote: On 2017年07月20日 10:27, Alex Xie wrote: In RCU read-side critical sections, blocking or sleeping is prohibited. Reported by: Dave Airlie [ 141.965723] = [

Re: [PATCH] drm/amdgpu: Optimize mutex usage (v3)

Hi Dave, Is it easy to reproduce this backtrace? If it is easy, would you give this patch a try? From 3c83e1f05352f4795ddc2a8c9acca65b4b58ded9 Mon Sep 17 00:00:00 2001 From: Alex Xie Date: Wed, 19 Jul 2017 21:51:56 -0400 Subject: [PATCH] drm/amdgpu: Fix a warning on

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

ing more than one page at once. Regards, Christian. Am 12.07.2017 um 08:26 schrieb axie: Hi Felix, I think you might want to add a boundary check to limit the ptrace access inside the BO. Otherwise there may be a potential security leak allowing others to access the whole memory by using ptr

Re: [PATCH] drm/amdgpu: trace VM flags as 64bits

Reviewed-by: Alex Xie On 2017-07-03 09:25 AM, Christian König wrote: From: Christian König Otherwise the upper bits are lost. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 18

Re: [PATCH] amdgpu: Set cik/si_support to 1 by default if radeon isn't built

Hi Michel, MODULE_PARM_DESC is "used to document arguments that the module can take. It takes two parameters: a variable name and a free form string describing that variable" I think we should avoid changing document when config change. How about changing it to something like the following

Re: [PATCH 1/3] drm/amdgpu: fix a typo

ustrations in life are like that. Marek On Fri, Jun 23, 2017 at 4:23 AM, axie <a...@amd.com> wrote: Hi Marek, So do you agree that spinlock disables CPU preemption, contrary to your original idea? If you have new reason that this patch does not improve, please speak out. Many patches i

Re: [PATCH 1/3] drm/amdgpu: fix a typo

nificantly, and then you do the measurement and it doesn't improve anything. I know the feeling very well. It sucks. The frustration comes from the investment of time and getting no return on the investment. Many frustrations in life are like that. Marek On Fri, Jun 23, 2017 at 4:23 AM, axie <

Re: [PATCH 1/3] drm/amdgpu: fix a typo

inefficiency you had seen e.g. with a CPU profiler? Marek On Thu, Jun 22, 2017 at 8:19 PM, axie <a...@amd.com> wrote: To clarify, local IRQ is disabled by calling raw_local_irq_save(flags); Function __lock_acquire double checks that the local IRQ is really disabled. On 2017-06-22 01:34 PM

Re: [PATCH 1/3] drm/amdgpu: fix a typo

Hi Marek, Spin lock and spin unlock is fast. But it is not so fast compared with atomic, which is a single CPU instruction in x86. 1. spinlock does NOT allow preemption at local CPU. Let us have a look at how spin lock was implemented. static inline void __raw_spin_lock(raw_spinlock_t

Re: [PATCH 2/2] drm/amdgpu: Optimize mutex usage (v2)

On 2017-06-16 01:48 PM, Christian König wrote: Am 16.06.2017 um 07:03 schrieb Alex Xie: Use rw_semaphore instead of mutex for bo_lists. In original function amdgpu_bo_list_get, the waiting for result->lock can be quite long while mutex bo_list_lock was holding. It can make other tasks

Re: [PATCH 1/4] drm/amdgpu: Optimization of critical section

On 2017-06-13 06:23 AM, Christian König wrote: Am 13.06.2017 um 08:29 schrieb axie: On 2017-06-12 07:00 PM, Christian König wrote: Am 12.06.2017 um 22:31 schrieb Alex Xie: This patch is to move a loop of unref BOs and several memory free function calls out of critical sections. Signed-off

Re: [PATCH 2/4] drm/amdgpu: Optimization of critical section

On 2017-06-12 06:47 PM, Christian König wrote: Am 12.06.2017 um 22:31 schrieb Alex Xie: Make the critical section smaller. There is no need to protect the bo_list, because there is no other task can access the newly created BO list yet. NAK, a task can guess the next id number so could get

Re: [PATCH 1/4] drm/amdgpu: Optimization of critical section

On 2017-06-12 07:00 PM, Christian König wrote: Am 12.06.2017 um 22:31 schrieb Alex Xie: This patch is to move a loop of unref BOs and several memory free function calls out of critical sections. Signed-off-by: Alex Xie --- drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | 5

Re: [PATCH 4/4] drm/amdgpu: Optimize mutex usage

Hi Christian, Regarding comment 1. Please read the file idr.c line 24 to line 29. Let me quote here. Isn't it surprise you? idr_alloc only need read lock. ... * Simultaneous modifications to the @idr are not allowed and should be * prevented by the user, usually with a lock. idr_alloc()

Re: [PATCH] drm/amdgpu/vm: fix warnings

Reviewed-by: Alex Xie On 2017-06-09 12:05 PM, Alex Deucher wrote: silence uninitialized variable warnings. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)

Re: [PATCH] drm/amdgpu/gfx: create a common bitmask function (v2)

ut using GENMASK() here, but that's not a must have. On the other hand we should probably consider using GENMASK() for our register headers. The parameters of the marco matches how our internal register database works, so that looks like a perfect fit. Regards, Christian. Am 08.06.2017 um 16:42

Re: [PATCH] drm/amdgpu/gfx: create a common bitmask function (v2)

g wrote: Actually we should only use static inline if we have to, see "15) The inline disease" in the coding style document, but for this case it actually looks valid to me as well. But wasn't there a macro for this in the Linux kernel headers we should use? Regards, Christian. Am 07

Re: [PATCH 4/6] drm/amdgpu/gfx: move more common KIQ code to amdgpu_gfx.c

Reviewed-by: Alex Xie On 2017-06-07 03:34 PM, Alex Deucher wrote: Lots more common stuff. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 103 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h

Re: [PATCH 6/6] drm/amdgpu/gfx: consolidate mqd buffer setup code

Reviewed-by: Alex Xie On 2017-06-07 03:34 PM, Alex Deucher wrote: It was duplicated across multiple generations. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 66 ++

Re: [PATCH 5/6] drm/amdgpu/gfx: move mec parameter setup into sw_init

Reviewed-by: Alex Xie On 2017-06-07 03:34 PM, Alex Deucher wrote: This will allow us to share more mec code. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 30 +--

Re: [PATCH 2/6] drm/amdgpu/gfx9: remove spurious line in kiq setup

Reviewed-by: Alex Xie On 2017-06-07 03:34 PM, Alex Deucher wrote: This overrode what queue was actually assigned for kiq. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 1 - 1 file changed, 1 deletion(-) diff --git

Re: [PATCH 3/6] drm/amdgpu: move mec queue helpers to amdgpu_gfx.h

Reviewed-by: Alex Xie On 2017-06-07 03:34 PM, Alex Deucher wrote: They are gfx related, not general helpers. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu.h| 30 --

Re: [PATCH 1/6] drm/amdgpu/gfx8: whitespace change

Reviewed-by: Alex Xie On 2017-06-07 03:34 PM, Alex Deucher wrote: Make it consistent. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

Re: [PATCH 2/3] drm/amdgpu: move gfx_v*_0_compute_queue_acquire to common code

Reviewed-by: Alex Xie On 2017-06-07 11:10 AM, Alex Deucher wrote: Same function was duplicated in all gfx IP files. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 37 +++

Re: [PATCH 1/3] drm/amdgpu: fix mec queue policy on single MEC asics

Hi Alex I agree that we revert the change for single MEC for the time being. Reviewed-by: Alex Xie On 2017-06-07 11:10 AM, Alex Deucher wrote: Fixes hangs on single MEC asics. Fixes: 2ed286fb434 (drm/amdgpu: new queue policy, take first 2 queues of each pipe v2)

Re: [PATCH 1/3] drm/amdgpu: fix mec queue policy on single MEC asics

Hi Alex, In Catalyst driver source code, Stoney is listed as supported, I don't know how well it is supported though. I think at least people have run some graphic operations. What kind of hangs happens in Stoney? Is it a graphic operation hang? Or OpenCL? Or something else? How easily it

Re: [PATCH 1/3] drm/amdgpu: fix mec queue policy on single MEC asics

Hi Alex, In closed source driver, we assign compute queues to all 4 pipes always. There is no hangs. May I know which ASIC? Assign all queues in first pipe first mec can slow things down. Thanks, Alex Bin Xie On 2017-06-07 11:10 AM, Alex Deucher wrote: Fixes hangs on single MEC asics.

Re: [PATCH] drm/amdgpu/gfx: create a common bitmask function (v2)

Thanks for the change. "static inline" may improve speed, though this patch is not a critical code path. Perhaps it will be true in future... Reviewed-by: Alex Xie On 2017-06-06 06:19 PM, Alex Deucher wrote: The same function was duplicated in all the gfx IPs. Use a

Re: [PATCH] drm/amdgpu/gfx: create a common bitmask function

For such a simple function, I would implement it inside the header file with "static inline". Thanks, Alex Bin On 2017-06-06 05:42 PM, Alex Deucher wrote: The same function was duplicated in all the gfx IPs. Use a single implementation for all. Suggested-by: Andres Rodriguez

Re: amd-gfx Digest, Vol 13, Issue 29

Hi Michel, Thanks. As I work more for open source driver, this digest mode becomes more annoying. I didn't even know that amd-gfx can send individual emails to me. As a result, I did not know how to ask correct question about my puzzling. I did ask around once. Now I wondered how I