INIT_WORK(&work->base, gmc_v8_0_vm_fault_sched);
However VF is used or not, schedule work shouldn't handle registers reading for
interrupt, especially for status register, which could have been changed when
you handle it in schedule work after interrupt.
Regards,
David Zhou
-Original Messag
Thanks you for your comments, David. I totally agree on your point.
However, The VM fault status registers record the latest VM fault info no
matter when they’re changed, that’s what we care about since we don’t handle
too much for VM fault even in bare metal system.
On the other hand, what do
A bug NAK on this! amdgpu_gart_table_vram_unpin() must be called during
suspend.
Otherwise the GART table can be corrupted and we run into a whole bunch
of problems.
We could add a "BUG_ON(adev->gart.table_addr != NULL);" here to double
check that, but just ignoring that something went horri
Am 04.02.2017 um 11:21 schrieb Monk Liu:
Change-Id: I68729b1d32d5e300b8f03a923d2065d51dbe6f7a
Signed-off-by: Monk Liu
Reviewed-by: Christian König for this one.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/
Am 06.02.2017 um 04:18 schrieb Zhou, David(ChunMing):
I'm curious what problem this patch fix? Any crash?
My impression list_for will check if the list is empty, am I wrong?
Yeah, I agree as well. list_for won't do anything if the list is empty.
So this patch doesn't has any effect as far as
Am 04.02.2017 um 11:34 schrieb Monk Liu:
for SRIOV vf, Guest couldn't really access PCI registers so
gpu_reset() and asic_reset should be avoided.
for suspend it could run for SRIOV because cg/pg routine
already modified for SRIOV vf case, besides we should remove
the req/rel gpu access around i
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 Rodriguez
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h
Indeed a very nice set, only briefly looked over it and only found a
small issue on patch #2.
Apart from that the set is Acked-by: Christian König
.
Regards,
Christian.
Am 04.02.2017 um 13:08 schrieb Edward O'Callaghan:
This series is,
Reviewed-by: Edward O'Callaghan
On 02/04/2017 03:51 P
Hi Pixel,
I got your mean just now, since your VF must use KIQ to read/write
registers, which use fence_wait to wait reading register completed.
The alternative way is implementing a new kiq reading/writing register
way by using udelay instead of fence wait when reading/writing register
in inte
Am 06.02.2017 um 07:24 schrieb Pixel Ding:
The SRIOV host driver cleans framebuffer for each VF, guest driver
needn't this action which costs much time on some virtualization
platform, otherwise it might get timeout to initialize.
Signed-off-by: Pixel Ding
---
drivers/gpu/drm/amd/amdgpu/amdgp
Hi Pixel,
yeah agree with David here, but even busy waiting for the KIQ register
read is not really an option in the interrupt handler.
Additional to that when we have a VM fault we usually see a mass storm
of them. So allocating and scheduling a work item for each fault like
you do here wil
Hi Jerry,
thanks for the defines. I accidentally compiled the patch without SI
support, so I didn't noted that they are missing.
Going to integrate them and send out the patch set once more.
Regards,
Christian.
Am 06.02.2017 um 09:51 schrieb Zhang, Jerry:
Hi all,
We also need below for SI(
Hi all,
We also need below for SI(gmc v6) support.
{{{
diff --git a/drivers/gpu/drm/amd/include/asic_reg/gmc/gmc_6_0_sh_mask.h
b/drivers/gpu/drm/amd/include/asic_reg/
index 0f6c6c8..7155312 100644
--- a/drivers/gpu/drm/amd/include/asic_reg/gmc/gmc_6_0_sh_mask.h
+++ b/drivers/gpu/drm/amd/include/
Hi Pixel,
you don't seem to understand the reason for the clear here.
It is completely irrelevant that the host is clearing the memory for the
guest, the problem is that the guest reuse the memory it got assigned
from the host multiple times.
IIRC we added this because you could see leftover
Hi Christian,
The underlying host driver clears VF’s framebuffer when guest driver shake
hands with it, that is done before guest driver init. I think it’s unnecessary
to clear FB again even with GPU for VF.
—
Sincerely Yours,
Pixel
On 06/02/2017, 4:49 PM, "Koenig, Christian" wrote:
>Am
Thank you for the clarification, I get it.
—
Sincerely Yours,
Pixel
On 06/02/2017, 5:17 PM, "Koenig, Christian" wrote:
>Hi Pixel,
>
>you don't seem to understand the reason for the clear here.
>
>It is completely irrelevant that the host is clearing the memory for the
>guest, the proble
Sorry for the late response.
Yes, I set the fan speed to max in this patch when user set high performance.
Considering that: 1. set fan speed to max is helpful to let GPU run under
highest clock as long as possible.
2. avoid GPU rapid temperature rise in some case.
Best Rega
+ clocks->count = mclk_table->count
Missing semicolon. Will fix in V2.
Best Regards
Rex
-Original Message-
From: Rex Zhu [mailto:rex@amd.com]
Sent: Monday, February 06, 2017 1:09 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhu, Rex
Subject: [PATCH 2/2] drm/amd/powerplay:
Zhu, Rex wrote:
Sorry for the late response.
Yes, I set the fan speed to max in this patch when user set high performance.
Considering that: 1. set fan speed to max is helpful to let GPU run under
highest clock as long as possible.
2. avoid GPU rapid temperature rise in some
Hi Monk,
In
static int pp_suspend(void *handle)
{
ret = pp_check(pp_handle);
if (ret != 0)
return ret;
in suspend function, when dpm disabled/srv, also neet to return 0.
Best Regards
Rex
-Original Message-
From: amd-gfx [mailto:amd-gfx-bou
Please see in line.
Best Regards
Rex
-Original Message-
From: Andy Furniss [mailto:adf.li...@gmail.com]
Sent: Monday, February 06, 2017 8:32 PM
To: Zhu, Rex; Alex Deucher
Cc: amd-gfx list
Subject: Re: [PATCH 4/4] drm/amdgpu: extend profiling mode.
Zhu, Rex wrote:
> Sorry for the late re
Thanks,
I hadn't test S3 feature currently so didn't run into it by far
BR Monk
-Original Message-
From: Zhu, Rex
Sent: Monday, February 06, 2017 8:32 PM
To: Liu, Monk ; amd-gfx@lists.freedesktop.org
Cc: Liu, Monk
Subject: RE: [PATCH 04/21] drm/amdgpu:fix powerplay logic
Hi Monk,
In
Actually I have more patches for gpu_reset feature for SRIOV case, but I didn't
send out them, so this patch can be skipped.
I'll cleanup all those patches more and send out for review later
BR Monk
-Original Message-
From: Christian König [mailto:deathsim...@vodafone.de]
Sent: Monday,
E looks like I missed the part of S3 function
But if this is from a GPU reset , we also shouldn't continue run this function
otherwise GPU reset will fail (SRIOV reset test)
BR Monk
-Original Message-
From: Christian König [mailto:deathsim...@vodafone.de]
Sent: Monday, February 0
Hello Xiangliang Yu,
The patch ab71ac56f6d8: "drm/amdgpu/virt: implement VI virt operation
interfaces" from Jan 12, 2017, leads to the following static checker
warning:
drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c:310
xgpu_vi_init_golden_registers()
warn: string literals are always true
Hui? We shouldn't need to call this function from a GPU reset, do we
really do so?
But even if we call it from GPU reset we certainly should have called
the matching unpin function before.
Otherwise we certainly won't be able to resume from the next suspend
after a GPU reset.
Regards,
Chri
On 2017-02-06 12:08 AM, Rex Zhu wrote:
> Change-Id: I09011c5e6d5493db7e3d9a7ff7ab8c871a8db862
> Signed-off-by: Rex Zhu
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgp
Thanks, I'll sort & cleanup my patches and send again.
BR Monk
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of
Christian K?nig
Sent: Monday, February 06, 2017 4:18 PM
To: Zhou, David(ChunMing) ; Liu, Monk ;
amd-gfx@lists.freedesktop.org
Subje
seems reasonable.
but i think need to check num_levels can't be 0. in some case, there is only
one level of mclk, and higher than the max validation clocks.. and will lead
kernel panic.
Best Regards
Rex
From: Wentland, Harry
Sent: Monday, February 6, 2017 1
True, we should probably always keep one level even if it's larger than
max_clock, but output a big fat warning message when that happens.
Harry
On 2017-02-06 10:36 AM, Zhu, Rex wrote:
> seems reasonable.
>
>
> but i think need to check num_levels can't be 0. in some case, there is
> only one
I recall why I made this patch
When testing SRIOV gpu reset feature, I it will always waiting and not return
if without this patch, with more look into it:
Because gpu_srio_reset (will send patch for this routine later) doesn't call
amdgpu_suspend(), so the gart table BO won't get unpin, which
Fixes bug where say "-R gfx" would not actually dump the full
ring contents.
Adds feature where if you specify start and stop, e.g.,
"-R gfx[0:16]" will enable the decoder.
Signed-off-by: Tom St Denis
---
src/app/ring_read.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
dif
Hi Tom,
On 5 February 2017 at 22:24, Tom St Denis wrote:
> (v2): Use findLibDRM script instead of directly finding path
>
Since the project already depends on libdrm you might want to use the
drmDevice2 API and drop the iteration over all PCI devices
(libpciaccess dependency).
If the former is l
In the current KFD branch, we changed our equivalent of the MQD commit
function to copy most of the MQD registers in a loop and just update a
few registers manually to get the right programming sequence and work
around some HW errata. We were told that this is what the HW scheduler
does as well. Yo
Hi Andres,
Thank you for tackling this task. It's more involved than I expected,
mostly because I didn't have much awareness of the MQD management in amdgpu.
I made one comment in a separate message about the unified MQD commit
function, if you want to bring that more in line with our latest ROCm
I have to NAK that idea since we use umr on NPI work which doesn't necessarily
have libdrm support.
Also umr can read/write registers via pci access without amdgpu loaded (handy
if amdgpu fails to init properly).
Though you are right that libdrm is technically a requirement and I should add
t
Apparently I missed the bottom of your reply (all of the clients I have
outlook/gmail do top post only ...) as for the cmake changes. I'm for it if you
want to submit a patch. I can't imagine a lot of cross compiling though since
users will typically be using it on the platform they built it fo
We finally were able to give this patch a spin. It looks good, although
we still have a ton of MST problems.
Reviewed-by: Harry Wentland
You can find it on
https://cgit.freedesktop.org/~hwentland/linux/log/?h=amd-staging-dc-4.9
Harry
On 2017-01-27 12:58 PM, Krzysztof Nowicki wrote:
> From: Krz
* Fix for some MST issues with hubs and HP docks
* Fix for crash with modesetting driver
* bunch of pixel format work in base DC
Charlene Liu (2):
drm/amd/display: Fix YCbCr pixel format shows green issue
drm/amd/display: HDMI YCbCr422 12bpc pixel format issue
Harry Wentland (1):
drm/amd/d
They might call commit with ACTION_NOTHING without a mode.
We shouldn't crash but simply skip updating stream scaling
settings since scaling obviously didn't change without a
provided mode.
Change-Id: Id787a2f3dd73eef3512cb35f48c8cd5842d22032
Signed-off-by: Harry Wentland
Reviewed-by: Andrey Grod
From: Hersen Wu
Change-Id: I5f5392ff482213ae99bf254384f68ef29063d70f
Signed-off-by: Hersen Wu
Reviewed-by: Tony Cheng
Acked-by: Harry Wentland
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link
From: Charlene Liu
Change-Id: Ife9d9a6f177e8eb8ec2526d3ef419226fd3833c8
Signed-off-by: Charlene Liu
Reviewed-by: Charlene Liu
Acked-by: Harry Wentland
---
drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/dr
From: Krzysztof Nowicki
Remove a false assumption that a cached EDID will be present whenever
the connector is in a connected state as this will only be true for
logical MST ports. For physical ports the EDID will never be cached,
which will cause them to always appear as disconnected.
This reve
From: Yongqiang Sun
Change-Id: I360090f0b9c9200a8ebc0ca3d75e370b80a8f6cc
Signed-off-by: Yongqiang Sun
Reviewed-by: Jordan Lazare
Acked-by: Harry Wentland
---
drivers/gpu/drm/amd/display/dc/inc/hw/hw_shared.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/a
From: Vitaly Prosyak
Change-Id: Ibd6c485431d8f789ebfea699d780ac318ced66e8
Signed-off-by: Vitaly Prosyak
Reviewed-by: Tony Cheng
Acked-by: Harry Wentland
---
drivers/gpu/drm/amd/display/dc/calcs/bandwidth_calcs.c | 5 +
drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 6 --
dri
From: Charlene Liu
Change-Id: I7c7ff93d61b4bc29194ee0e4252be956721e7e9e
Signed-off-by: Charlene Liu
Reviewed-by: Tony Cheng
Acked-by: Harry Wentland
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 7 -
drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 30 ++--
Hi Christian,
I think you mean loading KMS multiple times by “reuse”. At every time loading
KMS, guest driver tells the host to clear FB during early init. I can’t see a
case that fb_probe is invoked out of loading KMS, is there?
Anyway I understand we don’t want to have many SRIOV conditional
Thanks! I'll fix it.
Thanks!
Xiangliang Yu
> -Original Message-
> From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> Sent: Monday, February 06, 2017 7:19 PM
> To: Yu, Xiangliang
> Cc: amd-gfx@lists.freedesktop.org
> Subject: [bug report] drm/amdgpu/virt: implement VI virt operatio
Hi David/Christian,
Tested the proposed method which prints warning only, there’s no problem. I
will send another review because it’s a totally different change.
—
Sincerely Yours,
Pixel
On 06/02/2017, 4:56 PM, "Christian König" wrote:
>Hi Pixel,
>
>yeah agree with David here, but even b
VF uses KIQ to access registers. When VM fault occurs, the driver
can't get back the fence of KIQ submission and runs into CPU soft
lockup.
Signed-off-by: Pixel Ding
---
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_
Maybe we can get the some useful info from IV entry.
Regards,
Jerry (Junwei Zhang)
Linux Base Graphics
SRDC Software Development
_
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Pixel Ding
> Sent: Tu
Good point.
—
Sincerely Yours,
Pixel
On 07/02/2017, 1:54 PM, "Zhang, Jerry" wrote:
>Maybe we can get the some useful info from IV entry.
>
>Regards,
>Jerry (Junwei Zhang)
>
>Linux Base Graphics
>SRDC Software Development
>_
>
>
>> -Original Message
Change-Id: Iac592f1a6c927677008feabc1b7af6f18c580910
Signed-off-by: Monk Liu
---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index 0e2c906..df1cfc5 100644
--- a/drivers/gpu/
Change-Id: I650a78c8d27f76997e1ef6e3934d0d7e043d4715
Signed-off-by: Monk Liu
---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 52 +++
1 file changed, 52 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index 22bd
Change-Id: If4dc6bb92d6a364125a568f37ea409e4c438e6a2
Signed-off-by: Monk Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 2 ++
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c| 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
b/drivers/gpu/drm/amd/amdgpu/
Change-Id: I93a4e97f1d24a289ab20c2a62371f3e303322587
Signed-off-by: Monk Liu
---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 9 +
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 6 ++
drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 6 ++
drivers/gpu/drm/amd/amdgpu/vi.c| 6 ++
4 files c
Change-Id: I9717e200be8af36f52d6305e02ffea178044c851
Signed-off-by: Monk Liu
---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index df1cfc5..fd
Signed-off-by: Monk Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 158 -
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h | 1 +
2 files changed, 158 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/
1,like pp_hw_init, we shouldn't report error if PP disabled
2,disable pp_en if sriov
Change-Id: I6d259f9609f223998bea236f64676b9c22133e4e
Signed-off-by: Monk Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c | 2 +-
drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 2 +-
2 files changed, 2 ins
this lock is used for sriov_gpu_reset, only get this mutex
can run into sriov_gpu_reset.
we have two cases triggers gpu_reset for SRIOV:
1) we have submit timedout and trigger reset voluntarily
2) hypervisor found world switch hang and trigger flr and notify we to
do gpu reset.
both cases need
sw part only invoked once during sw_init.
hw part invoked during first drv load and resume later.
that way we cannot alloc mqd in hw/resume, we only keep
mqd allocted in sw_init routine.
and hw_init routine only kmap and set it.
Change-Id: Ib0b788c71154e79819e8abb8daee9b9234a8eabb
Signed-off-by:
Change-Id: Ib11de11fb0a9e8086e542b932c9c62d5aa40ebb2
Signed-off-by: Monk Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 10 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h | 2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
b/d
From: Ken Xue
Change-Id: If3a7d05824847234759b86563e8052949e171972
Signed-off-by: Ken Xue
---
drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
b/drivers/gpu/drm/amd/amdgpu/
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| 36 +++-
2 files changed, 18 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/amd/a
some registers are pf&vf copy, and we can safely use
mmio method to access them.
and some time we are forbid to use kiq to access register
like in INTR context.
Change-Id: Ie6dc323dc86829a4a6ceb7073c269b106b534c4a
Signed-off-by: Monk Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 10 +
use it to seperate first driver load and later reset/resume
Change-Id: I991e0da52ccd197716d279bf9014de46d39acfea
Signed-off-by: Monk Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers
Change-Id: I383d7ce858a136d7b112180f86e3d632d37b4d1c
Signed-off-by: Monk Liu
---
drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
b/drivers/gpu/drm/amd/amdgpu/mxgpu_v
use is_load_stage 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: I41be940454a6638e9a8a05f096601eaa1fbeba
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/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/a
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 | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
b/drivers/gpu/dr
this is for a fine GPU reset/resume, which should
use nop clear ringbuffer prior to kickoff engine.
and also use the same clear macro in ring_init.
Change-Id: I7693891fd4431d64c025d052f1dd0ba797f2f0b7
Signed-off-by: Monk Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 2 +-
drivers/gpu/drm/a
VF uses KIQ to access registers. When VM fault occurs, the driver
can't get back the fence of KIQ submission and runs into CPU soft
lockup.
v2: print IV entry info
Signed-off-by: Pixel Ding
---
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/driv
patch 1-8 are some fixes for sriov gpu reset feature
patch 9 -20 are for sriov gpu reset
BR Monk
发件人: amd-gfx 代表 Monk Liu
发送时间: 2017年2月7日 14:11:07
收件人: amd-gfx@lists.freedesktop.org
抄送: Liu, Monk
主题: [PATCH 09/20] drm/amdgpu:implement SRIOV gpu_reset
Signed-
Change-Id: Ia5ada3e9990261ca70b03655424e6290701cdb9d
Signed-off-by: Monk Liu
---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 5 +
1 file changed, 1 insertion(+), 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 fd29124..4029d32 1006
Thank you, Jerry. You can find more detailed discussion in previous thread.
—
Sincerely Yours,
Pixel
On 07/02/2017, 3:03 PM, "Zhang, Jerry" wrote:
>If that info is enough for vf.
>Reviewed-by: Junwei Zhang
>
>Regards,
>Jerry (Junwei Zhang)
>
>Linux Base Graphics
>SRDC Software Developme
75 matches
Mail list logo
