On Tue, Feb 5, 2019 at 4:43 PM Kuehling, Felix wrote:
>
> The headline should start with "drm/amdgpu". This change is not KFD
> specific.
>
> I think Alex should review this change.
If we are going to change it, let's be consistent for all IPs (e.g.,
gfx, vcn, etc.).
Alex
>
> Regards,
>Feli
On Tue, Feb 5, 2019 at 4:38 PM Kasiviswanathan, Harish
wrote:
>
> The new Vega series GPU cards have in-built bridges. To get the pcie
> speed and width supported by the platform walk the hierarchy and get the
> slowest link.
>
> Change-Id: I3196d158b0c614cbb5d7a34c793a58cb95322d32
> Signed-off-by
On 2019-02-05 11:00 a.m., Koenig, Christian wrote:
> Ah! The initial clear of the PDs is syncing to everything!
Right. Using amdgpu_sync_resv(... AMDGPU_FENCE_OWNER_VM ...) in
amdgpu_vm_clear_bo seems to help. But if I also change the
amdgpu_job_submit to use AMDGPU_FENCE_OWNER_VM, I get a VM fa
Hi Dave, Daniel,
Fixes for 5.0:
- Fix missing freesync properties on eDP
- Fix locking in pasid mgr
- Fix clang warning in kfd
- DC/powerplay fix
- Fix reported rev ids on raven
- Doorbell fix for vega20
The following changes since commit 6e11ea9de9576a644045ffdc2067c09bc2012eda:
drm/amdgpu: T
Use HMM helper function hmm_vma_fault() to get physical pages backing
userptr and start CPU page table update track of those pages. Then use
hmm_vma_range_done() to check if those pages are updated before
amdgpu_cs_submit for gfx or before user queues are resumed for kfd.
If userptr pages are upda
Hi Christian,
I will submit new patch for review, my comments embedded inline below.
Thanks,
Philip
On 2019-02-05 1:09 p.m., Koenig, Christian wrote:
> Am 05.02.19 um 18:25 schrieb Yang, Philip:
>> [SNIP]+
+ if (r == -ERESTARTSYS) {
+ if (!--tries) {
+ DRM_ERR
The headline should start with "drm/amdgpu". This change is not KFD
specific.
I think Alex should review this change.
Regards,
Felix
On 2019-02-05 3:31 p.m., Zhao, Yong wrote:
> Indicate that the doorbell offset and range is in dwords.
>
> Change-Id: Ib0f2564ffa7b1940ffb8725cdc03f662184f5436
The new Vega series GPU cards have in-built bridges. To get the pcie
speed and width supported by the platform walk the hierarchy and get the
slowest link.
Change-Id: I3196d158b0c614cbb5d7a34c793a58cb95322d32
Signed-off-by: Harish Kasiviswanathan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |
v2: Fix SMU message format
Send override message after SMU enable features
Change-Id: Ib880c83bc7aa12be370cf6619acfe66e12664c9c
Signed-off-by: Harish Kasiviswanathan
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c | 45 +-
1 file changed, 27 insertions(+), 18 delet
Reserved doorbells for SDMA IH and VCN were not properly masked out
when allocating doorbells for CP user queues. This patch fixed that.
Change-Id: I670adfc3fd7725d2ed0bd9665cb7f69f8b9023c2
Signed-off-by: Yong Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c| 17 +++
drivers/g
We can directly calculate the sdma doorbell index in the process doorbell
pages through the doorbell_index structure in amdgpu_device, so no need
to cache them in kgd2kfd_shared_resources any more, resulting in more
portable code.
Change-Id: Ic657799856ed0256f36b01e502ef0cab263b1f49
Signed-off-by:
Because CP can use all doorbells outside the ones reserved for SDMA, IH,
and VCN, so the value set to CP_MEC_DOORBELL_RANGE_UPPER should be the
maximal index possible in a page.
Change-Id: I402a56ce9a80e6c2ed2f96be431ae71ca88e73a4
Signed-off-by: Yong Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_do
They are no longer used, so delete them to avoid confusion.
Change-Id: I3cf23fe7110ff88f53c0c279b2b4ec8d1a53b87c
Signed-off-by: Yong Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_doorbell.h | 8
drivers/gpu/drm/amd/amdgpu/vega10_reg_init.c | 2 --
drivers/gpu/drm/amd/amdgpu/vega20_reg_init
Indicate that the doorbell offset and range is in dwords.
Change-Id: Ib0f2564ffa7b1940ffb8725cdc03f662184f5436
Signed-off-by: Yong Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_doorbell.h | 3 ++-
drivers/gpu/drm/amd/amdgpu/nbio_v6_1.c | 6
Am 05.02.19 um 18:25 schrieb Yang, Philip:
> [SNIP]+
>>> + if (r == -ERESTARTSYS) {
>>> + if (!--tries) {
>>> + DRM_ERROR("Possible deadlock? Retry too many times\n");
>>> + return -EDEADLK;
>>> + }
>>> + goto restart;
>> You really need to restart the
Den 05.02.2019 17.31, skrev Daniel Vetter:
> On Tue, Feb 05, 2019 at 11:20:55AM +0100, Noralf Trønnes wrote:
>>
>>
>> Den 05.02.2019 10.11, skrev Daniel Vetter:
>>> On Mon, Feb 04, 2019 at 06:35:28PM +0100, Noralf Trønnes wrote:
Den 04.02.2019 16.41, skrev Daniel Vetter:
> On S
On 2019-02-05 4:45 p.m., Christian König wrote:
> Possible, but unlikely.
>
> That sounds more like a reference counting problem where something is
> killing the BO while it is still on the LRU.
FWIW, I've hit this twice now today, whereas I don't remember ever
hitting it before (not 100% sure th
Hi Christian,
My comments are embedded below. I will submit another patch to address
those.
Thanks,
Philip
On 2019-02-05 6:52 a.m., Christian König wrote:
> Am 04.02.19 um 19:23 schrieb Yang, Philip:
>> Use HMM helper function hmm_vma_fault() to get physical pages backing
>> userptr and start C
On Tue, Feb 05, 2019 at 11:20:55AM +0100, Noralf Trønnes wrote:
>
>
> Den 05.02.2019 10.11, skrev Daniel Vetter:
> > On Mon, Feb 04, 2019 at 06:35:28PM +0100, Noralf Trønnes wrote:
> >>
> >>
> >> Den 04.02.2019 16.41, skrev Daniel Vetter:
> >>> On Sun, Feb 03, 2019 at 04:41:56PM +0100, Noralf Trø
Ah! The initial clear of the PDs is syncing to everything!
Ok, that is easy to fix.
Christian.
Am 05.02.19 um 16:49 schrieb Kuehling, Felix:
> I saw a backtrace from the GPU scheduler when I was debugging this yesterday,
> but those backtraces never tell us where the command submission came fro
I saw a backtrace from the GPU scheduler when I was debugging this yesterday,
but those backtraces never tell us where the command submission came from. It
could be memory initialization, or some migration at buffer-validation.
Basically, any command submission triggered by page table allocation
Possible, but unlikely.
That sounds more like a reference counting problem where something is
killing the BO while it is still on the LRU.
Need to double check how that can happen,
Christian.
Am 05.02.19 um 16:02 schrieb Michel Dänzer:
Hit this with an amdgpu piglit run today, see the attach
Am 05.02.19 um 16:20 schrieb Kuehling, Felix:
This may cause regressions in KFD if PT BO allocation can trigger
eviction fences.
I don't think that can happen, but need to double check as well.
Otherwise allocating page tables could try to evict other page tables from the
same process and that
> > This may cause regressions in KFD if PT BO allocation can trigger
> > eviction fences.
> I don't think that can happen, but need to double check as well.
>
> Otherwise allocating page tables could try to evict other page tables from
> the same process and that seriously doesn't make much sen
Hit this with an amdgpu piglit run today, see the attached dmesg
excerpt. It's ttm_bo_ref_bug() being called from ttm_bo_del_from_lru().
Maybe this is still fallout from the "cleanup setting bulk_movable" change?
--
Earthling Michel Dänzer | http://www.amd.com
Libre
On 2019-02-04 3:16 a.m., Vishwakarma, Pratik wrote:
> Remove extraneous parentheses around the comparison
> to silence this warning
>
> Signed-off-by: Pratik Vishwakarma
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.c | 2 +-
> 1 file changed, 1
Am 04.02.19 um 19:23 schrieb Yang, Philip:
Use HMM helper function hmm_vma_fault() to get physical pages backing
userptr and start CPU page table update track of those pages. Then use
hmm_vma_range_done() to check if those pages are updated before
amdgpu_cs_submit for gfx or before user queues ar
Am 04.02.19 um 19:23 schrieb Yang, Philip:
There is circular lock between gfx and kfd path with HMM change:
lock(dqm) -> bo::reserve -> amdgpu_mn_lock
To avoid this, move init/unint_mqd() out of lock(dqm), to remove nested
locking between mmap_sem and bo::reserve. The locking order
is: bo::reser
Am 05.02.19 um 01:33 schrieb Kuehling, Felix:
On 2019-02-04 3:17 p.m., Kuehling, Felix wrote:
This may cause regressions in KFD if PT BO allocation can trigger
eviction fences. The previous call to amdgpu_vm_alloc_pts was in a
context where we had temporarily removed the eviction fence. PT BO
al
This may cause regressions in KFD if PT BO allocation can trigger
eviction fences.
I don't think that can happen, but need to double check as well.
Otherwise allocating page tables could try to evict other page tables
from the same process and that seriously doesn't make much sense.
Do you k
Am 05.02.19 um 10:21 schrieb S, Shirish:
> On 2/4/2019 9:00 PM, Liu, Leo wrote:
>> On 2/4/19 7:49 AM, Koenig, Christian wrote:
>>> Am 04.02.19 um 13:44 schrieb S, Shirish:
vce ring test fails during resume since mmVCE_RB_RPTR*
is not intitalized/updated.
Hence start vce block be
Den 05.02.2019 10.11, skrev Daniel Vetter:
> On Mon, Feb 04, 2019 at 06:35:28PM +0100, Noralf Trønnes wrote:
>>
>>
>> Den 04.02.2019 16.41, skrev Daniel Vetter:
>>> On Sun, Feb 03, 2019 at 04:41:56PM +0100, Noralf Trønnes wrote:
The only thing now that makes drm_dev_unplug() special is that
On 2/4/2019 9:00 PM, Liu, Leo wrote:
> On 2/4/19 7:49 AM, Koenig, Christian wrote:
>> Am 04.02.19 um 13:44 schrieb S, Shirish:
>>> vce ring test fails during resume since mmVCE_RB_RPTR*
>>> is not intitalized/updated.
>>>
>>> Hence start vce block before ring test.
>> Mhm, I wonder why this ever w
On Mon, Feb 04, 2019 at 06:35:28PM +0100, Noralf Trønnes wrote:
>
>
> Den 04.02.2019 16.41, skrev Daniel Vetter:
> > On Sun, Feb 03, 2019 at 04:41:56PM +0100, Noralf Trønnes wrote:
> >> The only thing now that makes drm_dev_unplug() special is that it sets
> >> drm_device->unplugged. Move this co
Hello David Francis,
This is a semi-automatic email about new static checker warnings.
The patch 8a48b44cd00f: "drm/amd/display: Call into DC once per
multiplane flip" from Dec 11, 2018, leads to the following Smatch
complaint:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:47
35 matches
Mail list logo
