,
David Zhou
On 2018年04月26日 11:47, Ding, Pixel wrote:
> Hi Monk,
>
> Please review it. Thanks.
>
> —
> Sincerely Yours,
> Pixel
>
>
> On 2018/4/25, 4:39 PM, "Pixel Ding" wrote:
>
>
Hi Monk,
Please review it. Thanks.
—
Sincerely Yours,
Pixel
On 2018/4/25, 4:39 PM, "Pixel Ding" wrote:
The current sequence in scheduler thread is:
1. update last sched fence
2. job begin (adding to mirror list)
3. job finish (remove from mirror list)
4. back to 1
k CMPL if it’s necessary. any problem?
I don't understand your point
[Pixel]generally, CMPL is not handled by rcv_msg anymore but in peek_msg. we
can remove the logics here.
-Original Message-
From: Ding, Pixel
Sent: 2018年3月7日 16:3
Hi Monk,
It’s a long patch which could split into 6 pieces at most… anyway I got some
questions inline to have a better understanding.
—
Sincerely Yours,
Pixel
On 06/03/2018, 11:29 AM, "amd-gfx on behalf of Monk Liu"
wrote:
this patch actually refactor mailbox implmentations, and
a
Actually, for mailbox registers once the byte field is touched even not
changed, the mailbox behaves, so we need the byte width accessing to those sort
of regs.
Please correct the typo in commit title. With that change,
Reviewed-by: Pixel Ding
—
Sincerely Yours,
Pixel
On 06/03/2018, 7:05 P
Reviewed-by: Pixel Ding
—
Sincerely Yours,
Pixel
On 01/03/2018, 4:21 PM, "amd-gfx on behalf of Liu, Monk"
wrote:
Hi Christian
KIQ is used by kernel, and we submit commands on it without gpu scheduler,
In sriov env, register access must go through KIQ in non-exclusive mode
Hi Monk,
Please review.
—
Sincerely Yours,
Pixel
On 12/12/2017, 2:05 PM, "Pixel Ding" wrote:
Both doorbell and polling mem are working on Tonga VF. SDMA issue
happens because SDMA engine accepts doorbell writes even if it's
inactive, that introduces conflict when world switch rou
I got it, the IH sw_fini is done later than DCE while your other patch cleans
up timer in DCE sw_fini.
Maybe you can call amdgpu_irq_put() here, anyway your patch is already in:)
—
Sincerely Yours,
Pixel
On 16/11/2017, 5:28 PM, "Ding, Pixel" wrote:
>Hi Monk,
>
>I’
Hi Monk,
I’m not for sure what issue you are fixing. The timer should be cancelled while
the IRQ is put to disable vblank . However there is a known rmmod issue fixed
with “02d319e drm/amdgpu/virtual_dce: Remove the rmmod error message”.
Can you take a look at that patch or tell why or in which
When exclusive mode timeout happens, the VF is not active anymore. Exclusive
requests will be ignored by host. Unload kms or device fini also request
exclusive mode and it will get timeout again since no response received.
This only happens for exclusive mode timeout, so I didn’t put them in gen
Hi Christian,
Please help reviewing.
Hi Gary,
with this change debugfs will be cleaned up by DRM, we don’t need to handle it
anymore.
—
Sincerely Yours,
Pixel
On 08/11/2017, 11:29 AM, "amd-gfx on behalf of Pixel Ding"
wrote:
>Retry at drm_dev_register instead of amdgpu_device_init
Hi Christian,
I give a quick try according to your suggestion. It also works and cleaner. I
will send a new patch to revise the retry_init. Please help reviewing later.
—
Sincerely Yours,
Pixel
On 08/11/2017, 10:40 AM, "Ding, Pixel" wrote:
>Hi Christian,
>
>The retr
Hi Christian,
The retry_init only handles the failure caused by exclusive mode timeout. It
checks the MMIO to see if there’s exclusive mode timeout, and retry init if
there’s, otherwise just return error.
For exclusive timeout case, the host layer issues a FLR on this VF so driver
needn't clea
e sufficient.
>
>On the other hand in an SRIOV environment the host can resize the BAR
>before starting the client, so that whole stuff shouldn't be necessary
>in the first place.
>
>Regards,
>Christian.
>
>Am 06.11.2017 um 10:34 schrieb Ding, Pixel:
>> What b
.
—
Sincerely Yours,
Pixel
On 06/11/2017, 5:16 PM, "Christian König"
wrote:
>Am 06.11.2017 um 08:21 schrieb Ding, Pixel:
>> Hi Christian,
>>
>> The latest driver fails to load on SRIOV VF with xen hypervisor driver.
>>
>> +int amdgpu_devi
Hi Christian,
The latest driver fails to load on SRIOV VF with xen hypervisor driver.
+int amdgpu_device_resize_fb_bar(struct amdgpu_device *adev)
+{
+ u64 space_needed = roundup_pow_of_two(adev->mc.real_vram_size);
+ u32 rbar_size = order_base_2(((space_needed >> 20) | 1)) - 1;
+ u16
Hi Felix,
KFD will set HQD. These registers must be accessed in exclusive mode, otherwise
driver use KIQ to access them which causes world switch failure.
—
Sincerely Yours,
Pixel
On 02/11/2017, 9:49 PM, "Kuehling, Felix" wrote:
>Hi Pixel,
>
>I'm curious, which part of the KFD initial
Hi Oded,
Please ignore them so far. I need to consider more like that the probe is
included in retry init logics.
—
Sincerely Yours,
Pixel
On 01/11/2017, 1:53 PM, "amd-gfx on behalf of Pixel Ding"
wrote:
>Hi Oded,
>
>Please review.
>
>[PATCH 1/2] drm/amdkfd: initialise kgd field insid
I’m not for sure about this case you talked about. Assume that it could happen
and the KFD probe and init are invoked when loading it manually.
For baremetal device, it’s always correct.
For SRIOV virtual function, it doesn’t behave correctly with or without this
patch. KFD initialization also n
Hi Oded,
Would you please help reviewing the V2 patch?
—
Sincerely Yours,
Pixel
On 31/10/2017, 9:47 AM, "Pixel Ding" wrote:
>From: pding
>
>Move kfd probe prior to device init. Release exclusive mode
>after hw_init if kfd is not enabled.
>
>v2:
> - pass pdev param
>
>Signed-off-by: pd
we need to remember for the future
>not to access other adev fields, and that seems risky and not correct
>
>
>
>
>On Mon, Oct 30, 2017 at 10:30 AM, Ding, Pixel wrote:
>> Get your point. I don’t know why the test is passed however will revise
>> later.
>>
&
Get your point. I don’t know why the test is passed however will revise later.
I definitely want the know if KFD is enabled before device init. Any
suggestion? Or do you mind if the pdev is passed to probe in other way?
—
Sincerely Yours,
Pixel
On 30/10/2017, 4:20 PM, "Oded Gabbay" wro
Thanks:) I only got the ack for part 1…
—
Sincerely Yours,
Pixel
On 26/10/2017, 10:29 AM, "Deucher, Alexander" wrote:
>> -Original Message-----
>> From: Ding, Pixel
>> Sent: Wednesday, October 25, 2017 10:20 PM
>> To: amd-gfx@lists.freedesktop.org; D
Hi Alex,
Any concern about this patch? it’s split as suggested.
—
Sincerely Yours,
Pixel
On 25/10/2017, 10:17 AM, "Pixel Ding" wrote:
>From: pding
>
>Hi Alex,
>
>Split the wait_reset patch to 2. Part 2.
>
>please review.
>
>---
>
>Signed-off-by: pding
>---
> drivers/gpu/drm/amd/amdgpu/
Host rejects frequent exclusive mode requesting, otherwise an attacking VF may
cause problems. Sleep for a while to let host accept next request here.
—
Sincerely Yours,
Pixel
On 26/10/2017, 6:44 AM, "Alex Deucher" wrote:
>On Tue, Oct 24, 2017 at 10:19 PM, Pixel Ding wrote:
>> From: pd
Thanks Andres, revised in v2.
—
Sincerely Yours,
Pixel
On 23/10/2017, 11:44 PM, "amd-gfx on behalf of Andres Rodriguez"
wrote:
>
>
>On 2017-10-23 06:03 AM, Pixel Ding wrote:
>> From: pding
>>
>> The exclusive mode has real-time limitation in reality, such like being
>> done in 300ms.
ts.freedesktop.org] On Behalf
>> Of Pixel Ding
>> Sent: Monday, October 23, 2017 6:03 AM
>> To: amd-gfx@lists.freedesktop.org
>> Cc: Sun, Gary; Ding, Pixel; Li, Bingley
>> Subject: [PATCH 1/7] drm/amdgpu: release VF exclusive accessing after
>> hw_init
>&
d init failed, and make sure
>it is called before re-init
>
>
>-Original Message-
>From: Ding, Pixel
>Sent: 2017年10月24日 9:31
>To: Liu, Monk ; amd-gfx@lists.freedesktop.org; Xiao, Jack
>
>Cc: Sun, Gary ; Li, Bingley
>Subject: Re: [PATCH 5/7] drm/amdgpu:
Sorry for the misunderstanding. Will test with similar fix instead of 5248e3d9
directly later.
—
Sincerely Yours,
Pixel
On 24/10/2017, 9:31 AM, "Ding, Pixel" wrote:
>Tested with 5248e3d9, however issue is still reproduced in reinit case.
>
>+Jack,
>To bypass
To: amd-gfx@lists.freedesktop.org
>> Cc: Sun, Gary; Ding, Pixel; Li, Bingley
>> Subject: [PATCH 4/7] drm/amdgpu/virt: add function to check MMIO
>> accessing
>>
>> From: pding
>>
>> MMIO space can be blocked on virtualised device. Add this function
&g
t;Pixel Ding
>Sent: 2017年10月23日 18:04
>To: amd-gfx@lists.freedesktop.org
>Cc: Sun, Gary ; Ding, Pixel ; Li,
>Bingley
>Subject: [PATCH 6/7] drm/amdgpu/virt: add wait_reset virt ops
>
>From: pding
>
>Driver can use this interface to check if there's a function le
e fixed by that
>patch, please verify
>
>-Original Message-
>From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Pixel Ding
>Sent: 2017年10月23日 18:04
>To: amd-gfx@lists.freedesktop.org
>Cc: Sun, Gary ; Ding, Pixel ; Li,
>Bingley
>Subje
()
function name?
—
Sincerely Yours,
Pixel
On 18/10/2017, 10:08 PM, "Deucher, Alexander" wrote:
>> -Original Message-
>> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
>> Of Christian König
>> Sent: Wednesday, October 18, 20
Thanks Alex. Some comments inline.
—
Sincerely Yours,
Pixel
On 19/10/2017, 10:34 AM, "Alex Deucher" wrote:
>On Wed, Oct 18, 2017 at 9:44 PM, Pixel Ding wrote:
>> From: pding
>>
>> The post checking on scratch registers isn't reliable for virtual function.
>>
>> v2: only change in IGP r
Hi Alex,
This is the v2 patch as you suggested. Only fix the issue found in
amdgpu_bios.c.
Please review, thanks.
—
Sincerely Yours,
Pixel
On 19/10/2017, 9:44 AM, "amd-gfx on behalf of Pixel Ding"
wrote:
>From: pding
>
>The post checking on scratch registers isn't reliable for virt
estly have no idea what you do here.
>
>ASIC post is not something I've every worked on.
>
>It looks odd that you add/remove some static keyword here, but I can't
>judge the technical correctness.
>
>Monk, Alex what do you think of this?
>
>Sorry,
>Chris
Hi Christian,
Would you please take a look at this change? It’s to unify the VBIOS post
checking.
—
Sincerely Yours,
Pixel
On 18/10/2017, 10:25 AM, "Ding, Pixel" wrote:
>Hi all,
>
>Could someone review this patch?
>
>—
>Sincerely Yours,
>Pixel
>
&
Thanks Christian:) will change the return value as you suggested.
—
Sincerely Yours,
Pixel
On 18/10/2017, 3:05 PM, "Koenig, Christian" wrote:
>Am 18.10.2017 um 02:56 schrieb Pixel Ding:
>> From: pding
>>
>> Register accessing is performed when IRQ is disabled. Never sleep in
>> this fun
Hi all,
Could someone review this patch?
—
Sincerely Yours,
Pixel
On 17/10/2017, 4:06 PM, "amd-gfx on behalf of Ding, Pixel"
wrote:
>you can see the difference of function amdgpu_need_post. Generally speaking,
>there were 2 functions to check VBIOS posting, one
stian" wrote:
>Am 17.10.2017 um 10:38 schrieb Ding, Pixel:
>> [SNIP]
>>>> + if (seq >= wait_seq && wait_seq >= last_seq)
>>>> + break;
>>>> + if (seq <= last_seq &&
>>>> +
On 17/10/2017, 4:20 PM, "Koenig, Christian" wrote:
>Am 17.10.2017 um 08:37 schrieb Pixel Ding:
>> From: pding
>>
>> Register accessing is performed when IRQ is disabled. Never sleep in
>> this function.
>>
>> Known issue: dead sleep in many use cases of index/data registers.
>>
>> v2: wrap poll
posting
because SCRATCH registers are not the expected value. Is it clear?
—
Sincerely Yours,
Pixel
On 17/10/2017, 5:00 PM, "Liu, Monk" wrote:
>From the patch itself I still couldn't tell the difference
>
>-Original Message-
>From: Ding, Pixel
>Se
17年10月17日 14:38
>To: amd-gfx@lists.freedesktop.org; Liu, Monk ; Koenig,
>Christian
>Cc: Li, Bingley ; Sun, Gary ; Ding,
>Pixel
>Subject: [PATCH 2/3] drm/amdgpu: report more amdgpu_fence_info v2
>
>From: pding
>
>Only for GFX ring. This can help checking MCBP feature.
>
&
st_needed
>to check_post
>
>-Original Message-
>From: Pixel Ding [mailto:pixel.d...@amd.com]
>Sent: 2017年10月17日 14:38
>To: amd-gfx@lists.freedesktop.org; Liu, Monk ; Koenig,
>Christian
>Cc: Li, Bingley ; Sun, Gary ; Ding,
>Pixel
>Subject: [PATCH 1/3] drm/amdgpu: always
.
—
Sincerely Yours,
Pixel
On 16/10/2017, 9:25 AM, "Ding, Pixel" wrote:
>OK, I would keep both methods working together.
>—
>Sincerely Yours,
>Pixel
>
>
>
>
>
>
>
>On 13/10/2017, 6:04 PM, "Liu, Monk" wrote:
>
>>Why there will be rac
sleep waiting is synchroniz sleep, it just release CPU resource to other
>process/thread, so the order is guaranteed
>
>BR Monk
>
>-----Original Message-
>From: Ding, Pixel
>Sent: 2017年10月13日 17:39
>To: Liu, Monk ; amd-gfx@lists.freedesktop.org
>Cc: Li, Bingley
>
in IRQ CONTEXT, you can call
>wreg_kiq_busy() or wreg_no_kiq(),
>
>But don't just change the original function
>
>BR Monk
>
>-Original Message-
>From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Pixel Ding
>Sent: 2017年10月13日 1
Get it.
—
Sincerely Yours,
Pixel
On 13/10/2017, 5:28 PM, "Liu, Monk" wrote:
>@Ding, Pixel
>
>+ seq_printf(m, "Last preempted 0x%08x\n",
>+ le32_to_cpu(*(ring->fence_drv.cpu_addr + 2)));
>
>Please hand
On 13/10/2017, 5:16 PM, "Christian König"
wrote:
>Am 13.10.2017 um 10:26 schrieb Pixel Ding:
>> From: pding
>>
>> Register accessing is performed when IRQ is disabled. Never sleep in
>> this function.
>>
>> Known issue: dead sleep in many use cases of index/data registers.
>>
>> Signed-off-by
nts two dw after the address where the CPU writes the
>seqno. Where is the code which setups the CP to do this?
>
>As far as I can see that line should always print just zero (or some
>random number if the memory is actually not initialized to anything).
>
>Regards,
>Christian.
wb_get
>routine on detail
>
>BR Monk
>
>-Original Message-
>From: Ding, Pixel
>Sent: 2017年10月13日 17:19
>To: Koenig, Christian ;
>amd-gfx@lists.freedesktop.org; Liu, Monk
>Cc: Li, Bingley
>Subject: Re: [PATCH 3/4] drm/amdgpu: report preemption fence via
This patch is not for implementation of MCBP handled by driver itself. In SRIOV
use case the preemption is handle in host layer. What I do here is just check
if the preemption occurs, so there’s no code to handle it.
—
Sincerely Yours,
Pixel
On 13/10/2017, 5:03 PM, "Ding, Pixel&qu
Yes I tried smp_mb but it doesn’t help…
We will follow up this issue continuously until fix the root cause.
—
Sincerely Yours,
Pixel
On 13/10/2017, 5:17 PM, "Christian König"
wrote:
>Am 13.10.2017 um 10:26 schrieb Pixel Ding:
>> From: pding
>>
>> The polling memory was standalone in VRA
ring printing it like
>this is just pure speculation.
>
>Regards,
>Christian.
>
>Am 13.10.2017 um 10:41 schrieb Ding, Pixel:
>> Thanks Christian,
>>
>> I’m not sure if I get your point, but yes the preemption fence offset could
>> be changed.
>>
>> Is
Thanks Christian,
I’m not sure if I get your point, but yes the preemption fence offset could be
changed.
Is it OK to limit this information only for SRIOV VF on Tonga and Vega whose
format is known? It can help use to identify if MCBP is working correctly or
not.
—
Sincerely Yours,
Pixel
here some reason to use this macro?
---
Sincerely Yours,
Pixel
On 25/09/2017, 3:12 PM, "Ding, Pixel" wrote:
>Yes, it seems not related to the seen issue. The previous change simplifies
>the shift operations while the logic is same. Please ignore.
>
Original Message-
>From: Pixel Ding [mailto:pixel.d...@amd.com]
>Sent: Monday, September 25, 2017 2:16 PM
>To: amd-gfx@lists.freedesktop.org; Ding, Pixel ; Min,
>Frank ; Liu, Monk ; Deucher, Alexander
>
>Subject: [PATCH] drm/amdgpu: right shift 2 bits for
>SDMA_GFX_R
Yes, it seems not related to the seen issue. The previous change simplifies the
shift operations while the logic is same. Please ignore.
—
Sincerely Yours,
Pixel
On 25/09/2017, 3:08 PM, "Christian König"
wrote:
>NAK, that doesn't looks correct to me.
>
>> Both Tonga and Vega register S
+Xiangliang,
—
Sincerely Yours,
Pixel
On 25/09/2017, 2:38 PM, "Pixel Ding" wrote:
>Both Tonga and Vega register SPECs indicate that this registers only
>use 31:2 bits in DW. SRIOV test case immediately fails withtout this
>shift.
>
>v2: write to ADDR field
>
>Signed-off-by: Pixel Ding
>
Hi Xiangliang,
Please verify as Monk requested.
—
Sincerely Yours,
Pixel
On 04/05/2017, 4:22 PM, "Liu, Monk" wrote:
>Like I said, you need to test it on amd-staging-4.9 branch
>
>I don't think this patch is necessary unless you prove it
>
>-Original M
after FLR, so guest driver still need
>this cleaning,
>
>Please keep this patch in your AWS branch only.
>
>BR Monk
>
>-Original Message-
>From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Xiangliang Yu
>Sent: Thursday, May 04, 2017 2:
Xiangliang Yu
>Sent: Thursday, May 04, 2017 2:34 PM
>To: amd-gfx@lists.freedesktop.org
>Cc: Ding, Pixel ; Yu, Xiangliang
>Subject: [PATCH 2/6] drm/amdgpu: reset GDW, GWS and OA software copy to update
>them
>
>From: Pixel Ding
>
>Reset GDW, GWS and OA when SRIOV do res
ux Base Graphics
>SRDC Software Development
>_
>
>
>> -Original Message-
>> From: Pixel Ding [mailto:pixel.d...@amd.com]
>> Sent: Tuesday, February 07, 2017 14:07
>> To: Zhou, David(ChunMing); Koenig, Christian; Zhang, Jerry
&
_
>
>
>> -Original Message-
>> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of
>> Pixel Ding
>> Sent: Tuesday, February 07, 2017 13:49
>> To: Zhou, David(ChunMing); Koenig, Christian
>> Cc: Ding, Pixel; amd-gfx@lists.fr
ad of fence wait when reading/writing
>> register in interrupt context.
>>
>> Regards,
>> David Zhou
>>
>> On 2017年02月06日 15:55, Ding, Pixel wrote:
>>> Thanks you for your comments, David. I totally agree on your point.
>>>
>>> However, The
when the resolution wasn't a multiple of the
>character height.
>
>Regards,
>Christian.
>
>Am 06.02.2017 um 10:09 schrieb Ding, Pixel:
>> Hi Christian,
>>
>> The underlying host driver clears VF’s framebuffer when guest driver shake
>> hands with it, tha
ht.
>
>Regards,
>Christian.
>
>Am 06.02.2017 um 10:09 schrieb Ding, Pixel:
>> 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
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
have been changed
>when you handle it in schedule work after interrupt.
>
>Regards,
>David Zhou
>
>-Original Message-
>From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Pixel Ding
>Sent: Monday, February 06, 2017 3:00 PM
>To: amd-gfx
Reviewed-by: Pixel Ding
—
Sincerely Yours,
Pixel
On 19/01/2017, 5:46 PM, "amd-gfx on behalf of Xiangliang Yu"
wrote:
>If start all VFs at same time, the GPU hypervisor need more time
>to handle mailbox access. Set it to five seconds according to
>test experience.
>
>Signed-off-by: Xi
Christian,
Thank you for the quick comments. The revision is coming soon.
—
Sincerely Yours,
Pixel
On 18/01/2017, 9:26 PM, "Christian König" wrote:
>Am 18.01.2017 um 11:37 schrieb Pixel Ding:
>> From: Ding Pixel
>>
>> Return success when the ring is
71 matches
Mail list logo
