Hi Xiangliang,
Thanks for your suggestions, I will make a new patch according to the discussion
Thanks & Best Wishes,
Trigger Huang
-Original Message-
From: Yu, Xiangliang
Sent: Friday, February 17, 2017 2:15 PM
To: Huang, Trigger ; amd-gfx@lists.freedesktop.org
Cc: Liu, Monk ; Huang, T
Hi Trigger,
Can you try to move src->data= NULL into gfx_v8_0_kiq_set_interrupt_state
function? I think it is more simple and clear.
Thanks!
Xiangliang Yu
> -Original Message-
> From: Trigger Huang [mailto:trigger.hu...@amd.com]
> Sent: Thursday, February 16, 2017 6:48 PM
> To: amd-gfx@
v2: move the config struct to drm_amdgpu_info_device
Signed-off-by: Junwei Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 7 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 1 +
drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 6 ++
drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 6 ++
dri
Hi Christian,
Thanks for specifying it.
Please check my update in another mail if getting the correct info as you
mentioned.
> Just make sure that the default value is zero, this way you keep backward
> compatible with older kernel interfaces.
I have checked all gfx from 6 to 8. By default the
On 2017年02月16日 20:08, Christian König wrote:
Am 16.02.2017 um 12:39 schrieb Nicolai Hähnle:
From: Nicolai Hähnle
By using ttm_bo_init_reserved instead of the manual initialization of
the reservation object, the reservation lock will be properly unlocked
and destroyed when the TTM BO initiali
On 17/02/17 12:10 AM, Deucher, Alexander wrote:
>> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
>> On 15/02/17 11:47 AM, Alex Deucher wrote:
>>> On Tue, Feb 14, 2017 at 9:30 PM, Michel Dänzer
>> wrote:
From: Michel Dänzer
The crtc_h/vdisplay fields may not
On 17.02.2017 00:02, Alex Deucher wrote:
On Thu, Feb 16, 2017 at 5:55 PM, Nicolai Hähnle wrote:
From: Nicolai Hähnle
When the fast blit path fails while attempting to move a buffer from RAM
to VRAM, we fall back to a CPU-based memcpy that cannot handle split VRAM
buffers. Instead of crashing,
On Thu, Feb 16, 2017 at 5:55 PM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> When the fast blit path fails while attempting to move a buffer from RAM
> to VRAM, we fall back to a CPU-based memcpy that cannot handle split VRAM
> buffers. Instead of crashing, simply fail the buffer move.
>
> I
From: Nicolai Hähnle
When the fast blit path fails while attempting to move a buffer from RAM
to VRAM, we fall back to a CPU-based memcpy that cannot handle split VRAM
buffers. Instead of crashing, simply fail the buffer move.
Ideally, we would teach TTM about split buffers so that the fallback
Hi Dave,
Fixes for 4.11. Highlights:
- fix >2 displays on asics with 3 or 5 crtcs
- fix SI headless asics
- powerplay fixes for new polaris variants
- misc fixes
The following changes since commit 13f62f54d174d3417c3caaafedf5e22a0a03e442:
Merge branch 'drm-next-4.11' of git://people.freedeskto
On Fri, Feb 3, 2017 at 11:47 AM, Arnd Bergmann wrote:
> gcc-4.8 warns about '{0}' being used an an initializer for nested structures:
>
> drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c: In function
> ‘gfx_v8_0_ring_emit_ce_meta_init’:
> drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c:7263:2: warning: missing braces
Hi Dave,
Just one regression fix interlaced modes on radeon.
The following changes since commit 697d3a21615672b2bf7724a65755799260325dda:
Merge tag 'drm-intel-fixes-2017-02-09' of
git://anongit.freedesktop.org/git/drm-intel into drm-fixes (2017-02-10 10:14:24
+1000)
are available in the git
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Michel Dänzer
> Sent: Wednesday, February 15, 2017 10:24 PM
> To: Alex Deucher
> Cc: amd-gfx list
> Subject: Re: [PATCH] drm/radeon: Use mode h/vdisplay fields to hide out of
> bounds HW curso
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Xiangliang Yu
> Sent: Thursday, February 16, 2017 2:25 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Yu, Xiangliang
> Subject: [PATCH 3/3] drm/amdgpu/gfx: free memory of mqd backup
>
> Need to
In some cases, manually insmod/rmmod amdgpu is necessary. When
unloading amdgpu, the KIQ IRQ enable/disable function will case
system hang. The root cause is, in the sequence of function
amdgpu_fini, the sw_fini of IP block AMD_IP_BLOCK_TYPE_GFX will be
invoked earlier than that of AMD_IP_BLOCK_TYP
Am 16.02.2017 um 12:39 schrieb Nicolai Hähnle:
From: Nicolai Hähnle
By using ttm_bo_init_reserved instead of the manual initialization of
the reservation object, the reservation lock will be properly unlocked
and destroyed when the TTM BO initialization fails.
Actual deadlocks caused by the mi
From: Nicolai Hähnle
As the comment says: callers of ttm_bo_init cannot rely on having the
only reference to the BO when the function returns successfully.
Signed-off-by: Nicolai Hähnle
---
include/drm/ttm/ttm_bo_api.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/in
From: Nicolai Hähnle
By using ttm_bo_init_reserved instead of the manual initialization of
the reservation object, the reservation lock will be properly unlocked
and destroyed when the TTM BO initialization fails.
Actual deadlocks caused by the missing unlock should have been fixed
by "drm/ttm:
From: Nicolai Hähnle
This variant of ttm_bo_init returns the validated buffer object with
the reservation lock held when resv == NULL. This is convenient for
callers that want to use the BO immediately, e.g. for initializing its
contents.
Signed-off-by: Nicolai Hähnle
---
drivers/gpu/drm/ttm/t
Reviewed-by: Monk Liu
发件人: Trigger Huang
发送时间: 2017年2月16日 18:48:19
收件人: amd-gfx@lists.freedesktop.org
抄送: Liu, Monk; Yu, Xiangliang; Huang, Trigger
主题: [PATCH] drm/amdgpu: Fix module unload hang by KIQ IRQ set
In some cases, manually insmod/rmmod amdgpu is neces
Xiangliang
good cleanup, but there are more, please help proceed them all:
struct amdgpu_mec {
struct amdgpu_bo*hpd_eop_obj;
u64hpd_eop_gpu_addr;
u32 num_pipe;
u32 num_mec;
u32 num_queue;
struct vi_mqd*mqd_backup[AMDGPU_MAX_COMPUTE_RINGS + 1];
};
cha
On 16.02.2017 11:01, Christian König wrote:
Am 15.02.2017 um 18:28 schrieb Nicolai Hähnle:
Hi Christian,
On 15.02.2017 16:59, Christian König wrote:
Nicolai could you give that set a try?
It should fix your problems with PRT tear down on process crash.
Yes, it fixes those issues for me, tha
Am 15.02.2017 um 18:28 schrieb Nicolai Hähnle:
Hi Christian,
On 15.02.2017 16:59, Christian König wrote:
Nicolai could you give that set a try?
It should fix your problems with PRT tear down on process crash.
Yes, it fixes those issues for me, thanks! The first two patches have
my R-b, for
Am 16.02.2017 um 10:24 schrieb Zhang, Jerry:
-Original Message-
From: Christian König [mailto:deathsim...@vodafone.de]
Sent: Thursday, February 16, 2017 17:12
To: Zhang, Jerry; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/1] drm/amdgpu: export gfx capability by gpu info
Am 16.02.2
On 16.02.2017 02:00, Michel Dänzer wrote:
On 16/02/17 04:10 AM, Nicolai Hähnle wrote:
From: Nicolai Hähnle
Open-code the initial ttm_bo_validate call, so that we can properly
unlock the reservation lock when it fails. Also, properly destruct
the reservation object when the first part of TTM BO
> -Original Message-
> From: Christian König [mailto:deathsim...@vodafone.de]
> Sent: Thursday, February 16, 2017 17:12
> To: Zhang, Jerry; amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH 1/1] drm/amdgpu: export gfx capability by gpu info
>
> Am 16.02.2017 um 03:53 schrieb Junwei Zhang
Am 16.02.2017 um 08:25 schrieb Xiangliang Yu:
vi_mqd is only used by VI family but mqd_ptr is common for all
ASIC, so change the pointer to void.
Signed-off-by: Xiangliang Yu
Nice cleanup, patch is Reviewed-by: Christian König
.
Patch #2 and #3 are Acked-by: Christian König .
Regards,
Chr
Am 16.02.2017 um 03:53 schrieb Junwei Zhang:
Change-Id: Ibf3e4dbb7deb83271adabc275c9b7a0e0652541a
Signed-off-by: Junwei Zhang
Complete NAK on this. The drm_amdgpu_capability structure is specific to
the pro driver.
The Vulkan stack on the other hand is supposed to work on the open stack
as
Am 16.02.2017 um 02:49 schrieb Michel Dänzer:
On 15/02/17 06:42 PM, Christian König wrote:
IOMMU might not help here, cause when it would be the GPU we would have
made a mapping once and then the page in question is never unmapped (IIRC).
That sounds like something which should be fixed if poss
We should properly prefix which kernel module this spewed
from in dmesg for consistency to the user.
Signed-off-by: Edward O'Callaghan
---
drivers/gpu/drm/amd/powerplay/inc/pp_debug.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/i
30 matches
Mail list logo