[AMD Official Use Only - Internal Distribution Only]
Hi Christian,
> Hi Jiange, well that looks correct to me, but seems to be a bit to
> complicated. What exactly was wrong with version 3?
(1) If you open amdgpu_autodump, use it and close it, then you can't open it
again, because
[AMD Official Use Only - Internal Distribution Only]
Ping..
-Original Message-
From: Quan, Evan
Sent: Wednesday, April 29, 2020 10:39 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; dan.carpen...@oracle.com;
Quan, Evan
Subject: [PATCH] drm/amdgpu: address the static
Hi all:
I'm a newer about the amdgpu driver.
I have a question about it.
In my company, there are some experiments about HDMI hotplug.
First, I introduce the lab environment:
cpu: huawei kunpeng
os: uos
kernel: 4.19.90
video card: Radeon HD 700
the lab step is:
1, I connect the hdmi and vga with
Releasing the AMDGPU BO ref directly leads to problems when BOs were
exported as DMA bufs. Releasing the GEM reference makes sure that the
AMDGPU/TTM BO is not freed too early.
Also take a GEM reference when importing BOs from DMABufs to keep
references to imported BOs balances properly.
Am 2020-05-05 um 1:29 p.m. schrieb Felix Kuehling:
> Am 2020-05-05 um 11:19 a.m. schrieb Christian König:
>> Am 05.05.20 um 16:58 schrieb Felix Kuehling:
>>> Am 2020-05-05 um 3:47 a.m. schrieb Christian König:
Just to reply here once more, this patch is a clear NAK.
>>>
>>> Agreed. But see
On Tue, May 5, 2020 at 7:25 AM Arnd Bergmann wrote:
>
> Clang does not appear to care, and instead prints a warning:
>
> clang: warning: argument unused during compilation: '-mhard-float'
> [-Wunused-command-line-argument]
>
> Signed-off-by: Arnd Bergmann
I want to be super careful here, this
Just register the a pointer to the backlight device and use
that. Unifies the DC and non-DC handling.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 73 ++--
1 file changed, 30 insertions(+), 43 deletions(-)
diff --git
See also
https://lore.kernel.org/lkml/cadnq5_ndtzh5_rgdwkj9c_42xlvrnccs5ddu1ysptfzp94k...@mail.gmail.com/T/#me707e09e92c6e487285e8bb382a607e4e782c249
On Tue, May 5, 2020 at 7:17 AM Christian König wrote:
>
> Am 05.05.20 um 16:15 schrieb Arnd Bergmann:
> > Multiplying 10 by four overruns
[AMD Official Use Only - Internal Distribution Only]
I will do that instead. Thanks for the recommendation!
Kent
> -Original Message-
> From: Alex Deucher
> Sent: Tuesday, May 5, 2020 3:20 PM
> To: Russell, Kent
> Cc: amd-gfx list
> Subject: Re: [PATCH] Revert "Revert "drm/amdgpu:
On Tue, May 5, 2020 at 2:57 PM Kent Russell wrote:
>
> This reverts commit e71391880aa72709fac53f98d96a2d4e8875b9fa.
>
> The RAS issue at the base of this problem appears to have been addressed
>
> Signed-off-by: Kent Russell
> Change-Id: I338a985e19cae8e103bd44b0f238314e9460d396
Would probably
This reverts commit e71391880aa72709fac53f98d96a2d4e8875b9fa.
The RAS issue at the base of this problem appears to have been addressed
Signed-off-by: Kent Russell
Change-Id: I338a985e19cae8e103bd44b0f238314e9460d396
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 26 ++
1
Sure, I'll file one after work today.
To clarify though, FreeSync still "works" as in the monitor refresh rate
is updating, but it constantly bounces between the maximum and minimum
freesync refresh rates, causing it to look VERY stuttery.
Thanks for the attention, I'll file the but tonight. If
Can you file a full bug report on the gitlab tracker?
FreeSync is still working on my Navi setups with this patch applied, and
this patch is essentially just a revert of another patch already (where
FreeSync worked before).
I can understand the v2 of this series causing issues, but the v1
Am 2020-05-05 um 11:19 a.m. schrieb Christian König:
> Am 05.05.20 um 16:58 schrieb Felix Kuehling:
>> Am 2020-05-05 um 3:47 a.m. schrieb Christian König:
>>> Just to reply here once more, this patch is a clear NAK.
>>
>> Agreed. But see below. I don't think all is well.
>>
>>>
>>> The references
Mario or Nick any thoughts?
Alex
On Mon, May 4, 2020 at 1:35 PM Matt Coffin wrote:
>
> Hey guys,
>
> This is still an issue for me, and I'm still having to run a patch to
> revert this as of 5.7-rc4. To avoid breaking a lot of people's Navi
> setups in 5.7, is there any news on this? Has anyone
Same as gfx9. This allows us to kill the waves for hung
shaders.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index
On Tue, May 5, 2020 at 10:07 AM Christian König
wrote:
>
> Am 05.05.20 um 16:01 schrieb Arnd Bergmann:
> > After the structure was padded to 1024 bytes, it is no longer
> > suitable for being a local variable, as the function surpasses
> > the warning limit for 32-bit architectures:
> >
> >
Am 05.05.20 um 16:58 schrieb Felix Kuehling:
Am 2020-05-05 um 3:47 a.m. schrieb Christian König:
Just to reply here once more, this patch is a clear NAK.
Agreed. But see below. I don't think all is well.
The references are grabbed in the call path of drm_gem_prime_export()
and dropped
Applied. Thanks!
Alex
On Tue, May 5, 2020 at 9:27 AM Andriy Gapon wrote:
>
> This uses backlight_device_set_brightness() to set the brightness
> level requested via ATIF.
>
> Signed-off-by: Andriy Gapon
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 20 +++-
> 1 file
Am 2020-05-05 um 3:47 a.m. schrieb Christian König:
> Just to reply here once more, this patch is a clear NAK.
Agreed. But see below. I don't think all is well.
>
> The references are grabbed in the call path of drm_gem_prime_export()
> and dropped again in drm_gem_dmabuf_release().
>
> So they
After the structure was padded to 1024 bytes, it is no longer
suitable for being a local variable, as the function surpasses
the warning limit for 32-bit architectures:
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:587:5: error: stack frame size of 1072
bytes in function 'amdgpu_ras_feature_enable'
Multiplying 10 by four overruns a 'long' variable, as clang
points out:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:4160:53: error: overflow in
expression; result is -294967296 with type 'long' [-Werror,-Winteger-overflow]
expires = ktime_get_mono_fast_ns() + NSEC_PER_SEC
Clang does not appear to care, and instead prints a warning:
clang: warning: argument unused during compilation: '-mhard-float'
[-Wunused-command-line-argument]
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/dc/calcs/Makefile | 5 +++--
On Tue, May 5, 2020 at 2:59 AM ChenTao wrote:
>
> Fixes warning because pipe is unsigned long and can never be negtative
>
> vers/gpu/drm/radeon/radeon_kms.c:831:11: warning:
> comparison of unsigned expression < 0 is always false [-Wtype-limits]
> if (pipe < 0 || pipe >= rdev->num_crtc) {
>
On Sat, May 2, 2020 at 4:35 AM Nathan Chancellor
wrote:
>
> When building with Clang:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:4160:53: warning: overflow in
> expression; result is -294967296 with type 'long' [-Winteger-overflow]
> expires = ktime_get_mono_fast_ns() +
We set the fb smem pointer to the offset into the BAR which doesn't
handle framebuffers in system memory. Use virt_to_phys which should
handle both BARs and system memory.
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=207581
Fixes: 6c8d74caa2fa33 ("drm/amdgpu: Enable scatter gather display
Am 05.05.20 um 16:15 schrieb Arnd Bergmann:
Multiplying 10 by four overruns a 'long' variable, as clang
points out:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:4160:53: error: overflow in
expression; result is -294967296 with type 'long' [-Werror,-Winteger-overflow]
Am 05.05.20 um 16:01 schrieb Arnd Bergmann:
After the structure was padded to 1024 bytes, it is no longer
suitable for being a local variable, as the function surpasses
the warning limit for 32-bit architectures:
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:587:5: error: stack frame size of 1072
This uses backlight_device_set_brightness() to set the brightness
level requested via ATIF.
Signed-off-by: Andriy Gapon
---
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
---
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
index 1e41367ef74ee..a8157a5154243 100644
---
Here are a couple more:
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:534 amdgpu_ras_is_feature_allowed()
error: undefined (user controlled) shift '(((1))) << (head->block)'
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:542 amdgpu_ras_is_feature_enabled()
error: undefined (user controlled) shift '(((1)))
Hello xinhui pan,
The patch c030f2e4166c: "drm/amdgpu: add amdgpu_ras.c to support ras
(v2)" from Oct 31, 2018, leads to the following static checker
warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:620 amdgpu_ras_feature_enable()
warn: uncapped user index
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
Just to reply here once more, this patch is a clear NAK.
The references are grabbed in the call path of drm_gem_prime_export()
and dropped again in drm_gem_dmabuf_release().
So they are perfectly balanced as far as I can see.
Regards,
Christian.
Am 01.05.20 um 16:44 schrieb Felix Kuehling:
On 2020-05-01 11:20, Jason Gunthorpe wrote:
From: Jason Gunthorpe
Presumably the intent here was that hmm_range_fault() could put the data
into some HW specific format and thus avoid some work. However, nothing
actually does that, and it isn't clear how anything actually could do that
as
On 2020-05-01 11:20, Jason Gunthorpe wrote:
From: Jason Gunthorpe
hmm_vma_walk->last is supposed to be updated after every write to the
pfns, so that it can be returned by hmm_range_fault(). However, this is
not done consistently. Fortunately nothing checks the return code of
hmm_range_fault()
On 2020-05-01 11:20, Jason Gunthorpe wrote:
From: Jason Gunthorpe
This is just an alias for HMM_PFN_ERROR, nothing cares that the error was
because of a special page vs any other error case.
Reviewed-by: John Hubbard
thanks,
--
John Hubbard
NVIDIA
Acked-by: Felix Kuehling
Reviewed-by:
Fixes warning because pipe is unsigned long and can never be negtative
vers/gpu/drm/radeon/radeon_kms.c:831:11: warning:
comparison of unsigned expression < 0 is always false [-Wtype-limits]
if (pipe < 0 || pipe >= rdev->num_crtc) {
drivers/gpu/drm/radeon/radeon_kms.c:857:11: warning:
39 matches
Mail list logo
