sysfs interface to read pcie speed&width 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 ++-
drivers/gp
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 a/drivers/g
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 commi
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
> b/drivers/gpu/
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 added
> -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&width info on navi
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 onl
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 AS
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 objects
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 bi
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 a/driv
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 a/drivers/gpu/drm/amd/amdgpu/amdgpu_km
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
drivers/gpu/drm/drm_dp_
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 --
drivers/gpu/drm/amd/amdg
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 chang
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
---
drivers/gpu/drm/amd/display/dc/core/dc_resour
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
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 Kazl
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 L
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 typo.
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 radeo
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 | 22
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 changes
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 b/include/uapi/linux/p
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 +++
drivers/gpu/d
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 drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.
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 a/driv
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 ++
dri
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
b/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
b/drivers/gpu/d
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 --git
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 de
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
b/drivers/gpu/drm/amd/amd
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 ++
drivers/gpu/drm/amd/powe
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
b/d
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 dc7eb28f0296..d5bc8be
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 999445c5c010..c
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
--- a/dri
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
b/drivers/gpu/drm/amd/powerplay/amdgpu_
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 f3977abbd1e2..b404b7a6e
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 49
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 7c1068efe651..d2989e9484b
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 100644
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 -
drivers/gpu/drm/amd/amdgpu/jpeg
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 a/drivers/gpu/dr
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 i
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(&sched->work_tdr) in drm_sched_cleanup_jobs -
crash log attached in crash.log.
> -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 ; lin
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 e
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 JP
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 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 sho
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 requi
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
> ---
> drivers
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
>>> [-Wol
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 separa
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 JPE
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 (scif_dm
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 i
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 dri
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
---
drivers/infiniband/hw/hfi1/fil
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 is
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 ---
include/linux/hmm.h
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 even
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()
[..]
ib_umem_notifier
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
Si
From: Jason Gunthorpe
Remove the hmm_mirror object and use the mmu_interval_notifier API instead
for the range, and use the normal mmu_notifier API for the general
invalidation callback.
While here re-organize the pagefault path so the locking pattern is clear.
nouveau is the only driver that u
+ 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 m->cp_hqd_cntl
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
---
drivers/gpu/drm/amd/amdk
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 a/drivers/gpu/drm
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
Signed-o
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 memallo
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. Anothe
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
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 V
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
Reviewed
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 ---
driver
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 -
drivers/gpu/
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
> To:
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 Powerg
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 p
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 th
90 matches
Mail list logo
