Re: [PATCH 4/7] drm/radeon: Fill out gem_object->resv

On Tue, Jun 25, 2019 at 10:42:05PM +0200, Daniel Vetter wrote: > That way we can ditch our gem_prime_res_obj implementation. Since ttm > absolutely needs the right reservation object all the boilerplate is > already there and we just have to wire it up correctly. > > Note that gem/prime doesn't

[PATCH 4/7] drm/radeon: Fill out gem_object->resv

That way we can ditch our gem_prime_res_obj implementation. Since ttm absolutely needs the right reservation object all the boilerplate is already there and we just have to wire it up correctly. Note that gem/prime doesn't care when we do this, as long as we do it before the bo is registered and

Re: [PATCH 1/1] drm/amdkfd: Add queue status indicator to HQD dump

On 2019-06-24 9:41 a.m., Zeng, Oak wrote: > Hi Felix, > > See one comment inline > > Regards, > Oak > > -Original Message- > From: amd-gfx On Behalf Of Kuehling, > Felix > Sent: Friday, June 21, 2019 3:48 PM > To: amd-gfx@lists.freedesktop.org > Cc: Kuehling, Felix > Subject: [PATCH

Re: [PATCH 4/6] drm/amd/amdgpu: Check stream in amdgpu_dm_commit_planes

On 6/24/19 11:15 AM, Ernst Sjöstrand wrote: > Reported by smatch: > amdgpu_dm.c:5637 amdgpu_dm_commit_planes() error: we previously assumed > 'acrtc_state->stream' could be null > This seems to be checked for null pretty consistently elsewhere. > > Signed-off-by: Ernst Sjöstrand This is

Re: [PATCH] drm/amdgpu: Don't skip display settings in hwmgr_resume()

On Thu, Jun 20, 2019 at 7:22 PM Lyude Paul wrote: > > I'm not entirely sure why this is, but for some reason: > > 921935dc6404 ("drm/amd/powerplay: enforce display related settings only on > needed") > > Breaks runtime PM resume on the Radeon PRO WX 3100 (Lexa) in one the > pre-production

Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v12

On Tue, Jun 25, 2019 at 02:46:49PM +0200, Christian König wrote: > On the exporter side we add optional explicit pinning callbacks. If those > callbacks are implemented the framework no longer caches sg tables and the > map/unmap callbacks are always called with the lock of the reservation object

[PATCH xf86-video-ati] present: Check that we can get a KMS FB for flipping

From: Michel Dänzer This can legitimately fail if the pixmap's storage is shared from another device, e.g. when using PRIME render offloading. (Ported from amdgpu commit 7d3fef72e0c871e1677e9e544f4cae5e238b5c52) Signed-off-by: Michel Dänzer --- src/radeon.h | 1 +

RE: [PATCH] drm/amd/powerplay: add missing smu_get_clk_info_from_vbios() call

The comments below is actually for check_pptable, instead of get_clk_info_from vbios. Please adjust the comments as well. * check if the format_revision in vbios is up to pptable header * version, and the structure size is not 0. */ With that fixed, the patch is Reviewed-by: Hawking Zhang

Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v12

On Tue, Jun 25, 2019 at 05:13:42PM +0200, Christian König wrote: > Am 25.06.19 um 17:07 schrieb Daniel Vetter: > > On Tue, Jun 25, 2019 at 4:45 PM Christian König > > wrote: > > > > > -if (attach->sgt) > > > > > +if (attach->sgt) { > > > > > +if

RE: [PATCH 2/2] drm/amdgpu/display: switch udelay to msleep

Series is Reviewed-by: Hawking Zhang Regards, Hawking -Original Message- From: amd-gfx On Behalf Of Alex Deucher Sent: 2019年6月25日 21:59 To: amd-gfx@lists.freedesktop.org Cc: Deucher, Alexander Subject: [PATCH 2/2] drm/amdgpu/display: switch udelay to msleep We may need to sleep for up

Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v12

Am 25.06.19 um 17:07 schrieb Daniel Vetter: On Tue, Jun 25, 2019 at 4:45 PM Christian König wrote: Am 25.06.19 um 16:35 schrieb Daniel Vetter: Hi Christian, On Tue, Jun 25, 2019 at 02:46:49PM +0200, Christian König wrote: On the exporter side we add optional explicit pinning callbacks. If

[PATCH] drm/amd/powerplay: add missing smu_get_clk_info_from_vbios() call

This seems a merge error. Change-Id: I67389739512c8297da1187428682cc59f560ab03 Signed-off-by: Evan Quan --- drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c

Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v12

On Tue, Jun 25, 2019 at 4:45 PM Christian König wrote: > > Am 25.06.19 um 16:35 schrieb Daniel Vetter: > > Hi Christian, > > > > On Tue, Jun 25, 2019 at 02:46:49PM +0200, Christian König wrote: > >> On the exporter side we add optional explicit pinning callbacks. If those > >> callbacks are

Re: [PATCH 08/24] drm/amd/display: add audio related regs

Thanks for catching that, it was left in by mistake when trying to fix some compile issues. I will push a patch to remove it Bhawan On 2019-06-25 12:15 a.m., Dave Airlie wrote: > On Fri, 7 Jun 2019 at 06:55, Bhawanpreet Lakha > wrote: >> From: Charlene Liu >> >> Signed-off-by: Charlene Liu

Re: [PATCH 1/2] drm/amdgpu/powerplay: FEATURE_MASK is 64 bit so use ULL

On 6/25/19 9:58 AM, Alex Deucher wrote: > ULL is needed for 32 bit arches. > > Signed-off-by: Alex Deucher Reviewed-by: Nicholas Kazlauskas > --- > drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 2 +- > drivers/gpu/drm/amd/powerplay/vega20_ppt.c | 2 +- > 2 files changed, 2 insertions(+), 2

Re: [PATCH 2/2] drm/amdgpu/display: switch udelay to msleep

On 6/25/19 9:58 AM, Alex Deucher wrote: > We may need to sleep for up to 80ms: > > /* First DPCD read after VDD ON can fail if the particular board > * does not have HPD pin wired correctly. So if DPCD read fails, > * which it should never happen, retry a few times. Target worst > * case

Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v12

Am 25.06.19 um 16:35 schrieb Daniel Vetter: Hi Christian, On Tue, Jun 25, 2019 at 02:46:49PM +0200, Christian König wrote: On the exporter side we add optional explicit pinning callbacks. If those callbacks are implemented the framework no longer caches sg tables and the map/unmap callbacks

Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v12

Hi Christian, On Tue, Jun 25, 2019 at 02:46:49PM +0200, Christian König wrote: > On the exporter side we add optional explicit pinning callbacks. If those > callbacks are implemented the framework no longer caches sg tables and the > map/unmap callbacks are always called with the lock of the

Re: [PATCH] drm/amd/display: Use msleep instead of udelay for 8ms wait

Am 25.06.19 um 16:12 schrieb Lucas Stach: > Hi Harry, > > Am Dienstag, den 25.06.2019, 10:00 -0400 schrieb Harry Wentland: >> arm32's udelay only allows values up to 2000 microseconds. msleep >> does the trick for us here as there is no problem if this isn't >> microsecond accurate and takes a tad

Re: [PATCH] drm/amd/display: Use msleep instead of udelay for 8ms wait

Hi Harry, Am Dienstag, den 25.06.2019, 10:00 -0400 schrieb Harry Wentland: > arm32's udelay only allows values up to 2000 microseconds. msleep > does the trick for us here as there is no problem if this isn't > microsecond accurate and takes a tad longer. A "tad" longer in this case means likely

[PATCH] drm/amd/display: Use msleep instead of udelay for 8ms wait

arm32's udelay only allows values up to 2000 microseconds. msleep does the trick for us here as there is no problem if this isn't microsecond accurate and takes a tad longer. Signed-off-by: Harry Wentland --- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 +- 1 file changed, 1 insertion(+),

[PATCH 2/2] drm/amdgpu/display: switch udelay to msleep

We may need to sleep for up to 80ms: /* First DPCD read after VDD ON can fail if the particular board * does not have HPD pin wired correctly. So if DPCD read fails, * which it should never happen, retry a few times. Target worst * case scenario of 80 ms. */ Switch udelay to msleep to avoid

[PATCH 1/2] drm/amdgpu/powerplay: FEATURE_MASK is 64 bit so use ULL

ULL is needed for 32 bit arches. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 2 +- drivers/gpu/drm/amd/powerplay/vega20_ppt.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c

Re: [PATCH] drm/amd/powerplay: support runtime ppfeatures setting on Navi10

Reviewed-by: Alex Deucher From: amd-gfx on behalf of Evan Quan Sent: Tuesday, June 25, 2019 4:49 AM To: amd-gfx@lists.freedesktop.org Cc: Quan, Evan Subject: [PATCH] drm/amd/powerplay: support runtime ppfeatures setting on Navi10 Implement Navi10 backend for

[PATCH 6/6] drm/amdgpu: add independent DMA-buf import v7

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

[PATCH 3/6] drm/ttm: use the parent resv for ghost objects v2

This way we can even pipeline imported BO evictions. v2: Limit this to only cases when the parent object uses a separate reservation object as well. This fixes another OOM problem. Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_bo_util.c | 20 +++- 1 file

[PATCH 4/6] drm/amdgpu: use allowed_domains for exported DMA-bufs

Avoid that we ping/pong the buffers when we stop to pin DMA-buf exports by using the allowed domains for exported buffers. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git

[PATCH 2/6] drm/ttm: remove the backing store if no placement is given

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

[PATCH 5/6] drm/amdgpu: add independent DMA-buf export v6

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

[PATCH 1/6] dma-buf: add dynamic DMA-buf handling v12

On the exporter side we add optional explicit pinning callbacks. If those callbacks are implemented the framework no longer caches sg tables and the map/unmap callbacks are always called with the lock of the reservation object held. On the importer side we add an optional invalidate callback.

Re: [PATCH v2] drm/amdgpu: fix scheduler timeout calc

please ignore this mail. I'll prepare v3 patch to simplify code logic. 获取 Outlook for Android From: Cui, Flora Sent: Tuesday, June 25, 2019 5:43:38 PM To: amd-gfx@lists.freedesktop.org Cc: Cui, Flora Subject: [PATCH v2] drm/amdgpu: fix

Re: [PATCH libdrm 0/9] amdgpu:

On 2019-06-25 11:44 a.m., Koenig, Christian wrote: > Am 25.06.19 um 10:02 schrieb Michel Dänzer: >> On 2019-06-24 7:31 p.m., Christian König wrote: >>> Patches #1 - #3 look good to me, but I'm not sure if the rest is such a >>> good idea. >>> >>> Basically you not only want to use the same FD for

Re: [PATCH libdrm 0/9] amdgpu:

Am 25.06.19 um 10:02 schrieb Michel Dänzer: > On 2019-06-24 7:31 p.m., Christian König wrote: >> Patches #1 - #3 look good to me, but I'm not sure if the rest is such a >> good idea. >> >> Basically you not only want to use the same FD for CS, but also for >> basically all buffer functions and as

[PATCH v2] drm/amdgpu: fix scheduler timeout calc

scheduler timeout is in jiffies v2: move timeout check to amdgpu_device_get_job_timeout_settings after parsing the value & add negative value check Change-Id: I26708c163db943ff8d930dd81bcab4b4b9d84eb2 Signed-off-by: Flora Cui --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 6 +- 1 file

[PATCH] drm/amd/powerplay: support runtime ppfeatures setting on Navi10

Implement Navi10 backend for runtime ppfeatures status retrieving and setting support. Change-Id: Ib498b934c260e351c6cafedcd865fd931319e7a3 Signed-off-by: Evan Quan --- drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 165 + 1 file changed, 165 insertions(+) diff --git

Re: [PATCH libdrm 0/9] amdgpu:

On 2019-06-24 7:31 p.m., Christian König wrote: > Patches #1 - #3 look good to me, but I'm not sure if the rest is such a > good idea. > > Basically you not only want to use the same FD for CS, but also for > basically all buffer functions and as far as I can see we break that here. How so? The

[PATCH v2] drm/amd/powerplay:clean up the residual mutex for smu_hw_init

The mutex for procting SMU during hw_init was removed as system will be deadlock when smu_populate_umd_state_clk try get SMU mutex. Therefore need remove the residual mutex from failed path. Change-Id: Id8019c01b9496c067efda4817a46983e4da3b6e4 Signed-off-by: Prike Liang ---

Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v10

On Tue, Jun 25, 2019 at 07:20:12AM +, Koenig, Christian wrote: > Am 24.06.19 um 16:41 schrieb Daniel Vetter: > > On Mon, Jun 24, 2019 at 03:58:00PM +0200, Christian König wrote: > >> Am 24.06.19 um 13:23 schrieb Koenig, Christian: > >>> Am 21.06.19 um 18:27 schrieb Daniel Vetter: > >>> >

Re: [PATCH v4 hmm 11/12] mm/hmm: Remove confusing comment and logic from hmm_release

Looks good, Reviewed-by: Christoph Hellwig ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v4 hmm 04/12] mm/hmm: Simplify hmm_get_or_create and make it reliable

Looks good, Reviewed-by: Christoph Hellwig ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH] drm/amd/powerplay:clean up the residual mutex for smu_hw_init

With the patch header updated, the patch is Reviewed-by: Evan Quan > -Original Message- > From: amd-gfx On Behalf Of > Prike Liang > Sent: Monday, June 24, 2019 5:38 PM > To: amd-gfx@lists.freedesktop.org > Cc: Liang, Prike ; Huang, Ray > ; Feng, Kenneth ; Quan, > Evan > Subject:

Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v10

Am 24.06.19 um 16:41 schrieb Daniel Vetter: > On Mon, Jun 24, 2019 at 03:58:00PM +0200, Christian König wrote: >> Am 24.06.19 um 13:23 schrieb Koenig, Christian: >>> Am 21.06.19 um 18:27 schrieb Daniel Vetter: >>> So I pondered a few ideas while working out: 1) We drop this