Change-Id: Ica8f86577a50d817119de4b4fb95068dc72652a9
Signed-off-by: Monk Liu
---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index 6734e55..8f545992
no need to use a delay work since we don't know how
much time hypervisor takes on FLR, so just polling
and waiting in a work.
Change-Id: I41b6336baa00b1fd299311349402a17951b585a2
Signed-off-by: Monk Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h | 2 +-
drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
v2:
use in_rest to fix compute ring test failure issue
which occured after FLR/gpu_reset.
we need backup a clean status of MQD which was created in drv load
stage, and use it in resume stage, otherwise KCQ and KIQ all may
faild in ring/ib test.
Change-Id: I41be940454a6638e9a8a05f096601eaa1fbebaab
this is required for restoring the mqds after GPU reset.
Change-Id: I84f821faa657a5d942c33d30f206eb66b579c2f8
Signed-off-by: Monk Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 10 ++
2 files changed, 11 insertions(+)
diff --git a/drivers/g
In resume routine, we need clr RB prior to the
ring test of engine, otherwise some engine hang
duplicated during GPU reset.
Change-Id: Ie28f5aa677074f922e4a1a2eeeb7fe06461d9bdb
Signed-off-by: Monk Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 2 +-
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c|
Use no kiq version reg access due to:
1) better performance
2) INTR context consideration (some routine in mailbox is in
INTR context e.g.xgpu_vi_mailbox_rcv_irq)
Change-Id: I383d7ce858a136d7b112180f86e3d632d37b4d1c
Signed-off-by: Monk Liu
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/am
use it to seperate driver load and gpu reset/resume
because gfx IP need different approach for different
hw_init trigger source
Change-Id: I991e0da52ccd197716d279bf9014de46d39acfea
Signed-off-by: Monk Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
1 file changed, 1 insertion(+)
diff --git a
some registers are PF & VF copy, and we can safely use
mmio method to access them.
and sometime we are forbid to use kiq to access registers
for example in INTR context.
we need a MACRO that always disable KIQ for regs accessing
Change-Id: Ie6dc323dc86829a4a6ceb7073c269b106b534c4a
Signed-off-by:
this flag will get cleared by request gpu access
Change-Id: Ie484bb0141420055370e019dcd8c110fb34f8a1b
Signed-off-by: Monk Liu
---
drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
b/drivers/gpu/drm/
we can use it clear ring buffer instead of fullfill
0, which is not correct for engine
Change-Id: I89dcd7b6c4de558f9b2860209a2739c7d4af262d
Signed-off-by: Monk Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/a
From: Ken Xue
Change-Id: If3a7d05824847234759b86563e8052949e171972
Signed-off-by: Ken Xue
Acked-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
b/drive
On 08/02/17 06:26 PM, Monk Liu wrote:
>
> + WREG32(temp + i,
> + unique_indices[i] & 0x3);
> + WREG32(data + i,
> + unique_indices[i] >> 20);
Use a single line in both cases (or fix
ib_pool init should prior to fbdev_init, otherwise
there will be error from amdgpu_sa_bo_new
(amdgpu_sa.c:323)
fbdev_init will call ttm_validate which further call
amdgpu_sa_bo_new.
Change-Id: I3a969570d443f61a44f67b0d76b3871ca5c3ea81
Signed-off-by: Monk Liu
---
drivers/gpu/drm/amd/amdgpu/amdgp
Am 08.02.2017 um 05:01 schrieb Edward O'Callaghan:
On 02/08/2017 12:24 PM, Pixel Ding wrote:
CPU is not efficient to do this job. There's a failure caused by this
is that handshaking gets timeout of SRIOV virtual function.
Can you fixup the commit message a little but otherwise,
Reviewed-by: E
+ /* now we are okay to resume SMC/CP/SDMA */
+ amdgpu_resume_late(adev);
As I wrote in the other thread as well calling amdgpu_resume() without
proper suspend will just mess up a whole bunch of internal structures.
So a clear NAK on that approach. If you don't need the hw stop whic
Am 08.02.2017 um 10:41 schrieb Monk Liu:
ib_pool init should prior to fbdev_init, otherwise
there will be error from amdgpu_sa_bo_new
(amdgpu_sa.c:323)
fbdev_init will call ttm_validate which further call
amdgpu_sa_bo_new.
Change-Id: I3a969570d443f61a44f67b0d76b3871ca5c3ea81
Signed-off-by: Monk
From: Nicolai Hähnle
This variant allows the caller full control over flags and size, and
allows passing a NULL bo (for PRT support).
Cc: Christian König
Cc: Bas Nieuwenhuizen
Cc: Jerry Zhang
Signed-off-by: Nicolai Hähnle
---
amdgpu/amdgpu.h| 28
amdgpu/amdg
From: Nicolai Hähnle
This is a new kernel interface.
Signed-off-by: Nicolai Hähnle
---
include/drm/amdgpu_drm.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
index d8f2497..7012515 100644
--- a/include/drm/amdgpu_drm.h
+++ b/include/d
On 08.02.2017 13:44, Nicolai Hähnle wrote:
On 08.02.2017 13:39, Christian König wrote:
Am 08.02.2017 um 13:34 schrieb Nicolai Hähnle:
From: Nicolai Hähnle
This variant allows the caller full control over flags and size, and
allows passing a NULL bo (for PRT support).
Cc: Christian König
Cc:
Am 08.02.2017 um 13:34 schrieb Nicolai Hähnle:
From: Nicolai Hähnle
This variant allows the caller full control over flags and size, and
allows passing a NULL bo (for PRT support).
Cc: Christian König
Cc: Bas Nieuwenhuizen
Cc: Jerry Zhang
Signed-off-by: Nicolai Hähnle
Reviewed-by: Christ
Am 08.02.2017 um 13:55 schrieb Nicolai Hähnle:
On 08.02.2017 13:44, Nicolai Hähnle wrote:
On 08.02.2017 13:39, Christian König wrote:
Am 08.02.2017 um 13:34 schrieb Nicolai Hähnle:
From: Nicolai Hähnle
This variant allows the caller full control over flags and size, and
allows passing a NULL
On 08.02.2017 13:39, Christian König wrote:
Am 08.02.2017 um 13:34 schrieb Nicolai Hähnle:
From: Nicolai Hähnle
This variant allows the caller full control over flags and size, and
allows passing a NULL bo (for PRT support).
Cc: Christian König
Cc: Bas Nieuwenhuizen
Cc: Jerry Zhang
Signed-
》As I wrote in the other thread as well calling amdgpu_resume() without proper
suspend will just mess up a whole bunch of internal structures.
please name at least one, I'll check and see how to improve
and like I said, this approach is correct and verified by hang test, if
internal structures
From: Christian König
For PRT support we need mappings which aren't backed by any memory.
v2: fix parameter checking
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/
From: Christian König
Enable/disable the handling globally for now and
print a warning when we enable it for the first time.
v2: write to the correct register, adjust bits to that hw generation
v3: fix compilation, add the missing register bit definitions
Signed-off-by: Christian König
---
dr
From: Christian König
Future hardware generations can handle PRT flags on a per page basis,
but current hardware can only turn it on globally.
Add the basic handling for both, a global callback to enable/disable
triggered by setting a per mapping flag.
Signed-off-by: Christian König
---
drive
Hi guys,
ok I finally found time to write an unit test for this and hammered out the
last few bugs.
Seems to work fine on my Tonga now. Please note that this set is based on "fix
race in GEM VA map IOCTL v2", without that patch you will run into a NULL
pointer dereference during PRT mapping.
From: Junwei Zhang
Till GFX8 we can only enable PRT support globally, but with the next hardware
generation we can do this on a per page basis.
Keep the interface consistent by adding PRT mappings and enable
support globally on current hardware when the first mapping is made.
v2: disable PRT su
From: Christian König
Enable/disable the handling globally for now and
print a warning when we enable it for the first time.
v2: set correct register
Signed-off-by: Junwei Zhang
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 57 +++
From: Christian König
Enable/disable the handling globally for now and
print a warning when we enable it for the first time.
v2: set correct register
Signed-off-by: Junwei Zhang
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 57 +++
From: Christian König
Just a simple test if PRT works or not.
Signed-off-by: Christian König
---
tests/amdgpu/basic_tests.c | 66 --
1 file changed, 64 insertions(+), 2 deletions(-)
diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.
and like I said, this approach is correct and verified by hang test
Completely irrelevant.
Please try the following:
1. Trigger a hang
2. Reset the GPU
3. Suspend the VM with glxgears running
4. Resume the VM
I'm pretty sure that with your approach that either suspending or
resuming the VM wit
wait a minutes ...
》3. suspend the VM with glxgears running
do you mean turn VM into s3 mode ?
if so we not get that step, the S3 suspend/resume function is not supported by
SRIOV vf case.
发件人: Christian König
发送时间: 2017年2月8日 23:13:46
收件人: Liu, Monk; amd
On 08/02/17 07:52 PM, Christian König wrote:
> Am 08.02.2017 um 10:41 schrieb Monk Liu:
>> ib_pool init should prior to fbdev_init, otherwise
>> there will be error from amdgpu_sa_bo_new
>> (amdgpu_sa.c:323)
>>
>> fbdev_init will call ttm_validate which further call
>> amdgpu_sa_bo_new.
>>
>> Chang
yeah, make sense
@Christian, why move fbdev_init() further down after ib test ? any
consideration ?
发件人: Michel Dänzer
发送时间: 2017年2月8日 23:19:23
收件人: Christian König; Liu, Monk
抄送: amd-gfx@lists.freedesktop.org
主题: Re: [PATCH] drm/amdgpu:fix amdgpu_sa_bo_new erro
do you mean turn VM into s3 mode ?
if so we not get that step, the S3 suspend/resume function is not
supported by SRIOV vf case.
Then just try to unbind the fb and unload the module.
The idea of the suspend/resume callbacks are that they are only called
in pairs.
See suspend is supposed t
If I understand you correct you really don't need all that reload and restore
dance. Instead what you need for the SRIOV case is just reinitializing the
hardware, isn't it?
That this works is just pure coincident because we don't have backup/restore
function for the blocks enabled for SRIOV.
The IB test make the decision if the hardware is working or not.
So they should be the first commands (except for the ring tests) we send
to the hardware.
When we allocate the fb before the test we send the clear command to the
hardware without knowing if the hardware really works or not.
N
we will send another patch to fix it later that using ->hw_init instead of
->resume .
BR Monk
发件人: amd-gfx 代表 Liu, Monk
发送时间: 2017年2月8日 23:40:35
收件人: Christian König; amd-gfx@lists.freedesktop.org
主题: 答复: 答复: 答复: SPAM //答复: [PATCH 09/20] drm/amdgpu:implement
On 09/02/17 12:30 AM, Christian König wrote:
> The IB test make the decision if the hardware is working or not.
>
> So they should be the first commands (except for the ring tests) we send
> to the hardware.
>
> When we allocate the fb before the test we send the clear command to the
> hardware w
agreed, why not just use cpu to clear it ? is it because performance ?
发件人: Michel Dänzer
发送时间: 2017年2月8日 23:52:02
收件人: Christian König; Liu, Monk
抄送: amd-gfx@lists.freedesktop.org
主题: Re: 答复: [PATCH] drm/amdgpu:fix amdgpu_sa_bo_new error
On 09/02/17 12:30 AM, Ch
Am 08.02.2017 um 16:53 schrieb Liu, Monk:
agreed, why not just use cpu to clear it ? is it because performance ?
Pixel Ding removed the CPU clear because "There's a failure caused by
this is that handshaking gets timeout of SRIOV virtual function."
I can only assume that this is really add
that's because some customer modified QEMU and trap each VF's memory access,
which cost too much time if using CPU access FB,
emmm, I guess we have no better choice by far, do as you suggested,
to kill risk the negative effect that we may have no console if ib test failed,
I suggest we don't
Hey Felix,
Thanks for the pointer to the ROCm mqd commit. I like that the
workarounds are easy to spot. I'll add that to a new patch series I'm
working on for some bug-fixes for perf being lower on pipes other than
pipe 0.
I haven't tested this yet on kaveri/carrizo. I'm hoping someone with
On 2017-02-06 03:31 AM, Christian König wrote:
Am 04.02.2017 um 05:51 schrieb Andres Rodriguez:
The CP_MEC_DOORBELL_RANGE_* and CP_PQ_STATUS.DOORBELL_ENABLE registers
are not HQD specific.
They only need to be set once if at least 1 pipe requested doorbell
support.
Signed-off-by: Andres Rodr
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Wednesday, February 08, 2017 4:27 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk
> Subject: [PATCH 01/11] drm/amdgpu:use MACRO like other places
>
> Change-Id: Ica8f8
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Wednesday, February 08, 2017 4:27 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk
> Subject: [PATCH 05/11] drm/amdgpu:use work instead of delay-work
>
> no need to use
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Wednesday, February 08, 2017 4:27 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk
> Subject: [PATCH 09/11] drm/amdgpu:imple ring clear
>
> we can use it clear ring buf
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Wednesday, February 08, 2017 4:27 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk
> Subject: [PATCH 10/11] drm/amdgpu:use clear_ring to clr RB
>
> In resume routine, w
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Wednesday, February 08, 2017 4:27 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk
> Subject: [PATCH 07/11] drm/amdgpu:new field in_resete introduced for gfx
>
> use it
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Wednesday, February 08, 2017 4:27 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk
> Subject: [PATCH 08/11] drm/amdgpu:alloc mqd backup
>
> this is required for restori
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Wednesday, February 08, 2017 4:27 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk
> Subject: [PATCH 11/11] drm/amdgpu:fix kiq_resume routine (V2)
>
> v2:
> use in_rest
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Wednesday, February 08, 2017 4:27 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk
> Subject: [PATCH 06/11] drm/amdgpu:RUNTIME flag should clr later
>
> this flag will
On 08.02.2017 16:06, Christian König wrote:
From: Christian König
Just a simple test if PRT works or not.
Signed-off-by: Christian König
Reviewed-by: Nicolai Hähnle
Too bad we can't ask the kernel whether a VM fault happened :/
I haven't pushed my libdrm patches yet because my understand
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Wednesday, February 08, 2017 4:27 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk
> Subject: [PATCH 02/11] drm/amdgpu:impl RREG32 no kiq version
>
> some registers are
Hi,
Heads up to whoever is using or developing for the following kernel branch:
https://cgit.freedesktop.org/~agd5f/linux/tree/?h=amd-staging-4.9
It seems like a recent commit has caused 32bit builds to fail. I haven't
been able to look into it myself or do a bisect, but it seems like it was
som
On 08/02/17 11:53 AM, Jeremy Newton wrote:
Hi,
Heads up to whoever is using or developing for the following kernel branch:
https://cgit.freedesktop.org/~agd5f/linux/tree/?h=amd-staging-4.9
It seems like a recent commit has caused 32bit builds to fail. I haven't
been able to look into it myself
On Wed, Feb 8, 2017 at 6:23 PM, Andres Rodriguez wrote:
> Hey Felix,
>
> Thanks for the pointer to the ROCm mqd commit. I like that the workarounds
> are easy to spot. I'll add that to a new patch series I'm working on for
> some bug-fixes for perf being lower on pipes other than pipe 0.
>
> I hav
Thank you Oded.
- Andres
On 2017-02-08 02:32 PM, Oded Gabbay wrote:
On Wed, Feb 8, 2017 at 6:23 PM, Andres Rodriguez wrote:
Hey Felix,
Thanks for the pointer to the ROCm mqd commit. I like that the workarounds
are easy to spot. I'll add that to a new patch series I'm working on for
some bug-
When ttm_bo_init() fails, the reservation mutex should be unlocked.
In debug build, the kernel reported "possible recursive locking
detected" in this codepath. For debugging purposes, I also added
a "WARN_ON(ww_mutex_is_locked())" when ttm_bo_init() fails and the
mutex was locked as expected.
Thi
Like ttm_bo_validate(), ttm_bo_init() might need to move BO and
the number of bytes moved by TTM should be reported. This can help
the throttle buffer migration mechanism to make a better decision.
Signed-off-by: Samuel Pitoiset
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
drivers/gpu/d
On 09/02/17 08:35 AM, Samuel Pitoiset wrote:
> When ttm_bo_init() fails, the reservation mutex should be unlocked.
>
> In debug build, the kernel reported "possible recursive locking
> detected" in this codepath. For debugging purposes, I also added
> a "WARN_ON(ww_mutex_is_locked())" when ttm_bo_
On 09/02/17 08:35 AM, Samuel Pitoiset wrote:
> Like ttm_bo_validate(), ttm_bo_init() might need to move BO and
> the number of bytes moved by TTM should be reported. This can help
> the throttle buffer migration mechanism to make a better decision.
>
> Signed-off-by: Samuel Pitoiset
[...]
> @@
Reviewed-by: Xiangliang Yu
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Wednesday, February 08, 2017 5:27 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk
> Subject: [PATCH 05/11] drm/amdgpu:use work instead of
Reviewed-by: Xiangliang.Yu
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Wednesday, February 08, 2017 5:27 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk
> Subject: [PATCH 06/11] drm/amdgpu:RUNTIME flag should
Reviewed-by: Xiangliang.Yu
Thanks!
Xiangliang Yu
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Wednesday, February 08, 2017 5:27 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk
> Subject: [PATCH 02/11] drm/am
Reviewed-by: Xiangliang Yu
Thanks!
Xiangliang Yu
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Wednesday, February 08, 2017 5:27 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Xue, Ken
> Subject: [PATCH 03/11] drm/amd
Reviewed-by: Xiangliang Yu
Thanks!
Xiangliang Yu
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Wednesday, February 08, 2017 5:27 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk
> Subject: [PATCH 04/11] drm/a
Reviewed-by: Xiangliang Yu
Thanks!
Xiangliang Yu
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Wednesday, February 08, 2017 5:27 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk
> Subject: [PATCH 08/11] drm/
Reviewed-by: Xiangliang Yu
Thanks!
Xiangliang Yu
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Wednesday, February 08, 2017 5:27 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk
> Subject: [PATCH 11/11] drm/a
On Tue, Feb 7, 2017 at 8:16 AM, Dan Carpenter wrote:
> If "rdev->bios" is NULL then we don't need to free it.
>
> Signed-off-by: Dan Carpenter
applied. thanks!
>
> diff --git a/drivers/gpu/drm/radeon/radeon_bios.c
> b/drivers/gpu/drm/radeon/radeon_bios.c
> index 00cfb5d2875f..04c0ed41374f 100
On Fri, Feb 3, 2017 at 3:23 PM, Colin King wrote:
> From: Colin Ian King
>
> bo_va is being kfree'd twice, once in the call to amdgpu_vm_bo_rmv
> and then a short while later. Fix this double free by removing
> the 2nd kfree.
>
> Detected by CoverityScan, CID#1399524 ("Double Free")
>
> Signed-of
ib_pool init should prior to fbdev_init, otherwise
there will be error from amdgpu_sa_bo_new
(amdgpu_sa.c:323)
fbdev_init will call ttm_validate which further call
amdgpu_sa_bo_new.
v2:
move fbdev_init behind ib test.
Change-Id: I3a969570d443f61a44f67b0d76b3871ca5c3ea81
Signed-off-by: Monk Liu
1)remove braces not needed
2)don't return failure on debugfs_firmware_init failed
Change-Id: I90ec3197184d0fdda54575bfbad7b705aa178698
Signed-off-by: Monk Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Wednesday, February 08, 2017 10:50 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk
> Subject: [PATCH 1/2] drm/amdgpu:fix amdgpu_sa_bo_new error(v2)
>
> ib_pool init
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Wednesday, February 08, 2017 10:50 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk
> Subject: [PATCH 2/2] drm/amdgpu:cleanup
>
> 1)remove braces not needed
> 2)don't r
On Fri, Feb 3, 2017 at 5:15 AM, Michel Dänzer wrote:
> On 02/02/17 06:36 PM, Christian König wrote:
>> Am 02.02.2017 um 07:09 schrieb Michel Dänzer:
>>> [SNIP]
>>> OTOH the people running the kernel aren't always the same people
>>> building it, so the downside is that this would potentially delay
no suspend invoked so after VF FLR by host, we just
call hw_init to reinitialize IPs.
Change-Id: If09cb42b09bee6acc84e6b239ef537ad5a3df41c
Signed-off-by: Monk Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drive
Change-Id: I37901358f0dc3e24c0b05df5d2231947cc717c93
Signed-off-by: Monk Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 73086d0..be9e27d 100644
--- a/drivers/gpu/drm/am
79 matches
Mail list logo
