Inline.
-Original Message-
From: amd-gfx On Behalf Of Tuikov, Luben
Sent: Friday, October 25, 2019 5:17 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Pelloux-prayer, Pierre-eric
; Tuikov, Luben ;
Koenig, Christian
Subject: [PATCH] drm/amdgpu: GFX9, GFX10: GRBM
Acked-by: Evan Quan
-Original Message-
From: amd-gfx On Behalf Of Liu, Aaron
Sent: Thursday, October 24, 2019 5:13 PM
To: Gong, Curry ; amd-gfx@lists.freedesktop.org
Cc: Gong, Curry
Subject: RE: [PATCH] drm/amd/powerplay: modify the parameters of
SMU_MSG_PowerUpVcn to 0
Reviewed-by:
Simplify padding calculations.
Signed-off-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/cik_sdma.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 4 ++--
Hi Mark,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.4-rc4 next-20191024]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify
The GRBM interface is now capable of bursting
1-cycle op per register, a WRITE followed by
another WRITE, or a WRITE followed by a READ--much
faster than previous muti-cycle per
completed-transaction interface. This causes a
problem, whereby status registers requiring a
read/write by hardware,
The KIQ is on the second MEC and its reservation is covered in the
latter logic, so no need to reserve its bit twice.
Change-Id: Ieee390953a60c7d43de5a9aec38803f1f583a4a9
Signed-off-by: Yong Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 8
1 file changed, 8 deletions(-)
diff
From: Mikita Lipski
- Adding encoder atomic check to find vcpi slots for a connector
- Using DRM helper functions to calculate PBN
- Adding connector atomic check to release vcpi slots if connector
loses CRTC
- Calculate PBN and VCPI slots only once during atomic
check and store them on
Problem:
When run_job fails and HW fence returned is NULL we still signal
the s_fence to avoid hangs but the user has no way of knowing if
the actual HW job was ran and finished.
Fix:
Allow .run_job implementations to return ERR_PTR in the fence pointer
returned and then set this error for
Use ERR_PTR to return back the error happened during amdgpu_ib_schedule.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index
On 2019-10-24 14:46, Sierra Guiza, Alejandro (Alex) wrote:
> The bitmap in cu_info structure is defined as a 4x4 size array. In
> Acturus, this matrix is initialized as a 4x2. Based on the 8 shaders.
> In the gpu cache filling initialization, the access to the bitmap matrix
> was done as an 8x1
The bitmap in cu_info structure is defined as a 4x4 size array. In
Acturus, this matrix is initialized as a 4x2. Based on the 8 shaders.
In the gpu cache filling initialization, the access to the bitmap matrix
was done as an 8x1 instead of 4x2. Causing an out of bounds memory
access error.
Due to
Thanks, pushed out.
Cheers,
Tom
On 2019-10-24 2:27 p.m., Tuikov, Luben wrote:
> The valid contents of rings is invariably the
> range [rptr, wptr). Augment the ring range to
> interpret the '.' ("here") notation to mean rptr
> or wptr when given on the left or right of the
> range limits. This
The valid contents of rings is invariably the
range [rptr, wptr). Augment the ring range to
interpret the '.' ("here") notation to mean rptr
or wptr when given on the left or right of the
range limits. This augments the range notation as
follows:
1) No range given, print the whole ring.
2) [.]
Hi Tom,
Thanks for debugging it!
I'll reapply and resend it.
Regards,
Luben
On 2019-10-24 9:44 a.m., StDenis, Tom wrote:
> This diff fixes your patch, can you resend please?
>
>
> diff --git a/src/app/ring_read.c b/src/app/ring_read.c
> index 9cbecb0..c1c9187 100644
> ---
Hi,
> Can you send me a copy of the vbios from that board?
>
> (as root)
> (use lspci to get the bus id)
> cd /sys/bus/pci/devices/
> echo 1 > rom
> cat rom > /tmp/vbios.rom
> echo 0 > rom
Sure, sent as private message.
Also, I got hold of a RX570 from another vendor and tested that. Works
On Tue, Oct 22, 2019 at 7:01 AM Sylvain Munaut <246...@gmail.com> wrote:
>
> Hi All,
>
> More testing over the last few days showed that only either the lowest
> power mode, or slightly above can work. Oh, I also tested 5.4-rc3 just
> in case but same results.
> It doesn't seem to be the affected
On 10/24/19 7:01 AM, Christian König wrote:
Am 24.10.19 um 12:58 schrieb S, Shirish:
[Why]
Upon GPU reset, kernel cleans up already submitted jobs
via drm_sched_cleanup_jobs.
This schedules ib's via drm_sched_main()->run_job, leading to
race condition of rings being ready or not, since during
This diff fixes your patch, can you resend please?
diff --git a/src/app/ring_read.c b/src/app/ring_read.c
index 9cbecb0..c1c9187 100644
--- a/src/app/ring_read.c
+++ b/src/app/ring_read.c
@@ -120,16 +120,16 @@ void umr_read_ring(struct umr_asic *asic, char
*ringpath)
NAK, this patch breaks something in decoding the words of the packets.
Instead of decoding I get a lot of PKT0 lines. I'll see if I can debug
this.
Tom
On 2019-10-23 5:11 p.m., Tuikov, Luben wrote:
> The valid contents of rings is invariably the
> range [rptr, wptr). Augment the ring range
> -Original Message-
> From: amd-gfx On Behalf Of
> Quan, Evan
> Sent: Thursday, October 24, 2019 2:25 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Li, Candice ; Quan, Evan
> Subject: [PATCH] drm/amd/powerplay: correct current clock level label for
> Arcturus
>
> For dpm disabled case,
On Thu, Oct 24, 2019 at 01:16:32PM +0200, Christian König wrote:
> This way the TTM is destroyed with the correct dma_resv object
> locked and we can even pipeline imported BO evictions.
>
> v2: Limit this to only cases when the parent object uses a separate
> reservation object as well. This
On Wed, 23 Oct 2019, Mark Salyzyn wrote:
> I will split this between pure and inert documentation/comments for now,
> with a followup later for the code portion which understandably is more
> controversial.
Please split by driver/subsystem too, and it'll be all around much
easier for everyone.
This way the TTM is destroyed with the correct dma_resv object
locked and we can even pipeline imported BO evictions.
v2: Limit this to only cases when the parent object uses a separate
reservation object as well. This fixes another OOM problem.
v3: fix init and try_lock on the wrong object
Am 24.10.19 um 12:58 schrieb S, Shirish:
[Why]
Upon GPU reset, kernel cleans up already submitted jobs
via drm_sched_cleanup_jobs.
This schedules ib's via drm_sched_main()->run_job, leading to
race condition of rings being ready or not, since during reset
rings may be suspended.
NAK, exactly
[Why]
Upon GPU reset, kernel cleans up already submitted jobs
via drm_sched_cleanup_jobs.
This schedules ib's via drm_sched_main()->run_job, leading to
race condition of rings being ready or not, since during reset
rings may be suspended.
[How]
make GPU reset's amdgpu_device_ip_resume_phase2() &
Am 24.10.19 um 12:51 schrieb Zhou, David(ChunMing):
On 2019/10/24 下午6:25, Christian König wrote:
Ping?
Am 18.10.19 um 13:58 schrieb Christian König:
This way the TTM is destroyed with the correct dma_resv object
locked and we can even pipeline imported BO evictions.
v2: Limit this to only
On 2019/10/24 下午6:25, Christian König wrote:
> Ping?
>
> Am 18.10.19 um 13:58 schrieb Christian König:
>> This way the TTM is destroyed with the correct dma_resv object
>> locked and we can even pipeline imported BO evictions.
>>
>> v2: Limit this to only cases when the parent object uses a
The value of the register mmMP1_SMN_C2PMSG_90 should be 0 when
initializing smu and after resuming smu.
Signed-off-by: chen gong
---
drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 3 ++-
drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h | 1 +
drivers/gpu/drm/amd/powerplay/smu_v12_0.c |
Thanks Feifei!
From: Xu, Feifei
Sent: Thursday, October 24, 2019 18:12
To: Yin, Tianci (Rico) ; amd-gfx@lists.freedesktop.org
Cc: Xiao, Jack ; Yuan, Xiaojie ; Yin,
Tianci (Rico) ; Zhang, Hawking
Subject: RE: [PATCH 2/3] drm/amdgpu/gfx10: update gfx golden
Ping?
Am 18.10.19 um 13:58 schrieb Christian König:
This way the TTM is destroyed with the correct dma_resv object
locked and we can even pipeline imported BO evictions.
v2: Limit this to only cases when the parent object uses a separate
reservation object as well. This fixes another OOM
Series is reviewed-by: Feifei Xu
Thanks,
Feifei
-Original Message-
From: amd-gfx On Behalf Of Tianci Yin
Sent: Thursday, October 24, 2019 6:10 PM
To: amd-gfx@lists.freedesktop.org
Cc: Xu, Feifei ; Xiao, Jack ; Yuan,
Xiaojie ; Yin, Tianci (Rico) ; Zhang,
Hawking
Subject: [PATCH 2/3]
From: "Tianci.Yin"
update registers: mmCGTT_SPI_CLK_CTRL
Change-Id: I35fb25be1340d8c062e0e5bfff642009a00d52cf
Signed-off-by: Tianci.Yin
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
From: "Tianci.Yin"
update registers: mmCGTT_SPI_CLK_CTRL
Change-Id: Ic64d532c61adfdeb681903f1133d9b353579ac55
Signed-off-by: Tianci.Yin
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
Reviewed-by: Aaron Liu
BR,
Aaron Liu
> -Original Message-
> From: amd-gfx On Behalf Of chen
> gong
> Sent: Thursday, October 24, 2019 4:59 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Gong, Curry
> Subject: [PATCH] drm/amd/powerplay: modify the parameters of
> SMU_MSG_PowerUpVcn to 0
The parameters what SMU_MSG_PowerUpVcn need is 0, not 1
Signed-off-by: chen gong
---
drivers/gpu/drm/amd/powerplay/renoir_ppt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
b/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
index
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 3 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 3 +--
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 2 +-
5 files changed, 5
On Wed, Oct 23, 2019 at 12:52:23PM -0400, Jerome Glisse wrote:
> > Going another step further what hinders us to put the lock into the mmu
> > range notifier itself and have _lock()/_unlock() helpers?
> >
> > I mean having the lock in the driver only makes sense when the driver would
> > be
dc.c:583:null check is needed after using kzalloc function
Signed-off-by: zhongshiqi
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 5d1aded..4b8819c
On Wed, Oct 23, 2019 at 05:24:45PM +, Jason Gunthorpe wrote:
> mlx5 is similar, but not currently coded quite right, there is one
> lock that protects the command queue for submitting invalidations to
> the HW and it doesn't make a lot of sense to have additional fine
> grained locking beyond
For dpm disabled case, it's assumed the only one support clock
level is always current clock level.
Change-Id: I5cc2b7e82af888dc5e8268597ee761e9e1a26855
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/powerplay/arcturus_ppt.c | 24 +---
1 file changed, 16 insertions(+), 8
40 matches
Mail list logo
