DC invokes DC_FPU_START/END in multiple parts of the code; this can
create a situation where we invoke this FPU operation in a nested way or
exit too early. For avoiding this situation, this commit adds a
mechanism where dc_fpu_begin/end manages the access to
kernel_fpu_begin/end.
Change since
The display core files rely on FPU, which requires to be compiled with
special flags. Ideally, we don't want these FPU operations spread around
the DC code; nevertheless, it happens in the current source. This commit
introduces a new directory named fpu_operations that intends to
centralize all
We don't have any mechanism for tracing FPU operations inside the
display core, making the debug work a little bit tricky. This commit
introduces a trace mechanism inside our DC_FP_START/END macros for
trying to alleviate this problem.
Changes since V2:
- Make sure that we compile FPU operation
To fully isolate FPU operations in a single place, we must avoid
situations where compilers spill FP values to registers due to FP enable
in a specific C file. Note that even if we isolate all FPU functions in
a single file and call its interface from other files, the compiler
might enable the use
Hi,
In the display core, we utilize floats and doubles units for calculating
modesetting parameters. One side effect of our approach to use double-precision
is the fact that we spread multiple FPU access across our driver, which means
that we can accidentally clobber user space FPU state.
#
This fixes a bug which if we probe a non-existing
I2C device, and the SMU returns 0xFF, from then on
we can never communicate with the SMU, because the
code before this patch reads and interprets 0xFF
as a terminal error, and thus we never write 0
into register 90 to clear the status (and
[Why]
Avoid conflict with address ranges mapped by SVM
mechanism that try to be allocated again through
ioctl_alloc in the same process. And viceversa.
[How]
For ioctl_alloc_memory_of_gpu allocations
Check if the address range passed into ioctl memory
alloc does not exist already in the
On 2021-07-19 1:49 p.m., Anson Jacob wrote:
> Fix make htmldocs complaint:
> ./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:628: warning: Excess
> function parameter 'interrupt_params' description in 'DMUB_TRACE_MAX_READ'
>
> Signed-off-by: Anson Jacob
> ---
>
Regards,
Oak
On 2021-07-17, 3:22 PM, "amd-gfx on behalf of Alex Sierra"
wrote:
Two helpers added. One checks if zone device page is generic
type. The other if page is either private or generic type.
Signed-off-by: Alex Sierra
---
include/linux/mm.h | 8
This is an attempt to have generic FPU enable/disable
calls similar to x86.
So that we can simplify gpu/drm/amd/display/dc/os_types.h
Also adds FPU correctness logic seen in x86.
Anson Jacob (2):
ppc/fpu: Add generic FPU api similar to x86
drm/amd/display: Use PPC FPU functions
- Add kernel_fpu_begin & kernel_fpu_end API as x86
- Add logic similar to x86 to ensure fpu
begin/end call correctness
- Add kernel_fpu_enabled to know if FPU is enabled
Signed-off-by: Anson Jacob
---
arch/powerpc/include/asm/switch_to.h | 29 ++
arch/powerpc/kernel/process.c|
Use kernel_fpu_begin & kernel_fpu_end for PPC
Depends on "ppc/fpu: Add generic FPU api similar to x86"
Signed-off-by: Anson Jacob
---
drivers/gpu/drm/amd/display/dc/os_types.h | 28 ++-
1 file changed, 2 insertions(+), 26 deletions(-)
diff --git
Fix make htmldocs complaint:
./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:628: warning: Excess
function parameter 'interrupt_params' description in 'DMUB_TRACE_MAX_READ'
Signed-off-by: Anson Jacob
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 ++-
1 file changed, 2
On Mon, Jul 19, 2021 at 12:16 PM Luben Tuikov wrote:
>
> This fixes a bug which if we probe a non-existing
> I2C device, and the SMU returns 0xFF, from then on
> we can never communicate with the SMU, because the
> code before this patch reads and interprets 0xFF
> as a terminal error, and thus
This fixes a bug which if we probe a non-existing
I2C device, and the SMU returns 0xFF, from then on
we can never communicate with the SMU, because the
code before this patch reads and interprets 0xFF
as a terminal error, and thus we never write 0
into register 90 to clear the status (and
[AMD Official Use Only]
> -Original Message-
> From: Kuehling, Felix
> Sent: Saturday, July 17, 2021 1:47 AM
> To: Kim, Jonathan ; amd-
> g...@lists.freedesktop.org
> Subject: Re: [PATCH 2/3] drm/amdkfd: report xgmi bandwidth between
> direct peers to the kfd
>
> Am 2021-07-16 um 12:43
[AMD Official Use Only]
> -Original Message-
> From: Lazar, Lijo
> Sent: Monday, July 19, 2021 3:22 AM
> To: Kim, Jonathan ; amd-
> g...@lists.freedesktop.org
> Cc: Kuehling, Felix
> Subject: Re: [PATCH 2/3] drm/amdkfd: report xgmi bandwidth between
> direct peers to the kfd
>
>
>
> On
[AMD Official Use Only]
> -Original Message-
> From: Kuehling, Felix
> Sent: Saturday, July 17, 2021 1:37 AM
> To: Kim, Jonathan ; amd-
> g...@lists.freedesktop.org
> Subject: Re: [PATCH 3/3] drm/amdkfd: report pcie bandwidth to the kfd
>
> Am 2021-07-16 um 12:43 p.m. schrieb Jonathan
[Public]
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Anson Jacob
Sent: Monday, July 19, 2021 11:19 AM
To: amd-gfx@lists.freedesktop.org
Cc: Jacob, Anson
Subject: [PATCH] drm/amdgpu: Fix documentaion for amdgpu_bo_add_to_shadow_list
make htmldocs
make htmldocs complaints about parameter for amdgpu_bo_add_to_shadow_list
./drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:739: warning: Excess function
parameter 'bo' description in 'amdgpu_bo_add_to_shadow_list'
./drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:739: warning: Function parameter
or
On 2021-07-16 10:46 p.m., Felix
Kuehling wrote:
Currently the SVM get_attr call allows querying, which flags are set
in the entire address range. Add the opposite query, which flags are
clear in the entire address range. Both queries can be combined in a
From: Veerabadhran Gopalakrishnan
Signed-off-by: Veerabadhran Gopalakrishnan
---
drivers/gpu/drm/amd/amdgpu/nv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c b/drivers/gpu/drm/amd/amdgpu/nv.c
index cf73a6923..751c7b8b1 100644
---
[Public]
.codec_count = ARRAY_SIZE(bg_video_codecs_decode_array),
You need to change bg_xxx to yc_xxx as well.
Regards,
Guchun
-Original Message-
From: amd-gfx On Behalf Of
veerabadhran.gopalakrish...@amd.com
Sent: Monday, July 19, 2021 9:39 PM
To: amd-gfx@lists.freedesktop.org
Cc:
From: Veerabadhran Gopalakrishnan
Signed-off-by: Veerabadhran Gopalakrishnan
---
drivers/gpu/drm/amd/amdgpu/nv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c b/drivers/gpu/drm/amd/amdgpu/nv.c
index cf73a6923..3027b44df 100644
---
On 2021-07-19 4:24 a.m., Lazar, Lijo
wrote:
On 7/14/2021 11:28 PM, Luben Tuikov wrote:
This fixes a bug which if we probe a non-existing
I2C device, and the SMU returns 0xFF, from then on
we can never communicate with the SMU, because the
code before
[Public]
Hi all,
This week this patchset was tested on the following systems:
HP Envy 360, with Ryzen 5 4500U, with the following display types: eDP 1080p
60hz, 4k 60hz (via USB-C to DP/HDMI), 1440p 144hz (via USB-C to DP/HDMI),
1680*1050 60hz (via USB-C to DP and then DP to DVI/VGA)
AMD
On Sat, Jul 17, 2021 at 02:21:25PM -0500, Alex Sierra wrote:
> return res;
> }
> -
> +EXPORT_SYMBOL_GPL(lookup_resource);
> /*
Please keep this empty line (after the EXPORT_SYMBOL).
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
On Sat, Jul 17, 2021 at 02:21:30PM -0500, Alex Sierra wrote:
> Add MEMORY_DEVICE_GENERIC case to free_zone_device_page
> callback.
> Device generic type memory case is now able to free its
> pages properly.
No need for the early line breaks:
Add MEMORY_DEVICE_GENERIC case to
On Sat, Jul 17, 2021 at 02:21:27PM -0500, Alex Sierra wrote:
> + migrate.flags = adev->gmc.xgmi.connected_to_cpu ?
> + MIGRATE_VMA_SELECT_SYSTEM :
> MIGRATE_VMA_SELECT_DEVICE_PRIVATE;
Please just use a good old if/else to keep the code readable.
[AMD Official Use Only]
Besides, I think our current KMD have three types of kernel sdma jobs:
1) adev->mman.entity, it is already a KERNEL priority entity
2) vm->immediate
3) vm->delay
Do you mean now vm->immediate or delay are used as moving jobs instead of
mman.entity ?
Thanks
[AMD Official Use Only]
If there is move jobs clashing there we probably need to fix the bugs of those
move jobs
Previously I believe you also remember that we agreed to always trust kernel
jobs especially paging jobs,
Without set paging jobs' priority to KERNEL level how can we keep that
On 7/14/2021 11:28 PM, Luben Tuikov wrote:
This fixes a bug which if we probe a non-existing
I2C device, and the SMU returns 0xFF, from then on
we can never communicate with the SMU, because the
code before this patch reads and interprets 0xFF
as a terminal error, and thus we never write 0
On 7/16/2021 10:13 PM, Jonathan Kim wrote:
Report the min/max bandwidth in megabytes to the kfd for direct
xgmi connections only.
v2: change reporting from num links to bandwidth
Signed-off-by: Jonathan Kim
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 23 ++
Am 19.07.21 um 11:42 schrieb Liu, Monk:
[AMD Official Use Only]
Besides, I think our current KMD have three types of kernel sdma jobs:
1) adev->mman.entity, it is already a KERNEL priority entity
2) vm->immediate
3) vm->delay
Do you mean now vm->immediate or delay are used as moving jobs
[Why]
Current vm_pte entities have NORMAL priority, in SRIOV multi-vf
use case, the vf flr happens first and then job time out is found.
There can be several jobs timeout during a very small time slice.
And if the innocent sdma job time out is found before the real bad
job, then the innocent sdma
Am 19.07.21 um 07:57 schrieb Jingwen Chen:
[Why]
Current vm_pte entities have NORMAL priority, in SRIOV multi-vf
use case, the vf flr happens first and then job time out is found.
There can be several jobs timeout during a very small time slice.
And if the innocent sdma job time out is found
[AMD Official Use Only]
Hi Leo
Can you help to review this patch?
--
BW
Pengju Zhou
> -Original Message-
> From: amd-gfx On Behalf Of Zhou,
> Peng Ju
> Sent: Friday, July 16, 2021 10:15 AM
> To: Liu, Monk ; Alex
37 matches
Mail list logo
