The question is where do we rearm the timer for this problem to occur?
Regards,
Christian.
Am 12.11.19 um 20:21 schrieb Andrey Grodzovsky:
I was able to reproduce the crash by using the attached
simulate_crash.patch - waiting on guilty job to signal in reset work
and artificially rearming
Reviewed-by: Kenneth Feng
-Original Message-
From: amd-gfx On Behalf Of Evan Quan
Sent: Tuesday, November 12, 2019 9:47 AM
To: amd-gfx@lists.freedesktop.org
Cc: alexdeuc...@gmail.com; Matt Coffin ; Quan, Evan
Subject: [PATCH] drm/amd/powerplay: avoid DPM reenable process on Navi1x
On 12/11/2019 08:53, Wayne Lin wrote:
> [Why]
> In hdmi_mode_alternate_clock(), it adds an exception for VIC 4
> mode (4096x2160@24) due to there is no alternate clock defined for
> that mode in HDMI1.4b. But HDMI2.0 adds 23.98Hz for that mode.
>
> [How]
> Remove the exception
Shouldn't it be
On Mon, Nov 11, 2019 at 03:58:29PM +0100, Christian König wrote:
> Ghost BOs need to stick with the resv object only when the origin is imported.
>
> This is a low hanging fruit to avoid OOM situations on evictions.
>
> Signed-off-by: Christian König
I guess I still don't get what ghost
Hi Emily,
you need to print which scheduler instance is freeing the jobs and which
one is triggering the reset. The TID and PID is completely meaningless
here since we are called from different worker threads and the TID/PID
can change on each call.
Apart from that I will look into this a
Am 11.11.19 um 21:49 schrieb Alex Deucher:
flush/cancel delayed works before doing finalization
to avoid concurrently requests.
Signed-off-by: Alex Deucher
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
On 2019-11-12 11:08 a.m., Kazlauskas, Nicholas wrote:
> On 2019-11-12 10:16 a.m., mikita.lip...@amd.com wrote:
>> From: Mikita Lipski
>>
>> [why]
>> The function is expected to return instance of the timing generator
>> therefore we shouldn't be returning boolean in integer function,
>> and we
+ Laurent
From: Zhao, Yong
Sent: Monday, November 11, 2019 6:25 PM
To: amd-gfx@lists.freedesktop.org ; Cornwall,
Jay
Cc: Zhao, Yong
Subject: [PATCH 3/3] drm/amdkfd: Fix a bug when calculating save_area_used_size
workgroup context data writes from
This is done for other GFX in commit bb2d2128a54c4. Port it to GFX10.
Change-Id: I9e04872be3af0e90f5f6930226896b1ea545f3d9
Signed-off-by: Yong Zhao
---
drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v10.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git
Adapt the change from 1cd106ecfc1f04
The change is:
drm/amdkfd: Stop using GFP_NOIO explicitly
This is no longer needed with the memalloc_nofs_save/restore in
dqm_lock/unlock
Change-Id: I42450b2c149d2b1842be99a8f355c829a0079e7c
Signed-off-by: Yong Zhao
---
On 2019-11-12 2:51 a.m., Yuehaibing wrote:
> On 2019/11/12 10:39, Joe Perches wrote:
>> On Mon, 2019-11-11 at 20:28 +0800, YueHaibing wrote:
>>> Fix a build warning:
>>>
>>> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:75:1:
>>> warning: 'static' is not at beginning of declaration
>>>
On 2019-11-11 7:28 a.m., YueHaibing wrote:
> Fix a build warning:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:75:1:
> warning: 'static' is not at beginning of declaration
> [-Wold-style-declaration]
>
> Signed-off-by: YueHaibing
Reviewed-by: Harry Wentland
Harry
> ---
>
From JPEG2.0, JPEG is a separated IP block, and has it own PG/CG,
and power management. It doesn't require FW, so indepedent from FW
loading as well.
Patch 1-4: Separate JPEG1.0 from SW wise, since JPEG1.0 is still
combined with VCN1.0 esp. in power management;
Patch 5-8: Separate JPEG2.0 as an
On Tue, Nov 12, 2019 at 1:03 PM Leo Liu wrote:
>
> From JPEG2.0, JPEG is a separated IP block, and has it own PG/CG,
> and power management. It doesn't require FW, so indepedent from FW
> loading as well.
>
> Patch 1-4: Separate JPEG1.0 from SW wise, since JPEG1.0 is still
> combined with VCN1.0
On 2019-11-12 2:49 p.m., Alex Deucher wrote:
On Tue, Nov 12, 2019 at 1:03 PM Leo Liu wrote:
From JPEG2.0, JPEG is a separated IP block, and has it own PG/CG,
and power management. It doesn't require FW, so indepedent from FW
loading as well.
Patch 1-4: Separate JPEG1.0 from SW wise, since
On Tue, Nov 12, 2019 at 2:57 PM Leo Liu wrote:
>
>
> On 2019-11-12 2:49 p.m., Alex Deucher wrote:
> > On Tue, Nov 12, 2019 at 1:03 PM Leo Liu wrote:
> >> From JPEG2.0, JPEG is a separated IP block, and has it own PG/CG,
> >> and power management. It doesn't require FW, so indepedent from FW
>
On Tue, Nov 12, 2019 at 3:16 PM Leo Liu wrote:
>
>
> On 2019-11-12 3:12 p.m., Alex Deucher wrote:
> > On Tue, Nov 12, 2019 at 2:57 PM Leo Liu wrote:
> >>
> >> On 2019-11-12 2:49 p.m., Alex Deucher wrote:
> >>> On Tue, Nov 12, 2019 at 1:03 PM Leo Liu wrote:
> From JPEG2.0, JPEG is a
On 2019-11-12 3:34 p.m., Alex Deucher wrote:
On Tue, Nov 12, 2019 at 3:16 PM Leo Liu wrote:
On 2019-11-12 3:12 p.m., Alex Deucher wrote:
On Tue, Nov 12, 2019 at 2:57 PM Leo Liu wrote:
On 2019-11-12 2:49 p.m., Alex Deucher wrote:
On Tue, Nov 12, 2019 at 1:03 PM Leo Liu wrote:
From
From: Jason Gunthorpe
8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp, hfi1,
scif_dma, vhost, gntdev, hmm) drivers are using a common pattern where
they only use invalidate_range_start/end and immediately check the
invalidating range against some driver data structure to tell
From: Jason Gunthorpe
The new API is an exact match for the needs of radeon.
For some reason radeon tries to remove overlapping ranges from the
interval tree, but interval trees (and mmu_interval_notifier_insert())
support overlapping ranges directly. Simply delete all this code.
Since this
From: Jason Gunthorpe
hmm_mirror's handling of ranges does not use a sequence count which
results in this bug:
CPU0 CPU1
hmm_range_wait_until_valid(range)
valid == true
From: Jason Gunthorpe
Now that we have KERNEL_HEADER_TEST all headers are generally compile
tested, so relying on makefile tricks to avoid compiling code that depends
on CONFIG_MMU_NOTIFIER is more annoying.
Instead follow the usual pattern and provide most of the header with only
the functions
From: Jason Gunthorpe
This converts one of the two users of mmu_notifiers to use the new API.
The conversion is fairly straightforward, however the existing use of
notifiers here seems to be racey.
Tested-by: Dennis Dalessandro
Signed-off-by: Jason Gunthorpe
---
From: Jason Gunthorpe
Remove the interval tree in the driver and rely on the tree maintained by
the mmu_notifier for delivering mmu_notifier invalidation callbacks.
For some reason amdgpu has a very complicated arrangement where it tries
to prevent duplicate entries in the interval_tree, this
From: Jason Gunthorpe
The only two users of this are now converted to use mmu_interval_notifier,
delete all the code and update hmm.rst.
Reviewed-by: Jérôme Glisse
Tested-by: Ralph Campbell
Signed-off-by: Jason Gunthorpe
---
Documentation/vm/hmm.rst | 105 ---
From: Jason Gunthorpe
There is no reason to get the invalidate_range_start() callback via an
indirection through hmm_mirror, just register a normal notifier directly.
Tested-by: Ralph Campbell
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 95
From: Jason Gunthorpe
Of the 13 users of mmu_notifiers, 8 of them use only
invalidate_range_start/end() and immediately intersect the
mmu_notifier_range with some kind of internal list of VAs. 4 use an
interval tree (i915_gem, radeon_mn, umem_odp, hfi1). 4 use a linked list
of some kind
I was able to reproduce the crash by using the attached
simulate_crash.patch - waiting on guilty job to signal in reset work and
artificially rearming the timeout timer just before the check for
!cancel_delayed_work(>work_tdr) in drm_sched_cleanup_jobs -
crash log attached in crash.log. This
On 2019-11-12 3:12 p.m., Alex Deucher wrote:
On Tue, Nov 12, 2019 at 2:57 PM Leo Liu wrote:
On 2019-11-12 2:49 p.m., Alex Deucher wrote:
On Tue, Nov 12, 2019 at 1:03 PM Leo Liu wrote:
From JPEG2.0, JPEG is a separated IP block, and has it own PG/CG,
and power management. It doesn't
On 2019-11-12 4:26 p.m., Yong Zhao wrote:
Adapt the change from 1cd106ecfc1f04
The change is:
drm/amdkfd: Stop using GFP_NOIO explicitly
This is no longer needed with the memalloc_nofs_save/restore in
dqm_lock/unlock
Change-Id: I42450b2c149d2b1842be99a8f355c829a0079e7c
Hi Felix,
See one thing inline I am not too sure.
Yong
On 2019-11-12 4:30 p.m., Felix Kuehling wrote:
On 2019-11-12 4:26 p.m., Yong Zhao wrote:
Adapt the change from 1cd106ecfc1f04
The change is:
drm/amdkfd: Stop using GFP_NOIO explicitly
This is no longer needed with the
On 2019-11-12 4:35 p.m., Yong Zhao wrote:
Hi Felix,
See one thing inline I am not too sure.
Yong
On 2019-11-12 4:30 p.m., Felix Kuehling wrote:
On 2019-11-12 4:26 p.m., Yong Zhao wrote:
Adapt the change from 1cd106ecfc1f04
The change is:
drm/amdkfd: Stop using GFP_NOIO explicitly
> -Original Message-
> From: amd-gfx On Behalf Of
> Bjorn Helgaas
> Sent: Tuesday, November 12, 2019 12:35 PM
> To: Deucher, Alexander ; Koenig, Christian
> ; Zhou, David(ChunMing)
> ; David Airlie ; Daniel Vetter
>
> Cc: Frederick Lawler ; linux-...@vger.kernel.org;
> Michel Dänzer ;
From: Jason Gunthorpe
gntdev simply wants to monitor a specific VMA for any notifier events,
this can be done straightforwardly using mmu_interval_notifier_insert()
over the VMA's VA range.
The notifier should be attached until the original VMA is destroyed.
It is unclear if any of this is
From: Jason Gunthorpe
Convert the collision-retry lock around hmm_range_fault to use the one now
provided by the mmu_interval notifier.
Although this driver does not seem to use the collision retry lock that
hmm provides correctly, it can still be converted over to use the
mmu_interval_notifier
From: Jason Gunthorpe
find_vma() must be called under the mmap_sem, reorganize this code to
do the vma check after entering the lock.
Further, fix the unlocked use of struct task_struct's mm, instead use
the mm from hmm_mirror which has an active mm_grab. Also the mm_grab
must be converted to a
From: Jason Gunthorpe
Replace the internal interval tree based mmu notifier with the new common
mmu_interval_notifier_insert() API. This removes a lot of code and fixes a
deadlock that can be triggered in ODP:
zap_page_range()
mmu_notifier_invalidate_range_start()
[..]
From: Jason Gunthorpe
Only the function calls are stubbed out with static inlines that always
fail. This is the standard way to write a header for an optional component
and makes it easier for drivers that only optionally need HMM_MIRROR.
Reviewed-by: Jérôme Glisse
Tested-by: Ralph Campbell
On 2019-11-11 6:25 p.m., Yong Zhao wrote:
workgroup context data writes from m->cp_hqd_cntl_stack_size, so we
should deduct it when calculating the used size.
Looks like something I missed in upstreaming. As far as I can tell this
was originally part of a commit by Jay on amd-kfd-staging.
For VCN1.0, the separation is just in code wise, JPEG1.0 HW is still
included in the VCN1.0 HW.
Signed-off-by: Leo Liu
---
drivers/gpu/drm/amd/amdgpu/Makefile| 3 +-
drivers/gpu/drm/amd/amdgpu/jpeg_v1_0.c | 584 +
drivers/gpu/drm/amd/amdgpu/jpeg_v1_0.h | 32 ++
They are no longer needed, using from JPEG2.0 instead.
Signed-off-by: Leo Liu
---
drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c | 260 +-
1 file changed, 3 insertions(+), 257 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c
They will be used for JPEG2.0 and later.
Signed-off-by: Leo Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.c | 80
drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.h | 10 +++
2 files changed, 90 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.c
And enable them for Navi1x and Renoir
Signed-off-by: Leo Liu
---
drivers/gpu/drm/amd/amdgpu/jpeg_v2_0.c | 62 +++---
drivers/gpu/drm/amd/amdgpu/nv.c| 8 +++-
drivers/gpu/drm/amd/amdgpu/soc15.c | 2 +
3 files changed, 45 insertions(+), 27 deletions(-)
diff
It got separated from VCN2.0 with a new jpeg_v2_0_ip_block
Signed-off-by: Leo Liu
---
drivers/gpu/drm/amd/amdgpu/Makefile| 3 +-
drivers/gpu/drm/amd/amdgpu/jpeg_v2_0.c | 809 +
drivers/gpu/drm/amd/amdgpu/jpeg_v2_0.h | 42 ++
3 files changed, 853 insertions(+), 1
By using JPEG IP block type
Signed-off-by: Leo Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 9 +++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
Similar to SDMA, VCN etc.
Signed-off-by: Leo Liu
---
drivers/gpu/drm/amd/powerplay/amdgpu_smu.c| 2 ++
drivers/gpu/drm/amd/powerplay/inc/smu_v12_0.h | 2 ++
drivers/gpu/drm/amd/powerplay/renoir_ppt.c| 1 +
drivers/gpu/drm/amd/powerplay/smu_internal.h | 2 ++
By separating the JPEG power feature, and using its
own PowerUp and PowerDown messages
Signed-off-by: Leo Liu
---
drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 32 --
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
From VCN2.0, JPEG2.0 is a separated IP block.
Signed-off-by: Leo Liu
---
drivers/gpu/drm/amd/include/amd_shared.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/include/amd_shared.h
b/drivers/gpu/drm/amd/include/amd_shared.h
index
It will be used for different SMU specific to HW
Signed-off-by: Leo Liu
---
drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h
b/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h
index
From JPEG2.0, it will use its own PG/CG
Signed-off-by: Leo Liu
---
drivers/gpu/drm/amd/include/amd_shared.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/include/amd_shared.h
b/drivers/gpu/drm/amd/include/amd_shared.h
index d5bc8be4d70c..d655a76bedc6 100644
---
From JPEG2.0, JPEG is a separated IP block, and has it own PG/CG,
and power management. It doesn't require FW, so indepedent from FW
loading as well.
Patch 1-4: Separate JPEG1.0 from SW wise, since JPEG1.0 is still
combined with VCN1.0 esp. in power management;
Patch 5-10: Separate JPEG2.0 as an
It will be used for all versions of JPEG eventually. Previous
JPEG tests will be removed later since they are still used by
JPEG2.x.
Signed-off-by: Leo Liu
---
drivers/gpu/drm/amd/amdgpu/Makefile | 5 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.c | 135 +++
It will be used for JPEG IP 1.0, 2.0, 2.5 and later.
Signed-off-by: Leo Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 5 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.h | 46
2 files changed, 51 insertions(+)
create mode 100644
JPEG1.0 will be functional along with VCN1.0
Signed-off-by: Leo Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 6 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 8 +++-
3 files changed, 8 insertions(+), 10 deletions(-)
diff --git
Arcturus VCN and JPEG only got CG support, and no PG support
Signed-off-by: Leo Liu
---
drivers/gpu/drm/amd/amdgpu/soc15.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c
b/drivers/gpu/drm/amd/amdgpu/soc15.c
index
By using its own JPEG PowerUp and PowerDown messages
Signed-off-by: Leo Liu
---
drivers/gpu/drm/amd/powerplay/renoir_ppt.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
b/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
index
By using its own IP block type.
Signed-off-by: Leo Liu
---
drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 3 +++
drivers/gpu/drm/amd/powerplay/smu_internal.h | 2 ++
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
On 2019-11-11 8:29 p.m., Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> Add definitions for these PCIe Link Control 2 register fields:
>
> Enter Compliance
> Transmit Margin
>
> and use them in amdgpu and radeon.
>
> NOTE: This is a functional change because "7 << 9" was apparently a
On Tue, Nov 12, 2019 at 05:45:15PM +0100, Michel Dänzer wrote:
> On 2019-11-11 8:29 p.m., Bjorn Helgaas wrote:
> > From: Bjorn Helgaas
> >
> > Add definitions for these PCIe Link Control 2 register fields:
> >
> > Enter Compliance
> > Transmit Margin
> >
> > and use them in amdgpu and
By adding JPEG IP block to the family
Signed-off-by: Leo Liu
---
drivers/gpu/drm/amd/amdgpu/nv.c| 3 +++
drivers/gpu/drm/amd/amdgpu/soc15.c | 2 ++
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c b/drivers/gpu/drm/amd/amdgpu/nv.c
index
It also doen't care about FW loading type, so enabling it directly.
Signed-off-by: Leo Liu
---
drivers/gpu/drm/amd/amdgpu/soc15.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c
b/drivers/gpu/drm/amd/amdgpu/soc15.c
index b404b7a6e593..689ffa6ede57
And clean up the duplicated stuff
Signed-off-by: Leo Liu
---
drivers/gpu/drm/amd/amdgpu/Makefile | 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.h | 3 +
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 105
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h | 5 -
By using its own enabling function
Signed-off-by: Leo Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 8
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.h | 1 +
drivers/gpu/drm/amd/amdgpu/jpeg_v2_0.c | 10 +-
3 files changed, 18 insertions(+), 1 deletion(-)
diff --git
From: Bjorn Helgaas
Replace hard-coded magic numbers with the descriptive PCI_EXP_LNKCTL2
definitions. No functional change intended.
Signed-off-by: Bjorn Helgaas
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/cik.c | 22 ++
drivers/gpu/drm/amd/amdgpu/si.c |
From: Bjorn Helgaas
Previously we masked PCIe Link Control 2 register values with "7 << 9",
which was apparently intended to be the Transmit Margin field, but instead
was the high order bit of Transmit Margin, the Enter Modified Compliance
bit, and the Compliance SOS bit.
Correct the mask to "7
From: Bjorn Helgaas
amdgpu and radeon do a bit of mucking with the PCIe Link Control 2
register, some of it using hard-coded magic numbers. The idea here is to
replace those with #defines.
Since v2:
- Fix a gpu_cfg2 case in amdgpu/si.c that I had missed
- Separate out the functional
From: Bjorn Helgaas
Add definitions for the Enter Compliance and Transmit Margin fields of the
PCIe Link Control 2 register.
Signed-off-by: Bjorn Helgaas
---
include/uapi/linux/pci_regs.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/uapi/linux/pci_regs.h
When gfxoff is enabled, accessing gfx registers via MMIO
can lead to a hang.
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205497
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
On 2019-11-12 10:16 a.m., mikita.lip...@amd.com wrote:
From: Mikita Lipski
[why]
The function is expected to return instance of the timing generator
therefore we shouldn't be returning boolean in integer function,
and we shouldn't be returning zero so changing it to -1.
Signed-off-by: Mikita
From: Mikita Lipski
[why]
The function is expected to return instance of the timing generator
therefore we shouldn't be returning boolean in integer function,
and we shouldn't be returning zero so changing it to -1.
Signed-off-by: Mikita Lipski
---
Hi all,
Dave and me chatted about this last week on irc. Essentially we have:
$ git grep SPDX.*GPL -- ':(glob)drivers/gpu/drm/*c'
drivers/gpu/drm/drm_client.c:// SPDX-License-Identifier: GPL-2.0
drivers/gpu/drm/drm_damage_helper.c:// SPDX-License-Identifier: GPL-2.0 OR MIT
From: Mikita Lipski
[why]
For MST connector atomic check we have to check a new CRTC state
instead of an old one, when checking if CRTC is disabled to
release VCPI slots allocated.
Signed-off-by: Mikita Lipski
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
1 file
On Tue, Nov 12, 2019 at 3:13 AM YueHaibing wrote:
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c: In function
> get_pbn_from_timing:
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2364:11: warning:
> variable bpc set but
When gfxoff is enabled, accessing gfx registers via MMIO
can lead to a hang.
v2: return cached registers properly.
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205497
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/nv.c| 27 --
On 2019-11-12 10:15 a.m., mikita.lip...@amd.com wrote:
From: Mikita Lipski
[why]
For MST connector atomic check we have to check a new CRTC state
instead of an old one, when checking if CRTC is disabled to
release VCPI slots allocated.
Signed-off-by: Mikita Lipski
Reviewed-by: Nicholas
sysfs interface to read pcie speed info on navi1x.
Signed-off-by: Kenneth Feng
---
drivers/gpu/drm/amd/powerplay/amdgpu_smu.c| 10 +++---
drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h | 8 +
drivers/gpu/drm/amd/powerplay/navi10_ppt.c| 50 ++-
On 2019/11/12 10:39, Joe Perches wrote:
> On Mon, 2019-11-11 at 20:28 +0800, YueHaibing wrote:
>> Fix a build warning:
>>
>> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:75:1:
>> warning: 'static' is not at beginning of declaration
>> [-Wold-style-declaration]
> []
>> diff --git
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c: In function
get_pbn_from_timing:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2364:11: warning:
variable bpc set but not used [-Wunused-but-set-variable]
It is not used since
On Mon, 2019-11-11 at 20:28 +0800, YueHaibing wrote:
> Fix a build warning:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:75:1:
> warning: 'static' is not at beginning of declaration
> [-Wold-style-declaration]
[]
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
>
Reviewed-by: Kenneth Feng
-Original Message-
From: amd-gfx On Behalf Of Evan Quan
Sent: Tuesday, November 12, 2019 2:37 PM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan
Subject: [PATCH] drm/amd/powerplay: issue BTC on Navi during SMU setup
[CAUTION: External Email]
RunBTC is
> -Original Message-
> From: amd-gfx On Behalf Of
> Kenneth Feng
> Sent: Tuesday, November 12, 2019 4:40 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Feng, Kenneth
> Subject: [PATCH] drm/amd/powerplay: read pcie speed/width info
>
> sysfs interface to read pcie speed info on navi1x.
>
On Tue, Nov 12, 2019 at 07:35:53PM +, Deucher, Alexander wrote:
> > -Original Message-
> > From: amd-gfx On Behalf Of
> > Bjorn Helgaas
> > Sent: Tuesday, November 12, 2019 12:35 PM
> > To: Deucher, Alexander ; Koenig, Christian
> > ; Zhou, David(ChunMing)
> > ; David Airlie ; Daniel
On 2019-11-11 6:25 p.m., Yong Zhao wrote:
Given control stack is now in the userspace context save restore area
on GFX10, the same as GFX8, it is not needed to copy it back to userspace.
Change-Id: I063ddc3026eefa57713ec47b466a90f9bf9d49b8
Signed-off-by: Yong Zhao
Patches 1 and 2 are
The ops_asic_specific function pointers are actually quite generic after
using a simple if condition. Eliminate it by code refactoring.
Change-Id: Icb891289cca31acdbe2d2eea76a426f1738b9c08
Signed-off-by: Yong Zhao
---
drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c | 63 ---
The only difference that CIK kernel queue functions are different from
VI is avoid allocating eop_mem. We can achieve that by using a if
condition.
Change-Id: Iea9cbc82f603ff008a906c5ee32325ddcd02d963
Signed-off-by: Yong Zhao
---
drivers/gpu/drm/amd/amdkfd/Makefile | 1 -
For Navi10, SMU_MSG_PowerUpJpeg message does not need an argument.
> -Original Message-
> From: amd-gfx On Behalf Of Leo Liu
> Sent: Wednesday, November 13, 2019 2:03 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Leo
> Subject: [PATCH 12/21] drm/amd/powerplay: add JPEG power control
On Renior, both SMU_MSG_PowerDownJpeg and SMU_MSG_PowerUpJpeg need an argument.
> -Original Message-
> From: amd-gfx On Behalf Of Leo Liu
> Sent: Wednesday, November 13, 2019 2:03 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Leo
> Subject: [PATCH 13/21] drm/amd/powerplay: add
On Renior, both SMU_MSG_PowerDownJpeg and SMU_MSG_PowerUpJpeg need an argument.
> -Original Message-
> From: amd-gfx On Behalf Of Leo Liu
> Sent: Wednesday, November 13, 2019 2:03 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Leo
> Subject: [PATCH 14/21] drm/amd/powerplay: add JPEG
This patch is reviewed-by: Evan Quan
However, i just find we need a separate patch to clear PP_GFXOFF_MASK support
from Arcturus.
Can you do that or you want me to do that?
> -Original Message-
> From: amd-gfx On Behalf Of Alex
> Deucher
> Sent: Tuesday, November 12, 2019 11:13 PM
>
89 matches
Mail list logo
