Re: [PATCH v3 38/41] powerpc: convert put_page() to put_user_page*()
Hi John,
john.hubb...@gmail.com writes:
> diff --git a/arch/powerpc/mm/book3s64/iommu_api.c
> b/arch/powerpc/mm/book3s64/iommu_api.c
> index b056cae3388b..e126193ba295 100644
> --- a/arch/powerpc/mm/book3s64/iommu_api.c
> +++ b/arch/powerpc/mm/book3s64/iommu_api.c
> @@ -203,6 +202,7 @@ static void mm_iommu_unpin(struct
> mm_iommu_table_group_mem_t *mem)
> {
> long i;
> struct page *page = NULL;
> + bool dirty = false;
I don't think you need that initialisation do you?
> if (!mem->hpas)
> return;
> @@ -215,10 +215,9 @@ static void mm_iommu_unpin(struct
> mm_iommu_table_group_mem_t *mem)
> if (!page)
> continue;
>
> - if (mem->hpas[i] & MM_IOMMU_TABLE_GROUP_PAGE_DIRTY)
> - SetPageDirty(page);
> + dirty = mem->hpas[i] & MM_IOMMU_TABLE_GROUP_PAGE_DIRTY;
> - put_page(page);
> + put_user_pages_dirty_lock(, 1, dirty);
> mem->hpas[i] = 0;
> }
> }
cheers
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 1/2] drm/amd/powerplay: re-define smu interface version for smu v11
From: tiancyin
[why]
navi14 share same defination of smu interface version with navi10,
anyone of them update the version may break the other one's
version checking.
[how]
create different version defination, so that they can
update their version separately.
Signed-off-by: tiancyin
---
drivers/gpu/drm/amd/powerplay/inc/smu11_driver_if.h | 4 +++-
.../gpu/drm/amd/powerplay/inc/smu11_driver_if_navi10.h | 4 +++-
drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h| 5 +
drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 1 -
drivers/gpu/drm/amd/powerplay/smu_v11_0.c| 16
drivers/gpu/drm/amd/powerplay/vega20_ppt.c | 1 -
6 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/inc/smu11_driver_if.h
b/drivers/gpu/drm/amd/powerplay/inc/smu11_driver_if.h
index 755d51f..fdc6b7a 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/smu11_driver_if.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/smu11_driver_if.h
@@ -27,7 +27,9 @@
// *** IMPORTANT ***
// SMU TEAM: Always increment the interface version if
// any structure is changed in this file
-#define SMU11_DRIVER_IF_VERSION 0x13
+// Be aware of that the version should be updated in
+// smu_v11_0.h, rename is also needed.
+// #define SMU11_DRIVER_IF_VERSION 0x13
#define PPTABLE_V20_SMU_VERSION 3
diff --git a/drivers/gpu/drm/amd/powerplay/inc/smu11_driver_if_navi10.h
b/drivers/gpu/drm/amd/powerplay/inc/smu11_driver_if_navi10.h
index adbbfeb..6d9e79e 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/smu11_driver_if_navi10.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/smu11_driver_if_navi10.h
@@ -26,7 +26,9 @@
// *** IMPORTANT ***
// SMU TEAM: Always increment the interface version if
// any structure is changed in this file
-#define SMU11_DRIVER_IF_VERSION 0x33
+// Be aware of that the version should be updated in
+// smu_v11_0.h, maybe rename is also needed.
+// #define SMU11_DRIVER_IF_VERSION 0x33
#define PPTABLE_NV10_SMU_VERSION 8
diff --git a/drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h
b/drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h
index fcb5801..97605e9 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h
@@ -25,6 +25,11 @@
#include "amdgpu_smu.h"
+#define SMU11_DRIVER_IF_VERSION_INV 0x
+#define SMU11_DRIVER_IF_VERSION_VG20 0x13
+#define SMU11_DRIVER_IF_VERSION_NV10 0x33
+#define SMU11_DRIVER_IF_VERSION_NV14 0x33
+
/* MP Apertures */
#define MP0_Public 0x0380
#define MP0_SRAM 0x0390
diff --git a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
index be88c5d..fdc7db0 100644
--- a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
+++ b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
@@ -1630,6 +1630,5 @@ void navi10_set_ppt_funcs(struct smu_context *smu)
struct smu_table_context *smu_table = >smu_table;
smu->ppt_funcs = _ppt_funcs;
- smu->smc_if_version = SMU11_DRIVER_IF_VERSION;
smu_table->table_count = TABLE_COUNT;
}
diff --git a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
index c078bf4..91dfae1 100644
--- a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
+++ b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
@@ -271,6 +271,22 @@ static int smu_v11_0_check_fw_version(struct smu_context
*smu)
smu_minor = (smu_version >> 8) & 0xff;
smu_debug = (smu_version >> 0) & 0xff;
+ switch (smu->adev->asic_type) {
+ case CHIP_VEGA20:
+ smu->smc_if_version = SMU11_DRIVER_IF_VERSION_VG20;
+ break;
+ case CHIP_NAVI10:
+ smu->smc_if_version = SMU11_DRIVER_IF_VERSION_NV10;
+ break;
+ case CHIP_NAVI14:
+ smu->smc_if_version = SMU11_DRIVER_IF_VERSION_NV14;
+ break;
+ default:
+ pr_err("smu unsuported asic type:%d.\n",smu->adev->asic_type);
+ smu->smc_if_version = SMU11_DRIVER_IF_VERSION_INV;
+ break;
+ }
+
/*
* 1. if_version mismatch is not critical as our fw is designed
* to be backward compatible.
diff --git a/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
b/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
index 52c8fc9..e28c004 100644
--- a/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
+++ b/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
@@ -3173,6 +3173,5 @@ void vega20_set_ppt_funcs(struct smu_context *smu)
struct smu_table_context *smu_table = >smu_table;
smu->ppt_funcs = _ppt_funcs;
- smu->smc_if_version = SMU11_DRIVER_IF_VERSION;
smu_table->table_count = TABLE_COUNT;
}
--
2.7.4
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 2/2] drm/amd/powerplay: update smu11_driver_if_navi10.h
From: tiancyin
update the smu11_driver_if_navi10.h since navi14 smu fw
update to 53.12
Change-Id: If0f729ec87c98f24e1794f0847eac5ba23671e34
Reviewed-by: Evan Quan
Signed-off-by: tiancyin
---
.../drm/amd/powerplay/inc/smu11_driver_if_navi10.h | 25 +-
drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h | 2 +-
2 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/inc/smu11_driver_if_navi10.h
b/drivers/gpu/drm/amd/powerplay/inc/smu11_driver_if_navi10.h
index 6d9e79e..ac0120e 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/smu11_driver_if_navi10.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/smu11_driver_if_navi10.h
@@ -506,10 +506,11 @@ typedef struct {
uint32_t Status;
uint16_t DieTemperature;
- uint16_t MemoryTemperature;
+ uint16_t CurrentMemoryTemperature;
- uint16_t SelectedCardPower;
- uint16_t Reserved4;
+ uint16_t MemoryTemperature;
+ uint8_t MemoryHotspotPosition;
+ uint8_t Reserved4;
uint32_t BoardLevelEnergyAccumulator;
} OutOfBandMonitor_t;
@@ -801,7 +802,12 @@ typedef struct {
// Mvdd Svi2 Div Ratio Setting
uint32_t MvddRatio; // This is used for MVDD Vid workaround. It has 16
fractional bits (Q16.16)
- uint32_t BoardReserved[9];
+ uint8_t RenesesLoadLineEnabled;
+ uint8_t GfxLoadlineResistance;
+ uint8_t SocLoadlineResistance;
+ uint8_t Padding8_Loadline;
+
+ uint32_t BoardReserved[8];
// Padding for MMHUB - do not modify this
uint32_t MmHubPadding[8]; // SMU internal use
@@ -905,13 +911,22 @@ typedef struct {
} Watermarks_t;
typedef struct {
+ uint16_t avgPsmCount[28];
+ uint16_t minPsmCount[28];
+ floatavgPsmVoltage[28];
+ floatminPsmVoltage[28];
+
+ uint32_t MmHubPadding[32]; // SMU internal use
+} AvfsDebugTable_t_NV14;
+
+typedef struct {
uint16_t avgPsmCount[36];
uint16_t minPsmCount[36];
floatavgPsmVoltage[36];
floatminPsmVoltage[36];
uint32_t MmHubPadding[8]; // SMU internal use
-} AvfsDebugTable_t;
+} AvfsDebugTable_t_NV10;
typedef struct {
uint8_t AvfsVersion;
diff --git a/drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h
b/drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h
index 97605e9..ee8542d 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h
@@ -28,7 +28,7 @@
#define SMU11_DRIVER_IF_VERSION_INV 0x
#define SMU11_DRIVER_IF_VERSION_VG20 0x13
#define SMU11_DRIVER_IF_VERSION_NV10 0x33
-#define SMU11_DRIVER_IF_VERSION_NV14 0x33
+#define SMU11_DRIVER_IF_VERSION_NV14 0x34
/* MP Apertures */
#define MP0_Public 0x0380
--
2.7.4
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH v6 19/24] drm/bridge: dumb-vga-dac: Provide ddc symlink in connector sysfs directory
On Fri, Jul 26, 2019 at 07:23:13PM +0200, Andrzej Pietrasiewicz wrote: > Use the ddc pointer provided by the generic connector. > > Signed-off-by: Andrzej Pietrasiewicz > Reviewed-by: Neil Armstrong This patch results in a crash when running qemu:versatilepb. Unable to handle kernel NULL pointer dereference at virtual address 00c5 pgd = (ptrval) [00c5] *pgd= Internal error: Oops: 5 [#1] ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 5.3.0-rc1+ #1 Hardware name: ARM-Versatile (Device Tree Support) PC is at sysfs_do_create_link_sd+0x38/0xd8 LR is at sysfs_do_create_link_sd+0x38/0xd8 pc : []lr : []psr: a153 sp : c783bd18 ip : fp : c783bde8 r10: c7ef5ea8 r9 : 0001 r8 : c0955dc0 r7 : c73cb5b0 r6 : c73cd800 r5 : 00ad r4 : r3 : c7838ae0 r2 : r1 : 0008 r0 : c0aa2898 Flags: NzCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment none Control: 00093177 Table: 4000 DAC: 0053 Process swapper (pid: 1, stack limit = 0x(ptrval)) Stack: (0xc783bd18 to 0xc783c000) bd00: c73ccc48 c73ccc74 bd20: c73cd800 c0ac7c88 c729cc80 c7ef5ea8 c04c7fc0 c73ccc48 c0a73068 bd40: c73cd800 c0ac7c88 c04c87e0 0001 c04cefcc c04dc3f8 bd60: c73a9030 c73cd800 c73ccc48 7fc2ce37 c73cd800 c04cefcc bd80: c73cd800 c04b4ebc c0a73068 c7ef5ea8 c783bde8 c049ffcc bda0: c73a9020 c73cd800 c78e6000 c73a9020 c73a9020 c0a73068 c04df2f8 bdc0: c783bde8 c095a76c c73a9020 c0065744 c73ccc20 c73a9020 0001 bde0: c7838ae0 c73ccc20 7fc2ce37 c78e6000 c0ac7c34 be00: c07dc1f8 c0a6b384 c0a59858 c045e8d8 c78e6000 c1173a78 be20: c0ac7c34 c04e77c4 c78e6000 c0ac7c34 c0ac7c34 c0a73068 be40: e000 c0a6b384 c04e7a34 c0ac7c34 c0ac7c34 c0a73068 c78e6000 be60: c0ac7c34 c0a73068 e000 c0a6b384 c0a59858 c04e7cf0 be80: c0ac7c34 c78e6000 c04e7d7c c0ac7c34 c04e7cf8 c04e5928 bea0: c73b2800 c78d88a0 c78dd110 7fc2ce37 e000 c0ac7c34 c73b2800 c0ac16e0 bec0: c04e6b28 c095a73c c0af0a60 c0a73068 c0ac7c34 c0af0a60 c0a73068 bee0: c0a401c4 c04e8968 e000 c0af0a60 c0a73068 c000b3bc 0115 bf00: c7ffce6c c7ffce00 c09e15b0 0115 0115 c0048844 c09e000c c097cfd4 bf20: 0006 0006 c7ffce6c e000 c006954c bf40: e000 7fc2ce37 c0afb000 c0af0a60 0115 c0afb000 0007 c0a59850 bf60: e000 c0a111e8 0006 0006 c0a10678 7fc2ce37 bf80: c07824cc bfa0: c07824d4 c00090b0 bfc0: bfe0: 0013 [] (sysfs_do_create_link_sd) from [] (drm_connector_register.part.1+0x40/0xa0) [] (drm_connector_register.part.1) from [] (drm_connector_register_all+0x90/0xb8) [] (drm_connector_register_all) from [] (drm_modeset_register_all+0x44/0x6c) [] (drm_modeset_register_all) from [] (drm_dev_register+0x15c/0x1c0) [] (drm_dev_register) from [] (pl111_amba_probe+0x2e0/0x4ac) [] (pl111_amba_probe) from [] (amba_probe+0x9c/0x118) [] (amba_probe) from [] (really_probe+0x1c0/0x2bc) [] (really_probe) from [] (driver_probe_device+0x5c/0x170) [] (driver_probe_device) from [] (device_driver_attach+0x58/0x60) [] (device_driver_attach) from [] (__driver_attach+0x84/0xc0) [] (__driver_attach) from [] (bus_for_each_dev+0x70/0xb4) [] (bus_for_each_dev) from [] (bus_add_driver+0x154/0x1e0) [] (bus_add_driver) from [] (driver_register+0x74/0x108) [] (driver_register) from [] (do_one_initcall+0x84/0x2e4) [] (do_one_initcall) from [] (kernel_init_freeable+0x2bc/0x394) [] (kernel_init_freeable) from [] (kernel_init+0x8/0xf0) [] (kernel_init) from [] (ret_from_fork+0x14/0x24) Exception stack(0xc783bfb0 to 0xc783bff8) bfa0: bfc0: bfe0: 0013 Code: e59f00a0 e1a09003 e1a08002 eb176e54 (e5955018) ---[ end trace f503b374936886c5 ]--- Bisect log attached. Guenter --- # bad: [3880be629e26f6c407593602398c6651860d5fae] Add linux-next specific files for 20190807 # good: [e21a712a9685488f5ce80495b37b9fdbe96c230d] Linux 5.3-rc3 git bisect start 'HEAD' 'v5.3-rc3' # good: [83d74da9e6d2ca78b32e9e794c6bcbd433d5efaa] Merge remote-tracking branch 'crypto/master' git bisect good 83d74da9e6d2ca78b32e9e794c6bcbd433d5efaa # bad: [3add021bff629f1792a5e4268afe13b3047b5523] Merge remote-tracking branch 'sound/for-next' git bisect bad 3add021bff629f1792a5e4268afe13b3047b5523 # good: [4ef58ee18a654b1992d00281501d6eff051a0c5e] Merge remote-tracking branch 'amd
Re: [PATCH 00/34] put_user_pages(): miscellaneous call sites
On 8/7/19 7:36 PM, Ira Weiny wrote:
On Wed, Aug 07, 2019 at 10:46:49AM +0200, Michal Hocko wrote:
On Wed 07-08-19 10:37:26, Jan Kara wrote:
On Fri 02-08-19 12:14:09, John Hubbard wrote:
On 8/2/19 7:52 AM, Jan Kara wrote:
On Fri 02-08-19 07:24:43, Matthew Wilcox wrote:
On Fri, Aug 02, 2019 at 02:41:46PM +0200, Jan Kara wrote:
On Fri 02-08-19 11:12:44, Michal Hocko wrote:
On Thu 01-08-19 19:19:31, john.hubb...@gmail.com wrote:
[...]
Before I go on, I would like to say that the "imbalance" of get_user_pages()
and put_page() bothers me from a purist standpoint... However, since this
discussion cropped up I went ahead and ported my work to Linus' current master
(5.3-rc3+) and in doing so I only had to steal a bit of Johns code... Sorry
John... :-(
I don't have the commit messages all cleaned up and I know there may be some
discussion on these new interfaces but I wanted to throw this series out there
because I think it may be what Jan and Michal are driving at (or at least in
that direction.
Right now only RDMA and DAX FS's are supported. Other users of GUP will still
fail on a DAX file and regular files will still be at risk.[2]
I've pushed this work (based 5.3-rc3+ (33920f1ec5bf)) here[3]:
https://github.com/weiny2/linux-kernel/tree/linus-rdmafsdax-b0-v3
I think the most relevant patch to this conversation is:
https://github.com/weiny2/linux-kernel/commit/5d377653ba5cf11c3b716f904b057bee6641aaf6
ohhh...can you please avoid using the old __put_user_pages_dirty()
function? I thought I'd caught things early enough to get away with
the rename and deletion of that. You could either:
a) open code an implementation of vaddr_put_pages_dirty_lock() that
doesn't call any of the *put_user_pages_dirty*() variants, or
b) include my first patch ("") are part of your series, or
c) base this on Andrews's tree, which already has merged in my first patch.
thanks,
--
John Hubbard
NVIDIA
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 1/2] md/powerplay: re-define smu interface version for smu v11
From: tiancyin
[why]
navi14 share same defination of smu interface version with navi10,
anyone of them update the version may break the other one's
version checking.
[how]
create different version defination, so that they can
update their version separately.
Signed-off-by: tiancyin
---
drivers/gpu/drm/amd/powerplay/inc/smu11_driver_if.h | 4 +++-
.../gpu/drm/amd/powerplay/inc/smu11_driver_if_navi10.h | 4 +++-
drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h| 5 +
drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 1 -
drivers/gpu/drm/amd/powerplay/smu_v11_0.c| 16
drivers/gpu/drm/amd/powerplay/vega20_ppt.c | 1 -
6 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/inc/smu11_driver_if.h
b/drivers/gpu/drm/amd/powerplay/inc/smu11_driver_if.h
index 755d51f..fdc6b7a 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/smu11_driver_if.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/smu11_driver_if.h
@@ -27,7 +27,9 @@
// *** IMPORTANT ***
// SMU TEAM: Always increment the interface version if
// any structure is changed in this file
-#define SMU11_DRIVER_IF_VERSION 0x13
+// Be aware of that the version should be updated in
+// smu_v11_0.h, rename is also needed.
+// #define SMU11_DRIVER_IF_VERSION 0x13
#define PPTABLE_V20_SMU_VERSION 3
diff --git a/drivers/gpu/drm/amd/powerplay/inc/smu11_driver_if_navi10.h
b/drivers/gpu/drm/amd/powerplay/inc/smu11_driver_if_navi10.h
index adbbfeb..6d9e79e 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/smu11_driver_if_navi10.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/smu11_driver_if_navi10.h
@@ -26,7 +26,9 @@
// *** IMPORTANT ***
// SMU TEAM: Always increment the interface version if
// any structure is changed in this file
-#define SMU11_DRIVER_IF_VERSION 0x33
+// Be aware of that the version should be updated in
+// smu_v11_0.h, maybe rename is also needed.
+// #define SMU11_DRIVER_IF_VERSION 0x33
#define PPTABLE_NV10_SMU_VERSION 8
diff --git a/drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h
b/drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h
index fcb5801..97605e9 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h
@@ -25,6 +25,11 @@
#include "amdgpu_smu.h"
+#define SMU11_DRIVER_IF_VERSION_INV 0x
+#define SMU11_DRIVER_IF_VERSION_VG20 0x13
+#define SMU11_DRIVER_IF_VERSION_NV10 0x33
+#define SMU11_DRIVER_IF_VERSION_NV14 0x33
+
/* MP Apertures */
#define MP0_Public 0x0380
#define MP0_SRAM 0x0390
diff --git a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
index be88c5d..fdc7db0 100644
--- a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
+++ b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
@@ -1630,6 +1630,5 @@ void navi10_set_ppt_funcs(struct smu_context *smu)
struct smu_table_context *smu_table = >smu_table;
smu->ppt_funcs = _ppt_funcs;
- smu->smc_if_version = SMU11_DRIVER_IF_VERSION;
smu_table->table_count = TABLE_COUNT;
}
diff --git a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
index c078bf4..91dfae1 100644
--- a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
+++ b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
@@ -271,6 +271,22 @@ static int smu_v11_0_check_fw_version(struct smu_context
*smu)
smu_minor = (smu_version >> 8) & 0xff;
smu_debug = (smu_version >> 0) & 0xff;
+ switch (smu->adev->asic_type) {
+ case CHIP_VEGA20:
+ smu->smc_if_version = SMU11_DRIVER_IF_VERSION_VG20;
+ break;
+ case CHIP_NAVI10:
+ smu->smc_if_version = SMU11_DRIVER_IF_VERSION_NV10;
+ break;
+ case CHIP_NAVI14:
+ smu->smc_if_version = SMU11_DRIVER_IF_VERSION_NV14;
+ break;
+ default:
+ pr_err("smu unsuported asic type:%d.\n",smu->adev->asic_type);
+ smu->smc_if_version = SMU11_DRIVER_IF_VERSION_INV;
+ break;
+ }
+
/*
* 1. if_version mismatch is not critical as our fw is designed
* to be backward compatible.
diff --git a/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
b/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
index 52c8fc9..e28c004 100644
--- a/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
+++ b/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
@@ -3173,6 +3173,5 @@ void vega20_set_ppt_funcs(struct smu_context *smu)
struct smu_table_context *smu_table = >smu_table;
smu->ppt_funcs = _ppt_funcs;
- smu->smc_if_version = SMU11_DRIVER_IF_VERSION;
smu_table->table_count = TABLE_COUNT;
}
--
2.7.4
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 2/2] drm/amd/powerplay: update smu11_driver_if_navi10.h
From: tiancyin
update the smu11_driver_if_navi10.h since navi14 smu fw
update to 53.12
Change-Id: If0f729ec87c98f24e1794f0847eac5ba23671e34
Reviewed-by: Evan Quan
Signed-off-by: tiancyin
---
.../drm/amd/powerplay/inc/smu11_driver_if_navi10.h | 26 +-
drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h | 2 +-
2 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/inc/smu11_driver_if_navi10.h
b/drivers/gpu/drm/amd/powerplay/inc/smu11_driver_if_navi10.h
index 6d9e79e..4b7c5c2 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/smu11_driver_if_navi10.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/smu11_driver_if_navi10.h
@@ -506,10 +506,11 @@ typedef struct {
uint32_t Status;
uint16_t DieTemperature;
- uint16_t MemoryTemperature;
+ uint16_t CurrentMemoryTemperature;
- uint16_t SelectedCardPower;
- uint16_t Reserved4;
+ uint16_t MemoryTemperature;
+ uint8_t MemoryHotspotPosition;
+ uint8_t Reserved4;
uint32_t BoardLevelEnergyAccumulator;
} OutOfBandMonitor_t;
@@ -801,7 +802,13 @@ typedef struct {
// Mvdd Svi2 Div Ratio Setting
uint32_t MvddRatio; // This is used for MVDD Vid workaround. It has 16
fractional bits (Q16.16)
- uint32_t BoardReserved[9];
+ //FIXME: Reneses VR workaround
+ uint8_t RenesesLoadLineEnabled;
+ uint8_t GfxLoadlineResistance;
+ uint8_t SocLoadlineResistance;
+ uint8_t Padding8_Loadline;
+
+ uint32_t BoardReserved[8];
// Padding for MMHUB - do not modify this
uint32_t MmHubPadding[8]; // SMU internal use
@@ -905,13 +912,22 @@ typedef struct {
} Watermarks_t;
typedef struct {
+ uint16_t avgPsmCount[28];
+ uint16_t minPsmCount[28];
+ floatavgPsmVoltage[28];
+ floatminPsmVoltage[28];
+
+ uint32_t MmHubPadding[32]; // SMU internal use
+} AvfsDebugTable_t_NV14;
+
+typedef struct {
uint16_t avgPsmCount[36];
uint16_t minPsmCount[36];
floatavgPsmVoltage[36];
floatminPsmVoltage[36];
uint32_t MmHubPadding[8]; // SMU internal use
-} AvfsDebugTable_t;
+} AvfsDebugTable_t_NV10;
typedef struct {
uint8_t AvfsVersion;
diff --git a/drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h
b/drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h
index 97605e9..ee8542d 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h
@@ -28,7 +28,7 @@
#define SMU11_DRIVER_IF_VERSION_INV 0x
#define SMU11_DRIVER_IF_VERSION_VG20 0x13
#define SMU11_DRIVER_IF_VERSION_NV10 0x33
-#define SMU11_DRIVER_IF_VERSION_NV14 0x33
+#define SMU11_DRIVER_IF_VERSION_NV14 0x34
/* MP Apertures */
#define MP0_Public 0x0380
--
2.7.4
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: add navi14 PCI ID
Reviewed-by: Xiaojie Yuan
BR,
Xiaojie
From: amd-gfx on behalf of Alex Deucher
Sent: Thursday, August 8, 2019 3:41 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH] drm/amdgpu: add navi14 PCI ID
Add the navi14 PCI device id.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index cf334c465805..79e22c221b77 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1007,6 +1007,8 @@ static const struct pci_device_id pciidlist[] = {
{0x1002, 0x731A, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI10},
{0x1002, 0x731B, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI10},
{0x1002, 0x731F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI10},
+ /* Navi14 */
+ {0x1002, 0x7340, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI14},
{0, 0, 0}
};
--
2.20.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 04/15] mm: remove the pgmap field from struct hmm_vma_walk
On Wed, Aug 7, 2019 at 10:45 AM Jason Gunthorpe wrote:
>
> On Tue, Aug 06, 2019 at 07:05:42PM +0300, Christoph Hellwig wrote:
> > There is only a single place where the pgmap is passed over a function
> > call, so replace it with local variables in the places where we deal
> > with the pgmap.
> >
> > Signed-off-by: Christoph Hellwig
> > mm/hmm.c | 62
> > 1 file changed, 27 insertions(+), 35 deletions(-)
> >
> > diff --git a/mm/hmm.c b/mm/hmm.c
> > index 9a908902e4cc..d66fa29b42e0 100644
> > +++ b/mm/hmm.c
> > @@ -278,7 +278,6 @@ EXPORT_SYMBOL(hmm_mirror_unregister);
> >
> > struct hmm_vma_walk {
> > struct hmm_range*range;
> > - struct dev_pagemap *pgmap;
> > unsigned long last;
> > unsigned intflags;
> > };
> > @@ -475,6 +474,7 @@ static int hmm_vma_handle_pmd(struct mm_walk *walk,
> > #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> > struct hmm_vma_walk *hmm_vma_walk = walk->private;
> > struct hmm_range *range = hmm_vma_walk->range;
> > + struct dev_pagemap *pgmap = NULL;
> > unsigned long pfn, npages, i;
> > bool fault, write_fault;
> > uint64_t cpu_flags;
> > @@ -490,17 +490,14 @@ static int hmm_vma_handle_pmd(struct mm_walk *walk,
> > pfn = pmd_pfn(pmd) + pte_index(addr);
> > for (i = 0; addr < end; addr += PAGE_SIZE, i++, pfn++) {
> > if (pmd_devmap(pmd)) {
> > - hmm_vma_walk->pgmap = get_dev_pagemap(pfn,
> > - hmm_vma_walk->pgmap);
> > - if (unlikely(!hmm_vma_walk->pgmap))
> > + pgmap = get_dev_pagemap(pfn, pgmap);
> > + if (unlikely(!pgmap))
> > return -EBUSY;
>
> Unrelated to this patch, but what is the point of getting checking
> that the pgmap exists for the page and then immediately releasing it?
> This code has this pattern in several places.
>
> It feels racy
Agree, not sure what the intent is here. The only other reason call
get_dev_pagemap() is to just check in general if the pfn is indeed
owned by some ZONE_DEVICE instance, but if the intent is to make sure
the device is still attached/enabled that check is invalidated at
put_dev_pagemap().
If it's the former case, validating ZONE_DEVICE pfns, I imagine we can
do something cheaper with a helper that is on the order of the same
cost as pfn_valid(). I.e. replace PTE_DEVMAP with a mem_section flag
or something similar.
>
> > }
> > pfns[i] = hmm_device_entry_from_pfn(range, pfn) | cpu_flags;
> > }
> > - if (hmm_vma_walk->pgmap) {
> > - put_dev_pagemap(hmm_vma_walk->pgmap);
> > - hmm_vma_walk->pgmap = NULL;
>
> Putting the value in the hmm_vma_walk would have made some sense to me
> if the pgmap was not set to NULL all over the place. Then the most
> xa_loads would be eliminated, as I would expect the pgmap tends to be
> mostly uniform for these use cases.
>
> Is there some reason the pgmap ref can't be held across
> faulting/sleeping? ie like below.
No restriction on holding refs over faulting / sleeping.
>
> Anyhow, I looked over this pretty carefully and the change looks
> functionally OK, I just don't know why the code is like this in the
> first place.
>
> Reviewed-by: Jason Gunthorpe
>
> diff --git a/mm/hmm.c b/mm/hmm.c
> index 9a908902e4cc38..4e30128c23a505 100644
> --- a/mm/hmm.c
> +++ b/mm/hmm.c
> @@ -497,10 +497,6 @@ static int hmm_vma_handle_pmd(struct mm_walk *walk,
> }
> pfns[i] = hmm_device_entry_from_pfn(range, pfn) | cpu_flags;
> }
> - if (hmm_vma_walk->pgmap) {
> - put_dev_pagemap(hmm_vma_walk->pgmap);
> - hmm_vma_walk->pgmap = NULL;
> - }
> hmm_vma_walk->last = end;
> return 0;
> #else
> @@ -604,10 +600,6 @@ static int hmm_vma_handle_pte(struct mm_walk *walk,
> unsigned long addr,
> return 0;
>
> fault:
> - if (hmm_vma_walk->pgmap) {
> - put_dev_pagemap(hmm_vma_walk->pgmap);
> - hmm_vma_walk->pgmap = NULL;
> - }
> pte_unmap(ptep);
> /* Fault any virtual address we were asked to fault */
> return hmm_vma_walk_hole_(addr, end, fault, write_fault, walk);
> @@ -690,16 +682,6 @@ static int hmm_vma_walk_pmd(pmd_t *pmdp,
> return r;
> }
> }
> - if (hmm_vma_walk->pgmap) {
> - /*
> -* We do put_dev_pagemap() here and not in
> hmm_vma_handle_pte()
> -* so that we can leverage get_dev_pagemap() optimization
> which
> -* will not re-take a reference on a pgmap if we already have
> -* one.
> -*/
> - put_dev_pagemap(hmm_vma_walk->pgmap);
> - hmm_vma_walk->pgmap = NULL;
> - }
> pte_unmap(ptep - 1);
>
[pull] amdgpu, amdkfd drm-fixes-5.3
Hi Dave, Daniel, Fixes for 5.3. Nothing too major bug-wise. I'm reverting the kfd GWS ioctl that was added this cycle. After working with it for a while the kfd team decided it wasn't quite right. I should have been stricter with it in the beginning. Revert it. The following changes since commit 9c8c9c7cdb4c8fb48a2bc70f41a07920f761d2cd: Merge tag 'exynos-drm-fixes-for-v5.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes (2019-08-02 17:10:17 +0200) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux tags/drm-fixes-5.3-2019-08-07 for you to fetch changes up to 4b3e30ed3ec7864e798403a63ff2e96bd0c19ab0: Revert "drm/amdkfd: New IOCTL to allocate queue GWS" (2019-08-07 10:21:38 -0500) drm-fixes-5.3-2019-08-07: amdgpu: - Fixes VCN to handle the latest navi10 firmware - Fixes for fan control on navi10 - Properly handle SMU metrics table on navi10 - Fix a resume regression on Stoney amdkfd: - Revert new GWS ioctl. It's not ready. Alex Deucher (1): Revert "drm/amdkfd: New IOCTL to allocate queue GWS" Evan Quan (1): drm/amd/powerplay: correct navi10 vcn powergate Kevin Wang (1): drm/amd/powerplay: honor hw limit on fetching metrics data for navi10 Likun Gao (1): drm/amdgpu: pin the csb buffer on hw init for gfx v8 Marek Olšák (1): Revert "drm/amdgpu: fix transform feedback GDS hang on gfx10 (v2)" Matt Coffin (1): drm/amd/powerplay: Allow changing of fan_control in smu_v11_0 Thong Thai (2): drm/amd/amdgpu/vcn_v2_0: Mark RB commands as KMD commands drm/amd/amdgpu/vcn_v2_0: Move VCN 2.0 specific dec ring test to vcn_v2_0 drivers/gpu/drm/amd/amdgpu/amdgpu_gds.h| 1 - drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h| 1 + drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 12 +--- drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 40 + drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c | 44 +++--- drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 28 - drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 4 +- drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h | 1 + drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 79 +- drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 2 +- include/uapi/linux/kfd_ioctl.h | 20 +-- 11 files changed, 138 insertions(+), 94 deletions(-) ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: hmm cleanups, v2
On Tue, Aug 06, 2019 at 07:05:38PM +0300, Christoph Hellwig wrote: > > Hi Jérôme, Ben, Felix and Jason, > > below is a series against the hmm tree which cleans up various minor > bits and allows HMM_MIRROR to be built on all architectures. > > Diffstat: > > 11 files changed, 94 insertions(+), 210 deletions(-) > > A git tree is also available at: > > git://git.infradead.org/users/hch/misc.git hmm-cleanups.2 > > Gitweb: > > > http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/hmm-cleanups.2 > > Changes since v1: > - fix the cover letter subject > - improve various patch descriptions > - use svmm->mm in nouveau_range_fault > - inverse the hmask field when using it > - select HMM_MIRROR instead of making it a user visible option I think it is straightforward enough to move into -next, so applied to the hmm.git lets get some more reviewed-bys/tested-by though. For now I dropped 'remove the pgmap field from struct hmm_vma_walk' just to hear the followup and 'amdgpu: remove CONFIG_DRM_AMDGPU_USERPTR' until the AMD team Acks Thanks, Jason ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: replace readq/writeq with atomic64 operations
On Wed, Aug 7, 2019 at 9:03 AM Koenig, Christian wrote: > > Am 07.08.19 um 15:00 schrieb Christoph Hellwig: > > On Wed, Aug 07, 2019 at 10:55:01AM +, Koenig, Christian wrote: > Essentially writeq/readq doesn't seems to be available on all > architectures either. > >>> writeq/readq are provided whenever the CPU actually supports 64-bit > >>> atomic loads and stores. > >> Is there a config option which we can make the driver depend on? > >> > >> I mean that ARM doesn't support 64bit atomic loads and stores on MMIO is > >> quite a boomer for us. > > The model is to cheack if readq/writeq are defined, and if not to > > include the one of io-64-nonatomic-hi-lo.h or io-64-nonatomic-lo-hi.h. > > The reason for that is that hardware is supposed to be able to deal with > > two 32-bit writes, but it depends on the hardware if the lower or upper > > half is what commits the write. > > Read, but as I understood Tao change this is not the case here. > Otherwise we would just use our WREG32/RREG32 macros in the driver. > > Tao, please explain why exactly we need the WREG64/RREG64 change which > caused this. We use this for doorbells as well which is also MMIO. Basically we have the requirement to read or write the full 64 bits in one operation. E.g., for 64-bit doorbells, the entire register is the trigger so if we do it as two writes, we'll miss half the update. In the case of some error counter registers, reading the register will clear the value so we need to read out the full value or we lose the half the value. This works properly on x86 and AMD64. Alex > > Christian. > > > > > The only 32-bit platform that claims support for readq/writeq is sh, > > and I have doubts if that actually works as expected. > > ___ > amd-gfx mailing list > amd-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 09/15] mm: don't abuse pte_index() in hmm_vma_handle_pmd
On Tue, Aug 06, 2019 at 07:05:47PM +0300, Christoph Hellwig wrote: > pte_index is an internal arch helper in various architectures, > without consistent semantics. Open code that calculation of a PMD > index based on the virtual address instead. > > Signed-off-by: Christoph Hellwig > --- > mm/hmm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) There sure are a lot of different ways to express this, but this one looks OK to me, at least the switch from the PTRS_PER_PTE expression in the x86 imlpementation to PMD_MASK looks equivalent Reviewed-by: Jason Gunthorpe Jason ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 07/15] mm: remove the page_shift member from struct hmm_range
On Tue, Aug 06, 2019 at 07:05:45PM +0300, Christoph Hellwig wrote:
> All users pass PAGE_SIZE here, and if we wanted to support single
> entries for huge pages we should really just add a HMM_FAULT_HUGEPAGE
> flag instead that uses the huge page size instead of having the
> caller calculate that size once, just for the hmm code to verify it.
>
> Signed-off-by: Christoph Hellwig
> Acked-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 1 -
> drivers/gpu/drm/nouveau/nouveau_svm.c | 1 -
> include/linux/hmm.h | 22 -
> mm/hmm.c| 42 ++---
> 4 files changed, 9 insertions(+), 57 deletions(-)
Having looked at ODP more closley this doesn't seem to match what it
needs anyhow. It can keep using its checking algorithm
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 71d6e7087b0b..8bf79288c4e2 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -818,7 +818,6 @@ int amdgpu_ttm_tt_get_user_pages(struct amdgpu_bo *bo,
> struct page **pages)
> 0 : range->flags[HMM_PFN_WRITE];
> range->pfn_flags_mask = 0;
> range->pfns = pfns;
> - range->page_shift = PAGE_SHIFT;
> range->start = start;
> range->end = start + ttm->num_pages * PAGE_SIZE;
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
> b/drivers/gpu/drm/nouveau/nouveau_svm.c
> index 41fad4719ac6..668d4bd0c118 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_svm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_svm.c
> @@ -680,7 +680,6 @@ nouveau_svm_fault(struct nvif_notify *notify)
>args.i.p.addr + args.i.p.size, fn - fi);
>
> /* Have HMM fault pages within the fault window to the GPU. */
> - range.page_shift = PAGE_SHIFT;
> range.start = args.i.p.addr;
> range.end = args.i.p.addr + args.i.p.size;
> range.pfns = args.phys;
> diff --git a/include/linux/hmm.h b/include/linux/hmm.h
> index c5b51376b453..51e18fbb8953 100644
> --- a/include/linux/hmm.h
> +++ b/include/linux/hmm.h
> @@ -158,7 +158,6 @@ enum hmm_pfn_value_e {
> * @values: pfn value for some special case (none, special, error, ...)
> * @default_flags: default flags for the range (write, read, ... see hmm doc)
> * @pfn_flags_mask: allows to mask pfn flags so that only default_flags
> matter
> - * @page_shift: device virtual address shift value (should be >= PAGE_SHIFT)
> * @pfn_shifts: pfn shift value (should be <= PAGE_SHIFT)
> * @valid: pfns array did not change since it has been fill by an HMM
> function
> */
> @@ -172,31 +171,10 @@ struct hmm_range {
> const uint64_t *values;
> uint64_tdefault_flags;
> uint64_tpfn_flags_mask;
> - uint8_t page_shift;
> uint8_t pfn_shift;
> boolvalid;
> };
>
> -/*
> - * hmm_range_page_shift() - return the page shift for the range
> - * @range: range being queried
> - * Return: page shift (page size = 1 << page shift) for the range
> - */
> -static inline unsigned hmm_range_page_shift(const struct hmm_range *range)
> -{
> - return range->page_shift;
> -}
> -
> -/*
> - * hmm_range_page_size() - return the page size for the range
> - * @range: range being queried
> - * Return: page size for the range in bytes
> - */
> -static inline unsigned long hmm_range_page_size(const struct hmm_range
> *range)
> -{
> - return 1UL << hmm_range_page_shift(range);
> -}
> -
> /*
> * hmm_range_wait_until_valid() - wait for range to be valid
> * @range: range affected by invalidation to wait on
> diff --git a/mm/hmm.c b/mm/hmm.c
> index 926735a3aef9..f26d6abc4ed2 100644
> --- a/mm/hmm.c
> +++ b/mm/hmm.c
> @@ -344,13 +344,12 @@ static int hmm_vma_walk_hole_(unsigned long addr,
> unsigned long end,
> struct hmm_vma_walk *hmm_vma_walk = walk->private;
> struct hmm_range *range = hmm_vma_walk->range;
> uint64_t *pfns = range->pfns;
> - unsigned long i, page_size;
> + unsigned long i;
>
> hmm_vma_walk->last = addr;
> - page_size = hmm_range_page_size(range);
> - i = (addr - range->start) >> range->page_shift;
> + i = (addr - range->start) >> PAGE_SHIFT;
>
> - for (; addr < end; addr += page_size, i++) {
> + for (; addr < end; addr += PAGE_SIZE, i++) {
> pfns[i] = range->values[HMM_PFN_NONE];
> if (fault || write_fault) {
> int ret;
> @@ -772,7 +771,7 @@ static int hmm_vma_walk_hugetlb_entry(pte_t *pte,
> unsigned long hmask,
> struct mm_walk *walk)
> {
> #ifdef CONFIG_HUGETLB_PAGE
> - unsigned long addr = start, i, pfn, mask, size, pfn_inc;
> + unsigned long addr = start, i, pfn, mask;
> struct hmm_vma_walk
Re: [PATCH 04/15] mm: remove the pgmap field from struct hmm_vma_walk
On Tue, Aug 06, 2019 at 07:05:42PM +0300, Christoph Hellwig wrote:
> There is only a single place where the pgmap is passed over a function
> call, so replace it with local variables in the places where we deal
> with the pgmap.
>
> Signed-off-by: Christoph Hellwig
> mm/hmm.c | 62
> 1 file changed, 27 insertions(+), 35 deletions(-)
>
> diff --git a/mm/hmm.c b/mm/hmm.c
> index 9a908902e4cc..d66fa29b42e0 100644
> +++ b/mm/hmm.c
> @@ -278,7 +278,6 @@ EXPORT_SYMBOL(hmm_mirror_unregister);
>
> struct hmm_vma_walk {
> struct hmm_range*range;
> - struct dev_pagemap *pgmap;
> unsigned long last;
> unsigned intflags;
> };
> @@ -475,6 +474,7 @@ static int hmm_vma_handle_pmd(struct mm_walk *walk,
> #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> struct hmm_vma_walk *hmm_vma_walk = walk->private;
> struct hmm_range *range = hmm_vma_walk->range;
> + struct dev_pagemap *pgmap = NULL;
> unsigned long pfn, npages, i;
> bool fault, write_fault;
> uint64_t cpu_flags;
> @@ -490,17 +490,14 @@ static int hmm_vma_handle_pmd(struct mm_walk *walk,
> pfn = pmd_pfn(pmd) + pte_index(addr);
> for (i = 0; addr < end; addr += PAGE_SIZE, i++, pfn++) {
> if (pmd_devmap(pmd)) {
> - hmm_vma_walk->pgmap = get_dev_pagemap(pfn,
> - hmm_vma_walk->pgmap);
> - if (unlikely(!hmm_vma_walk->pgmap))
> + pgmap = get_dev_pagemap(pfn, pgmap);
> + if (unlikely(!pgmap))
> return -EBUSY;
Unrelated to this patch, but what is the point of getting checking
that the pgmap exists for the page and then immediately releasing it?
This code has this pattern in several places.
It feels racy
> }
> pfns[i] = hmm_device_entry_from_pfn(range, pfn) | cpu_flags;
> }
> - if (hmm_vma_walk->pgmap) {
> - put_dev_pagemap(hmm_vma_walk->pgmap);
> - hmm_vma_walk->pgmap = NULL;
Putting the value in the hmm_vma_walk would have made some sense to me
if the pgmap was not set to NULL all over the place. Then the most
xa_loads would be eliminated, as I would expect the pgmap tends to be
mostly uniform for these use cases.
Is there some reason the pgmap ref can't be held across
faulting/sleeping? ie like below.
Anyhow, I looked over this pretty carefully and the change looks
functionally OK, I just don't know why the code is like this in the
first place.
Reviewed-by: Jason Gunthorpe
diff --git a/mm/hmm.c b/mm/hmm.c
index 9a908902e4cc38..4e30128c23a505 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -497,10 +497,6 @@ static int hmm_vma_handle_pmd(struct mm_walk *walk,
}
pfns[i] = hmm_device_entry_from_pfn(range, pfn) | cpu_flags;
}
- if (hmm_vma_walk->pgmap) {
- put_dev_pagemap(hmm_vma_walk->pgmap);
- hmm_vma_walk->pgmap = NULL;
- }
hmm_vma_walk->last = end;
return 0;
#else
@@ -604,10 +600,6 @@ static int hmm_vma_handle_pte(struct mm_walk *walk,
unsigned long addr,
return 0;
fault:
- if (hmm_vma_walk->pgmap) {
- put_dev_pagemap(hmm_vma_walk->pgmap);
- hmm_vma_walk->pgmap = NULL;
- }
pte_unmap(ptep);
/* Fault any virtual address we were asked to fault */
return hmm_vma_walk_hole_(addr, end, fault, write_fault, walk);
@@ -690,16 +682,6 @@ static int hmm_vma_walk_pmd(pmd_t *pmdp,
return r;
}
}
- if (hmm_vma_walk->pgmap) {
- /*
-* We do put_dev_pagemap() here and not in hmm_vma_handle_pte()
-* so that we can leverage get_dev_pagemap() optimization which
-* will not re-take a reference on a pgmap if we already have
-* one.
-*/
- put_dev_pagemap(hmm_vma_walk->pgmap);
- hmm_vma_walk->pgmap = NULL;
- }
pte_unmap(ptep - 1);
hmm_vma_walk->last = addr;
@@ -751,10 +733,6 @@ static int hmm_vma_walk_pud(pud_t *pudp,
pfns[i] = hmm_device_entry_from_pfn(range, pfn) |
cpu_flags;
}
- if (hmm_vma_walk->pgmap) {
- put_dev_pagemap(hmm_vma_walk->pgmap);
- hmm_vma_walk->pgmap = NULL;
- }
hmm_vma_walk->last = end;
return 0;
}
@@ -1026,6 +1004,14 @@ long hmm_range_fault(struct hmm_range *range, unsigned
int flags)
/* Keep trying while the range is valid. */
} while (ret == -EBUSY && range->valid);
+ /*
+* We do put_dev_pagemap() here so that we can leverage
+* get_dev_pagemap() optimization
Re: [Regression] "drm/amdgpu: enable gfxoff again on raven series (v2)"
Hi Ray,
at 00:03, Huang, Ray wrote:
May I know the all firmware version in your system?
# cat amdgpu_firmware_info
VCE feature version: 0, firmware version: 0x
UVD feature version: 0, firmware version: 0x
MC feature version: 0, firmware version: 0x
ME feature version: 40, firmware version: 0x0099
PFP feature version: 40, firmware version: 0x00ae
CE feature version: 40, firmware version: 0x004d
RLC feature version: 1, firmware version: 0x0213
RLC SRLC feature version: 1, firmware version: 0x0001
RLC SRLG feature version: 1, firmware version: 0x0001
RLC SRLS feature version: 1, firmware version: 0x0001
MEC feature version: 40, firmware version: 0x018b
MEC2 feature version: 40, firmware version: 0x018b
SOS feature version: 0, firmware version: 0x
ASD feature version: 0, firmware version: 0x001ad4d4
TA XGMI feature version: 0, firmware version: 0x
TA RAS feature version: 0, firmware version: 0x
SMC feature version: 0, firmware version: 0x1e44
SDMA0 feature version: 41, firmware version: 0x00a9
VCN feature version: 0, firmware version: 0x0110901c
DMCU feature version: 0, firmware version: 0x
VBIOS version: 113-RAVEN-103
Kai-Heng
Thanks,
Ray
From: Kai-Heng Feng
Sent: Wednesday, August 7, 2019 8:50 PM
To: Huang, Ray
Cc: Deucher, Alexander; Koenig, Christian; Zhou, David(ChunMing); amd-gfx
list; dri-de...@lists.freedesktop.org; LKML; Anthony Wong
Subject: [Regression] "drm/amdgpu: enable gfxoff again on raven series
(v2)"
Hi,
After commit 005440066f92 ("drm/amdgpu: enable gfxoff again on raven series
(v2)”), browsers on Raven Ridge systems cause serious corruption like this:
https://launchpadlibrarian.net/436319772/Screenshot%20from%202019-08-07%2004-20-34.png
Firmwares for Raven Ridge is up-to-date.
Kai-Heng
Re: [PATCH v19 00/15] arm64: untag user pointers passed to the kernel
On Tue, Aug 6, 2019 at 7:13 PM Will Deacon wrote: > > On Wed, Jul 24, 2019 at 03:20:59PM +0100, Will Deacon wrote: > > On Wed, Jul 24, 2019 at 04:16:49PM +0200, Andrey Konovalov wrote: > > > On Wed, Jul 24, 2019 at 4:02 PM Will Deacon wrote: > > > > On Tue, Jul 23, 2019 at 08:03:29PM +0200, Andrey Konovalov wrote: > > > > > Should this go through the mm or the arm tree? > > > > > > > > I would certainly prefer to take at least the arm64 bits via the arm64 > > > > tree > > > > (i.e. patches 1, 2 and 15). We also need a Documentation patch > > > > describing > > > > the new ABI. > > > > > > Sounds good! Should I post those patches together with the > > > Documentation patches from Vincenzo as a separate patchset? > > > > Yes, please (although as you say below, we need a new version of those > > patches from Vincenzo to address the feedback on v5). The other thing I > > should say is that I'd be happy to queue the other patches in the series > > too, but some of them are missing acks from the relevant maintainers (e.g. > > the mm/ and fs/ changes). > > Ok, I've queued patches 1, 2, and 15 on a stable branch here: > > > https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/tbi > > which should find its way into -next shortly via our for-next/core branch. > If you want to make changes, please send additional patches on top. > > This is targetting 5.4, but I will drop it before the merge window if > we don't have both of the following in place: > > * Updated ABI documentation with Acks from Catalin and Kevin Catalin has posted a new version today. > * The other patches in the series either Acked (so I can pick them up) > or queued via some other tree(s) for 5.4. So we have the following patches in this series: 1. arm64: untag user pointers in access_ok and __uaccess_mask_ptr 2. arm64: Introduce prctl() options to control the tagged user addresses ABI 3. lib: untag user pointers in strn*_user 4. mm: untag user pointers passed to memory syscalls 5. mm: untag user pointers in mm/gup.c 6. mm: untag user pointers in get_vaddr_frames 7. fs/namespace: untag user pointers in copy_mount_options 8. userfaultfd: untag user pointers 9. drm/amdgpu: untag user pointers 10. drm/radeon: untag user pointers in radeon_gem_userptr_ioctl 11. IB/mlx4: untag user pointers in mlx4_get_umem_mr 12. media/v4l2-core: untag user pointers in videobuf_dma_contig_user_get 13. tee/shm: untag user pointers in tee_shm_register 14. vfio/type1: untag user pointers in vaddr_get_pfn 15. selftests, arm64: add a selftest for passing tagged pointers to kernel 1, 2 and 15 have been picked by Will. 11 has been picked up by Jason. 9, 10, 12, 13 and 14 have acks from their subsystem maintainers. 3 touches generic lib code, I'm not sure if there's a dedicated maintainer for that. The ones that are left are the mm ones: 4, 5, 6, 7 and 8. Andrew, could you take a look and give your Acked-by or pick them up directly? > > Make sense? > > Cheers, > > Will Thanks!
Re: [PATCH] drm/amd/display: Remove drm_dsc_dc.c
On 2019-08-07 10:29 a.m., David Francis wrote:
> This file was accidentally added to the driver during
> Navi promotion
>
> Nothing includes it. No makefile attempts to compile it, and
> it would fail compilation if they tried
>
> Remove it
>
> Signed-off-by: David Francis
Reviewed-by: Harry Wentland
Harry
> ---
> .../gpu/drm/amd/display/dc/dsc/drm_dsc_dc.c | 453 --
> 1 file changed, 453 deletions(-)
> delete mode 100644 drivers/gpu/drm/amd/display/dc/dsc/drm_dsc_dc.c
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dsc/drm_dsc_dc.c
> b/drivers/gpu/drm/amd/display/dc/dsc/drm_dsc_dc.c
> deleted file mode 100644
> index fd1fb1653479..
> --- a/drivers/gpu/drm/amd/display/dc/dsc/drm_dsc_dc.c
> +++ /dev/null
> @@ -1,453 +0,0 @@
> -// SPDX-License-Identifier: MIT
> -/*
> - * Copyright © 2018 Intel Corp
> - *
> - * Author:
> - * Manasi Navare
> - */
> -
> -/* DC versions of linux includes */
> -#include
> -
> -#define EXPORT_SYMBOL(symbol)/* nothing */
> -#define BUILD_BUG_ON(cond) /* nothing */
> -#define DIV_ROUND_UP(a, b) (((b) + (a) - 1) / (b))
> -#define ERANGE -1
> -#define DRM_DEBUG_KMS(msg) /* nothing */
> -#define cpu_to_be16(__x) little_to_big(__x)
> -#define MAX(x, y)((x) > (y) ? (x) : (y))
> -
> -static unsigned short little_to_big(int data)
> -{
> - /* Swap lower and upper byte. DMCU uses big endian format. */
> - return (0xff & (data >> 8)) + ((data & 0xff) << 8);
> -}
> -
> -/*
> - * Everything below this comment was copied directly from drm_dsc.c.
> - * Only the functions needed in DC are included.
> - * Please keep this file synced with upstream.
> - */
> -
> -/**
> - * DOC: dsc helpers
> - *
> - * These functions contain some common logic and helpers to deal with VESA
> - * Display Stream Compression standard required for DSC on Display Port/eDP
> or
> - * MIPI display interfaces.
> - */
> -
> -/**
> - * drm_dsc_pps_payload_pack() - Populates the DSC PPS
> - *
> - * @pps_payload:
> - * Bitwise struct for DSC Picture Parameter Set. This is defined
> - * by drm_dsc_picture_parameter_set
> - * @dsc_cfg:
> - * DSC Configuration data filled by driver as defined by
> - * drm_dsc_config
> - *
> - * DSC source device sends a picture parameter set (PPS) containing the
> - * information required by the sink to decode the compressed frame. Driver
> - * populates the DSC PPS struct using the DSC configuration parameters in
> - * the order expected by the DSC Display Sink device. For the DSC, the sink
> - * device expects the PPS payload in big endian format for fields
> - * that span more than 1 byte.
> - */
> -void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set
> *pps_payload,
> - const struct drm_dsc_config *dsc_cfg)
> -{
> - int i;
> -
> - /* Protect against someone accidently changing struct size */
> - BUILD_BUG_ON(sizeof(*pps_payload) !=
> - DP_SDP_PPS_HEADER_PAYLOAD_BYTES_MINUS_1 + 1);
> -
> - memset(pps_payload, 0, sizeof(*pps_payload));
> -
> - /* PPS 0 */
> - pps_payload->dsc_version =
> - dsc_cfg->dsc_version_minor |
> - dsc_cfg->dsc_version_major << DSC_PPS_VERSION_MAJOR_SHIFT;
> -
> - /* PPS 1, 2 is 0 */
> -
> - /* PPS 3 */
> - pps_payload->pps_3 =
> - dsc_cfg->line_buf_depth |
> - dsc_cfg->bits_per_component << DSC_PPS_BPC_SHIFT;
> -
> - /* PPS 4 */
> - pps_payload->pps_4 =
> - ((dsc_cfg->bits_per_pixel & DSC_PPS_BPP_HIGH_MASK) >>
> - DSC_PPS_MSB_SHIFT) |
> - dsc_cfg->vbr_enable << DSC_PPS_VBR_EN_SHIFT |
> - dsc_cfg->simple_422 << DSC_PPS_SIMPLE422_SHIFT |
> - dsc_cfg->convert_rgb << DSC_PPS_CONVERT_RGB_SHIFT |
> - dsc_cfg->block_pred_enable << DSC_PPS_BLOCK_PRED_EN_SHIFT;
> -
> - /* PPS 5 */
> - pps_payload->bits_per_pixel_low =
> - (dsc_cfg->bits_per_pixel & DSC_PPS_LSB_MASK);
> -
> - /*
> - * The DSC panel expects the PPS packet to have big endian format
> - * for data spanning 2 bytes. Use a macro cpu_to_be16() to convert
> - * to big endian format. If format is little endian, it will swap
> - * bytes to convert to Big endian else keep it unchanged.
> - */
> -
> - /* PPS 6, 7 */
> - pps_payload->pic_height = cpu_to_be16(dsc_cfg->pic_height);
> -
> - /* PPS 8, 9 */
> - pps_payload->pic_width = cpu_to_be16(dsc_cfg->pic_width);
> -
> - /* PPS 10, 11 */
> - pps_payload->slice_height = cpu_to_be16(dsc_cfg->slice_height);
> -
> - /* PPS 12, 13 */
> - pps_payload->slice_width = cpu_to_be16(dsc_cfg->slice_width);
> -
> - /* PPS 14, 15 */
> - pps_payload->chunk_size = cpu_to_be16(dsc_cfg->slice_chunk_size);
> -
> - /* PPS 16 */
> - pps_payload->initial_xmit_delay_high =
> - ((dsc_cfg->initial_xmit_delay &
> - DSC_PPS_INIT_XMIT_DELAY_HIGH_MASK) >>
> -
RE: [PATCH] Revert "drm/amdkfd: New IOCTL to allocate queue GWS"
Acked-by: Oak Zeng
Regards,
Oak
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Wednesday, August 7, 2019 11:01 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH] Revert "drm/amdkfd: New IOCTL to allocate queue GWS"
This reverts commit 1a058c3376765ee31d65e28cbbb9d4ff15120056.
This interface is still in too much flux. Revert until it's sorted out.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 28
include/uapi/linux/kfd_ioctl.h | 20 +
2 files changed, 1 insertion(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index 26b15cc56c31..1d3cd5c50d5f 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -1567,32 +1567,6 @@ static int kfd_ioctl_unmap_memory_from_gpu(struct file
*filep,
return err;
}
-static int kfd_ioctl_alloc_queue_gws(struct file *filep,
- struct kfd_process *p, void *data)
-{
- int retval;
- struct kfd_ioctl_alloc_queue_gws_args *args = data;
- struct kfd_dev *dev;
-
- if (!hws_gws_support)
- return -ENODEV;
-
- dev = kfd_device_by_id(args->gpu_id);
- if (!dev) {
- pr_debug("Could not find gpu id 0x%x\n", args->gpu_id);
- return -ENODEV;
- }
- if (dev->dqm->sched_policy == KFD_SCHED_POLICY_NO_HWS)
- return -ENODEV;
-
- mutex_lock(>mutex);
- retval = pqm_set_gws(>pqm, args->queue_id, args->num_gws ? dev->gws
: NULL);
- mutex_unlock(>mutex);
-
- args->first_gws = 0;
- return retval;
-}
-
static int kfd_ioctl_get_dmabuf_info(struct file *filep,
struct kfd_process *p, void *data)
{
@@ -1795,8 +1769,6 @@ static const struct amdkfd_ioctl_desc amdkfd_ioctls[] = {
AMDKFD_IOCTL_DEF(AMDKFD_IOC_IMPORT_DMABUF,
kfd_ioctl_import_dmabuf, 0),
- AMDKFD_IOCTL_DEF(AMDKFD_IOC_ALLOC_QUEUE_GWS,
- kfd_ioctl_alloc_queue_gws, 0),
};
#define AMDKFD_CORE_IOCTL_COUNTARRAY_SIZE(amdkfd_ioctls)
diff --git a/include/uapi/linux/kfd_ioctl.h b/include/uapi/linux/kfd_ioctl.h
index 070d1bc7e725..20917c59f39c 100644
--- a/include/uapi/linux/kfd_ioctl.h
+++ b/include/uapi/linux/kfd_ioctl.h
@@ -410,21 +410,6 @@ struct kfd_ioctl_unmap_memory_from_gpu_args {
__u32 n_success;/* to/from KFD */
};
-/* Allocate GWS for specific queue
- *
- * @gpu_id: device identifier
- * @queue_id:queue's id that GWS is allocated for
- * @num_gws: how many GWS to allocate
- * @first_gws: index of the first GWS allocated.
- * only support contiguous GWS allocation
- */
-struct kfd_ioctl_alloc_queue_gws_args {
- __u32 gpu_id; /* to KFD */
- __u32 queue_id; /* to KFD */
- __u32 num_gws; /* to KFD */
- __u32 first_gws;/* from KFD */
-};
-
struct kfd_ioctl_get_dmabuf_info_args {
__u64 size; /* from KFD */
__u64 metadata_ptr; /* to KFD */
@@ -544,10 +529,7 @@ enum kfd_mmio_remap {
#define AMDKFD_IOC_IMPORT_DMABUF \
AMDKFD_IOWR(0x1D, struct kfd_ioctl_import_dmabuf_args)
-#define AMDKFD_IOC_ALLOC_QUEUE_GWS \
- AMDKFD_IOWR(0x1E, struct kfd_ioctl_alloc_queue_gws_args)
-
#define AMDKFD_COMMAND_START 0x01
-#define AMDKFD_COMMAND_END 0x1F
+#define AMDKFD_COMMAND_END 0x1E
#endif
--
2.20.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
RE: [PATCH 1/2] drm/amdgpu: Export function to flush TLB of specific vm hub
Thanks. I realized I didn't read the code careful enough...The workaround is
only for navi10 and navi12 - I didn't read this correctly and was thinking
gfxhub tlb invalidation was done twice.
I understand the codes now. I think the HW SDMA bug has been fixed in navi14 so
we don't need that WA for 14.
Regards,
Oak
-Original Message-
From: Christian König
Sent: Wednesday, August 7, 2019 4:51 AM
To: Zeng, Oak ; Kuehling, Felix ;
Koenig, Christian ; amd-gfx@lists.freedesktop.org;
Zhang, Hawking ; Deucher, Alexander
Cc: Zhou1, Tao ; Liu, Shaoyun
Subject: Re: [PATCH 1/2] drm/amdgpu: Export function to flush TLB of specific
vm hub
> Does the coded below invalidate TLB on both mm and gfx hub?
No, just the gfx hub. The VMHUBs on Navi are unfortunately really buggy, so we
had to do a lot of workarounds to get them into a state where they actually did
what was expected from them.
One major issue for example is that you can't do MMIO based VM invalidation
when the engine is busy. To work around this we do the invalidation with the
(IIRC) SDMA engine as soon as that one is working.
The is the code you are noting below.
Regards,
Christian.
Am 07.08.19 um 04:40 schrieb Zeng, Oak:
> Ok, will do it.
>
> BTW, does those codes below really needed, in function
> gmc_v10_0_flush_gpu_tlb. I think if we have the bug, then before below
> codes, when we flush TLB of gfxhub through mmio, it has already
> triggered the bug. Also as we already invalidated tlb on both mm and
> gfx hub (in the same function gmc_v10_0_flush_gpu_tlb), what is the
> point of below codes? Does the coded below invalidate TLB on both mm
> and gfx hub? Also @Zhang, Hawking@Deucher, Alexander
>
> /* The SDMA on Navi has a bug which can theoretically result in memory
>* corruption if an invalidation happens at the same time as an VA
>* translation. Avoid this by doing the invalidation from the SDMA
>* itself.
>*/
> r = amdgpu_job_alloc_with_ib(adev, 16 * 4, );
> if (r)
> goto error_alloc;
>
> job->vm_pd_addr = amdgpu_gmc_pd_addr(adev->gart.bo);
> job->vm_needs_flush = true;
> amdgpu_ring_pad_ib(ring, >ibs[0]);
> r = amdgpu_job_submit(job, >mman.entity,
> AMDGPU_FENCE_OWNER_UNDEFINED, );
>
> Regards,
> Oak
>
> -Original Message-
> From: Christian König
> Sent: Monday, August 5, 2019 5:37 AM
> To: Zeng, Oak ; amd-gfx@lists.freedesktop.org
> Cc: Kuehling, Felix ; Zhou1, Tao
> ; Liu, Shaoyun
> Subject: Re: [PATCH 1/2] drm/amdgpu: Export function to flush TLB of
> specific vm hub
>
> Am 02.08.19 um 18:04 schrieb Zeng, Oak:
>> This is for kfd to reuse amdgpu TLB invalidation function. There is
>> already a gmc function flush_gpu_tlb to flush TLB on all vm hub. On
>> gfx10, kfd only needs to flush TLB on gfx hub but not on mm hub. So
>> export a function for KFD flush TLB only on gfx hub.
> I would rather go ahead and add another parameter to flush_gpu_tlb to note
> which hub needs flushing.
>
> We can probably easily extend the few callers to flush all hubs needed.
>
> Christian.
>
>> Change-Id: I58ff00969f88438cfd3dc7e9deb7bff0c1bb4133
>> Signed-off-by: Oak Zeng
>> ---
>>drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h | 4
>>drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 1 +
>>2 files changed, 5 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h
>> index 071145a..0bd4a4f 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h
>> @@ -88,6 +88,9 @@ struct amdgpu_vmhub {
>> * GPU MC structures, functions & helpers
>> */
>>struct amdgpu_gmc_funcs {
>> +/* flush vm tlb of specific hub */
>> +void (*flush_vm_hub)(struct amdgpu_device *adev, uint32_t vmid,
>> + unsigned int vmhub, uint32_t flush_type);
>> /* flush the vm tlb via mmio */
>> void (*flush_gpu_tlb)(struct amdgpu_device *adev,
>>uint32_t vmid, uint32_t flush_type); @@ -180,6
>> +183,7 @@
>> struct amdgpu_gmc {
>> struct ras_common_if*ras_if;
>>};
>>
>> +#define amdgpu_gmc_flush_vm_hub(adev, vmid, vmhub, type)
>> +((adev)->gmc.gmc_funcs->flush_vm_hub((adev), (vmid), (vmhub),
>> +(type)))
>>#define amdgpu_gmc_flush_gpu_tlb(adev, vmid, type)
>> (adev)->gmc.gmc_funcs->flush_gpu_tlb((adev), (vmid), (type))
>>#define amdgpu_gmc_emit_flush_gpu_tlb(r, vmid, addr)
>> (r)->adev->gmc.gmc_funcs->emit_flush_gpu_tlb((r), (vmid), (addr))
>>#define amdgpu_gmc_emit_pasid_mapping(r, vmid, pasid)
>> (r)->adev->gmc.gmc_funcs->emit_pasid_mapping((r), (vmid), (pasid))
>> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
>> b/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
>> index 4e3ac10..247515d 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
>> @@ -416,6 +416,7 @@ static void
[PATCH] nouveau/hmm: map pages after migration
When memory is migrated to the GPU it is likely to be accessed by GPU
code soon afterwards. Instead of waiting for a GPU fault, map the
migrated memory into the GPU page tables with the same access permissions
as the source CPU page table entries. This preserves copy on write
semantics.
Signed-off-by: Ralph Campbell
Cc: Christoph Hellwig
Cc: Jason Gunthorpe
Cc: "Jérôme Glisse"
Cc: Ben Skeggs
---
This patch is based on top of Christoph Hellwig's 9 patch series
https://lore.kernel.org/linux-mm/20190729234611.gc7...@redhat.com/T/#u
"turn the hmm migrate_vma upside down" but without patch 9
"mm: remove the unused MIGRATE_PFN_WRITE" and adds a use for the flag.
drivers/gpu/drm/nouveau/nouveau_dmem.c | 45 +-
drivers/gpu/drm/nouveau/nouveau_svm.c | 86 ++
drivers/gpu/drm/nouveau/nouveau_svm.h | 19 ++
3 files changed, 133 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c
b/drivers/gpu/drm/nouveau/nouveau_dmem.c
index ef9de82b0744..c83e6f118817 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dmem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c
@@ -25,11 +25,13 @@
#include "nouveau_dma.h"
#include "nouveau_mem.h"
#include "nouveau_bo.h"
+#include "nouveau_svm.h"
#include
#include
#include
#include
+#include
#include
#include
@@ -560,11 +562,12 @@ nouveau_dmem_init(struct nouveau_drm *drm)
}
static unsigned long nouveau_dmem_migrate_copy_one(struct nouveau_drm *drm,
- struct vm_area_struct *vma, unsigned long addr,
- unsigned long src, dma_addr_t *dma_addr)
+ struct vm_area_struct *vma, unsigned long src,
+ dma_addr_t *dma_addr, u64 *pfn)
{
struct device *dev = drm->dev->dev;
struct page *dpage, *spage;
+ unsigned long paddr;
spage = migrate_pfn_to_page(src);
if (!spage || !(src & MIGRATE_PFN_MIGRATE))
@@ -572,17 +575,21 @@ static unsigned long nouveau_dmem_migrate_copy_one(struct
nouveau_drm *drm,
dpage = nouveau_dmem_page_alloc_locked(drm);
if (!dpage)
- return 0;
+ goto out;
*dma_addr = dma_map_page(dev, spage, 0, PAGE_SIZE, DMA_BIDIRECTIONAL);
if (dma_mapping_error(dev, *dma_addr))
goto out_free_page;
+ paddr = nouveau_dmem_page_addr(dpage);
if (drm->dmem->migrate.copy_func(drm, 1, NOUVEAU_APER_VRAM,
- nouveau_dmem_page_addr(dpage), NOUVEAU_APER_HOST,
- *dma_addr))
+ paddr, NOUVEAU_APER_HOST, *dma_addr))
goto out_dma_unmap;
+ *pfn = NVIF_VMM_PFNMAP_V0_V | NVIF_VMM_PFNMAP_V0_VRAM |
+ ((paddr >> PAGE_SHIFT) << NVIF_VMM_PFNMAP_V0_ADDR_SHIFT);
+ if (src & MIGRATE_PFN_WRITE)
+ *pfn |= NVIF_VMM_PFNMAP_V0_W;
return migrate_pfn(page_to_pfn(dpage)) | MIGRATE_PFN_LOCKED;
out_dma_unmap:
@@ -590,18 +597,19 @@ static unsigned long nouveau_dmem_migrate_copy_one(struct
nouveau_drm *drm,
out_free_page:
nouveau_dmem_page_free_locked(drm, dpage);
out:
+ *pfn = NVIF_VMM_PFNMAP_V0_NONE;
return 0;
}
static void nouveau_dmem_migrate_chunk(struct migrate_vma *args,
- struct nouveau_drm *drm, dma_addr_t *dma_addrs)
+ struct nouveau_drm *drm, dma_addr_t *dma_addrs, u64 *pfns)
{
struct nouveau_fence *fence;
unsigned long addr = args->start, nr_dma = 0, i;
for (i = 0; addr < args->end; i++) {
args->dst[i] = nouveau_dmem_migrate_copy_one(drm, args->vma,
- addr, args->src[i], _addrs[nr_dma]);
+ args->src[i], _addrs[nr_dma], [i]);
if (args->dst[i])
nr_dma++;
addr += PAGE_SIZE;
@@ -615,10 +623,6 @@ static void nouveau_dmem_migrate_chunk(struct migrate_vma
*args,
dma_unmap_page(drm->dev->dev, dma_addrs[nr_dma], PAGE_SIZE,
DMA_BIDIRECTIONAL);
}
- /*
-* FIXME optimization: update GPU page table to point to newly migrated
-* memory.
-*/
migrate_vma_finalize(args);
}
@@ -631,11 +635,12 @@ nouveau_dmem_migrate_vma(struct nouveau_drm *drm,
unsigned long npages = (end - start) >> PAGE_SHIFT;
unsigned long max = min(SG_MAX_SINGLE_ALLOC, npages);
dma_addr_t *dma_addrs;
+ u64 *pfns;
struct migrate_vma args = {
.vma= vma,
.start = start,
};
- unsigned long c, i;
+ unsigned long i;
int ret = -ENOMEM;
args.src = kcalloc(max, sizeof(args.src), GFP_KERNEL);
@@ -649,19 +654,25 @@ nouveau_dmem_migrate_vma(struct nouveau_drm *drm,
if (!dma_addrs)
goto out_free_dst;
- for (i = 0; i < npages; i += c) {
- c = min(SG_MAX_SINGLE_ALLOC, npages);
-
[PATCH] Revert "drm/amdkfd: New IOCTL to allocate queue GWS"
This reverts commit 1a058c3376765ee31d65e28cbbb9d4ff15120056.
This interface is still in too much flux. Revert until
it's sorted out.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 28
include/uapi/linux/kfd_ioctl.h | 20 +
2 files changed, 1 insertion(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index 26b15cc56c31..1d3cd5c50d5f 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -1567,32 +1567,6 @@ static int kfd_ioctl_unmap_memory_from_gpu(struct file
*filep,
return err;
}
-static int kfd_ioctl_alloc_queue_gws(struct file *filep,
- struct kfd_process *p, void *data)
-{
- int retval;
- struct kfd_ioctl_alloc_queue_gws_args *args = data;
- struct kfd_dev *dev;
-
- if (!hws_gws_support)
- return -ENODEV;
-
- dev = kfd_device_by_id(args->gpu_id);
- if (!dev) {
- pr_debug("Could not find gpu id 0x%x\n", args->gpu_id);
- return -ENODEV;
- }
- if (dev->dqm->sched_policy == KFD_SCHED_POLICY_NO_HWS)
- return -ENODEV;
-
- mutex_lock(>mutex);
- retval = pqm_set_gws(>pqm, args->queue_id, args->num_gws ? dev->gws
: NULL);
- mutex_unlock(>mutex);
-
- args->first_gws = 0;
- return retval;
-}
-
static int kfd_ioctl_get_dmabuf_info(struct file *filep,
struct kfd_process *p, void *data)
{
@@ -1795,8 +1769,6 @@ static const struct amdkfd_ioctl_desc amdkfd_ioctls[] = {
AMDKFD_IOCTL_DEF(AMDKFD_IOC_IMPORT_DMABUF,
kfd_ioctl_import_dmabuf, 0),
- AMDKFD_IOCTL_DEF(AMDKFD_IOC_ALLOC_QUEUE_GWS,
- kfd_ioctl_alloc_queue_gws, 0),
};
#define AMDKFD_CORE_IOCTL_COUNTARRAY_SIZE(amdkfd_ioctls)
diff --git a/include/uapi/linux/kfd_ioctl.h b/include/uapi/linux/kfd_ioctl.h
index 070d1bc7e725..20917c59f39c 100644
--- a/include/uapi/linux/kfd_ioctl.h
+++ b/include/uapi/linux/kfd_ioctl.h
@@ -410,21 +410,6 @@ struct kfd_ioctl_unmap_memory_from_gpu_args {
__u32 n_success;/* to/from KFD */
};
-/* Allocate GWS for specific queue
- *
- * @gpu_id: device identifier
- * @queue_id:queue's id that GWS is allocated for
- * @num_gws: how many GWS to allocate
- * @first_gws: index of the first GWS allocated.
- * only support contiguous GWS allocation
- */
-struct kfd_ioctl_alloc_queue_gws_args {
- __u32 gpu_id; /* to KFD */
- __u32 queue_id; /* to KFD */
- __u32 num_gws; /* to KFD */
- __u32 first_gws;/* from KFD */
-};
-
struct kfd_ioctl_get_dmabuf_info_args {
__u64 size; /* from KFD */
__u64 metadata_ptr; /* to KFD */
@@ -544,10 +529,7 @@ enum kfd_mmio_remap {
#define AMDKFD_IOC_IMPORT_DMABUF \
AMDKFD_IOWR(0x1D, struct kfd_ioctl_import_dmabuf_args)
-#define AMDKFD_IOC_ALLOC_QUEUE_GWS \
- AMDKFD_IOWR(0x1E, struct kfd_ioctl_alloc_queue_gws_args)
-
#define AMDKFD_COMMAND_START 0x01
-#define AMDKFD_COMMAND_END 0x1F
+#define AMDKFD_COMMAND_END 0x1E
#endif
--
2.20.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amd/display: Remove drm_dsc_dc.c
This file was accidentally added to the driver during
Navi promotion
Nothing includes it. No makefile attempts to compile it, and
it would fail compilation if they tried
Remove it
Signed-off-by: David Francis
---
.../gpu/drm/amd/display/dc/dsc/drm_dsc_dc.c | 453 --
1 file changed, 453 deletions(-)
delete mode 100644 drivers/gpu/drm/amd/display/dc/dsc/drm_dsc_dc.c
diff --git a/drivers/gpu/drm/amd/display/dc/dsc/drm_dsc_dc.c
b/drivers/gpu/drm/amd/display/dc/dsc/drm_dsc_dc.c
deleted file mode 100644
index fd1fb1653479..
--- a/drivers/gpu/drm/amd/display/dc/dsc/drm_dsc_dc.c
+++ /dev/null
@@ -1,453 +0,0 @@
-// SPDX-License-Identifier: MIT
-/*
- * Copyright © 2018 Intel Corp
- *
- * Author:
- * Manasi Navare
- */
-
-/* DC versions of linux includes */
-#include
-
-#define EXPORT_SYMBOL(symbol) /* nothing */
-#define BUILD_BUG_ON(cond) /* nothing */
-#define DIV_ROUND_UP(a, b) (((b) + (a) - 1) / (b))
-#define ERANGE -1
-#define DRM_DEBUG_KMS(msg) /* nothing */
-#define cpu_to_be16(__x) little_to_big(__x)
-#define MAX(x, y) ((x) > (y) ? (x) : (y))
-
-static unsigned short little_to_big(int data)
-{
- /* Swap lower and upper byte. DMCU uses big endian format. */
- return (0xff & (data >> 8)) + ((data & 0xff) << 8);
-}
-
-/*
- * Everything below this comment was copied directly from drm_dsc.c.
- * Only the functions needed in DC are included.
- * Please keep this file synced with upstream.
- */
-
-/**
- * DOC: dsc helpers
- *
- * These functions contain some common logic and helpers to deal with VESA
- * Display Stream Compression standard required for DSC on Display Port/eDP or
- * MIPI display interfaces.
- */
-
-/**
- * drm_dsc_pps_payload_pack() - Populates the DSC PPS
- *
- * @pps_payload:
- * Bitwise struct for DSC Picture Parameter Set. This is defined
- * by drm_dsc_picture_parameter_set
- * @dsc_cfg:
- * DSC Configuration data filled by driver as defined by
- * drm_dsc_config
- *
- * DSC source device sends a picture parameter set (PPS) containing the
- * information required by the sink to decode the compressed frame. Driver
- * populates the DSC PPS struct using the DSC configuration parameters in
- * the order expected by the DSC Display Sink device. For the DSC, the sink
- * device expects the PPS payload in big endian format for fields
- * that span more than 1 byte.
- */
-void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set
*pps_payload,
- const struct drm_dsc_config *dsc_cfg)
-{
- int i;
-
- /* Protect against someone accidently changing struct size */
- BUILD_BUG_ON(sizeof(*pps_payload) !=
-DP_SDP_PPS_HEADER_PAYLOAD_BYTES_MINUS_1 + 1);
-
- memset(pps_payload, 0, sizeof(*pps_payload));
-
- /* PPS 0 */
- pps_payload->dsc_version =
- dsc_cfg->dsc_version_minor |
- dsc_cfg->dsc_version_major << DSC_PPS_VERSION_MAJOR_SHIFT;
-
- /* PPS 1, 2 is 0 */
-
- /* PPS 3 */
- pps_payload->pps_3 =
- dsc_cfg->line_buf_depth |
- dsc_cfg->bits_per_component << DSC_PPS_BPC_SHIFT;
-
- /* PPS 4 */
- pps_payload->pps_4 =
- ((dsc_cfg->bits_per_pixel & DSC_PPS_BPP_HIGH_MASK) >>
-DSC_PPS_MSB_SHIFT) |
- dsc_cfg->vbr_enable << DSC_PPS_VBR_EN_SHIFT |
- dsc_cfg->simple_422 << DSC_PPS_SIMPLE422_SHIFT |
- dsc_cfg->convert_rgb << DSC_PPS_CONVERT_RGB_SHIFT |
- dsc_cfg->block_pred_enable << DSC_PPS_BLOCK_PRED_EN_SHIFT;
-
- /* PPS 5 */
- pps_payload->bits_per_pixel_low =
- (dsc_cfg->bits_per_pixel & DSC_PPS_LSB_MASK);
-
- /*
-* The DSC panel expects the PPS packet to have big endian format
-* for data spanning 2 bytes. Use a macro cpu_to_be16() to convert
-* to big endian format. If format is little endian, it will swap
-* bytes to convert to Big endian else keep it unchanged.
-*/
-
- /* PPS 6, 7 */
- pps_payload->pic_height = cpu_to_be16(dsc_cfg->pic_height);
-
- /* PPS 8, 9 */
- pps_payload->pic_width = cpu_to_be16(dsc_cfg->pic_width);
-
- /* PPS 10, 11 */
- pps_payload->slice_height = cpu_to_be16(dsc_cfg->slice_height);
-
- /* PPS 12, 13 */
- pps_payload->slice_width = cpu_to_be16(dsc_cfg->slice_width);
-
- /* PPS 14, 15 */
- pps_payload->chunk_size = cpu_to_be16(dsc_cfg->slice_chunk_size);
-
- /* PPS 16 */
- pps_payload->initial_xmit_delay_high =
- ((dsc_cfg->initial_xmit_delay &
- DSC_PPS_INIT_XMIT_DELAY_HIGH_MASK) >>
-DSC_PPS_MSB_SHIFT);
-
- /* PPS 17 */
- pps_payload->initial_xmit_delay_low =
- (dsc_cfg->initial_xmit_delay & DSC_PPS_LSB_MASK);
-
- /* PPS 18, 19 */
- pps_payload->initial_dec_delay =
-
Re: [PATCH] drm/amdgpu: replace readq/writeq with atomic64 operations
On Wed, Aug 07, 2019 at 10:55:01AM +, Koenig, Christian wrote: > >> Essentially writeq/readq doesn't seems to be available on all > >> architectures either. > > writeq/readq are provided whenever the CPU actually supports 64-bit > > atomic loads and stores. > > Is there a config option which we can make the driver depend on? > > I mean that ARM doesn't support 64bit atomic loads and stores on MMIO is > quite a boomer for us. The model is to cheack if readq/writeq are defined, and if not to include the one of io-64-nonatomic-hi-lo.h or io-64-nonatomic-lo-hi.h. The reason for that is that hardware is supposed to be able to deal with two 32-bit writes, but it depends on the hardware if the lower or upper half is what commits the write. The only 32-bit platform that claims support for readq/writeq is sh, and I have doubts if that actually works as expected. ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH v3 10/41] media/ivtv: convert put_page() to put_user_page*()
On 8/7/19 3:33 AM, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page() or
> release_pages().
>
> This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
> ("mm: introduce put_user_page*(), placeholder versions").
>
> Cc: Andy Walls
> Cc: Mauro Carvalho Chehab
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: John Hubbard
Acked-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/media/pci/ivtv/ivtv-udma.c | 14 --
> drivers/media/pci/ivtv/ivtv-yuv.c | 11 +++
> 2 files changed, 7 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/media/pci/ivtv/ivtv-udma.c
> b/drivers/media/pci/ivtv/ivtv-udma.c
> index 5f8883031c9c..7c7f33c2412b 100644
> --- a/drivers/media/pci/ivtv/ivtv-udma.c
> +++ b/drivers/media/pci/ivtv/ivtv-udma.c
> @@ -92,7 +92,7 @@ int ivtv_udma_setup(struct ivtv *itv, unsigned long
> ivtv_dest_addr,
> {
> struct ivtv_dma_page_info user_dma;
> struct ivtv_user_dma *dma = >udma;
> - int i, err;
> + int err;
>
> IVTV_DEBUG_DMA("ivtv_udma_setup, dst: 0x%08x\n", (unsigned
> int)ivtv_dest_addr);
>
> @@ -119,8 +119,7 @@ int ivtv_udma_setup(struct ivtv *itv, unsigned long
> ivtv_dest_addr,
> IVTV_DEBUG_WARN("failed to map user pages, returned %d instead
> of %d\n",
> err, user_dma.page_count);
> if (err >= 0) {
> - for (i = 0; i < err; i++)
> - put_page(dma->map[i]);
> + put_user_pages(dma->map, err);
> return -EINVAL;
> }
> return err;
> @@ -130,9 +129,7 @@ int ivtv_udma_setup(struct ivtv *itv, unsigned long
> ivtv_dest_addr,
>
> /* Fill SG List with new values */
> if (ivtv_udma_fill_sg_list(dma, _dma, 0) < 0) {
> - for (i = 0; i < dma->page_count; i++) {
> - put_page(dma->map[i]);
> - }
> + put_user_pages(dma->map, dma->page_count);
> dma->page_count = 0;
> return -ENOMEM;
> }
> @@ -153,7 +150,6 @@ int ivtv_udma_setup(struct ivtv *itv, unsigned long
> ivtv_dest_addr,
> void ivtv_udma_unmap(struct ivtv *itv)
> {
> struct ivtv_user_dma *dma = >udma;
> - int i;
>
> IVTV_DEBUG_INFO("ivtv_unmap_user_dma\n");
>
> @@ -170,9 +166,7 @@ void ivtv_udma_unmap(struct ivtv *itv)
> ivtv_udma_sync_for_cpu(itv);
>
> /* Release User Pages */
> - for (i = 0; i < dma->page_count; i++) {
> - put_page(dma->map[i]);
> - }
> + put_user_pages(dma->map, dma->page_count);
> dma->page_count = 0;
> }
>
> diff --git a/drivers/media/pci/ivtv/ivtv-yuv.c
> b/drivers/media/pci/ivtv/ivtv-yuv.c
> index cd2fe2d444c0..2c61a11d391d 100644
> --- a/drivers/media/pci/ivtv/ivtv-yuv.c
> +++ b/drivers/media/pci/ivtv/ivtv-yuv.c
> @@ -30,7 +30,6 @@ static int ivtv_yuv_prep_user_dma(struct ivtv *itv, struct
> ivtv_user_dma *dma,
> struct yuv_playback_info *yi = >yuv_info;
> u8 frame = yi->draw_frame;
> struct yuv_frame_info *f = >new_frame_info[frame];
> - int i;
> int y_pages, uv_pages;
> unsigned long y_buffer_offset, uv_buffer_offset;
> int y_decode_height, uv_decode_height, y_size;
> @@ -81,8 +80,7 @@ static int ivtv_yuv_prep_user_dma(struct ivtv *itv, struct
> ivtv_user_dma *dma,
>uv_pages, uv_dma.page_count);
>
> if (uv_pages >= 0) {
> - for (i = 0; i < uv_pages; i++)
> - put_page(dma->map[y_pages + i]);
> + put_user_pages(>map[y_pages], uv_pages);
> rc = -EFAULT;
> } else {
> rc = uv_pages;
> @@ -93,8 +91,7 @@ static int ivtv_yuv_prep_user_dma(struct ivtv *itv, struct
> ivtv_user_dma *dma,
>y_pages, y_dma.page_count);
> }
> if (y_pages >= 0) {
> - for (i = 0; i < y_pages; i++)
> - put_page(dma->map[i]);
> + put_user_pages(dma->map, y_pages);
> /*
>* Inherit the -EFAULT from rc's
>* initialization, but allow it to be
> @@ -112,9 +109,7 @@ static int ivtv_yuv_prep_user_dma(struct ivtv *itv,
> struct ivtv_user_dma *dma,
> /* Fill & map SG List */
> if (ivtv_udma_fill_sg_list (dma, _dma, ivtv_udma_fill_sg_list (dma,
> _dma, 0)) < 0) {
> IVTV_DEBUG_WARN("could not allocate bounce buffers for highmem
> userspace buffers\n");
> - for (i = 0; i < dma->page_count; i++) {
> - put_page(dma->map[i]);
> - }
> + put_user_pages(dma->map,
Re: [PATCH 00/34] put_user_pages(): miscellaneous call sites
On Fri 02-08-19 12:14:09, John Hubbard wrote:
> On 8/2/19 7:52 AM, Jan Kara wrote:
> > On Fri 02-08-19 07:24:43, Matthew Wilcox wrote:
> > > On Fri, Aug 02, 2019 at 02:41:46PM +0200, Jan Kara wrote:
> > > > On Fri 02-08-19 11:12:44, Michal Hocko wrote:
> > > > > On Thu 01-08-19 19:19:31, john.hubb...@gmail.com wrote:
> > > > > [...]
> > > > > > 2) Convert all of the call sites for get_user_pages*(), to
> > > > > > invoke put_user_page*(), instead of put_page(). This involves
> > > > > > dozens of
> > > > > > call sites, and will take some time.
> > > > >
> > > > > How do we make sure this is the case and it will remain the case in
> > > > > the
> > > > > future? There must be some automagic to enforce/check that. It is
> > > > > simply
> > > > > not manageable to do it every now and then because then 3) will simply
> > > > > be never safe.
> > > > >
> > > > > Have you considered coccinele or some other scripted way to do the
> > > > > transition? I have no idea how to deal with future changes that would
> > > > > break the balance though.
>
> Hi Michal,
>
> Yes, I've thought about it, and coccinelle falls a bit short (it's not smart
> enough to know which put_page()'s to convert). However, there is a debug
> option planned: a yet-to-be-posted commit [1] uses struct page extensions
> (obviously protected by CONFIG_DEBUG_GET_USER_PAGES_REFERENCES) to add
> a redundant counter. That allows:
>
> void __put_page(struct page *page)
> {
> ...
> /* Someone called put_page() instead of put_user_page() */
> WARN_ON_ONCE(atomic_read(_ext->pin_count) > 0);
>
> > > >
> > > > Yeah, that's why I've been suggesting at LSF/MM that we may need to
> > > > create
> > > > a gup wrapper - say vaddr_pin_pages() - and track which sites dropping
> > > > references got converted by using this wrapper instead of gup. The
> > > > counterpart would then be more logically named as unpin_page() or
> > > > whatever
> > > > instead of put_user_page(). Sure this is not completely foolproof (you
> > > > can
> > > > create new callsite using vaddr_pin_pages() and then just drop refs
> > > > using
> > > > put_page()) but I suppose it would be a high enough barrier for missed
> > > > conversions... Thoughts?
>
> The debug option above is still a bit simplistic in its implementation
> (and maybe not taking full advantage of the data it has), but I think
> it's preferable, because it monitors the "core" and WARNs.
>
> Instead of the wrapper, I'm thinking: documentation and the passage of
> time, plus the debug option (perhaps enhanced--probably once I post it
> someone will notice opportunities), yes?
So I think your debug option and my suggested renaming serve a bit
different purposes (and thus both make sense). If you do the renaming, you
can just grep to see unconverted sites. Also when someone merges new GUP
user (unaware of the new rules) while you switch GUP to use pins instead of
ordinary references, you'll get compilation error in case of renaming
instead of hard to debug refcount leak without the renaming. And such
conflict is almost bound to happen given the size of GUP patch set... Also
the renaming serves against the "coding inertia" - i.e., GUP is around for
ages so people just use it without checking any documentation or comments.
After switching how GUP works, what used to be correct isn't anymore so
renaming the function serves as a warning that something has really
changed.
Your refcount debug patches are good to catch bugs in the conversions done
but that requires you to be able to excercise the code path in the first
place which may require particular HW or so, and you also have to enable
the debug option which means you already aim at verifying the GUP
references are treated properly.
Honza
--
Jan Kara
SUSE Labs, CR
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: replace readq/writeq with atomic64 operations
On Wed, Aug 07, 2019 at 08:53:25AM +, Koenig, Christian wrote: > Am 07.08.19 um 09:08 schrieb Christoph Hellwig: > > On Wed, Aug 07, 2019 at 10:56:40AM +0800, Tao Zhou wrote: > >> readq/writeq are not supported on all architectures > > NAK. You must not use atomic_* on __iomem (MMIO) memory. > > Well then what's the right thing to do here? > > Essentially writeq/readq doesn't seems to be available on all > architectures either. writeq/readq are provided whenever the CPU actually supports 64-bit atomic loads and stores. If it doesn't provide them atomic64* is not going to be atomic vs the I/O device either. And that is on top of the fact that for various architectures you can't simply use plain loads and stores on MMIO memory to start with, which is why we have the special accessors and the __iomem annotation. ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 15/15] amdgpu: remove CONFIG_DRM_AMDGPU_USERPTR
On Wed, Aug 07, 2019 at 06:57:24AM +, Koenig, Christian wrote: > Am 06.08.19 um 22:03 schrieb Jason Gunthorpe: > > On Tue, Aug 06, 2019 at 02:58:58PM -0400, Alex Deucher wrote: > >> On Tue, Aug 6, 2019 at 1:51 PM Kuehling, Felix > >> wrote: > >>> On 2019-08-06 13:44, Jason Gunthorpe wrote: > On Tue, Aug 06, 2019 at 07:05:53PM +0300, Christoph Hellwig wrote: > > The option is just used to select HMM mirror support and has a very > > confusing help text. Just pull in the HMM mirror code by default > > instead. > > > > Signed-off-by: Christoph Hellwig > >drivers/gpu/drm/Kconfig | 2 ++ > >drivers/gpu/drm/amd/amdgpu/Kconfig | 10 -- > >drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 -- > >drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 12 > >4 files changed, 2 insertions(+), 28 deletions(-) > Felix, was this an effort to avoid the arch restriction on hmm or > something? Also can't see why this was like this. > >>> This option predates KFD's support of userptrs, which in turn predates > >>> HMM. Radeon has the same kind of option, though it doesn't affect HMM in > >>> that case. > >>> > >>> Alex, Christian, can you think of a good reason to maintain userptr > >>> support as an option in amdgpu? I suspect it was originally meant as a > >>> way to allow kernels with amdgpu without MMU notifiers. Now it would > >>> allow a kernel with amdgpu without HMM or MMU notifiers. I don't know if > >>> this is a useful thing to have. > >> Right. There were people that didn't have MMU notifiers that wanted > >> support for the GPU. > > ?? Is that even a real thing? mmu_notifier does not have much kconfig > > dependency. > > Yes, that used to be a very real thing. > > Initially a lot of users didn't wanted mmu notifiers to be enabled > because of the performance overhead they costs. Seems strange to hear these days, every distro ships with it on, it is needed for kvm. > Then we had the problem that HMM mirror wasn't available on a lot of > architectures. Some patches for hmm are ready now that will fix this Jason ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH v3 11/41] media/v4l2-core/mm: convert put_page() to put_user_page*()
On 8/7/19 3:33 AM, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page() or
> release_pages().
>
> This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
> ("mm: introduce put_user_page*(), placeholder versions").
>
> Cc: Mauro Carvalho Chehab
> Cc: Kees Cook
> Cc: Hans Verkuil
> Cc: Sakari Ailus
> Cc: Jan Kara
> Cc: Robin Murphy
> Cc: Souptick Joarder
> Cc: Dan Williams
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: John Hubbard
Acked-by: Hans Verkuil
> ---
> drivers/media/v4l2-core/videobuf-dma-sg.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/videobuf-dma-sg.c
> b/drivers/media/v4l2-core/videobuf-dma-sg.c
> index 66a6c6c236a7..d6eeb437ec19 100644
> --- a/drivers/media/v4l2-core/videobuf-dma-sg.c
> +++ b/drivers/media/v4l2-core/videobuf-dma-sg.c
> @@ -349,8 +349,7 @@ int videobuf_dma_free(struct videobuf_dmabuf *dma)
> BUG_ON(dma->sglen);
>
> if (dma->pages) {
> - for (i = 0; i < dma->nr_pages; i++)
> - put_page(dma->pages[i]);
> + put_user_pages(dma->pages, dma->nr_pages);
> kfree(dma->pages);
> dma->pages = NULL;
> }
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: replace readq/writeq with atomic64 operations
On Wed, Aug 07, 2019 at 01:00:48PM +, Koenig, Christian wrote: > Am 07.08.19 um 14:59 schrieb Mark Brown: > > On Wed, Aug 07, 2019 at 10:55:01AM +, Koenig, Christian wrote: > >> Am 07.08.19 um 12:41 schrieb Christoph Hellwig: > >>> writeq/readq are provided whenever the CPU actually supports 64-bit > >>> atomic loads and stores. > >> Is there a config option which we can make the driver depend on? > > 64BIT should do the trick. > > That doesn't work because 32bit x86 does support writeq/readq as far as > I know. I also had a vague memory that x86-32 did support it with SSE, but I can't actually find any traces of that support. ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH v3 hmm 10/11] drm/amdkfd: use mmu_notifier_put
On Tue, Aug 06, 2019 at 11:47:44PM +, Kuehling, Felix wrote: > On 2019-08-06 19:15, Jason Gunthorpe wrote: > > From: Jason Gunthorpe > > > > The sequence of mmu_notifier_unregister_no_release(), > > mmu_notifier_call_srcu() is identical to mmu_notifier_put() with the > > free_notifier callback. > > > > As this is the last user of those APIs, converting it means we can drop > > them. > > > > Signed-off-by: Jason Gunthorpe > > Reviewed-by: Felix Kuehling > > > drivers/gpu/drm/amd/amdkfd/kfd_priv.h| 3 --- > > drivers/gpu/drm/amd/amdkfd/kfd_process.c | 10 -- > > 2 files changed, 4 insertions(+), 9 deletions(-) > > > > I'm really not sure what this is doing, but it is very strange to have a > > release with no other callback. It would be good if this would change to use > > get as well. > KFD uses the MMU notifier to detect process termination and free all the > resources associated with the process. This was first added for APUs > where the IOMMUv2 is set up to perform address translations using the > CPU page table for device memory access. That's where the association of > KFD process resources with the lifetime of the mm_struct comes from. When all the HW objects that could do DMA to this process are destroyed then the mmu notififer should be torn down. The module should remain locked until the DMA objects are destroyed. I'm still unclear why this is needed, the IOMMU for PASID already has notififers, and already blocks access when the mm_struct goes away, why add a second layer of tracking? Jason ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: replace readq/writeq with atomic64 operations
On Wed, Aug 07, 2019 at 10:55:01AM +, Koenig, Christian wrote: > Am 07.08.19 um 12:41 schrieb Christoph Hellwig: > > writeq/readq are provided whenever the CPU actually supports 64-bit > > atomic loads and stores. > Is there a config option which we can make the driver depend on? 64BIT should do the trick. signature.asc Description: PGP signature ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: replace readq/writeq with atomic64 operations
Am 07.08.19 um 15:00 schrieb Christoph Hellwig: > On Wed, Aug 07, 2019 at 10:55:01AM +, Koenig, Christian wrote: Essentially writeq/readq doesn't seems to be available on all architectures either. >>> writeq/readq are provided whenever the CPU actually supports 64-bit >>> atomic loads and stores. >> Is there a config option which we can make the driver depend on? >> >> I mean that ARM doesn't support 64bit atomic loads and stores on MMIO is >> quite a boomer for us. > The model is to cheack if readq/writeq are defined, and if not to > include the one of io-64-nonatomic-hi-lo.h or io-64-nonatomic-lo-hi.h. > The reason for that is that hardware is supposed to be able to deal with > two 32-bit writes, but it depends on the hardware if the lower or upper > half is what commits the write. Read, but as I understood Tao change this is not the case here. Otherwise we would just use our WREG32/RREG32 macros in the driver. Tao, please explain why exactly we need the WREG64/RREG64 change which caused this. Christian. > > The only 32-bit platform that claims support for readq/writeq is sh, > and I have doubts if that actually works as expected. ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[Regression] "drm/amdgpu: enable gfxoff again on raven series (v2)"
Hi,
After commit 005440066f92 ("drm/amdgpu: enable gfxoff again on raven series
(v2)”), browsers on Raven Ridge systems cause serious corruption like this:
https://launchpadlibrarian.net/436319772/Screenshot%20from%202019-08-07%2004-20-34.png
Firmwares for Raven Ridge is up-to-date.
Kai-Heng
Re: [PATCH] drm/amdgpu: replace readq/writeq with atomic64 operations
Am 07.08.19 um 12:41 schrieb Christoph Hellwig: > On Wed, Aug 07, 2019 at 08:53:25AM +, Koenig, Christian wrote: >> Am 07.08.19 um 09:08 schrieb Christoph Hellwig: >>> On Wed, Aug 07, 2019 at 10:56:40AM +0800, Tao Zhou wrote: readq/writeq are not supported on all architectures >>> NAK. You must not use atomic_* on __iomem (MMIO) memory. >> Well then what's the right thing to do here? >> >> Essentially writeq/readq doesn't seems to be available on all >> architectures either. > writeq/readq are provided whenever the CPU actually supports 64-bit > atomic loads and stores. Is there a config option which we can make the driver depend on? I mean that ARM doesn't support 64bit atomic loads and stores on MMIO is quite a boomer for us. Toa do you of hand know what we actually need the 64bit atomic stores for? E.g. what is the hardware background? Regards, Christian. > If it doesn't provide them atomic64* is > not going to be atomic vs the I/O device either. And that is on top > of the fact that for various architectures you can't simply use > plain loads and stores on MMIO memory to start with, which is why > we have the special accessors and the __iomem annotation. ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: fix gfx9 soft recovery
Am 07.08.19 um 09:40 schrieb Pelloux-prayer, Pierre-eric: The SOC15_REG_OFFSET() macro wasn't used, making the soft recovery fail. v2: use WREG32_SOC15 instead of WREG32 + SOC15_REG_OFFSET Signed-off-by: Pierre-Eric Pelloux-Prayer Reviewed-by: Alex Deucher Reviewed-by: Christian König --- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c index bcd0301eee1e..1a2963e4bc68 100644 --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c @@ -5375,7 +5375,7 @@ static void gfx_v9_0_ring_soft_recovery(struct amdgpu_ring *ring, unsigned vmid) value = REG_SET_FIELD(value, SQ_CMD, MODE, 0x01); value = REG_SET_FIELD(value, SQ_CMD, CHECK_VMID, 1); value = REG_SET_FIELD(value, SQ_CMD, VM_ID, vmid); - WREG32(mmSQ_CMD, value); + WREG32_SOC15(GC, 0, mmSQ_CMD, value); } static void gfx_v9_0_set_gfx_eop_interrupt_state(struct amdgpu_device *adev, ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: replace readq/writeq with atomic64 operations
Am 07.08.19 um 09:08 schrieb Christoph Hellwig: > On Wed, Aug 07, 2019 at 10:56:40AM +0800, Tao Zhou wrote: >> readq/writeq are not supported on all architectures > NAK. You must not use atomic_* on __iomem (MMIO) memory. Well then what's the right thing to do here? Essentially writeq/readq doesn't seems to be available on all architectures either. Regards, Christian. ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 1/2] drm/amdgpu: Export function to flush TLB of specific vm hub
Does the coded below invalidate TLB on both mm and gfx hub?
No, just the gfx hub. The VMHUBs on Navi are unfortunately really buggy,
so we had to do a lot of workarounds to get them into a state where they
actually did what was expected from them.
One major issue for example is that you can't do MMIO based VM
invalidation when the engine is busy. To work around this we do the
invalidation with the (IIRC) SDMA engine as soon as that one is working.
The is the code you are noting below.
Regards,
Christian.
Am 07.08.19 um 04:40 schrieb Zeng, Oak:
Ok, will do it.
BTW, does those codes below really needed, in function gmc_v10_0_flush_gpu_tlb.
I think if we have the bug, then before below codes, when we flush TLB of
gfxhub through mmio, it has already triggered the bug. Also as we already
invalidated tlb on both mm and gfx hub (in the same function
gmc_v10_0_flush_gpu_tlb), what is the point of below codes? Does the coded
below invalidate TLB on both mm and gfx hub? Also @Zhang, Hawking@Deucher,
Alexander
/* The SDMA on Navi has a bug which can theoretically result in memory
* corruption if an invalidation happens at the same time as an VA
* translation. Avoid this by doing the invalidation from the SDMA
* itself.
*/
r = amdgpu_job_alloc_with_ib(adev, 16 * 4, );
if (r)
goto error_alloc;
job->vm_pd_addr = amdgpu_gmc_pd_addr(adev->gart.bo);
job->vm_needs_flush = true;
amdgpu_ring_pad_ib(ring, >ibs[0]);
r = amdgpu_job_submit(job, >mman.entity,
AMDGPU_FENCE_OWNER_UNDEFINED, );
Regards,
Oak
-Original Message-
From: Christian König
Sent: Monday, August 5, 2019 5:37 AM
To: Zeng, Oak ; amd-gfx@lists.freedesktop.org
Cc: Kuehling, Felix ; Zhou1, Tao ; Liu,
Shaoyun
Subject: Re: [PATCH 1/2] drm/amdgpu: Export function to flush TLB of specific
vm hub
Am 02.08.19 um 18:04 schrieb Zeng, Oak:
This is for kfd to reuse amdgpu TLB invalidation function. There is
already a gmc function flush_gpu_tlb to flush TLB on all vm hub. On
gfx10, kfd only needs to flush TLB on gfx hub but not on mm hub. So
export a function for KFD flush TLB only on gfx hub.
I would rather go ahead and add another parameter to flush_gpu_tlb to note
which hub needs flushing.
We can probably easily extend the few callers to flush all hubs needed.
Christian.
Change-Id: I58ff00969f88438cfd3dc7e9deb7bff0c1bb4133
Signed-off-by: Oak Zeng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h | 4
drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 1 +
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h
index 071145a..0bd4a4f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h
@@ -88,6 +88,9 @@ struct amdgpu_vmhub {
* GPU MC structures, functions & helpers
*/
struct amdgpu_gmc_funcs {
+ /* flush vm tlb of specific hub */
+ void (*flush_vm_hub)(struct amdgpu_device *adev, uint32_t vmid,
+ unsigned int vmhub, uint32_t flush_type);
/* flush the vm tlb via mmio */
void (*flush_gpu_tlb)(struct amdgpu_device *adev,
uint32_t vmid, uint32_t flush_type); @@ -180,6
+183,7 @@
struct amdgpu_gmc {
struct ras_common_if*ras_if;
};
+#define amdgpu_gmc_flush_vm_hub(adev, vmid, vmhub, type)
+((adev)->gmc.gmc_funcs->flush_vm_hub((adev), (vmid), (vmhub),
+(type)))
#define amdgpu_gmc_flush_gpu_tlb(adev, vmid, type)
(adev)->gmc.gmc_funcs->flush_gpu_tlb((adev), (vmid), (type))
#define amdgpu_gmc_emit_flush_gpu_tlb(r, vmid, addr)
(r)->adev->gmc.gmc_funcs->emit_flush_gpu_tlb((r), (vmid), (addr))
#define amdgpu_gmc_emit_pasid_mapping(r, vmid, pasid)
(r)->adev->gmc.gmc_funcs->emit_pasid_mapping((r), (vmid), (pasid))
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
index 4e3ac10..247515d 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
@@ -416,6 +416,7 @@ static void gmc_v10_0_get_vm_pde(struct amdgpu_device
*adev, int level,
}
static const struct amdgpu_gmc_funcs gmc_v10_0_gmc_funcs = {
+ .flush_vm_hub = gmc_v10_0_flush_vm_hub,
.flush_gpu_tlb = gmc_v10_0_flush_gpu_tlb,
.emit_flush_gpu_tlb = gmc_v10_0_emit_flush_gpu_tlb,
.emit_pasid_mapping = gmc_v10_0_emit_pasid_mapping,
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 00/34] put_user_pages(): miscellaneous call sites
On Wed 07-08-19 10:37:26, Jan Kara wrote:
> On Fri 02-08-19 12:14:09, John Hubbard wrote:
> > On 8/2/19 7:52 AM, Jan Kara wrote:
> > > On Fri 02-08-19 07:24:43, Matthew Wilcox wrote:
> > > > On Fri, Aug 02, 2019 at 02:41:46PM +0200, Jan Kara wrote:
> > > > > On Fri 02-08-19 11:12:44, Michal Hocko wrote:
> > > > > > On Thu 01-08-19 19:19:31, john.hubb...@gmail.com wrote:
> > > > > > [...]
> > > > > > > 2) Convert all of the call sites for get_user_pages*(), to
> > > > > > > invoke put_user_page*(), instead of put_page(). This involves
> > > > > > > dozens of
> > > > > > > call sites, and will take some time.
> > > > > >
> > > > > > How do we make sure this is the case and it will remain the case in
> > > > > > the
> > > > > > future? There must be some automagic to enforce/check that. It is
> > > > > > simply
> > > > > > not manageable to do it every now and then because then 3) will
> > > > > > simply
> > > > > > be never safe.
> > > > > >
> > > > > > Have you considered coccinele or some other scripted way to do the
> > > > > > transition? I have no idea how to deal with future changes that
> > > > > > would
> > > > > > break the balance though.
> >
> > Hi Michal,
> >
> > Yes, I've thought about it, and coccinelle falls a bit short (it's not smart
> > enough to know which put_page()'s to convert). However, there is a debug
> > option planned: a yet-to-be-posted commit [1] uses struct page extensions
> > (obviously protected by CONFIG_DEBUG_GET_USER_PAGES_REFERENCES) to add
> > a redundant counter. That allows:
> >
> > void __put_page(struct page *page)
> > {
> > ...
> > /* Someone called put_page() instead of put_user_page() */
> > WARN_ON_ONCE(atomic_read(_ext->pin_count) > 0);
> >
> > > > >
> > > > > Yeah, that's why I've been suggesting at LSF/MM that we may need to
> > > > > create
> > > > > a gup wrapper - say vaddr_pin_pages() - and track which sites dropping
> > > > > references got converted by using this wrapper instead of gup. The
> > > > > counterpart would then be more logically named as unpin_page() or
> > > > > whatever
> > > > > instead of put_user_page(). Sure this is not completely foolproof
> > > > > (you can
> > > > > create new callsite using vaddr_pin_pages() and then just drop refs
> > > > > using
> > > > > put_page()) but I suppose it would be a high enough barrier for missed
> > > > > conversions... Thoughts?
> >
> > The debug option above is still a bit simplistic in its implementation
> > (and maybe not taking full advantage of the data it has), but I think
> > it's preferable, because it monitors the "core" and WARNs.
> >
> > Instead of the wrapper, I'm thinking: documentation and the passage of
> > time, plus the debug option (perhaps enhanced--probably once I post it
> > someone will notice opportunities), yes?
>
> So I think your debug option and my suggested renaming serve a bit
> different purposes (and thus both make sense). If you do the renaming, you
> can just grep to see unconverted sites. Also when someone merges new GUP
> user (unaware of the new rules) while you switch GUP to use pins instead of
> ordinary references, you'll get compilation error in case of renaming
> instead of hard to debug refcount leak without the renaming. And such
> conflict is almost bound to happen given the size of GUP patch set... Also
> the renaming serves against the "coding inertia" - i.e., GUP is around for
> ages so people just use it without checking any documentation or comments.
> After switching how GUP works, what used to be correct isn't anymore so
> renaming the function serves as a warning that something has really
> changed.
Fully agreed!
> Your refcount debug patches are good to catch bugs in the conversions done
> but that requires you to be able to excercise the code path in the first
> place which may require particular HW or so, and you also have to enable
> the debug option which means you already aim at verifying the GUP
> references are treated properly.
>
> Honza
>
> --
> Jan Kara
> SUSE Labs, CR
--
Michal Hocko
SUSE Labs
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 1/5] drm/amdgpu: Extends amdgpu vm definitions
Am 07.08.19 um 04:31 schrieb Zeng, Oak:
Add definition of all supported mtypes. The RW mtype
is recently introduced for arcturus. Also add definition
for the cachable/snoopable bit, which will be used later
in this series.
Change-Id: I96fc9bb4b6b1e62bdc10b600d8aaa6a802128d6d
Signed-off-by: Oak Zeng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 9 +++--
include/uapi/drm/amdgpu_drm.h | 4
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
index 2eda3a8..7a77477 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
@@ -80,8 +80,13 @@ struct amdgpu_bo_list_entry;
#define AMDGPU_PTE_MTYPE_VG10(a) ((uint64_t)(a) << 57)
#define AMDGPU_PTE_MTYPE_VG10_MASKAMDGPU_PTE_MTYPE_VG10(3ULL)
-#define AMDGPU_MTYPE_NC 0
-#define AMDGPU_MTYPE_CC 2
+enum amdgpu_mtype {
+ AMDGPU_MTYPE_NC = 0,
+ AMDGPU_MTYPE_WC = 1,
+ AMDGPU_MTYPE_CC = 2,
+ AMDGPU_MTYPE_UC = 3,
+ AMDGPU_MTYPE_RW = 4,
+};
#define AMDGPU_PTE_DEFAULT_ATC (AMDGPU_PTE_SYSTEM \
| AMDGPU_PTE_SNOOPED\
diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h
index ca97b68..2889663 100644
--- a/include/uapi/drm/amdgpu_drm.h
+++ b/include/uapi/drm/amdgpu_drm.h
@@ -503,6 +503,10 @@ struct drm_amdgpu_gem_op {
#define AMDGPU_VM_MTYPE_CC(3 << 5)
/* Use UC MTYPE instead of default MTYPE */
#define AMDGPU_VM_MTYPE_UC(4 << 5)
+/* Use RW MTYPE instead of default MTYPE */
+#define AMDGPU_VM_MTYPE_RW (5 << 5)
+/* Cacheable/snoopable */
+#define AMDGPU_VM_PAGE_SNOOPED (1 << 9)
That's a rather big NAK. Cache snooping is not something userspace is
allowed to be aware of.
Christian.
struct drm_amdgpu_gem_va {
/** GEM object handle */
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
RE: [PATCH v2 libdrm 0/3] add ras inject test for gfx and umc module
Reviewed-by: Hawking Zhang Regards, Hawking -Original Message- From: amd-gfx On Behalf Of Guchun Chen Sent: 2019年8月7日 14:52 To: amd-gfx@lists.freedesktop.org; Zhang, Hawking ; Li, Dennis ; Pan, Xinhui ; Zhou1, Tao Cc: Chen, Guchun Subject: [PATCH v2 libdrm 0/3] add ras inject test for gfx and umc module These patches are to support ras inject test for gfx and umc modules. Patch v2: Correct "eject" in all commits to "inject". Add more error checks and print when parsing configuration file. Add umc multi_uncorrectable test in default configuration file. Guchun Chen (3): amdgpu: add gfx ras inject configuration file tests/amdgpu/ras: refine ras inject test amdgpu: add umc ras inject test configuration configure.ac | 18 ++ data/amdgpu_ras.json | 267 meson.build | 1 + tests/amdgpu/Makefile.am | 5 +- tests/amdgpu/meson.build | 16 +- tests/amdgpu/ras_tests.c | 527 +++ 6 files changed, 783 insertions(+), 51 deletions(-) create mode 100644 data/amdgpu_ras.json -- 2.17.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amdgpu: fix gfx9 soft recovery
The SOC15_REG_OFFSET() macro wasn't used, making the soft recovery fail. v2: use WREG32_SOC15 instead of WREG32 + SOC15_REG_OFFSET Signed-off-by: Pierre-Eric Pelloux-Prayer Reviewed-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c index bcd0301eee1e..1a2963e4bc68 100644 --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c @@ -5375,7 +5375,7 @@ static void gfx_v9_0_ring_soft_recovery(struct amdgpu_ring *ring, unsigned vmid) value = REG_SET_FIELD(value, SQ_CMD, MODE, 0x01); value = REG_SET_FIELD(value, SQ_CMD, CHECK_VMID, 1); value = REG_SET_FIELD(value, SQ_CMD, VM_ID, vmid); - WREG32(mmSQ_CMD, value); + WREG32_SOC15(GC, 0, mmSQ_CMD, value); } static void gfx_v9_0_set_gfx_eop_interrupt_state(struct amdgpu_device *adev, -- 2.23.0.rc1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH v3 11/41] media/v4l2-core/mm: convert put_page() to put_user_page*()
On Tue, Aug 06, 2019 at 06:33:10PM -0700, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page() or
> release_pages().
>
> This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
> ("mm: introduce put_user_page*(), placeholder versions").
>
> Cc: Mauro Carvalho Chehab
> Cc: Kees Cook
> Cc: Hans Verkuil
> Cc: Sakari Ailus
> Cc: Jan Kara
> Cc: Robin Murphy
> Cc: Souptick Joarder
> Cc: Dan Williams
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: John Hubbard
Acked-by: Sakari Ailus
--
Sakari Ailus
sakari.ai...@linux.intel.com
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: replace readq/writeq with atomic64 operations
On Wed, Aug 07, 2019 at 10:56:40AM +0800, Tao Zhou wrote: > readq/writeq are not supported on all architectures NAK. You must not use atomic_* on __iomem (MMIO) memory. ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
RE: [PATCH v2 libdrm 0/3] add ras inject test for gfx and umc module
The series is: Reviewed-by: Tao Zhou > -Original Message- > From: amd-gfx On Behalf Of > Guchun Chen > Sent: 2019年8月7日 14:52 > To: amd-gfx@lists.freedesktop.org; Zhang, Hawking > ; Li, Dennis ; Pan, Xinhui > ; Zhou1, Tao > Cc: Chen, Guchun > Subject: [PATCH v2 libdrm 0/3] add ras inject test for gfx and umc module > > These patches are to support ras inject test for gfx and umc modules. > > Patch v2: > Correct "eject" in all commits to "inject". > Add more error checks and print when parsing configuration file. > Add umc multi_uncorrectable test in default configuration file. > > Guchun Chen (3): > amdgpu: add gfx ras inject configuration file > tests/amdgpu/ras: refine ras inject test > amdgpu: add umc ras inject test configuration > > configure.ac | 18 ++ > data/amdgpu_ras.json | 267 > meson.build | 1 + > tests/amdgpu/Makefile.am | 5 +- > tests/amdgpu/meson.build | 16 +- > tests/amdgpu/ras_tests.c | 527 +++--- > - > 6 files changed, 783 insertions(+), 51 deletions(-) create mode 100644 > data/amdgpu_ras.json > > -- > 2.17.1 > > ___ > amd-gfx mailing list > amd-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 15/15] amdgpu: remove CONFIG_DRM_AMDGPU_USERPTR
Am 06.08.19 um 22:03 schrieb Jason Gunthorpe: > On Tue, Aug 06, 2019 at 02:58:58PM -0400, Alex Deucher wrote: >> On Tue, Aug 6, 2019 at 1:51 PM Kuehling, Felix >> wrote: >>> On 2019-08-06 13:44, Jason Gunthorpe wrote: On Tue, Aug 06, 2019 at 07:05:53PM +0300, Christoph Hellwig wrote: > The option is just used to select HMM mirror support and has a very > confusing help text. Just pull in the HMM mirror code by default > instead. > > Signed-off-by: Christoph Hellwig >drivers/gpu/drm/Kconfig | 2 ++ >drivers/gpu/drm/amd/amdgpu/Kconfig | 10 -- >drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 -- >drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 12 >4 files changed, 2 insertions(+), 28 deletions(-) Felix, was this an effort to avoid the arch restriction on hmm or something? Also can't see why this was like this. >>> This option predates KFD's support of userptrs, which in turn predates >>> HMM. Radeon has the same kind of option, though it doesn't affect HMM in >>> that case. >>> >>> Alex, Christian, can you think of a good reason to maintain userptr >>> support as an option in amdgpu? I suspect it was originally meant as a >>> way to allow kernels with amdgpu without MMU notifiers. Now it would >>> allow a kernel with amdgpu without HMM or MMU notifiers. I don't know if >>> this is a useful thing to have. >> Right. There were people that didn't have MMU notifiers that wanted >> support for the GPU. > ?? Is that even a real thing? mmu_notifier does not have much kconfig > dependency. Yes, that used to be a very real thing. Initially a lot of users didn't wanted mmu notifiers to be enabled because of the performance overhead they costs. Then we had the problem that HMM mirror wasn't available on a lot of architectures. Not sure if we still need it separately, but I think that it shouldn't be removed without asking around if somebody still needs that. Christian. > > Jason ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH v2 libdrm 3/3] amdgpu: add umc ras inject test configuration
Both umc single_correctable and multi_uncorrectable
inject types are added.
Change-Id: I779f2f4f59c69fb08fdc09b7adba5b36e3af20ce
Signed-off-by: Dennis Li
Signed-off-by: Guchun Chen
---
data/amdgpu_ras.json | 17 +
1 file changed, 17 insertions(+)
diff --git a/data/amdgpu_ras.json b/data/amdgpu_ras.json
index 0863a182..26fd9465 100644
--- a/data/amdgpu_ras.json
+++ b/data/amdgpu_ras.json
@@ -1,6 +1,9 @@
{
"version": "0.0.1",
"block": {
+"umc": {
+"index": 0
+},
"gfx": {
"index": 2,
"subblock": {
@@ -126,6 +129,20 @@
"poison": 8
},
"tests": [
+{
+"name": "ras_umc.1.0",
+"block": "umc",
+"type": "single_correctable",
+"address": 0,
+"value": 0
+},
+{
+"name": "ras_umc.1.0",
+"block": "umc",
+"type": "multi_uncorrectable",
+"address": 0,
+"value": 0
+},
{
"name": "ras_gfx.2.1",
"block": "gfx",
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH v2 libdrm 0/3] add ras inject test for gfx and umc module
These patches are to support ras inject test for gfx and umc modules. Patch v2: Correct "eject" in all commits to "inject". Add more error checks and print when parsing configuration file. Add umc multi_uncorrectable test in default configuration file. Guchun Chen (3): amdgpu: add gfx ras inject configuration file tests/amdgpu/ras: refine ras inject test amdgpu: add umc ras inject test configuration configure.ac | 18 ++ data/amdgpu_ras.json | 267 meson.build | 1 + tests/amdgpu/Makefile.am | 5 +- tests/amdgpu/meson.build | 16 +- tests/amdgpu/ras_tests.c | 527 +++ 6 files changed, 783 insertions(+), 51 deletions(-) create mode 100644 data/amdgpu_ras.json -- 2.17.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH v2 libdrm 1/3] amdgpu: add gfx ras inject configuration file
This configuration file will be picked up when
running gfx ras inject tests by amdgpu_test tool.
For the time being, only add those tests that are
successfully trafficked. In addition, this file
can also be modified by user to add or delete ras
inject unit tests for different IP blocks/subblocks.
Change-Id: Ib18c0555c87c9f4e7ca36cc4938c25940f77fd2f
Signed-off-by: Dennis Li
Signed-off-by: Guchun Chen
---
data/amdgpu_ras.json | 250 +++
1 file changed, 250 insertions(+)
create mode 100644 data/amdgpu_ras.json
diff --git a/data/amdgpu_ras.json b/data/amdgpu_ras.json
new file mode 100644
index ..0863a182
--- /dev/null
+++ b/data/amdgpu_ras.json
@@ -0,0 +1,250 @@
+{
+"version": "0.0.1",
+"block": {
+"gfx": {
+"index": 2,
+"subblock": {
+"gfx_cpc_scratch": 0,
+"gfx_cpc_ucode": 1,
+"gfx_dc_state_me1": 2,
+"gfx_dc_csinvoc_me1": 3,
+"gfx_dc_restore_me1": 4,
+"gfx_dc_state_me2": 5,
+"gfx_dc_csinvoc_me2": 6,
+"gfx_dc_restore_me2": 7,
+"gfx_cpf_roq_me2": 8,
+"gfx_cpf_roq_me1": 9,
+"gfx_cpf_tag": 10,
+"gfx_cpg_dma_roq": 11,
+"gfx_cpg_dma_tag": 12,
+"gfx_cpg_tag": 13,
+"gfx_gds_mem": 14,
+"gfx_gds_input_queue": 15,
+"gfx_gds_oa_phy_cmd_ram_mem": 16,
+"gfx_gds_oa_phy_data_ram_mem": 17,
+"gfx_gds_oa_pipe_mem": 18,
+"gfx_spi_sr_mem": 19,
+"gfx_sq_sgpr": 20,
+"gfx_sq_lds_d": 21,
+"gfx_sq_lds_i": 22,
+"gfx_sq_vgpr": 23,
+"gfx_sqc_inst_utcl1_lfifo": 24,
+"gfx_sqc_data_cu0_write_data_buf": 25,
+"gfx_sqc_data_cu0_utcl1_lfifo": 26,
+"gfx_sqc_data_cu1_write_data_buf": 27,
+"gfx_sqc_data_cu1_utcl1_lfifo": 28,
+"gfx_sqc_data_cu2_write_data_buf": 29,
+"gfx_sqc_data_cu2_utcl1_lfifo": 30,
+"gfx_sqc_inst_banka_tag_ram": 31,
+"gfx_sqc_inst_banka_utcl1_miss_fifo": 32,
+"gfx_sqc_inst_banka_miss_fifo": 33,
+"gfx_sqc_inst_banka_bank_ram": 34,
+"gfx_sqc_data_banka_tag_ram": 35,
+"gfx_sqc_data_banka_hit_fifo": 36,
+"gfx_sqc_data_banka_miss_fifo": 37,
+"gfx_sqc_data_banka_dirty_bit_ram": 38,
+"gfx_sqc_data_banka_bank_ram": 39,
+"gfx_sqc_inst_bankb_tag_ram": 40,
+"gfx_sqc_inst_bankb_utcl1_miss_fifo": 41,
+"gfx_sqc_inst_bankb_miss_fifo": 42,
+"gfx_sqc_inst_bankb_bank_ram": 43,
+"gfx_sqc_data_bankb_tag_ram": 44,
+"gfx_sqc_data_bankb_hit_fifo": 45,
+"gfx_sqc_data_bankb_miss_fifo": 46,
+"gfx_sqc_data_bankb_dirty_bit_ram": 47,
+"gfx_sqc_data_bankb_bank_ram": 48,
+"gfx_ta_fs_dfifo": 49,
+"gfx_ta_fs_afifo": 50,
+"gfx_ta_fl_lfifo": 51,
+"gfx_ta_fx_lfifo": 52,
+"gfx_ta_fs_cfifo": 53,
+"gfx_tca_hole_fifo": 54,
+"gfx_tca_req_fifo": 55,
+"gfx_tcc_cache_data": 56,
+"gfx_tcc_cache_data_bank_0_1": 57,
+"gfx_tcc_cache_data_bank_1_0": 58,
+"gfx_tcc_cache_data_bank_1_1": 59,
+"gfx_tcc_cache_dirty_bank_0": 60,
+"gfx_tcc_cache_dirty_bank_1": 61,
+"gfx_tcc_high_rate_tag": 62,
+"gfx_tcc_low_rate_tag": 63,
+"gfx_tcc_in_use_dec": 64,
+"gfx_tcc_in_use_transfer": 65,
+"gfx_tcc_return_data": 66,
+"gfx_tcc_return_control": 67,
+"gfx_tcc_uc_atomic_fifo": 68,
+"gfx_tcc_write_return": 69,
+"gfx_tcc_write_cache_read": 70,
+"gfx_tcc_src_fifo": 71,
+"gfx_tcc_src_fifo_next_ram": 72,
+"gfx_tcc_cache_tag_probe_fifo": 73,
+"gfx_tcc_latency_fifo": 74,
+"gfx_tcc_latency_fifo_next_ram": 75,
+"gfx_tcc_wrret_tag_write_return": 76,
+"gfx_tcc_atomic_return_buffer": 77,
+"gfx_tci_write_ram": 78,
+"gfx_tcp_cache_ram": 79,
+"gfx_tcp_lfifo_ram": 80,
+"gfx_tcp_cmd_fifo": 81,
+"gfx_tcp_vm_fifo": 82,
+"gfx_tcp_db_ram": 83,
+"gfx_tcp_utcl1_lfifo0": 84,
+"gfx_tcp_utcl1_lfifo1": 85,
+"gfx_td_ss_fifo_lo": 86,
+"gfx_td_ss_fifo_hi": 87,
+"gfx_td_cs_fifo": 88,
+"gfx_ea_dramrd_cmdmem": 89,
+
