Hi folks
In commit d1c234e2cd, arm64 is granted to build kfd. Currently, it is physical
cpu id that is used for building the x86_64 vcrat, but logical cpu id is used
instead for arm64, though the function name requires apicid. Can we use the
physical id for both arches if it really has an up-hand
amdgpu_bo_destroy had a bug by calling amdgpu_bo_unref outside mutex_lock.
If amdgpu_device_recover_vram executed between amdgpu_bo_unref and
list_del_init,
it would get NULL of shadow->parent, then caused Call Trace and GPU reset
failed.
Change-Id: I41d7b54605e613e87ee03c3ad89c191063c19230
Sign
Am 15.04.19 um 23:17 schrieb Eric Anholt:
Andrey Grodzovsky writes:
From: Christian König
We now destroy finished jobs from the worker thread to make sure that
we never destroy a job currently in timeout processing.
By this we avoid holding lock around ring mirror list in drm_sched_stop
whic
Am 16.04.19 um 09:17 schrieb wentalou:
amdgpu_bo_destroy had a bug by calling amdgpu_bo_unref outside mutex_lock.
If amdgpu_device_recover_vram executed between amdgpu_bo_unref and
list_del_init,
it would get NULL of shadow->parent, then caused Call Trace and GPU reset
failed.
Change-Id: I41d7
amdgpu_bo_destroy had a bug by calling amdgpu_bo_unref outside mutex_lock.
If amdgpu_device_recover_vram executed between amdgpu_bo_unref and
list_del_init,
it would get NULL of shadow->parent, then caused Call Trace and GPU reset
failed.
Change-Id: I41d7b54605e613e87ee03c3ad89c191063c19230
Sign
Am 16.04.19 um 12:46 schrieb wentalou:
amdgpu_bo_destroy had a bug by calling amdgpu_bo_unref outside mutex_lock.
If amdgpu_device_recover_vram executed between amdgpu_bo_unref and
list_del_init,
it would get NULL of shadow->parent, then caused Call Trace and GPU reset
failed.
Change-Id: I41d7
On 2019-04-15 10:27 a.m., Nicholas Kazlauskas wrote:
> DC and DM already support DRM_FORMAT_RGB565, it's just missing from the
> list of valid formats.
>
> Cc: Harry Wentland
> Cc: Leo Li
> Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/di
On 4/16/19 9:28 AM, Wentland, Harry wrote:
> On 2019-04-15 10:27 a.m., Nicholas Kazlauskas wrote:
>> DC and DM already support DRM_FORMAT_RGB565, it's just missing from the
>> list of valid formats.
>>
>> Cc: Harry Wentland
>> Cc: Leo Li
>> Signed-off-by: Nicholas Kazlauskas
>
> Reviewed-by: Ha
On 4/16/19 5:47 AM, Christian König wrote:
> Am 15.04.19 um 23:17 schrieb Eric Anholt:
>> Andrey Grodzovsky writes:
>>
>>> From: Christian König
>>>
>>> We now destroy finished jobs from the worker thread to make sure that
>>> we never destroy a job currently in timeout processing.
>>> By this w
Am 16.04.19 um 16:36 schrieb Grodzovsky, Andrey:
> On 4/16/19 5:47 AM, Christian König wrote:
>> Am 15.04.19 um 23:17 schrieb Eric Anholt:
>>> Andrey Grodzovsky writes:
>>>
From: Christian König
We now destroy finished jobs from the worker thread to make sure that
we never des
On 4/16/19 10:43 AM, Koenig, Christian wrote:
> Am 16.04.19 um 16:36 schrieb Grodzovsky, Andrey:
>> On 4/16/19 5:47 AM, Christian König wrote:
>>> Am 15.04.19 um 23:17 schrieb Eric Anholt:
Andrey Grodzovsky writes:
> From: Christian König
>
> We now destroy finished jobs fr
>> Hmm. My MST-foo is admittedly weak so I'm not sure. A quick trawl through
>> the spec didn't provide any solid explanations either :( However eg.
>> "Figure 2-83: Example Multi-function MST Branch-Sink Device Enumeration"
>> in the DP 1.4 spec does appear to show kind of virtual DPCD thing behin
On 4/16/19 10:58 AM, Grodzovsky, Andrey wrote:
> On 4/16/19 10:43 AM, Koenig, Christian wrote:
>> Am 16.04.19 um 16:36 schrieb Grodzovsky, Andrey:
>>> On 4/16/19 5:47 AM, Christian König wrote:
Am 15.04.19 um 23:17 schrieb Eric Anholt:
> Andrey Grodzovsky writes:
>
>> From: Chris
From: Leo Li
This is needed by DC to support EDID emulation on USB-C ports.
CC: Samson Tam
CC: Harry Wentland
CC: Alex Deucher
Signed-off-by: Leo Li
---
drivers/gpu/drm/amd/include/atomfirmware.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/include/atomfirmware.h
Am 16.04.19 um 17:42 schrieb Grodzovsky, Andrey:
> On 4/16/19 10:58 AM, Grodzovsky, Andrey wrote:
>> On 4/16/19 10:43 AM, Koenig, Christian wrote:
>>> Am 16.04.19 um 16:36 schrieb Grodzovsky, Andrey:
On 4/16/19 5:47 AM, Christian König wrote:
> Am 15.04.19 um 23:17 schrieb Eric Anholt:
>>>
Could someone review this patch? Thanks!!
Regards,
Amber
On 2019-04-12 4:10 p.m., Lin, Amber wrote:
> Method of getting firmware version is the same across ASICs, so remove
> them from ASIC-specific files and create one in amdgpu_amdkfd.c. This new
> created get_fw_version simply reads fw_version
On Tue, Apr 16, 2019 at 03:28:24PM +, Li, Sun peng (Leo) wrote:
> >> Hmm. My MST-foo is admittedly weak so I'm not sure. A quick trawl through
> >> the spec didn't provide any solid explanations either :( However eg.
> >> "Figure 2-83: Example Multi-function MST Branch-Sink Device Enumeration"
This is a nice cleanup.
With this change, kfd2kgd_calls.get_fw_version is no longer used. You
should remove it from kgd_kfd_interface.h. Also move the enum
kgd_engine_type to amdgpu_amdkfd.h at the same time.
With that fixed, this patch is Reviewed-by: Felix Kuehling
On 2019-04-12 4:10 p.m.,
On 2019-04-16 2:44 a.m., Christian König wrote:
>>
>> It's not a high priority as I'm not aware of any applications that
>> actually make use of the cache information.
>>
> Which raises the question why we have done this in the first place?
> When nobody is using it could we just remove the inter
From: Christian König
Don't block others while waiting for the fences to finish, concurrent
submission is perfectly valid in this case and holding the lock can
prevent killed applications from terminating.
Signed-off-by: Christian König
Reviewed-by: Nicholas Kazlauskas
---
drivers/gpu/drm/amd
Patch '5edb0c9b Fix deadlock with display during hanged ring recovery'
was accidentaly removed during one of DALs code merges.
v4: Update description.
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Nicholas Kazlauskas
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 15 +--
1
From: Christian König
We now destroy finished jobs from the worker thread to make sure that
we never destroy a job currently in timeout processing.
By this we avoid holding lock around ring mirror list in drm_sched_stop
which should solve a deadlock reported by a user.
v2: Remove unused variable
For later driver's reference to see if the fence is signaled.
v2: Move parent fence put to resubmit jobs.
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
---
drivers/gpu/drm/scheduler/sched_main.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/dri
Also reject TDRs if another one already running.
v2:
Stop all schedulers across device and entire XGMI hive before
force signaling HW fences.
Avoid passing job_signaled to helper fnctions to keep all the decision
making about skipping HW reset in one place.
v3:
Fix SW sched. hang after non HW res
Make it mandatory for dynamic dma-buf callbacks to be called with the
reservation lock held.
For static dma-buf exporters we still have the fallback of using cached sgt.
v2: reordered
v3: rebased on sgt caching
v4: use the cached sgt when possible
Signed-off-by: Christian König
---
drivers/dma
Hi everybody,
core idea in this patch set is that DMA-buf importers can now provide an
optional invalidate callback. Using this callback and the reservation object
exporters can now avoid pinning DMA-buf memory for a long time while sharing it
between devices.
I've already send out an older ve
Each importer can now provide an invalidate_mappings callback.
This allows the exporter to provide the mappings without the need to pin
the backing store.
v2: don't try to invalidate mappings when the callback is NULL,
lock the reservation obj while using the attachments,
add helper to se
Pipeline removal of the BOs backing store when no placement is given
during validation.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 41d07faa2eae
To allow a smooth transition from pinning buffer objects to dynamic
invalidation we first start to cache the sg_table for an attachment
unless the driver explicitly says to not do so.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 24
include/linux/dma-bu
Add function variants which can be called with the reservation lock
already held.
v2: reordered, add lockdep asserts, fix kerneldoc
v3: rebased on sgt caching
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 63 +++
include/linux/dma-buf.h |
Pin and unpin the DMA-buf exported BOs only on demand and invalidate all
DMA-buf mappings when the underlying BO moves.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 5 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 73 --
2 files changed,
Add optional explicit pinning callbacks instead of implicitly assume the
exporter pins the buffer when a mapping is created.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 39 +++
include/linux/dma-buf.h | 37 +++--
This way we can even pipeline imported BO evictions.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 18 +-
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 895d77d799
Allow for invalidation of imported DMA-bufs.
v2: add dma_buf_pin/dma_buf_unpin support
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 24 ++
2 files changed, 30 insertions(+)
diff --git
The caching of SGT's is actually quite harmful and should probably removed
altogether when all drivers are audited.
Start by providing a separate DMA-buf export implementation in amdgpu. This is
also a prerequisite of unpinned DMA-buf handling.
v2: fix unintended recursion, remove debugging lefto
That is now done by the DMA-buf helpers instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_prime.c | 76 -
1 file changed, 16 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 1fadf5d5ed33
Instead of relying on the DRM functions just implement our own import
functions. This prepares support for taking care of unpinned DMA-buf.
v2: enable for all exporters, not just amdgpu, fix invalidation
handling, lock reservation object while setting callback
v3: change to new dma_buf attach
> -Original Message-
> From: sunpeng...@amd.com
> Sent: Tuesday, April 16, 2019 12:00 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Li, Sun peng (Leo) ; Tam, Samson
> ; Wentland, Harry ;
> Deucher, Alexander
> Subject: [PATCH] drm/amd/include: Add USB_C_TYPE to
> atom_encoder_cap_defs
>
>
Sorry for the slow response, I've been really busy ;_;
On Fri, 2019-04-12 at 12:05 -0400, sunpeng...@amd.com wrote:
> From: Leo Li
>
> In preparation for adding aux devices for DP MST:
>
> 1. A non-cyclic idr is used for the device minor version. That way,
>hotplug cycling MST devices won't
On Fri, 2019-04-12 at 12:05 -0400, sunpeng...@amd.com wrote:
> From: Ville Syrjälä
>
> Expose AUX devices for MST ports, similar to how they are exposed for
> SST.
>
> The registered device will have it's MST port path appended in order to
> identify it. i.e. /dev/drm_dp_aux4_mst:0-2-1
>
> So f
Ping...
Hi Christian and Alex
Can you help have a review on it? Thanks in advance.
Best Regards
Yintian Tao
-Original Message-
From: Yintian Tao
Sent: Tuesday, April 16, 2019 2:09 PM
To: amd-gfx@lists.freedesktop.org
Cc: Tao, Yintian
Subject: [PATCH] drm/amdgpu: disable DRIVER_ATOMI
Acked-by: Alex Deucher
On Tue, Apr 16, 2019 at 2:09 AM Yintian Tao wrote:
>
> Under SRIOV, we need disable DRIVER_ATOMIC.
> Otherwise, it will trigger WARN_ON at drm_universal_plane_init.
>
> Change-Id: I96a78d6e45b3a67ab9b9534e7071ae5daacc0f4f
> Signed-off-by: Yintian Tao
> ---
> drivers/gpu/
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of hersen wu
> Sent: Monday, April 15, 2019 10:18 PM
> To: amd-gfx@lists.freedesktop.org; Deucher, Alexander
>
> Cc: Wu, Hersen
> Subject: [PATCH 1/2] SWDEV-183622 4k@60hz dp monitor always fli
Patch is Tested-by: Likun Gao
-Original Message-
From: amd-gfx On Behalf Of Huang, Ray
Sent: Wednesday, April 17, 2019 2:26 PM
To: Wu, Hersen ; amd-gfx@lists.freedesktop.org; Deucher,
Alexander
Cc: Wu, Hersen
Subject: RE: [PATCH 1/2] SWDEV-183622 4k@60hz dp monitor always flicking
>
44 matches
Mail list logo
