The existing function doesn't compare the access bitmaps and flags.
This can result in failure to update those attributes in existing
ranges when all other attributes remained unchanged.
Because the access and flags attributes modify only some bits in the
respective bitmaps, we cannot compare them
Add null-pointer check after the last svm_range_new call. This was
originally reported by Zhou Qingyang based on a
static analyzer.
To avoid duplicating the unwinding code from svm_range_handle_overlap,
I merged the two functions into one.
Signed-off-by: Felix Kuehling
Cc: Zhou Qingyang
---
d
If an existing SVM range overlaps an svm_range_set_attr call, we would
normally split it in order to update only the overlapping part.
However, if the attributes of the existing range would not be changed
splitting it is unnecessary.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/k
Hawaii support is mostly untested these days. ROCm user mode also
depends on custom firmware for AQL packet processing, that was never
pushed upstream due to quality regressions in graphics driver testing.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 6 +-
1 fi
start_nocpsch would never set dqm->sched_running on Hawaii due to an
early return statement. This would trigger asserts in other functions
and end up in inconsistent states.
Bug: https://github.com/RadeonOpenCompute/ROCm/issues/1624
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kf
Guest OS will setup VCN instance 1 which is disabled as an enabled instance.
This will cause VCN ib ring test failure during modprobe.
Fixes: 36b7d5646476 ("drm/amdgpu: handle SRIOV VCN revision parsing")
Signed-off-by: Leslie Shi
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 3 +++
1 file chang
[Public]
Hi Leslie,
Can we move revision handling in this patch into
amdgpu_discovery_get_vcn_version? Then we will maintain all revision handlings
only in amdgpu_discovery.c.
Regards,
Guchun
-Original Message-
From: amd-gfx On Behalf Of Leslie Shi
Sent: Wednesday, December 8, 2021 4
Fix following warning in SRIOV during modprobe:
amdgpu :00:08.0: GFX9+ requires FB check based on format modifier
WARNING: CPU: 0 PID: 1023 at drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:1150
amdgpu_display_framebuffer_init+0x8e7/0xb40 [amdgpu]
Signed-off-by: Leslie Shi
---
drivers/gpu/drm
We found some headaches on ASICs don't need that,
so remove that for them.
Suggested-by: Lijo Lazar
Signed-off-by: Lang Yu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 47 +++---
1 file changed, 32 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgp
Currently, we don't find some neccesities to power on/off
SDMA in SMU hw_init/fini(). It makes more sense in SDMA
hw_init/fini().
Signed-off-by: Lang Yu
---
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
[AMD Official Use Only]
Hi Lang,
the function of smu_powergate_sdma() is only valid on renoir chip.
if you want to remove it, please also remove following callback pointer in
struct pptable_funcs{}.
related macro definitions also need to be cleaned up.
int (*powergate_sdma)(struct smu_context *
[AMD Official Use Only]
Reviewed-by: Kevin Wang
Best Regards,
Kevin
From: amd-gfx on behalf of Lang Yu
Sent: Wednesday, December 8, 2021 5:26 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Yu, Lang ;
Lazar, Lijo ; Huang, Ray
Subject: [PATCH 2
The psp bootloader functions code of psp_v13_0.c had been optimized before.
According the code style of psp_v13_0.c to remove the redundant code of
psp_v11_0.c.
Signed-off-by: yipechai
---
drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 79 ++
1 file changed, 16 insertions(+),
On 12/08/ , Wang, Yang(Kevin) wrote:
>[AMD Official Use Only]
>
>Hi Lang,
>the function of smu_powergate_sdma() is only valid on renoir chip.
>if you want to remove it, please also remove following callback pointer
>in struct pptable_funcs{}.
>related macro definitions also
[AMD Official Use Only]
OK, I miss this call path.
Reviewed-by: Kevin Wang
Best Regards,
Kevin
From: Yu, Lang
Sent: Wednesday, December 8, 2021 6:58 PM
To: Wang, Yang(Kevin)
Cc: amd-gfx@lists.freedesktop.org ; Deucher,
Alexander ; Lazar, Lijo ; Huang,
Ray
[AMD Official Use Only]
Reviewed-by: Hawking Zhang
Feel free to talk with Likun to get a sienna_cichlid board for the testing.
Regards,
Hawking
-Original Message-
From: Chai, Thomas
Sent: Wednesday, December 8, 2021 18:43
To: amd-gfx@lists.freedesktop.org
Cc: Chai, Thomas ; Zhang, Haw
Hi Isabella,
First of all, thanks a lot for sending this patch. This is a very
welcome improvement to display code :)
I added a few comments inline.
On 2021-12-07 8:25 p.m., Isabella Basso wrote:
This turns previously global functions into static, thus removing
compile-time warnings such as:
On 2021-12-07 8:25 p.m., Isabella Basso wrote:
This fixes the warnings below:
In function 'svm_range_map_to_gpu':
warning: variable 'bo_va' set but not used [-Wunused-but-set-variable]
1172 | struct amdgpu_bo_va bo_va;
| ^
...
In functi
On 2021-12-07 8:25 p.m., Isabella Basso wrote:
This fixes warnings caused by global functions lacking prototypes:, such as:
warning: no previous prototype for 'dcn303_hw_sequencer_construct'
[-Wmissing-prototypes]
12 | void dcn303_hw_sequencer_construct(struct dc *dc)
| ^~
Hi Isabella,
Thanks a lot for all of these improvements.
I reviewed all patches related to the display code.
Best Regards
Siqueira
On 2021-12-07 8:25 p.m., Isabella Basso wrote:
This patchset aims at fixing various compilation warnings in the AMD GPU
driver. All warnings were generated using
On 2021-12-07 2:18 p.m., Aurabindo Pillai wrote:
[Why&How]
A missing include statement triggered a warning when running
a build with W=1:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn303/dcn303_init.c:30:6: warning: no
previous prototype for 'dcn303_hw_sequencer_construct' [-Wmissing-prototy
On 2021-12-07 2:49 p.m., Yann Dirson wrote:
On Thu, Dec 02, 2021 at 11:01:32AM -0500, Rodrigo Siqueira wrote:
In the DC driver, we have multiple acronyms that are not obvious
most of
the time; the same idea is valid for amdgpu. This commit introduces
a DC
and amdgpu glossary in order to mak
[AMD Official Use Only]
Hi Siqueira,
Thanks for the heads up, lets apply Isabella's patch instead.
--
Regards,
Jay
From: Siqueira, Rodrigo
Sent: Wednesday, December 8, 2021 10:17 AM
To: Pillai, Aurabindo ; amd-gfx@lists.freedesktop.org
; Isabella Basso
Cc: We
On 12/8/2021 2:43 PM, Chen, Guchun wrote:
[Public]
Hi Leslie,
Can we move revision handling in this patch into
amdgpu_discovery_get_vcn_version? Then we will maintain all revision handlings
only in amdgpu_discovery.c.
This seems to be more about VCN config than revision. A better thing
Hi Rodrigo,
> On 2021-12-07 2:49 p.m., Yann Dirson wrote:
> >
> >> On Thu, Dec 02, 2021 at 11:01:32AM -0500, Rodrigo Siqueira wrote:
> >>> In the DC driver, we have multiple acronyms that are not obvious
> >>> most of
> >>> the time; the same idea is valid for amdgpu. This commit
> >>> introduces
On 2021-12-08 11:16 a.m., Yann Dirson wrote:
Hi Rodrigo,
On 2021-12-07 2:49 p.m., Yann Dirson wrote:
On Thu, Dec 02, 2021 at 11:01:32AM -0500, Rodrigo Siqueira wrote:
In the DC driver, we have multiple acronyms that are not obvious
most of
the time; the same idea is valid for amdgpu. Thi
On Wed, Dec 8, 2021 at 11:09 AM Lazar, Lijo wrote:
>
>
>
> On 12/8/2021 2:43 PM, Chen, Guchun wrote:
> > [Public]
> >
> > Hi Leslie,
> >
> > Can we move revision handling in this patch into
> > amdgpu_discovery_get_vcn_version? Then we will maintain all revision
> > handlings only in amdgpu_disc
[AMD Official Use Only]
Reviewed-by: Kent Russell
> -Original Message-
> From: amd-gfx On Behalf Of Felix
> Kuehling
> Sent: Wednesday, December 8, 2021 3:26 AM
> To: amd-gfx@lists.freedesktop.org
> Subject: [PATCH 2/2] drm/amdkfd: Make KFD support on Hawaii experimental
>
> Hawaii s
Am 2021-12-08 um 6:31 a.m. schrieb Alistair Popple:
> On Tuesday, 7 December 2021 5:52:43 AM AEDT Alex Sierra wrote:
>> Avoid long term pinning for Coherent device type pages. This could
>> interfere with their own device memory manager.
>> If caller tries to get user device coherent pages with PIN
On 2021-12-08 3:24 a.m., Felix Kuehling
wrote:
Add null-pointer check after the last svm_range_new call. This was
originally reported by Zhou Qingyang based on a
static analyzer.
To avoid duplicating the unwinding code from svm_range_handle_overlap,
I merge
On 2021-12-08 3:24 a.m., Felix Kuehling
wrote:
The existing function doesn't compare the access bitmaps and flags.
This can result in failure to update those attributes in existing
ranges when all other attributes remained unchanged.
Because the access and f
Am 2021-12-08 um 11:58 a.m. schrieb Felix Kuehling:
> Am 2021-12-08 um 6:31 a.m. schrieb Alistair Popple:
>> On Tuesday, 7 December 2021 5:52:43 AM AEDT Alex Sierra wrote:
>>> Avoid long term pinning for Coherent device type pages. This could
>>> interfere with their own device memory manager.
>>
Hi Alex,
This patch touches amd_shared.h
Could I get an ack ?
On 12/7/21 12:32 PM, Aurabindo Pillai wrote:
[Why]
Allow for disabling non transparent mode of LTTPR for running tests.
[How]
Add a feature flag and set them during init sequence. The flags are
already being used in DC.
Signed-off
On 2021-12-08 3:24 a.m., Felix Kuehling
wrote:
If an existing SVM range overlaps an svm_range_set_attr call, we would
normally split it in order to update only the overlapping part.
However, if the attributes of the existing range would not be changed
splitti
Am 2021-12-07 um 8:25 p.m. schrieb Isabella Basso:
> This fixes the warnings below:
>
> In function 'svm_range_map_to_gpu':
> warning: variable 'bo_va' set but not used [-Wunused-but-set-variable]
> 1172 | struct amdgpu_bo_va bo_va;
> | ^
> ...
> I
On 12/8/2021 11:30 AM, Felix Kuehling wrote:
Am 2021-12-08 um 11:58 a.m. schrieb Felix Kuehling:
Am 2021-12-08 um 6:31 a.m. schrieb Alistair Popple:
On Tuesday, 7 December 2021 5:52:43 AM AEDT Alex Sierra wrote:
Avoid long term pinning for Coherent device type pages. This could
interfere wit
On Tue, Dec 7, 2021 at 10:17 PM Isabella Basso wrote:
>
> Silences 166 compile-time warnings like:
>
> warning: 'UVD0_BASE' defined but not used [-Wunused-const-variable=]
> 129 | static const struct IP_BASE UVD0_BASE ={ { { { 0x7800, 0x7E00,
> 0, 0, 0 } },
> |
Applied. Thanks!
Alex
On Tue, Dec 7, 2021 at 10:17 PM Isabella Basso wrote:
>
> This fixes various warnings relating to erroneous docstring syntax, of
> which some are listed below:
>
> warning: Function parameter or member 'adev' not described in
> 'amdgpu_atomfirmware_ras_rom_addr'
> ...
>
On Tue, Dec 7, 2021 at 10:17 PM Isabella Basso wrote:
>
> This commit fixes the compile-time warning below:
>
> warning: no previous prototype for ‘amdgpu_ras_mca_query_error_status’
> [-Wmissing-prototypes]
I think this function can just be made static. It's not used outside
of amdgpu_ras.c.
Applied with minor tweaks to the commit message. Thanks!
Alex
On Tue, Dec 7, 2021 at 10:17 PM Isabella Basso wrote:
>
> This turns previously global functions into static, thus removing
> compile-time warnings such as:
>
> warning: no previous prototype for 'release_psp_cmd_buf'
> [-Wmissing-
Applied. Thanks!
Alex
On Tue, Dec 7, 2021 at 10:17 PM Isabella Basso wrote:
>
> This turns previously global functions into static, thus removing
> compile-time warnings such as:
>
> warning: no previous prototype for 'pm_set_resources_vi'
> [-Wmissing-prototypes]
> 113 | int pm_set_resour
Applied. Thanks!
On Wed, Dec 8, 2021 at 10:11 AM Rodrigo Siqueira Jordao
wrote:
>
>
>
> On 2021-12-07 8:25 p.m., Isabella Basso wrote:
> > This fixes warnings caused by global functions lacking prototypes:, such as:
> >
> > warning: no previous prototype for 'dcn303_hw_sequencer_construct'
> >
Applied. Thanks!
On Tue, Dec 7, 2021 at 10:17 PM Isabella Basso wrote:
>
> This fixes the warning below by changing the prototype to a location
> that's actually included by the .c files that call
> amdgpu_kms_compat_ioctl:
>
> warning: no previous prototype for ‘amdgpu_kms_compat_ioctl’
> [-W
On Tue, Dec 7, 2021 at 10:17 PM Isabella Basso wrote:
>
> Fix the warning below by switching header comments to be more aligned
> with AMD's docstrings:
>
> warning: Cannot understand * \file amdgpu_ioc32.c
> on line 2 - I thought it was a doc line
>
> Signed-off-by: Isabella Basso
> ---
> dr
Remove not unique timestamp WARNING as same timestamp interrupt happens
on some chips,
Drain fault need to wait for the processed_timestamp to be truly greater
than the checkpoint or the ring to be empty to be sure no stale faults
are handled.
Signed-off-by: Philip Yang
---
drivers/gpu/drm/amd/
Am 2021-12-08 um 3:16 p.m. schrieb Philip Yang:
> Remove not unique timestamp WARNING as same timestamp interrupt happens
> on some chips,
>
> Drain fault need to wait for the processed_timestamp to be truly greater
> than the checkpoint or the ring to be empty to be sure no stale faults
> are ha
On Wed, Dec 8, 2021 at 3:17 PM Philip Yang wrote:
>
> Remove not unique timestamp WARNING as same timestamp interrupt happens
> on some chips,
>
> Drain fault need to wait for the processed_timestamp to be truly greater
> than the checkpoint or the ring to be empty to be sure no stale faults
> are
On Wed, Dec 8, 2021 at 3:25 PM Alex Deucher wrote:
>
> On Wed, Dec 8, 2021 at 3:17 PM Philip Yang wrote:
> >
> > Remove not unique timestamp WARNING as same timestamp interrupt happens
> > on some chips,
> >
> > Drain fault need to wait for the processed_timestamp to be truly greater
> > than the
When an application having open file access to a node forks, its shared
mappings also get reflected in the address space of child process even
though it cannot access them with the object permissions applied. With the
existing permission checks on the gem objects, it might be reasonable to
also cre
Hi Alex,
>
> On Mon, Dec 6, 2021 at 4:36 PM Yann Dirson wrote:
> >
> > Hi Alex,
> >
> > > We have not validated virtualization of our integrated GPUs. I
> > > don't
> > > know that it will work at all. We had done a bit of testing but
> > > ran
> > > into the same issues with the PSP, but neve
50 matches
Mail list logo
