[PATCH] kbuild: use always-y instead of extra-y
As commit d0e628cd817f ("kbuild: doc: clarify the difference between
extra-y and always-y") explained, extra-y should be used for listing
the prerequsites of vmlinux. always-y is a better fix here.
Signed-off-by: Masahiro Yamada
---
Documentation/devicetree/bindings/Makefile | 8
drivers/gpu/drm/i915/Makefile | 2 +-
scripts/Makefile.lib | 10 +-
scripts/gdb/linux/Makefile | 2 +-
4 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/Makefile
b/Documentation/devicetree/bindings/Makefile
index 8f2b054bec5a..90fcad98984d 100644
--- a/Documentation/devicetree/bindings/Makefile
+++ b/Documentation/devicetree/bindings/Makefile
@@ -78,10 +78,10 @@ $(obj)/processed-schema.json: $(DT_SCHEMA_FILES)
check_dtschema_version FORCE
endif
-extra-$(CHECK_DT_BINDING) += processed-schema-examples.json
-extra-$(CHECK_DTBS) += processed-schema.json
-extra-$(CHECK_DT_BINDING) += $(patsubst $(src)/%.yaml,%.example.dts,
$(DT_SCHEMA_FILES))
-extra-$(CHECK_DT_BINDING) += $(patsubst $(src)/%.yaml,%.example.dt.yaml,
$(DT_SCHEMA_FILES))
+always-$(CHECK_DT_BINDING) += processed-schema-examples.json
+always-$(CHECK_DTBS) += processed-schema.json
+always-$(CHECK_DT_BINDING) += $(patsubst $(src)/%.yaml,%.example.dts,
$(DT_SCHEMA_FILES))
+always-$(CHECK_DT_BINDING) += $(patsubst $(src)/%.yaml,%.example.dt.yaml,
$(DT_SCHEMA_FILES))
# Hack: avoid 'Argument list too long' error for 'make clean'. Remove most of
# build artifacts here before they are processed by scripts/Makefile.clean
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 6d9e81ea67f4..938221894d0c 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -294,7 +294,7 @@ no-header-test := \
gvt/mpt.h \
gvt/scheduler.h
-extra-$(CONFIG_DRM_I915_WERROR) += \
+always-$(CONFIG_DRM_I915_WERROR) += \
$(patsubst %.h,%.hdrtest, $(filter-out $(no-header-test), \
$(shell cd $(srctree)/$(src) && find * -name '*.h')))
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 4612a887f28e..b8e587a17dcc 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -64,12 +64,12 @@ always-y += $(userprogs-always-y) $(userprogs-always-m)
# DTB
# If CONFIG_OF_ALL_DTBS is enabled, all DT blobs are built
-extra-y+= $(dtb-y)
-extra-$(CONFIG_OF_ALL_DTBS)+= $(dtb-)
+always-y += $(dtb-y)
+always-$(CONFIG_OF_ALL_DTBS) += $(dtb-)
ifneq ($(CHECK_DTBS),)
-extra-y += $(patsubst %.dtb,%.dt.yaml, $(dtb-y))
-extra-$(CONFIG_OF_ALL_DTBS) += $(patsubst %.dtb,%.dt.yaml, $(dtb-))
+always-y += $(patsubst %.dtb,%.dt.yaml, $(dtb-y))
+always-$(CONFIG_OF_ALL_DTBS) += $(patsubst %.dtb,%.dt.yaml, $(dtb-))
endif
# Add subdir path
@@ -230,7 +230,7 @@ $(obj)/%: $(src)/%_shipped
# target: source(s) FORCE
# $(if_changed,ld/objcopy/gzip)
#
-# and add target to extra-y so that we know we have to
+# and add target to 'targets' so that we know we have to
# read in the saved command line
# Linking
diff --git a/scripts/gdb/linux/Makefile b/scripts/gdb/linux/Makefile
index 124755087510..13903073cbff 100644
--- a/scripts/gdb/linux/Makefile
+++ b/scripts/gdb/linux/Makefile
@@ -18,7 +18,7 @@ quiet_cmd_gen_constants_py = GEN $@
$(CPP) -E -x c -P $(c_flags) $< > $@ ;\
sed -i '1,//d;' $@
-extra-y += constants.py
+always-y += constants.py
$(obj)/constants.py: $(src)/constants.py.in FORCE
$(call if_changed_dep,gen_constants_py)
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] amdgpu drm-next-5.12
Hi Dave, Daniel, More new stuff for 5.12. Now with non-x86 fixed. The following changes since commit 044a48f420b9d3c19a135b821c34de5b2bee4075: drm/amdgpu: fix DRM_INFO flood if display core is not supported (bug 210921) (2021-01-08 15:18:57 -0500) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-next-5.12-2021-01-20 for you to fetch changes up to 4aef0ebc6b65e8583bc3d96e05c7a039912b3ee6: drm/amdgpu: fix build error without x86 kconfig (v2) (2021-01-19 15:16:10 -0500) amd-drm-next-5.12-2021-01-20: amdgpu: - Fix non-x86 build - W=1 fixes from Lee Jones - Enable GPU reset on Navy Flounder - Kernel doc fixes - SMU workload profile fixes for APUs - Display updates - SR-IOV fixes - Vangogh SMU feature enablment and bug fixes - GPU reset support for Vangogh - Misc cleanups Alex Deucher (5): MAINTAINERS: update radeon/amdgpu/amdkfd git trees drm/amdgpu: add mode2 reset support for vangogh drm/amdgpu/nv: add mode2 reset handling drm/amdgpu: fix mode2 reset sequence for vangogh drm/amdgpu: Enable GPU reset for vangogh Aric Cyr (2): drm/amd/display: 3.2.117 drm/amd/display: 3.2.118 Bhawanpreet Lakha (2): drm/amd/display: enable HUBP blank behaviour drm/amd/display: Fix deadlock during gpu reset v3 Charlene Liu (1): drm/amd/display: change SMU repsonse timeout to 2s Chiawen Huang (1): drm/amd/display: removed unnecessary check when dpp clock increasing Colin Ian King (1): drm/amdgpu: Add missing BOOTUP_DEFAULT to profile_name[] Emily.Deng (1): drm/amdgpu: Decrease compute timeout to 10 s for sriov multiple VF Guchun Chen (1): drm/amdgpu: toggle on DF Cstate after finishing xgmi injection Huang Rui (13): drm/amd/pm: remove vcn/jpeg powergating feature checking for vangogh drm/amd/pm: enhance the real response for smu message (v2) drm/amd/pm: clean up get_allowed_feature_mask function drm/amd/pm: initial feature_enabled/feature_support bitmap for vangogh drm/amd/pm: don't mark all apu as true on feature mask drm/amdgpu: revise the mode2 reset for vangogh drm/amd/pm: fix the return value of pm message drm/amd/pm: implement the processor clocks which read by metric drm/amd/pm: implement processor fine grain feature for vangogh (v3) drm/amdgpu: fix vram type and bandwidth error for DDR5 and DDR4 drm/amd/display: fix the system memory page fault because of copy overflow drm/amd/display: fix the coding style issue of integrated_info drm/amdgpu: fix build error without x86 kconfig (v2) Jack Zhang (1): drm/amdgpu/sriov Stop data exchange for wholegpu reset Jacky Liao (1): drm/amd/display: Fix assert being hit with GAMCOR memory shut down Jeremy Cline (1): drm/amdkfd: Fix out-of-bounds read in kdf_create_vcrat_image_cpu() Jiansong Chen (2): drm/amdgpu: enable gpu recovery for navy_flounder drm/amd/pm: update driver if version for navy_flounder Jinzhou Su (4): drm/amd/pm: Add GFXOFF interface for Vangogh drm/amd/pm: Enable GfxOff for Vangogh drm/amdgpu: Add Secure Display TA header file drm/amdgpu: Add secure display TA interface John Clements (1): drm/amdgpu: updated fw attestation interface Jun Lei (1): drm/amd/display: implement T12 compliance Lee Jones (90): drm/amd/amdgpu/amdgpu_ih: Update 'amdgpu_ih_decode_iv_helper()'s function header drm/amd/amdgpu/vega20_ih: Add missing descriptions for 'ih' and fix spelling error drm/amd/pm/powerplay/hwmgr/process_pptables_v1_0: Provide description of 'call_back_func' drm/amd/pm/powerplay/hwmgr/ppatomctrl: Fix documentation for 'mpll_param' drm/amd/pm/powerplay/hwmgr/vega12_hwmgr: Fix legacy function header formatting drm/amd/pm/powerplay/hwmgr/vega20_hwmgr: Fix legacy function header formatting drm/amd/pm/powerplay/hwmgr/smu7_hwmgr: Fix formatting and spelling issues drm/amd/pm/powerplay/hwmgr/hwmgr: Move prototype into shared header drm/amd/pm/powerplay/hwmgr/vega10_hwmgr: Fix a bunch of kernel-doc formatting issues drm/amd/display/dc/basics/conversion: Demote obvious kernel-doc abuse drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs: Demote non-kernel-doc comment blocks drm/amd/display/dc/bios/command_table_helper: Fix kernel-doc formatting drm/amd/display/dc/bios/command_table_helper2: Fix legacy formatting problems drm/amd/display/dc/bios/bios_parser: Make local functions static drm/amd/display/dc/bios/bios_parser: Fix a whole bunch of legacy doc formatting drm/amd/display/dc/bios/bios_parser2: Fix some formatting issues and missing parameter docs drm/amd/display/dc/dce/dce_audio: Make function invoked by reference static drm/amd/dis
Re: [PATCH v4 07/14] drm/amdgpu: Register IOMMU topology notifier per device.
On 1/19/21 3:48 AM, Christian König wrote:
Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
Handle all DMA IOMMU gropup related dependencies before the
group is removed.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 5
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 46 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 10 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 ++
6 files changed, 65 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 478a7d8..2953420 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -51,6 +51,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1041,6 +1042,10 @@ struct amdgpu_device {
bool in_pci_err_recovery;
struct pci_saved_state *pci_state;
+
+ struct notifier_block nb;
+ struct blocking_notifier_head notifier;
+ struct list_head device_bo_list;
};
static inline struct amdgpu_device *drm_to_adev(struct drm_device *ddev)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 45e23e3..e99f4f1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -70,6 +70,8 @@
#include
#include
+#include
+
MODULE_FIRMWARE("amdgpu/vega10_gpu_info.bin");
MODULE_FIRMWARE("amdgpu/vega12_gpu_info.bin");
MODULE_FIRMWARE("amdgpu/raven_gpu_info.bin");
@@ -3200,6 +3202,39 @@ static const struct attribute *amdgpu_dev_attributes[]
= {
};
+static int amdgpu_iommu_group_notifier(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+ struct amdgpu_device *adev = container_of(nb, struct amdgpu_device, nb);
+ struct amdgpu_bo *bo = NULL;
+
+ /*
+ * Following is a set of IOMMU group dependencies taken care of before
+ * device's IOMMU group is removed
+ */
+ if (action == IOMMU_GROUP_NOTIFY_DEL_DEVICE) {
+
+ spin_lock(&ttm_bo_glob.lru_lock);
+ list_for_each_entry(bo, &adev->device_bo_list, bo) {
+ if (bo->tbo.ttm)
+ ttm_tt_unpopulate(bo->tbo.bdev, bo->tbo.ttm);
+ }
+ spin_unlock(&ttm_bo_glob.lru_lock);
That approach won't work. ttm_tt_unpopulate() might sleep on an IOMMU lock.
You need to use a mutex here or even better make sure you can access the
device_bo_list without a lock in this moment.
Christian.
I can think of switching to RCU list ? Otherwise, elements are added
on BO create and deleted on BO destroy, how can i prevent any of those from
happening while in this section besides mutex ? Make a copy list and run over it
instead ?
Andrey
+
+ if (adev->irq.ih.use_bus_addr)
+ amdgpu_ih_ring_fini(adev, &adev->irq.ih);
+ if (adev->irq.ih1.use_bus_addr)
+ amdgpu_ih_ring_fini(adev, &adev->irq.ih1);
+ if (adev->irq.ih2.use_bus_addr)
+ amdgpu_ih_ring_fini(adev, &adev->irq.ih2);
+
+ amdgpu_gart_dummy_page_fini(adev);
+ }
+
+ return NOTIFY_OK;
+}
+
+
/**
* amdgpu_device_init - initialize the driver
*
@@ -3304,6 +3339,8 @@ int amdgpu_device_init(struct amdgpu_device *adev,
INIT_WORK(&adev->xgmi_reset_work, amdgpu_device_xgmi_reset_func);
+ INIT_LIST_HEAD(&adev->device_bo_list);
+
adev->gfx.gfx_off_req_count = 1;
adev->pm.ac_power = power_supply_is_system_supplied() > 0;
@@ -3575,6 +3612,15 @@ int amdgpu_device_init(struct amdgpu_device *adev,
if (amdgpu_device_cache_pci_state(adev->pdev))
pci_restore_state(pdev);
+ BLOCKING_INIT_NOTIFIER_HEAD(&adev->notifier);
+ adev->nb.notifier_call = amdgpu_iommu_group_notifier;
+
+ if (adev->dev->iommu_group) {
+ r = iommu_group_register_notifier(adev->dev->iommu_group, &adev->nb);
+ if (r)
+ goto failed;
+ }
+
return 0;
failed:
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
index 0db9330..486ad6d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
@@ -92,7 +92,7 @@ static int amdgpu_gart_dummy_page_init(struct amdgpu_device
*adev)
*
* Frees the dummy page used by the driver (all asics).
*/
-static void amdgpu_gart_dummy_page_fini(struct amdgpu_device *adev)
+void amdgpu_gart_dummy_page_fini(struct amdgpu_device *adev)
{
if (!adev->dummy_page_addr)
return;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h
index afa2e28..5678d9c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h
@@ -61,6 +61,7 @@ int amdgpu_gart_table_vram_pin(
Re: [PATCH v4 07/14] drm/amdgpu: Register IOMMU topology notifier per device.
On 1/19/21 5:01 PM, Daniel Vetter wrote:
On Tue, Jan 19, 2021 at 10:22 PM Andrey Grodzovsky
wrote:
On 1/19/21 8:45 AM, Daniel Vetter wrote:
On Tue, Jan 19, 2021 at 09:48:03AM +0100, Christian König wrote:
Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
Handle all DMA IOMMU gropup related dependencies before the
group is removed.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 5
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 46
++
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 10 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 ++
6 files changed, 65 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 478a7d8..2953420 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -51,6 +51,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1041,6 +1042,10 @@ struct amdgpu_device {
boolin_pci_err_recovery;
struct pci_saved_state *pci_state;
+
+ struct notifier_block nb;
+ struct blocking_notifier_head notifier;
+ struct list_head device_bo_list;
};
static inline struct amdgpu_device *drm_to_adev(struct drm_device *ddev)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 45e23e3..e99f4f1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -70,6 +70,8 @@
#include
#include
+#include
+
MODULE_FIRMWARE("amdgpu/vega10_gpu_info.bin");
MODULE_FIRMWARE("amdgpu/vega12_gpu_info.bin");
MODULE_FIRMWARE("amdgpu/raven_gpu_info.bin");
@@ -3200,6 +3202,39 @@ static const struct attribute *amdgpu_dev_attributes[] =
{
};
+static int amdgpu_iommu_group_notifier(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+ struct amdgpu_device *adev = container_of(nb, struct amdgpu_device, nb);
+ struct amdgpu_bo *bo = NULL;
+
+ /*
+ * Following is a set of IOMMU group dependencies taken care of before
+ * device's IOMMU group is removed
+ */
+ if (action == IOMMU_GROUP_NOTIFY_DEL_DEVICE) {
+
+ spin_lock(&ttm_bo_glob.lru_lock);
+ list_for_each_entry(bo, &adev->device_bo_list, bo) {
+ if (bo->tbo.ttm)
+ ttm_tt_unpopulate(bo->tbo.bdev, bo->tbo.ttm);
+ }
+ spin_unlock(&ttm_bo_glob.lru_lock);
That approach won't work. ttm_tt_unpopulate() might sleep on an IOMMU lock.
You need to use a mutex here or even better make sure you can access the
device_bo_list without a lock in this moment.
I'd also be worried about the notifier mutex getting really badly in the
way.
Plus I'm worried why we even need this, it sounds a bit like papering over
the iommu subsystem. Assuming we clean up all our iommu mappings in our
device hotunplug/unload code, why do we still need to have an additional
iommu notifier on top, with all kinds of additional headaches? The iommu
shouldn't clean up before the devices in its group have cleaned up.
I think we need more info here on what the exact problem is first.
-Daniel
Originally I experienced the crash bellow on IOMMU enabled device, it happens
post device removal from PCI topology -
during shutting down of user client holding last reference to drm device file
(X in my case).
The crash is because by the time I get to this point struct device->iommu_group
pointer is NULL
already since the IOMMU group for the device is unset during PCI removal. So
this contradicts what you said above
that the iommu shouldn't clean up before the devices in its group have cleaned
up.
So instead of guessing when is the right place to place all IOMMU related
cleanups it makes sense
to get notification from IOMMU subsystem in the form of event
IOMMU_GROUP_NOTIFY_DEL_DEVICE
and use that place to do all the relevant cleanups.
Yeah that goes boom, but you shouldn't need this special iommu cleanup
handler. Making sure that all the dma-api mappings are gone needs to
be done as part of the device hotunplug, you can't delay that to the
last drm_device cleanup.
So I most of the patch here with pulling that out (should be outright
removed from the final release code even) is good, just not yet how
you call that new code. Probably these bits (aside from walking all
buffers and unpopulating the tt) should be done from the early_free
callback you're adding.
Also what I just realized: For normal unload you need to make sure the
hw is actually stopped first, before we unmap buffers. Otherwise
driver unload will likely result in wedged hw, probably not what you
want for debugging.
-Daniel
Since device removal from IOMMU group and this hook in particular
takes place before call to amdgpu_pci_remove essentially it means
that for IOMMU use case the entire amdgpu_device_fini_hw function
shouold be called here
[PATCH AUTOSEL 4.4 4/4] drm/nouveau/i2c/gm200: increase width of aux semaphore owner fields
From: Ben Skeggs
[ Upstream commit ba6e9ab0fcf3d76e3952deb12b5f993991621d9c ]
Noticed while debugging GA102.
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm204.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm204.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm204.c
index 7cac8fe372b6b..a3cede8df4fd9 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm204.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm204.c
@@ -33,7 +33,7 @@ static void
gm204_i2c_aux_fini(struct gm204_i2c_aux *aux)
{
struct nvkm_device *device = aux->base.pad->i2c->subdev.device;
- nvkm_mask(device, 0x00d954 + (aux->ch * 0x50), 0x0031, 0x);
+ nvkm_mask(device, 0x00d954 + (aux->ch * 0x50), 0x0071, 0x);
}
static int
@@ -54,10 +54,10 @@ gm204_i2c_aux_init(struct gm204_i2c_aux *aux)
AUX_ERR(&aux->base, "begin idle timeout %08x", ctrl);
return -EBUSY;
}
- } while (ctrl & 0x0301);
+ } while (ctrl & 0x0701);
/* set some magic, and wait up to 1ms for it to appear */
- nvkm_mask(device, 0x00d954 + (aux->ch * 0x50), 0x0030, ureq);
+ nvkm_mask(device, 0x00d954 + (aux->ch * 0x50), 0x0070, ureq);
timeout = 1000;
do {
ctrl = nvkm_rd32(device, 0x00d954 + (aux->ch * 0x50));
@@ -67,7 +67,7 @@ gm204_i2c_aux_init(struct gm204_i2c_aux *aux)
gm204_i2c_aux_fini(aux);
return -EBUSY;
}
- } while ((ctrl & 0x0300) != urep);
+ } while ((ctrl & 0x0700) != urep);
return 0;
}
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.4 3/4] drm/nouveau/bios: fix issue shadowing expansion ROMs
From: Ben Skeggs
[ Upstream commit 402a89660e9dc880710b12773076a336c9dab3d7 ]
This issue has generally been covered up by the presence of additional
expansion ROMs after the ones we're interested in, with header fetches
of subsequent images loading enough of the ROM to hide the issue.
Noticed on GA102, which lacks a type 0x70 image compared to TU102,.
[ 906.364197] nouveau :09:00.0: bios: : type 00, 65024 bytes
[ 906.381205] nouveau :09:00.0: bios: fe00: type 03, 91648 bytes
[ 906.405213] nouveau :09:00.0: bios: 00026400: type e0, 22016 bytes
[ 906.410984] nouveau :09:00.0: bios: 0002ba00: type e0, 366080 bytes
vs
[ 22.961901] nouveau :09:00.0: bios: : type 00, 60416 bytes
[ 22.984174] nouveau :09:00.0: bios: ec00: type 03, 71168 bytes
[ 23.010446] nouveau :09:00.0: bios: 00020200: type e0, 48128 bytes
[ 23.028220] nouveau :09:00.0: bios: 0002be00: type e0, 140800 bytes
[ 23.080196] nouveau :09:00.0: bios: 0004e400: type 70, 7168 bytes
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
index 7deb81b6dbac6..4b571cc6bc70f 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
@@ -75,7 +75,7 @@ shadow_image(struct nvkm_bios *bios, int idx, u32 offset,
struct shadow *mthd)
nvkm_debug(subdev, "%08x: type %02x, %d bytes\n",
image.base, image.type, image.size);
- if (!shadow_fetch(bios, mthd, image.size)) {
+ if (!shadow_fetch(bios, mthd, image.base + image.size)) {
nvkm_debug(subdev, "%08x: fetch failed\n", image.base);
return 0;
}
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 4/4] drm/nouveau/i2c/gm200: increase width of aux semaphore owner fields
From: Ben Skeggs
[ Upstream commit ba6e9ab0fcf3d76e3952deb12b5f993991621d9c ]
Noticed while debugging GA102.
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c
index a5783f4d972e3..c49795e779be4 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c
@@ -33,7 +33,7 @@ static void
gm200_i2c_aux_fini(struct gm200_i2c_aux *aux)
{
struct nvkm_device *device = aux->base.pad->i2c->subdev.device;
- nvkm_mask(device, 0x00d954 + (aux->ch * 0x50), 0x0031, 0x);
+ nvkm_mask(device, 0x00d954 + (aux->ch * 0x50), 0x0071, 0x);
}
static int
@@ -54,10 +54,10 @@ gm200_i2c_aux_init(struct gm200_i2c_aux *aux)
AUX_ERR(&aux->base, "begin idle timeout %08x", ctrl);
return -EBUSY;
}
- } while (ctrl & 0x0301);
+ } while (ctrl & 0x0701);
/* set some magic, and wait up to 1ms for it to appear */
- nvkm_mask(device, 0x00d954 + (aux->ch * 0x50), 0x0030, ureq);
+ nvkm_mask(device, 0x00d954 + (aux->ch * 0x50), 0x0070, ureq);
timeout = 1000;
do {
ctrl = nvkm_rd32(device, 0x00d954 + (aux->ch * 0x50));
@@ -67,7 +67,7 @@ gm200_i2c_aux_init(struct gm200_i2c_aux *aux)
gm200_i2c_aux_fini(aux);
return -EBUSY;
}
- } while ((ctrl & 0x0300) != urep);
+ } while ((ctrl & 0x0700) != urep);
return 0;
}
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 3/4] drm/nouveau/bios: fix issue shadowing expansion ROMs
From: Ben Skeggs
[ Upstream commit 402a89660e9dc880710b12773076a336c9dab3d7 ]
This issue has generally been covered up by the presence of additional
expansion ROMs after the ones we're interested in, with header fetches
of subsequent images loading enough of the ROM to hide the issue.
Noticed on GA102, which lacks a type 0x70 image compared to TU102,.
[ 906.364197] nouveau :09:00.0: bios: : type 00, 65024 bytes
[ 906.381205] nouveau :09:00.0: bios: fe00: type 03, 91648 bytes
[ 906.405213] nouveau :09:00.0: bios: 00026400: type e0, 22016 bytes
[ 906.410984] nouveau :09:00.0: bios: 0002ba00: type e0, 366080 bytes
vs
[ 22.961901] nouveau :09:00.0: bios: : type 00, 60416 bytes
[ 22.984174] nouveau :09:00.0: bios: ec00: type 03, 71168 bytes
[ 23.010446] nouveau :09:00.0: bios: 00020200: type e0, 48128 bytes
[ 23.028220] nouveau :09:00.0: bios: 0002be00: type e0, 140800 bytes
[ 23.080196] nouveau :09:00.0: bios: 0004e400: type 70, 7168 bytes
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
index 7deb81b6dbac6..4b571cc6bc70f 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
@@ -75,7 +75,7 @@ shadow_image(struct nvkm_bios *bios, int idx, u32 offset,
struct shadow *mthd)
nvkm_debug(subdev, "%08x: type %02x, %d bytes\n",
image.base, image.type, image.size);
- if (!shadow_fetch(bios, mthd, image.size)) {
+ if (!shadow_fetch(bios, mthd, image.base + image.size)) {
nvkm_debug(subdev, "%08x: fetch failed\n", image.base);
return 0;
}
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 8/9] drm/nouveau/privring: ack interrupts the same way as RM
From: Ben Skeggs [ Upstream commit e05e06cd34f5311f677294a08b609acfbc315236 ] Whatever it is that we were doing before doesn't work on Ampere. Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin --- drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gf100.c | 10 +++--- drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gk104.c | 10 +++--- 2 files changed, 14 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gf100.c b/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gf100.c index d80dbc8f09b20..55a4ea4393c62 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gf100.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gf100.c @@ -22,6 +22,7 @@ * Authors: Ben Skeggs */ #include "priv.h" +#include static void gf100_ibus_intr_hub(struct nvkm_subdev *ibus, int i) @@ -31,7 +32,6 @@ gf100_ibus_intr_hub(struct nvkm_subdev *ibus, int i) u32 data = nvkm_rd32(device, 0x122124 + (i * 0x0400)); u32 stat = nvkm_rd32(device, 0x122128 + (i * 0x0400)); nvkm_debug(ibus, "HUB%d: %06x %08x (%08x)\n", i, addr, data, stat); - nvkm_mask(device, 0x122128 + (i * 0x0400), 0x0200, 0x); } static void @@ -42,7 +42,6 @@ gf100_ibus_intr_rop(struct nvkm_subdev *ibus, int i) u32 data = nvkm_rd32(device, 0x124124 + (i * 0x0400)); u32 stat = nvkm_rd32(device, 0x124128 + (i * 0x0400)); nvkm_debug(ibus, "ROP%d: %06x %08x (%08x)\n", i, addr, data, stat); - nvkm_mask(device, 0x124128 + (i * 0x0400), 0x0200, 0x); } static void @@ -53,7 +52,6 @@ gf100_ibus_intr_gpc(struct nvkm_subdev *ibus, int i) u32 data = nvkm_rd32(device, 0x128124 + (i * 0x0400)); u32 stat = nvkm_rd32(device, 0x128128 + (i * 0x0400)); nvkm_debug(ibus, "GPC%d: %06x %08x (%08x)\n", i, addr, data, stat); - nvkm_mask(device, 0x128128 + (i * 0x0400), 0x0200, 0x); } void @@ -90,6 +88,12 @@ gf100_ibus_intr(struct nvkm_subdev *ibus) intr1 &= ~stat; } } + + nvkm_mask(device, 0x121c4c, 0x003f, 0x0002); + nvkm_msec(device, 2000, + if (!(nvkm_rd32(device, 0x121c4c) & 0x003f)) + break; + ); } static int diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gk104.c b/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gk104.c index 9025ed1bd2a99..4caf3ef087e1d 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gk104.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gk104.c @@ -22,6 +22,7 @@ * Authors: Ben Skeggs */ #include "priv.h" +#include static void gk104_ibus_intr_hub(struct nvkm_subdev *ibus, int i) @@ -31,7 +32,6 @@ gk104_ibus_intr_hub(struct nvkm_subdev *ibus, int i) u32 data = nvkm_rd32(device, 0x122124 + (i * 0x0800)); u32 stat = nvkm_rd32(device, 0x122128 + (i * 0x0800)); nvkm_debug(ibus, "HUB%d: %06x %08x (%08x)\n", i, addr, data, stat); - nvkm_mask(device, 0x122128 + (i * 0x0800), 0x0200, 0x); } static void @@ -42,7 +42,6 @@ gk104_ibus_intr_rop(struct nvkm_subdev *ibus, int i) u32 data = nvkm_rd32(device, 0x124124 + (i * 0x0800)); u32 stat = nvkm_rd32(device, 0x124128 + (i * 0x0800)); nvkm_debug(ibus, "ROP%d: %06x %08x (%08x)\n", i, addr, data, stat); - nvkm_mask(device, 0x124128 + (i * 0x0800), 0x0200, 0x); } static void @@ -53,7 +52,6 @@ gk104_ibus_intr_gpc(struct nvkm_subdev *ibus, int i) u32 data = nvkm_rd32(device, 0x128124 + (i * 0x0800)); u32 stat = nvkm_rd32(device, 0x128128 + (i * 0x0800)); nvkm_debug(ibus, "GPC%d: %06x %08x (%08x)\n", i, addr, data, stat); - nvkm_mask(device, 0x128128 + (i * 0x0800), 0x0200, 0x); } void @@ -90,6 +88,12 @@ gk104_ibus_intr(struct nvkm_subdev *ibus) intr1 &= ~stat; } } + + nvkm_mask(device, 0x12004c, 0x003f, 0x0002); + nvkm_msec(device, 2000, + if (!(nvkm_rd32(device, 0x12004c) & 0x003f)) + break; + ); } static int -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 9/9] drm/nouveau/i2c/gm200: increase width of aux semaphore owner fields
From: Ben Skeggs
[ Upstream commit ba6e9ab0fcf3d76e3952deb12b5f993991621d9c ]
Noticed while debugging GA102.
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c
index edb6148cbca04..d0e80ad526845 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c
@@ -33,7 +33,7 @@ static void
gm200_i2c_aux_fini(struct gm200_i2c_aux *aux)
{
struct nvkm_device *device = aux->base.pad->i2c->subdev.device;
- nvkm_mask(device, 0x00d954 + (aux->ch * 0x50), 0x0031, 0x);
+ nvkm_mask(device, 0x00d954 + (aux->ch * 0x50), 0x0071, 0x);
}
static int
@@ -54,10 +54,10 @@ gm200_i2c_aux_init(struct gm200_i2c_aux *aux)
AUX_ERR(&aux->base, "begin idle timeout %08x", ctrl);
return -EBUSY;
}
- } while (ctrl & 0x0301);
+ } while (ctrl & 0x0701);
/* set some magic, and wait up to 1ms for it to appear */
- nvkm_mask(device, 0x00d954 + (aux->ch * 0x50), 0x0030, ureq);
+ nvkm_mask(device, 0x00d954 + (aux->ch * 0x50), 0x0070, ureq);
timeout = 1000;
do {
ctrl = nvkm_rd32(device, 0x00d954 + (aux->ch * 0x50));
@@ -67,7 +67,7 @@ gm200_i2c_aux_init(struct gm200_i2c_aux *aux)
gm200_i2c_aux_fini(aux);
return -EBUSY;
}
- } while ((ctrl & 0x0300) != urep);
+ } while ((ctrl & 0x0700) != urep);
return 0;
}
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 7/9] drm/nouveau/bios: fix issue shadowing expansion ROMs
From: Ben Skeggs
[ Upstream commit 402a89660e9dc880710b12773076a336c9dab3d7 ]
This issue has generally been covered up by the presence of additional
expansion ROMs after the ones we're interested in, with header fetches
of subsequent images loading enough of the ROM to hide the issue.
Noticed on GA102, which lacks a type 0x70 image compared to TU102,.
[ 906.364197] nouveau :09:00.0: bios: : type 00, 65024 bytes
[ 906.381205] nouveau :09:00.0: bios: fe00: type 03, 91648 bytes
[ 906.405213] nouveau :09:00.0: bios: 00026400: type e0, 22016 bytes
[ 906.410984] nouveau :09:00.0: bios: 0002ba00: type e0, 366080 bytes
vs
[ 22.961901] nouveau :09:00.0: bios: : type 00, 60416 bytes
[ 22.984174] nouveau :09:00.0: bios: ec00: type 03, 71168 bytes
[ 23.010446] nouveau :09:00.0: bios: 00020200: type e0, 48128 bytes
[ 23.028220] nouveau :09:00.0: bios: 0002be00: type e0, 140800 bytes
[ 23.080196] nouveau :09:00.0: bios: 0004e400: type 70, 7168 bytes
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
index 7deb81b6dbac6..4b571cc6bc70f 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
@@ -75,7 +75,7 @@ shadow_image(struct nvkm_bios *bios, int idx, u32 offset,
struct shadow *mthd)
nvkm_debug(subdev, "%08x: type %02x, %d bytes\n",
image.base, image.type, image.size);
- if (!shadow_fetch(bios, mthd, image.size)) {
+ if (!shadow_fetch(bios, mthd, image.base + image.size)) {
nvkm_debug(subdev, "%08x: fetch failed\n", image.base);
return 0;
}
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 15/15] drm/nouveau/kms/nv50-: fix case where notifier buffer is at offset 0
From: Ben Skeggs
[ Upstream commit caeb6ab899c3d36a74cda6e299c6e1c9c4e2a22e ]
VRAM offset 0 is a valid address, triggered on GA102.
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 4 ++--
drivers/gpu/drm/nouveau/dispnv50/disp.h | 2 +-
drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 1bb0a9f6fa730..fbe156302ee86 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -131,7 +131,7 @@ nv50_dmac_destroy(struct nv50_dmac *dmac)
int
nv50_dmac_create(struct nvif_device *device, struct nvif_object *disp,
-const s32 *oclass, u8 head, void *data, u32 size, u64 syncbuf,
+const s32 *oclass, u8 head, void *data, u32 size, s64 syncbuf,
struct nv50_dmac *dmac)
{
struct nouveau_cli *cli = (void *)device->object.client;
@@ -166,7 +166,7 @@ nv50_dmac_create(struct nvif_device *device, struct
nvif_object *disp,
if (ret)
return ret;
- if (!syncbuf)
+ if (syncbuf < 0)
return 0;
ret = nvif_object_init(&dmac->base.user, 0xf000, NV_DMA_IN_MEMORY,
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.h
b/drivers/gpu/drm/nouveau/dispnv50/disp.h
index 66c125a6b0b3c..55205d23360c8 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.h
@@ -68,7 +68,7 @@ struct nv50_dmac {
int nv50_dmac_create(struct nvif_device *device, struct nvif_object *disp,
const s32 *oclass, u8 head, void *data, u32 size,
-u64 syncbuf, struct nv50_dmac *dmac);
+s64 syncbuf, struct nv50_dmac *dmac);
void nv50_dmac_destroy(struct nv50_dmac *);
u32 *evo_wait(struct nv50_dmac *, int nr);
diff --git a/drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c
b/drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c
index f7dbd965e4e72..b49a212af4d8d 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c
@@ -68,7 +68,7 @@ wimmc37b_init_(const struct nv50_wimm_func *func, struct
nouveau_drm *drm,
int ret;
ret = nv50_dmac_create(&drm->client.device, &disp->disp->object,
- &oclass, 0, &args, sizeof(args), 0,
+ &oclass, 0, &args, sizeof(args), -1,
&wndw->wimm);
if (ret) {
NV_ERROR(drm, "wimm%04x allocation failed: %d\n", oclass, ret);
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 13/15] drm/nouveau/i2c/gm200: increase width of aux semaphore owner fields
From: Ben Skeggs
[ Upstream commit ba6e9ab0fcf3d76e3952deb12b5f993991621d9c ]
Noticed while debugging GA102.
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c
index edb6148cbca04..d0e80ad526845 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c
@@ -33,7 +33,7 @@ static void
gm200_i2c_aux_fini(struct gm200_i2c_aux *aux)
{
struct nvkm_device *device = aux->base.pad->i2c->subdev.device;
- nvkm_mask(device, 0x00d954 + (aux->ch * 0x50), 0x0031, 0x);
+ nvkm_mask(device, 0x00d954 + (aux->ch * 0x50), 0x0071, 0x);
}
static int
@@ -54,10 +54,10 @@ gm200_i2c_aux_init(struct gm200_i2c_aux *aux)
AUX_ERR(&aux->base, "begin idle timeout %08x", ctrl);
return -EBUSY;
}
- } while (ctrl & 0x0301);
+ } while (ctrl & 0x0701);
/* set some magic, and wait up to 1ms for it to appear */
- nvkm_mask(device, 0x00d954 + (aux->ch * 0x50), 0x0030, ureq);
+ nvkm_mask(device, 0x00d954 + (aux->ch * 0x50), 0x0070, ureq);
timeout = 1000;
do {
ctrl = nvkm_rd32(device, 0x00d954 + (aux->ch * 0x50));
@@ -67,7 +67,7 @@ gm200_i2c_aux_init(struct gm200_i2c_aux *aux)
gm200_i2c_aux_fini(aux);
return -EBUSY;
}
- } while ((ctrl & 0x0300) != urep);
+ } while ((ctrl & 0x0700) != urep);
return 0;
}
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 12/15] drm/nouveau/privring: ack interrupts the same way as RM
From: Ben Skeggs [ Upstream commit e05e06cd34f5311f677294a08b609acfbc315236 ] Whatever it is that we were doing before doesn't work on Ampere. Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin --- drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gf100.c | 10 +++--- drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gk104.c | 10 +++--- 2 files changed, 14 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gf100.c b/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gf100.c index d80dbc8f09b20..55a4ea4393c62 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gf100.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gf100.c @@ -22,6 +22,7 @@ * Authors: Ben Skeggs */ #include "priv.h" +#include static void gf100_ibus_intr_hub(struct nvkm_subdev *ibus, int i) @@ -31,7 +32,6 @@ gf100_ibus_intr_hub(struct nvkm_subdev *ibus, int i) u32 data = nvkm_rd32(device, 0x122124 + (i * 0x0400)); u32 stat = nvkm_rd32(device, 0x122128 + (i * 0x0400)); nvkm_debug(ibus, "HUB%d: %06x %08x (%08x)\n", i, addr, data, stat); - nvkm_mask(device, 0x122128 + (i * 0x0400), 0x0200, 0x); } static void @@ -42,7 +42,6 @@ gf100_ibus_intr_rop(struct nvkm_subdev *ibus, int i) u32 data = nvkm_rd32(device, 0x124124 + (i * 0x0400)); u32 stat = nvkm_rd32(device, 0x124128 + (i * 0x0400)); nvkm_debug(ibus, "ROP%d: %06x %08x (%08x)\n", i, addr, data, stat); - nvkm_mask(device, 0x124128 + (i * 0x0400), 0x0200, 0x); } static void @@ -53,7 +52,6 @@ gf100_ibus_intr_gpc(struct nvkm_subdev *ibus, int i) u32 data = nvkm_rd32(device, 0x128124 + (i * 0x0400)); u32 stat = nvkm_rd32(device, 0x128128 + (i * 0x0400)); nvkm_debug(ibus, "GPC%d: %06x %08x (%08x)\n", i, addr, data, stat); - nvkm_mask(device, 0x128128 + (i * 0x0400), 0x0200, 0x); } void @@ -90,6 +88,12 @@ gf100_ibus_intr(struct nvkm_subdev *ibus) intr1 &= ~stat; } } + + nvkm_mask(device, 0x121c4c, 0x003f, 0x0002); + nvkm_msec(device, 2000, + if (!(nvkm_rd32(device, 0x121c4c) & 0x003f)) + break; + ); } static int diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gk104.c b/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gk104.c index 9025ed1bd2a99..4caf3ef087e1d 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gk104.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gk104.c @@ -22,6 +22,7 @@ * Authors: Ben Skeggs */ #include "priv.h" +#include static void gk104_ibus_intr_hub(struct nvkm_subdev *ibus, int i) @@ -31,7 +32,6 @@ gk104_ibus_intr_hub(struct nvkm_subdev *ibus, int i) u32 data = nvkm_rd32(device, 0x122124 + (i * 0x0800)); u32 stat = nvkm_rd32(device, 0x122128 + (i * 0x0800)); nvkm_debug(ibus, "HUB%d: %06x %08x (%08x)\n", i, addr, data, stat); - nvkm_mask(device, 0x122128 + (i * 0x0800), 0x0200, 0x); } static void @@ -42,7 +42,6 @@ gk104_ibus_intr_rop(struct nvkm_subdev *ibus, int i) u32 data = nvkm_rd32(device, 0x124124 + (i * 0x0800)); u32 stat = nvkm_rd32(device, 0x124128 + (i * 0x0800)); nvkm_debug(ibus, "ROP%d: %06x %08x (%08x)\n", i, addr, data, stat); - nvkm_mask(device, 0x124128 + (i * 0x0800), 0x0200, 0x); } static void @@ -53,7 +52,6 @@ gk104_ibus_intr_gpc(struct nvkm_subdev *ibus, int i) u32 data = nvkm_rd32(device, 0x128124 + (i * 0x0800)); u32 stat = nvkm_rd32(device, 0x128128 + (i * 0x0800)); nvkm_debug(ibus, "GPC%d: %06x %08x (%08x)\n", i, addr, data, stat); - nvkm_mask(device, 0x128128 + (i * 0x0800), 0x0200, 0x); } void @@ -90,6 +88,12 @@ gk104_ibus_intr(struct nvkm_subdev *ibus) intr1 &= ~stat; } } + + nvkm_mask(device, 0x12004c, 0x003f, 0x0002); + nvkm_msec(device, 2000, + if (!(nvkm_rd32(device, 0x12004c) & 0x003f)) + break; + ); } static int -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 14/15] drm/nouveau/mmu: fix vram heap sizing
From: Ben Skeggs
[ Upstream commit add42781ad76c5ae65127bf13852a4c6b2f08849 ]
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c
index ee11ccaf0563c..cb51e248cb41b 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c
@@ -316,9 +316,9 @@ nvkm_mmu_vram(struct nvkm_mmu *mmu)
{
struct nvkm_device *device = mmu->subdev.device;
struct nvkm_mm *mm = &device->fb->ram->vram;
- const u32 sizeN = nvkm_mm_heap_size(mm, NVKM_RAM_MM_NORMAL);
- const u32 sizeU = nvkm_mm_heap_size(mm, NVKM_RAM_MM_NOMAP);
- const u32 sizeM = nvkm_mm_heap_size(mm, NVKM_RAM_MM_MIXED);
+ const u64 sizeN = nvkm_mm_heap_size(mm, NVKM_RAM_MM_NORMAL);
+ const u64 sizeU = nvkm_mm_heap_size(mm, NVKM_RAM_MM_NOMAP);
+ const u64 sizeM = nvkm_mm_heap_size(mm, NVKM_RAM_MM_MIXED);
u8 type = NVKM_MEM_KIND * !!mmu->func->kind;
u8 heap = NVKM_MEM_VRAM;
int heapM, heapN, heapU;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 11/15] drm/nouveau/bios: fix issue shadowing expansion ROMs
From: Ben Skeggs
[ Upstream commit 402a89660e9dc880710b12773076a336c9dab3d7 ]
This issue has generally been covered up by the presence of additional
expansion ROMs after the ones we're interested in, with header fetches
of subsequent images loading enough of the ROM to hide the issue.
Noticed on GA102, which lacks a type 0x70 image compared to TU102,.
[ 906.364197] nouveau :09:00.0: bios: : type 00, 65024 bytes
[ 906.381205] nouveau :09:00.0: bios: fe00: type 03, 91648 bytes
[ 906.405213] nouveau :09:00.0: bios: 00026400: type e0, 22016 bytes
[ 906.410984] nouveau :09:00.0: bios: 0002ba00: type e0, 366080 bytes
vs
[ 22.961901] nouveau :09:00.0: bios: : type 00, 60416 bytes
[ 22.984174] nouveau :09:00.0: bios: ec00: type 03, 71168 bytes
[ 23.010446] nouveau :09:00.0: bios: 00020200: type e0, 48128 bytes
[ 23.028220] nouveau :09:00.0: bios: 0002be00: type e0, 140800 bytes
[ 23.080196] nouveau :09:00.0: bios: 0004e400: type 70, 7168 bytes
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
index 7deb81b6dbac6..4b571cc6bc70f 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
@@ -75,7 +75,7 @@ shadow_image(struct nvkm_bios *bios, int idx, u32 offset,
struct shadow *mthd)
nvkm_debug(subdev, "%08x: type %02x, %d bytes\n",
image.base, image.type, image.size);
- if (!shadow_fetch(bios, mthd, image.size)) {
+ if (!shadow_fetch(bios, mthd, image.base + image.size)) {
nvkm_debug(subdev, "%08x: fetch failed\n", image.base);
return 0;
}
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 25/26] drm/nouveau/mmu: fix vram heap sizing
From: Ben Skeggs
[ Upstream commit add42781ad76c5ae65127bf13852a4c6b2f08849 ]
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c
index ee11ccaf0563c..cb51e248cb41b 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c
@@ -316,9 +316,9 @@ nvkm_mmu_vram(struct nvkm_mmu *mmu)
{
struct nvkm_device *device = mmu->subdev.device;
struct nvkm_mm *mm = &device->fb->ram->vram;
- const u32 sizeN = nvkm_mm_heap_size(mm, NVKM_RAM_MM_NORMAL);
- const u32 sizeU = nvkm_mm_heap_size(mm, NVKM_RAM_MM_NOMAP);
- const u32 sizeM = nvkm_mm_heap_size(mm, NVKM_RAM_MM_MIXED);
+ const u64 sizeN = nvkm_mm_heap_size(mm, NVKM_RAM_MM_NORMAL);
+ const u64 sizeU = nvkm_mm_heap_size(mm, NVKM_RAM_MM_NOMAP);
+ const u64 sizeM = nvkm_mm_heap_size(mm, NVKM_RAM_MM_MIXED);
u8 type = NVKM_MEM_KIND * !!mmu->func->kind;
u8 heap = NVKM_MEM_VRAM;
int heapM, heapN, heapU;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 24/26] drm/nouveau/i2c/gm200: increase width of aux semaphore owner fields
From: Ben Skeggs
[ Upstream commit ba6e9ab0fcf3d76e3952deb12b5f993991621d9c ]
Noticed while debugging GA102.
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c
index edb6148cbca04..d0e80ad526845 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c
@@ -33,7 +33,7 @@ static void
gm200_i2c_aux_fini(struct gm200_i2c_aux *aux)
{
struct nvkm_device *device = aux->base.pad->i2c->subdev.device;
- nvkm_mask(device, 0x00d954 + (aux->ch * 0x50), 0x0031, 0x);
+ nvkm_mask(device, 0x00d954 + (aux->ch * 0x50), 0x0071, 0x);
}
static int
@@ -54,10 +54,10 @@ gm200_i2c_aux_init(struct gm200_i2c_aux *aux)
AUX_ERR(&aux->base, "begin idle timeout %08x", ctrl);
return -EBUSY;
}
- } while (ctrl & 0x0301);
+ } while (ctrl & 0x0701);
/* set some magic, and wait up to 1ms for it to appear */
- nvkm_mask(device, 0x00d954 + (aux->ch * 0x50), 0x0030, ureq);
+ nvkm_mask(device, 0x00d954 + (aux->ch * 0x50), 0x0070, ureq);
timeout = 1000;
do {
ctrl = nvkm_rd32(device, 0x00d954 + (aux->ch * 0x50));
@@ -67,7 +67,7 @@ gm200_i2c_aux_init(struct gm200_i2c_aux *aux)
gm200_i2c_aux_fini(aux);
return -EBUSY;
}
- } while ((ctrl & 0x0300) != urep);
+ } while ((ctrl & 0x0700) != urep);
return 0;
}
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 26/26] drm/nouveau/kms/nv50-: fix case where notifier buffer is at offset 0
From: Ben Skeggs
[ Upstream commit caeb6ab899c3d36a74cda6e299c6e1c9c4e2a22e ]
VRAM offset 0 is a valid address, triggered on GA102.
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 4 ++--
drivers/gpu/drm/nouveau/dispnv50/disp.h | 2 +-
drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index ee2b1e1199e09..daa79d39201f9 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -132,7 +132,7 @@ nv50_dmac_destroy(struct nv50_dmac *dmac)
int
nv50_dmac_create(struct nvif_device *device, struct nvif_object *disp,
-const s32 *oclass, u8 head, void *data, u32 size, u64 syncbuf,
+const s32 *oclass, u8 head, void *data, u32 size, s64 syncbuf,
struct nv50_dmac *dmac)
{
struct nouveau_cli *cli = (void *)device->object.client;
@@ -167,7 +167,7 @@ nv50_dmac_create(struct nvif_device *device, struct
nvif_object *disp,
if (ret)
return ret;
- if (!syncbuf)
+ if (syncbuf < 0)
return 0;
ret = nvif_object_init(&dmac->base.user, 0xf000, NV_DMA_IN_MEMORY,
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.h
b/drivers/gpu/drm/nouveau/dispnv50/disp.h
index 7c41b0599d1ac..284068fa6d007 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.h
@@ -70,7 +70,7 @@ struct nv50_dmac {
int nv50_dmac_create(struct nvif_device *device, struct nvif_object *disp,
const s32 *oclass, u8 head, void *data, u32 size,
-u64 syncbuf, struct nv50_dmac *dmac);
+s64 syncbuf, struct nv50_dmac *dmac);
void nv50_dmac_destroy(struct nv50_dmac *);
u32 *evo_wait(struct nv50_dmac *, int nr);
diff --git a/drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c
b/drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c
index f7dbd965e4e72..b49a212af4d8d 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c
@@ -68,7 +68,7 @@ wimmc37b_init_(const struct nv50_wimm_func *func, struct
nouveau_drm *drm,
int ret;
ret = nv50_dmac_create(&drm->client.device, &disp->disp->object,
- &oclass, 0, &args, sizeof(args), 0,
+ &oclass, 0, &args, sizeof(args), -1,
&wndw->wimm);
if (ret) {
NV_ERROR(drm, "wimm%04x allocation failed: %d\n", oclass, ret);
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 22/26] drm/nouveau/bios: fix issue shadowing expansion ROMs
From: Ben Skeggs
[ Upstream commit 402a89660e9dc880710b12773076a336c9dab3d7 ]
This issue has generally been covered up by the presence of additional
expansion ROMs after the ones we're interested in, with header fetches
of subsequent images loading enough of the ROM to hide the issue.
Noticed on GA102, which lacks a type 0x70 image compared to TU102,.
[ 906.364197] nouveau :09:00.0: bios: : type 00, 65024 bytes
[ 906.381205] nouveau :09:00.0: bios: fe00: type 03, 91648 bytes
[ 906.405213] nouveau :09:00.0: bios: 00026400: type e0, 22016 bytes
[ 906.410984] nouveau :09:00.0: bios: 0002ba00: type e0, 366080 bytes
vs
[ 22.961901] nouveau :09:00.0: bios: : type 00, 60416 bytes
[ 22.984174] nouveau :09:00.0: bios: ec00: type 03, 71168 bytes
[ 23.010446] nouveau :09:00.0: bios: 00020200: type e0, 48128 bytes
[ 23.028220] nouveau :09:00.0: bios: 0002be00: type e0, 140800 bytes
[ 23.080196] nouveau :09:00.0: bios: 0004e400: type 70, 7168 bytes
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
index 7deb81b6dbac6..4b571cc6bc70f 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
@@ -75,7 +75,7 @@ shadow_image(struct nvkm_bios *bios, int idx, u32 offset,
struct shadow *mthd)
nvkm_debug(subdev, "%08x: type %02x, %d bytes\n",
image.base, image.type, image.size);
- if (!shadow_fetch(bios, mthd, image.size)) {
+ if (!shadow_fetch(bios, mthd, image.base + image.size)) {
nvkm_debug(subdev, "%08x: fetch failed\n", image.base);
return 0;
}
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 23/26] drm/nouveau/privring: ack interrupts the same way as RM
From: Ben Skeggs [ Upstream commit e05e06cd34f5311f677294a08b609acfbc315236 ] Whatever it is that we were doing before doesn't work on Ampere. Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin --- drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gf100.c | 10 +++--- drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gk104.c | 10 +++--- 2 files changed, 14 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gf100.c b/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gf100.c index d80dbc8f09b20..55a4ea4393c62 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gf100.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gf100.c @@ -22,6 +22,7 @@ * Authors: Ben Skeggs */ #include "priv.h" +#include static void gf100_ibus_intr_hub(struct nvkm_subdev *ibus, int i) @@ -31,7 +32,6 @@ gf100_ibus_intr_hub(struct nvkm_subdev *ibus, int i) u32 data = nvkm_rd32(device, 0x122124 + (i * 0x0400)); u32 stat = nvkm_rd32(device, 0x122128 + (i * 0x0400)); nvkm_debug(ibus, "HUB%d: %06x %08x (%08x)\n", i, addr, data, stat); - nvkm_mask(device, 0x122128 + (i * 0x0400), 0x0200, 0x); } static void @@ -42,7 +42,6 @@ gf100_ibus_intr_rop(struct nvkm_subdev *ibus, int i) u32 data = nvkm_rd32(device, 0x124124 + (i * 0x0400)); u32 stat = nvkm_rd32(device, 0x124128 + (i * 0x0400)); nvkm_debug(ibus, "ROP%d: %06x %08x (%08x)\n", i, addr, data, stat); - nvkm_mask(device, 0x124128 + (i * 0x0400), 0x0200, 0x); } static void @@ -53,7 +52,6 @@ gf100_ibus_intr_gpc(struct nvkm_subdev *ibus, int i) u32 data = nvkm_rd32(device, 0x128124 + (i * 0x0400)); u32 stat = nvkm_rd32(device, 0x128128 + (i * 0x0400)); nvkm_debug(ibus, "GPC%d: %06x %08x (%08x)\n", i, addr, data, stat); - nvkm_mask(device, 0x128128 + (i * 0x0400), 0x0200, 0x); } void @@ -90,6 +88,12 @@ gf100_ibus_intr(struct nvkm_subdev *ibus) intr1 &= ~stat; } } + + nvkm_mask(device, 0x121c4c, 0x003f, 0x0002); + nvkm_msec(device, 2000, + if (!(nvkm_rd32(device, 0x121c4c) & 0x003f)) + break; + ); } static int diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gk104.c b/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gk104.c index 9025ed1bd2a99..4caf3ef087e1d 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gk104.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gk104.c @@ -22,6 +22,7 @@ * Authors: Ben Skeggs */ #include "priv.h" +#include static void gk104_ibus_intr_hub(struct nvkm_subdev *ibus, int i) @@ -31,7 +32,6 @@ gk104_ibus_intr_hub(struct nvkm_subdev *ibus, int i) u32 data = nvkm_rd32(device, 0x122124 + (i * 0x0800)); u32 stat = nvkm_rd32(device, 0x122128 + (i * 0x0800)); nvkm_debug(ibus, "HUB%d: %06x %08x (%08x)\n", i, addr, data, stat); - nvkm_mask(device, 0x122128 + (i * 0x0800), 0x0200, 0x); } static void @@ -42,7 +42,6 @@ gk104_ibus_intr_rop(struct nvkm_subdev *ibus, int i) u32 data = nvkm_rd32(device, 0x124124 + (i * 0x0800)); u32 stat = nvkm_rd32(device, 0x124128 + (i * 0x0800)); nvkm_debug(ibus, "ROP%d: %06x %08x (%08x)\n", i, addr, data, stat); - nvkm_mask(device, 0x124128 + (i * 0x0800), 0x0200, 0x); } static void @@ -53,7 +52,6 @@ gk104_ibus_intr_gpc(struct nvkm_subdev *ibus, int i) u32 data = nvkm_rd32(device, 0x128124 + (i * 0x0800)); u32 stat = nvkm_rd32(device, 0x128128 + (i * 0x0800)); nvkm_debug(ibus, "GPC%d: %06x %08x (%08x)\n", i, addr, data, stat); - nvkm_mask(device, 0x128128 + (i * 0x0800), 0x0200, 0x); } void @@ -90,6 +88,12 @@ gk104_ibus_intr(struct nvkm_subdev *ibus) intr1 &= ~stat; } } + + nvkm_mask(device, 0x12004c, 0x003f, 0x0002); + nvkm_msec(device, 2000, + if (!(nvkm_rd32(device, 0x12004c) & 0x003f)) + break; + ); } static int -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 21/26] drm/amd/display: Fix to be able to stop crc calculation
From: Wayne Lin
[ Upstream commit 02ce73b01e09e388614b22b7ebc71debf4a588f0 ]
[Why]
Find out when we try to disable CRC calculation,
crc generation is still enabled. Main reason is
that dc_stream_configure_crc() will never get
called when the source is AMDGPU_DM_PIPE_CRC_SOURCE_NONE.
[How]
Add checking condition that when source is
AMDGPU_DM_PIPE_CRC_SOURCE_NONE, we should also call
dc_stream_configure_crc() to disable crc calculation.
Also, clean up crc window when disable crc calculation.
Signed-off-by: Wayne Lin
Reviewed-by: Nicholas Kazlauskas
Acked-by: Qingqing Zhuo
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
index a549c7c717ddc..f0b001b3af578 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
@@ -113,7 +113,7 @@ int amdgpu_dm_crtc_configure_crc_source(struct drm_crtc
*crtc,
mutex_lock(&adev->dm.dc_lock);
/* Enable CRTC CRC generation if necessary. */
- if (dm_is_crc_source_crtc(source)) {
+ if (dm_is_crc_source_crtc(source) || source ==
AMDGPU_DM_PIPE_CRC_SOURCE_NONE) {
if (!dc_stream_configure_crc(stream_state->ctx->dc,
stream_state, enable, enable)) {
ret = -EINVAL;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 20/26] drm/amdgpu/psp: fix psp gfx ctrl cmds
From: Victor Zhao [ Upstream commit f14a5c34d143f6627f0be70c0de1d962f3a6ff1c ] psp GFX_CTRL_CMD_ID_CONSUME_CMD different for windows and linux, according to psp, linux cmds are not correct. v2: only correct GFX_CTRL_CMD_ID_CONSUME_CMD. Signed-off-by: Victor Zhao Reviewed-by: Emily.Deng Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/psp_gfx_if.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/psp_gfx_if.h b/drivers/gpu/drm/amd/amdgpu/psp_gfx_if.h index 74a9fe8e0cfb9..8c54f0be51bab 100644 --- a/drivers/gpu/drm/amd/amdgpu/psp_gfx_if.h +++ b/drivers/gpu/drm/amd/amdgpu/psp_gfx_if.h @@ -44,7 +44,7 @@ enum psp_gfx_crtl_cmd_id GFX_CTRL_CMD_ID_DISABLE_INT = 0x0006, /* disable PSP-to-Gfx interrupt */ GFX_CTRL_CMD_ID_MODE1_RST = 0x0007, /* trigger the Mode 1 reset */ GFX_CTRL_CMD_ID_GBR_IH_SET = 0x0008, /* set Gbr IH_RB_CNTL registers */ -GFX_CTRL_CMD_ID_CONSUME_CMD = 0x000A, /* send interrupt to psp for updating write pointer of vf */ +GFX_CTRL_CMD_ID_CONSUME_CMD = 0x0009, /* send interrupt to psp for updating write pointer of vf */ GFX_CTRL_CMD_ID_DESTROY_GPCOM_RING = 0x000C, /* destroy GPCOM ring */ GFX_CTRL_CMD_ID_MAX = 0x000F, /* max command ID */ -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.10 37/45] drm/nouveau/privring: ack interrupts the same way as RM
From: Ben Skeggs [ Upstream commit e05e06cd34f5311f677294a08b609acfbc315236 ] Whatever it is that we were doing before doesn't work on Ampere. Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin --- drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gf100.c | 10 +++--- drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gk104.c | 10 +++--- 2 files changed, 14 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gf100.c b/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gf100.c index 2340040942c93..1115376bc85f5 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gf100.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gf100.c @@ -22,6 +22,7 @@ * Authors: Ben Skeggs */ #include "priv.h" +#include static void gf100_ibus_intr_hub(struct nvkm_subdev *ibus, int i) @@ -31,7 +32,6 @@ gf100_ibus_intr_hub(struct nvkm_subdev *ibus, int i) u32 data = nvkm_rd32(device, 0x122124 + (i * 0x0400)); u32 stat = nvkm_rd32(device, 0x122128 + (i * 0x0400)); nvkm_debug(ibus, "HUB%d: %06x %08x (%08x)\n", i, addr, data, stat); - nvkm_mask(device, 0x122128 + (i * 0x0400), 0x0200, 0x); } static void @@ -42,7 +42,6 @@ gf100_ibus_intr_rop(struct nvkm_subdev *ibus, int i) u32 data = nvkm_rd32(device, 0x124124 + (i * 0x0400)); u32 stat = nvkm_rd32(device, 0x124128 + (i * 0x0400)); nvkm_debug(ibus, "ROP%d: %06x %08x (%08x)\n", i, addr, data, stat); - nvkm_mask(device, 0x124128 + (i * 0x0400), 0x0200, 0x); } static void @@ -53,7 +52,6 @@ gf100_ibus_intr_gpc(struct nvkm_subdev *ibus, int i) u32 data = nvkm_rd32(device, 0x128124 + (i * 0x0400)); u32 stat = nvkm_rd32(device, 0x128128 + (i * 0x0400)); nvkm_debug(ibus, "GPC%d: %06x %08x (%08x)\n", i, addr, data, stat); - nvkm_mask(device, 0x128128 + (i * 0x0400), 0x0200, 0x); } void @@ -90,6 +88,12 @@ gf100_ibus_intr(struct nvkm_subdev *ibus) intr1 &= ~stat; } } + + nvkm_mask(device, 0x121c4c, 0x003f, 0x0002); + nvkm_msec(device, 2000, + if (!(nvkm_rd32(device, 0x121c4c) & 0x003f)) + break; + ); } static int diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gk104.c b/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gk104.c index f3915f85838ed..22e487b493ad1 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gk104.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gk104.c @@ -22,6 +22,7 @@ * Authors: Ben Skeggs */ #include "priv.h" +#include static void gk104_ibus_intr_hub(struct nvkm_subdev *ibus, int i) @@ -31,7 +32,6 @@ gk104_ibus_intr_hub(struct nvkm_subdev *ibus, int i) u32 data = nvkm_rd32(device, 0x122124 + (i * 0x0800)); u32 stat = nvkm_rd32(device, 0x122128 + (i * 0x0800)); nvkm_debug(ibus, "HUB%d: %06x %08x (%08x)\n", i, addr, data, stat); - nvkm_mask(device, 0x122128 + (i * 0x0800), 0x0200, 0x); } static void @@ -42,7 +42,6 @@ gk104_ibus_intr_rop(struct nvkm_subdev *ibus, int i) u32 data = nvkm_rd32(device, 0x124124 + (i * 0x0800)); u32 stat = nvkm_rd32(device, 0x124128 + (i * 0x0800)); nvkm_debug(ibus, "ROP%d: %06x %08x (%08x)\n", i, addr, data, stat); - nvkm_mask(device, 0x124128 + (i * 0x0800), 0x0200, 0x); } static void @@ -53,7 +52,6 @@ gk104_ibus_intr_gpc(struct nvkm_subdev *ibus, int i) u32 data = nvkm_rd32(device, 0x128124 + (i * 0x0800)); u32 stat = nvkm_rd32(device, 0x128128 + (i * 0x0800)); nvkm_debug(ibus, "GPC%d: %06x %08x (%08x)\n", i, addr, data, stat); - nvkm_mask(device, 0x128128 + (i * 0x0800), 0x0200, 0x); } void @@ -90,6 +88,12 @@ gk104_ibus_intr(struct nvkm_subdev *ibus) intr1 &= ~stat; } } + + nvkm_mask(device, 0x12004c, 0x003f, 0x0002); + nvkm_msec(device, 2000, + if (!(nvkm_rd32(device, 0x12004c) & 0x003f)) + break; + ); } static int -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.10 40/45] drm/nouveau/kms/nv50-: fix case where notifier buffer is at offset 0
From: Ben Skeggs
[ Upstream commit caeb6ab899c3d36a74cda6e299c6e1c9c4e2a22e ]
VRAM offset 0 is a valid address, triggered on GA102.
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 4 ++--
drivers/gpu/drm/nouveau/dispnv50/disp.h | 2 +-
drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 36d6b6093d16d..5b8cabb099eb1 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -221,7 +221,7 @@ nv50_dmac_wait(struct nvif_push *push, u32 size)
int
nv50_dmac_create(struct nvif_device *device, struct nvif_object *disp,
-const s32 *oclass, u8 head, void *data, u32 size, u64 syncbuf,
+const s32 *oclass, u8 head, void *data, u32 size, s64 syncbuf,
struct nv50_dmac *dmac)
{
struct nouveau_cli *cli = (void *)device->object.client;
@@ -270,7 +270,7 @@ nv50_dmac_create(struct nvif_device *device, struct
nvif_object *disp,
if (ret)
return ret;
- if (!syncbuf)
+ if (syncbuf < 0)
return 0;
ret = nvif_object_ctor(&dmac->base.user, "kmsSyncCtxDma",
NV50_DISP_HANDLE_SYNCBUF,
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.h
b/drivers/gpu/drm/nouveau/dispnv50/disp.h
index 92bddc0836171..38dec11e7dda5 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.h
@@ -95,7 +95,7 @@ struct nv50_outp_atom {
int nv50_dmac_create(struct nvif_device *device, struct nvif_object *disp,
const s32 *oclass, u8 head, void *data, u32 size,
-u64 syncbuf, struct nv50_dmac *dmac);
+s64 syncbuf, struct nv50_dmac *dmac);
void nv50_dmac_destroy(struct nv50_dmac *);
/*
diff --git a/drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c
b/drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c
index 685b708713242..b390029c69ec1 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c
@@ -76,7 +76,7 @@ wimmc37b_init_(const struct nv50_wimm_func *func, struct
nouveau_drm *drm,
int ret;
ret = nv50_dmac_create(&drm->client.device, &disp->disp->object,
- &oclass, 0, &args, sizeof(args), 0,
+ &oclass, 0, &args, sizeof(args), -1,
&wndw->wimm);
if (ret) {
NV_ERROR(drm, "wimm%04x allocation failed: %d\n", oclass, ret);
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.10 39/45] drm/nouveau/mmu: fix vram heap sizing
From: Ben Skeggs
[ Upstream commit add42781ad76c5ae65127bf13852a4c6b2f08849 ]
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c
index de91e9a261725..6d5212ae2fd57 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c
@@ -316,9 +316,9 @@ nvkm_mmu_vram(struct nvkm_mmu *mmu)
{
struct nvkm_device *device = mmu->subdev.device;
struct nvkm_mm *mm = &device->fb->ram->vram;
- const u32 sizeN = nvkm_mm_heap_size(mm, NVKM_RAM_MM_NORMAL);
- const u32 sizeU = nvkm_mm_heap_size(mm, NVKM_RAM_MM_NOMAP);
- const u32 sizeM = nvkm_mm_heap_size(mm, NVKM_RAM_MM_MIXED);
+ const u64 sizeN = nvkm_mm_heap_size(mm, NVKM_RAM_MM_NORMAL);
+ const u64 sizeU = nvkm_mm_heap_size(mm, NVKM_RAM_MM_NOMAP);
+ const u64 sizeM = nvkm_mm_heap_size(mm, NVKM_RAM_MM_MIXED);
u8 type = NVKM_MEM_KIND * !!mmu->func->kind;
u8 heap = NVKM_MEM_VRAM;
int heapM, heapN, heapU;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.10 35/45] drm/amd/display: Fix to be able to stop crc calculation
From: Wayne Lin
[ Upstream commit 02ce73b01e09e388614b22b7ebc71debf4a588f0 ]
[Why]
Find out when we try to disable CRC calculation,
crc generation is still enabled. Main reason is
that dc_stream_configure_crc() will never get
called when the source is AMDGPU_DM_PIPE_CRC_SOURCE_NONE.
[How]
Add checking condition that when source is
AMDGPU_DM_PIPE_CRC_SOURCE_NONE, we should also call
dc_stream_configure_crc() to disable crc calculation.
Also, clean up crc window when disable crc calculation.
Signed-off-by: Wayne Lin
Reviewed-by: Nicholas Kazlauskas
Acked-by: Qingqing Zhuo
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
index d0699e98db929..e00a30e7d2529 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
@@ -113,7 +113,7 @@ int amdgpu_dm_crtc_configure_crc_source(struct drm_crtc
*crtc,
mutex_lock(&adev->dm.dc_lock);
/* Enable CRTC CRC generation if necessary. */
- if (dm_is_crc_source_crtc(source)) {
+ if (dm_is_crc_source_crtc(source) || source ==
AMDGPU_DM_PIPE_CRC_SOURCE_NONE) {
if (!dc_stream_configure_crc(stream_state->ctx->dc,
stream_state, enable, enable)) {
ret = -EINVAL;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.10 38/45] drm/nouveau/i2c/gm200: increase width of aux semaphore owner fields
From: Ben Skeggs
[ Upstream commit ba6e9ab0fcf3d76e3952deb12b5f993991621d9c ]
Noticed while debugging GA102.
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c
index edb6148cbca04..d0e80ad526845 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c
@@ -33,7 +33,7 @@ static void
gm200_i2c_aux_fini(struct gm200_i2c_aux *aux)
{
struct nvkm_device *device = aux->base.pad->i2c->subdev.device;
- nvkm_mask(device, 0x00d954 + (aux->ch * 0x50), 0x0031, 0x);
+ nvkm_mask(device, 0x00d954 + (aux->ch * 0x50), 0x0071, 0x);
}
static int
@@ -54,10 +54,10 @@ gm200_i2c_aux_init(struct gm200_i2c_aux *aux)
AUX_ERR(&aux->base, "begin idle timeout %08x", ctrl);
return -EBUSY;
}
- } while (ctrl & 0x0301);
+ } while (ctrl & 0x0701);
/* set some magic, and wait up to 1ms for it to appear */
- nvkm_mask(device, 0x00d954 + (aux->ch * 0x50), 0x0030, ureq);
+ nvkm_mask(device, 0x00d954 + (aux->ch * 0x50), 0x0070, ureq);
timeout = 1000;
do {
ctrl = nvkm_rd32(device, 0x00d954 + (aux->ch * 0x50));
@@ -67,7 +67,7 @@ gm200_i2c_aux_init(struct gm200_i2c_aux *aux)
gm200_i2c_aux_fini(aux);
return -EBUSY;
}
- } while ((ctrl & 0x0300) != urep);
+ } while ((ctrl & 0x0700) != urep);
return 0;
}
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.10 36/45] drm/nouveau/bios: fix issue shadowing expansion ROMs
From: Ben Skeggs
[ Upstream commit 402a89660e9dc880710b12773076a336c9dab3d7 ]
This issue has generally been covered up by the presence of additional
expansion ROMs after the ones we're interested in, with header fetches
of subsequent images loading enough of the ROM to hide the issue.
Noticed on GA102, which lacks a type 0x70 image compared to TU102,.
[ 906.364197] nouveau :09:00.0: bios: : type 00, 65024 bytes
[ 906.381205] nouveau :09:00.0: bios: fe00: type 03, 91648 bytes
[ 906.405213] nouveau :09:00.0: bios: 00026400: type e0, 22016 bytes
[ 906.410984] nouveau :09:00.0: bios: 0002ba00: type e0, 366080 bytes
vs
[ 22.961901] nouveau :09:00.0: bios: : type 00, 60416 bytes
[ 22.984174] nouveau :09:00.0: bios: ec00: type 03, 71168 bytes
[ 23.010446] nouveau :09:00.0: bios: 00020200: type e0, 48128 bytes
[ 23.028220] nouveau :09:00.0: bios: 0002be00: type e0, 140800 bytes
[ 23.080196] nouveau :09:00.0: bios: 0004e400: type 70, 7168 bytes
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
index 7deb81b6dbac6..4b571cc6bc70f 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
@@ -75,7 +75,7 @@ shadow_image(struct nvkm_bios *bios, int idx, u32 offset,
struct shadow *mthd)
nvkm_debug(subdev, "%08x: type %02x, %d bytes\n",
image.base, image.type, image.size);
- if (!shadow_fetch(bios, mthd, image.size)) {
+ if (!shadow_fetch(bios, mthd, image.base + image.size)) {
nvkm_debug(subdev, "%08x: fetch failed\n", image.base);
return 0;
}
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.10 33/45] drm/amd/display: disable dcn10 pipe split by default
From: "Li, Roman"
[ Upstream commit 9d03bb102028b4a3f4a64d6069b219e2e1c1f306 ]
[Why]
The initial purpose of dcn10 pipe split is to support some high
bandwidth mode which requires dispclk greater than max dispclk. By
initial bring up power measurement data, it showed power consumption is
less with pipe split for dcn block. This could be reason for enable pipe
split by default. By battery life measurement of some Chromebooks,
result shows battery life is longer with pipe split disabled.
[How]
Disable pipe split by default. Pipe split could be still enabled when
required dispclk is greater than max dispclk.
Tested-by: Daniel Wheeler
Signed-off-by: Hersen Wu
Signed-off-by: Roman Li
Reviewed-by: Roman Li
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
index a78712caf1244..0524d6f1adba6 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
@@ -608,8 +608,8 @@ static const struct dc_debug_options debug_defaults_drv = {
.disable_pplib_clock_request = false,
.disable_pplib_wm_range = false,
.pplib_wm_report_mode = WM_REPORT_DEFAULT,
- .pipe_split_policy = MPC_SPLIT_DYNAMIC,
- .force_single_disp_pipe_split = true,
+ .pipe_split_policy = MPC_SPLIT_AVOID,
+ .force_single_disp_pipe_split = false,
.disable_dcc = DCC_ENABLE,
.voltage_align_fclk = true,
.disable_stereo_support = true,
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.10 32/45] drm/amdgpu/psp: fix psp gfx ctrl cmds
From: Victor Zhao [ Upstream commit f14a5c34d143f6627f0be70c0de1d962f3a6ff1c ] psp GFX_CTRL_CMD_ID_CONSUME_CMD different for windows and linux, according to psp, linux cmds are not correct. v2: only correct GFX_CTRL_CMD_ID_CONSUME_CMD. Signed-off-by: Victor Zhao Reviewed-by: Emily.Deng Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/psp_gfx_if.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/psp_gfx_if.h b/drivers/gpu/drm/amd/amdgpu/psp_gfx_if.h index 4137dc710aafd..7ad0434be293b 100644 --- a/drivers/gpu/drm/amd/amdgpu/psp_gfx_if.h +++ b/drivers/gpu/drm/amd/amdgpu/psp_gfx_if.h @@ -47,7 +47,7 @@ enum psp_gfx_crtl_cmd_id GFX_CTRL_CMD_ID_DISABLE_INT = 0x0006, /* disable PSP-to-Gfx interrupt */ GFX_CTRL_CMD_ID_MODE1_RST = 0x0007, /* trigger the Mode 1 reset */ GFX_CTRL_CMD_ID_GBR_IH_SET = 0x0008, /* set Gbr IH_RB_CNTL registers */ -GFX_CTRL_CMD_ID_CONSUME_CMD = 0x000A, /* send interrupt to psp for updating write pointer of vf */ +GFX_CTRL_CMD_ID_CONSUME_CMD = 0x0009, /* send interrupt to psp for updating write pointer of vf */ GFX_CTRL_CMD_ID_DESTROY_GPCOM_RING = 0x000C, /* destroy GPCOM ring */ GFX_CTRL_CMD_ID_MAX = 0x000F, /* max command ID */ -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [drm:dm_plane_helper_prepare_fb [amdgpu]] *ERROR* Failed to pin framebuffer with error -12
On Fri, 15 Jan 2021 at 03:43, Mikhail Gavrilov
wrote:
>
In rc4, the number of warnings has dropped dramatically.
No more errors "kasan slab-out-of-bounds" and no "DMA-API device
driver failed to check map error".
But still not fixed "sleeping function called from invalid context at
include/linux/sched/mm.h:196" and "BUG: key 88810b0d9148 has not
been registered!"
Second issue Navi specific because it started to happen in 5.10 kernel
after replacing Radeon VII to 6900XT.
1.
BUG: sleeping function called from invalid context at
include/linux/sched/mm.h:196
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 500, name: systemd-udevd
1 lock held by systemd-udevd/500:
#0: 888107690258 (&dev->mutex){}-{3:3}, at:
device_driver_attach+0xa3/0x250
CPU: 9 PID: 500 Comm: systemd-udevd Not tainted
5.11.0-0.rc4.129.fc34.x86_64+debug #1
Hardware name: System manufacturer System Product Name/ROG STRIX
X570-I GAMING, BIOS 2802 10/21/2020
Call Trace:
dump_stack+0xae/0xe5
___might_sleep.cold+0x150/0x17e
? dcn30_clock_source_create+0x53/0x110 [amdgpu]
kmem_cache_alloc_trace+0x23f/0x270
dcn30_clock_source_create+0x53/0x110 [amdgpu]
dcn30_create_resource_pool+0x998/0x4890 [amdgpu]
? dcn30_calc_max_scaled_time+0x40/0x40 [amdgpu]
? lock_is_held_type+0xb8/0xf0
? unpoison_range+0x3a/0x60
? kasan_kmalloc.constprop.0+0x84/0xa0
? dc_create_resource_pool+0x26e/0x5e0 [amdgpu]
dc_create_resource_pool+0x26e/0x5e0 [amdgpu]
dc_create+0x636/0x1bc0 [amdgpu]
? lock_acquire+0x2dd/0x7a0
? sched_clock+0x5/0x10
? sched_clock_cpu+0x18/0x170
? find_held_lock+0x33/0x110
? dc_create_state+0xa0/0xa0 [amdgpu]
? lock_downgrade+0x6b0/0x6b0
? module_assert_mutex_or_preempt+0x3e/0x70
? lock_is_held_type+0xb8/0xf0
? unpoison_range+0x3a/0x60
? kasan_kmalloc.constprop.0+0x84/0xa0
amdgpu_dm_init.isra.0+0x479/0x640 [amdgpu]
? vprintk_emit+0x1c0/0x460
? dev_vprintk_emit+0x2d8/0x31a
? sched_clock+0x5/0x10
? dm_resume+0x13b0/0x13b0 [amdgpu]
? dev_attr_show.cold+0x35/0x35
? lock_downgrade+0x6b0/0x6b0
? dev_printk_emit+0x8c/0xa8
? dev_vprintk_emit+0x31a/0x31a
? wait_for_completion_io+0x240/0x240
? __dev_printk+0x71/0xdf
? smu_hw_init.cold+0x16b/0x18a [amdgpu]
? smu_suspend+0x240/0x240 [amdgpu]
? navi10_ih_irq_init+0xea3/0x2420 [amdgpu]
dm_hw_init+0xe/0x20 [amdgpu]
amdgpu_device_init.cold+0x3031/0x4940 [amdgpu]
? amdgpu_device_cache_pci_state+0xf0/0xf0 [amdgpu]
? pci_bus_read_config_byte+0x140/0x140
? do_pci_enable_device+0x1f8/0x260
? pci_find_saved_ext_cap+0x110/0x110
? pci_enable_bridge+0xf9/0x1e0
? pci_dev_check_d3cold+0x107/0x250
? pci_enable_device_flags+0x201/0x340
amdgpu_driver_load_kms+0x167/0x8a0 [amdgpu]
amdgpu_pci_probe+0x235/0x360 [amdgpu]
? amdgpu_pci_remove+0xd0/0xd0 [amdgpu]
local_pci_probe+0xd8/0x170
pci_device_probe+0x318/0x5c0
? kernfs_create_link+0x16c/0x230
? pci_device_remove+0x1d0/0x1d0
really_probe+0x224/0xc40
driver_probe_device+0x1f2/0x380
device_driver_attach+0x1df/0x250
__driver_attach+0xf6/0x260
? device_driver_attach+0x250/0x250
bus_for_each_dev+0x114/0x180
? subsys_dev_iter_exit+0x10/0x10
bus_add_driver+0x352/0x570
driver_register+0x20f/0x390
? __pci_register_driver+0x13a/0x210
? 0xc1d8d000
do_one_initcall+0xfb/0x530
? perf_trace_initcall_level+0x3d0/0x3d0
? __memset+0x2b/0x30
? unpoison_range+0x3a/0x60
do_init_module+0x1ce/0x7a0
load_module+0x9841/0xa380
? module_frob_arch_sections+0x20/0x20
? lockdep_hardirqs_on_prepare+0x3e0/0x3e0
? sched_clock_cpu+0x18/0x170
? sched_clock+0x5/0x10
? lock_acquire+0x2dd/0x7a0
? sched_clock+0x5/0x10
? lock_is_held_type+0xb8/0xf0
? __do_sys_init_module+0x18b/0x220
__do_sys_init_module+0x18b/0x220
? load_module+0xa380/0xa380
? ktime_get_coarse_real_ts64+0x12f/0x160
do_syscall_64+0x33/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7f2c109da07e
Code: 48 8b 0d f5 1d 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f
84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 af 00 00 00 0f 05 <48> 3d
01 f0 ff ff 73 01 c3 48 8b 0d c2 1d 0c 00 f7 d8 64 89 01 48
RSP: 002b:7ffc84d33f88 EFLAGS: 0246 ORIG_RAX: 00af
RAX: ffda RBX: 55b87f8260a0 RCX: 7f2c109da07e
RDX: 55b87f834060 RSI: 01e2cbf6 RDI: 7f2c0b7e0010
RBP: 7f2c0b7e0010 R08: 55b87f8281e0 R09: 7ffc84d30a26
R10: 55bd2404cc18 R11: 0246 R12: 55b87f834060
R13: 55b87f831ca0 R14: R15: 55b87f832640
[drm] Display Core initialized with v3.2.116!
[drm] DMUB hardware initialized: version=0x0201
usb 1-3.2: Device not responding to setup address.
usb 1-3.2: device not accepting address 5, error -71
[drm] REG_WAIT timeout 1us * 10 tries - mpc2_assert_idle_mpcc line:480
2.
BUG: key 88810b0d9148 has not been registered!
[ cut here ]
DEBUG_LOCKS_WARN_ON(1)
WARNING: CPU: 25 PID: 500 at kernel/locking/lockdep.c:4618
lockdep_init_map_waits+0x592/0x770
Modules linked in: amdgpu(+) drm_ttm_helper ttm iommu_v2 gpu_sched
drm
linux-next: build failure after merge of the drm-intel tree
Hi all,
After merging the drm-intel tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/gpu/drm/msm/dp/dp_ctrl.c: In function 'dp_ctrl_use_fixed_nvid':
drivers/gpu/drm/msm/dp/dp_ctrl.c:1425:16: error: implicit declaration of
function 'drm_dp_get_edid_quirks'; did you mean 'drm_do_get_edid'?
[-Werror=implicit-function-declaration]
1425 | edid_quirks = drm_dp_get_edid_quirks(ctrl->panel->edid);
|^~
|drm_do_get_edid
drivers/gpu/drm/msm/dp/dp_ctrl.c:1431:11: error: too many arguments to function
'drm_dp_has_quirk'
1431 | return (drm_dp_has_quirk(&ctrl->panel->desc, edid_quirks,
| ^~~~
In file included from drivers/gpu/drm/msm/dp/dp_ctrl.c:15:
include/drm/drm_dp_helper.h:2087:1: note: declared here
2087 | drm_dp_has_quirk(const struct drm_dp_desc *desc, enum drm_dp_quirk
quirk)
| ^~~~
Caused by commit
7c553f8b5a7d ("drm/dp: Revert "drm/dp: Introduce EDID-based quirks"")
Since the drm-intel tree still has its other build failure, I used the
version from next-20210108 again today.
--
Cheers,
Stephen Rothwell
pgpCNk21YxPSD.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/5] Share mtk mutex driver for both DRM and MDP
Chun-Kuang Hu 於 2021年1月7日 週四 上午7:17寫道：
>
> mtk mutex is a driver used by DRM and MDP [1], so this series move
> mtk mutex driver from DRM folder to soc folder, so it could be used
> by DRM and MDP.
Applied [1/5] ~ [4/5] to mediatek-drm-next [1].
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
Regards,
Chun-Kuang.
>
> Changes in v2:
> 1. Rebase onto mediatek-drm-next [2].
> 2. Export symbol for mtk-mutex API.
>
> [1] https://patchwork.kernel.org/patch/11140751/
> [2]
> https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
>
> CK Hu (5):
> drm/mediatek: Remove redundant file including
> drm/mediatek: Rename file mtk_drm_ddp to mtk_mutex
> drm/mediatek: Change disp/ddp term to mutex in mtk mutex driver
> drm/mediatek: Automatically search unclaimed mtk mutex in
> mtk_mutex_get()
> soc / drm: mediatek: Move mtk mutex driver to soc folder
>
> drivers/gpu/drm/mediatek/Makefile | 1 -
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 32 +-
> drivers/gpu/drm/mediatek/mtk_drm_ddp.h| 28 --
> drivers/gpu/drm/mediatek/mtk_drm_drv.c| 3 -
> drivers/gpu/drm/mediatek/mtk_drm_drv.h| 1 -
> drivers/soc/mediatek/Makefile | 1 +
> .../mediatek/mtk-mutex.c} | 328 +-
> include/linux/soc/mediatek/mtk-mutex.h| 26 ++
> 8 files changed, 212 insertions(+), 208 deletions(-)
> delete mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp.h
> rename drivers/{gpu/drm/mediatek/mtk_drm_ddp.c => soc/mediatek/mtk-mutex.c}
> (53%)
> create mode 100644 include/linux/soc/mediatek/mtk-mutex.h
>
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm/msm: Call suspend/resume conditionally
When putting iMX5 into suspend, the following flow is
observed:
[ 70.023427] [] (msm_atomic_commit_tail) from []
(commit_tail+0x9c/0x18c)
[ 70.031890] [] (commit_tail) from []
(drm_atomic_helper_commit+0x1a0/0x1d4)
[ 70.040627] [] (drm_atomic_helper_commit) from
[] (drm_atomic_helper_disable_all+0x1c4/0x1d4)
[ 70.050913] [] (drm_atomic_helper_disable_all) from
[] (drm_atomic_helper_suspend+0xb8/0x170)
[ 70.061198] [] (drm_atomic_helper_suspend) from
[] (drm_mode_config_helper_suspend+0x24/0x58)
In the i.MX5 case, priv->kms is not populated (as i.MX5 does not use any
of the Qualcomm display controllers), causing a NULL pointer
dereference in msm_atomic_commit_tail():
[ 24.268964] 8<--- cut here ---
[ 24.274602] Unable to handle kernel NULL pointer dereference at
virtual address
[ 24.283434] pgd = (ptrval)
[ 24.286387] [] *pgd=ca212831
[ 24.290788] Internal error: Oops: 17 [#1] SMP ARM
[ 24.295609] Modules linked in:
[ 24.298777] CPU: 0 PID: 197 Comm: init Not tainted 5.11.0-rc2-next-20210111
#333
[ 24.306276] Hardware name: Freescale i.MX53 (Device Tree Support)
[ 24.312442] PC is at msm_atomic_commit_tail+0x54/0xb9c
[ 24.317743] LR is at commit_tail+0xa4/0x1b0
Fix the problem by calling drm_mode_config_helper_suspend/resume()
conditionally.
Cc:
Fixes: ca8199f13498 ("drm/msm/dpu: ensure device suspend happens during PM
sleep")
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Newly introduced in this series.
drivers/gpu/drm/msm/msm_drv.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index c082b72b9e3b..0d1a94e06912 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1072,14 +1072,17 @@ static int __maybe_unused msm_pm_prepare(struct device
*dev)
{
struct drm_device *ddev = dev_get_drvdata(dev);
- return drm_mode_config_helper_suspend(ddev);
+ if (of_device_get_match_data(dev))
+ return drm_mode_config_helper_suspend(ddev);
+ return 0;
}
static void __maybe_unused msm_pm_complete(struct device *dev)
{
struct drm_device *ddev = dev_get_drvdata(dev);
- drm_mode_config_helper_resume(ddev);
+ if (of_device_get_match_data(dev))
+ drm_mode_config_helper_resume(ddev);
}
static const struct dev_pm_ops msm_pm_ops = {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] drm/msm: Call shutdown conditionally
Issuing a 'reboot' command in i.MX5 leads to the following flow:
[ 24.557742] [] (msm_atomic_commit_tail) from []
(commit_tail+0xa4/0x1b0)
[ 24.566349] [] (commit_tail) from []
(drm_atomic_helper_commit+0x154/0x188)
[ 24.575193] [] (drm_atomic_helper_commit) from
[] (drm_atomic_helper_disable_all+0x154/0x1c0)
[ 24.585599] [] (drm_atomic_helper_disable_all) from
[] (drm_atomic_helper_shutdown+0x94/0x12c)
[ 24.596094] [] (drm_atomic_helper_shutdown) from
In the i.MX5 case, priv->kms is not populated (as i.MX5 does not use any
of the Qualcomm display controllers), causing a NULL pointer
dereference in msm_atomic_commit_tail():
[ 24.268964] 8<--- cut here ---
[ 24.274602] Unable to handle kernel NULL pointer dereference at
virtual address
[ 24.283434] pgd = (ptrval)
[ 24.286387] [] *pgd=ca212831
[ 24.290788] Internal error: Oops: 17 [#1] SMP ARM
[ 24.295609] Modules linked in:
[ 24.298777] CPU: 0 PID: 197 Comm: init Not tainted 5.11.0-rc2-next-20210111
#333
[ 24.306276] Hardware name: Freescale i.MX53 (Device Tree Support)
[ 24.312442] PC is at msm_atomic_commit_tail+0x54/0xb9c
[ 24.317743] LR is at commit_tail+0xa4/0x1b0
Fix the problem by calling drm_atomic_helper_shutdown() conditionally.
Cc:
Fixes: 9d5cbf5fe46e ("drm/msm: add shutdown support for display
platform_driver")
Suggested-by: Rob Clark
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Explain in the commit log that the problem happens after a 'reboot' command.
drivers/gpu/drm/msm/msm_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 108c405e03dd..c082b72b9e3b 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1311,7 +1311,8 @@ static void msm_pdev_shutdown(struct platform_device
*pdev)
{
struct drm_device *drm = platform_get_drvdata(pdev);
- drm_atomic_helper_shutdown(drm);
+ if (get_mdp_ver(pdev))
+ drm_atomic_helper_shutdown(drm);
}
static const struct of_device_id dt_match[] = {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] drm/msm: Call shutdown conditionally
Issuing a 'reboot' command in i.MX5 leads to the following flow:
[ 24.557742] [] (msm_atomic_commit_tail) from []
(commit_tail+0xa4/0x1b0)
[ 24.566349] [] (commit_tail) from []
(drm_atomic_helper_commit+0x154/0x188)
[ 24.575193] [] (drm_atomic_helper_commit) from
[] (drm_atomic_helper_disable_all+0x154/0x1c0)
[ 24.585599] [] (drm_atomic_helper_disable_all) from
[] (drm_atomic_helper_shutdown+0x94/0x12c)
[ 24.596094] [] (drm_atomic_helper_shutdown) from
In the i.MX5 case, priv->kms is not populated (as i.MX5 does not use any
of the Qualcomm display controllers), causing a NULL pointer
dereference in msm_atomic_commit_tail():
[ 24.268964] 8<--- cut here ---
[ 24.274602] Unable to handle kernel NULL pointer dereference at
virtual address
[ 24.283434] pgd = (ptrval)
[ 24.286387] [] *pgd=ca212831
[ 24.290788] Internal error: Oops: 17 [#1] SMP ARM
[ 24.295609] Modules linked in:
[ 24.298777] CPU: 0 PID: 197 Comm: init Not tainted 5.11.0-rc2-next-20210111
#333
[ 24.306276] Hardware name: Freescale i.MX53 (Device Tree Support)
[ 24.312442] PC is at msm_atomic_commit_tail+0x54/0xb9c
[ 24.317743] LR is at commit_tail+0xa4/0x1b0
Fix the problem by calling drm_atomic_helper_shutdown() conditionally.
Cc:
Fixes: 9d5cbf5fe46e ("drm/msm: add shutdown support for display
platform_driver")
Suggested-by: Rob Clark
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Explain in the commit log that the problem happens after a 'reboot' command.
drivers/gpu/drm/msm/msm_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 108c405e03dd..c082b72b9e3b 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1311,7 +1311,8 @@ static void msm_pdev_shutdown(struct platform_device
*pdev)
{
struct drm_device *drm = platform_get_drvdata(pdev);
- drm_atomic_helper_shutdown(drm);
+ if (get_mdp_ver(pdev))
+ drm_atomic_helper_shutdown(drm);
}
static const struct of_device_id dt_match[] = {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/amdgpu/display: buffer INTERRUPT_LOW_IRQ_CONTEXT interrupt work
On 1/15/21 2:21 AM, Chen, Xiaogang wrote:
On 1/14/2021 1:24 AM, Grodzovsky, Andrey wrote:
On 1/14/21 12:11 AM, Chen, Xiaogang wrote:
On 1/12/2021 10:54 PM, Grodzovsky, Andrey wrote:
On 1/4/21 1:01 AM, Xiaogang.Chen wrote:
From: Xiaogang Chen
amdgpu DM handles INTERRUPT_LOW_IRQ_CONTEXT interrupt(hpd, hpd_rx) by
using work queue and uses single work_struct. If previous interrupt
has not been handled new interrupts(same type) will be discarded and
driver just sends "amdgpu_dm_irq_schedule_work FAILED" message out.
If some important hpd, hpd_rx related interrupts are missed by driver
the hot (un)plug devices may cause system hang or unstable, such as
system resumes from S3 sleep with mst device connected.
This patch dynamically allocates new amdgpu_dm_irq_handler_data for
new interrupts if previous INTERRUPT_LOW_IRQ_CONTEXT interrupt work
has not been handled. So the new interrupt works can be queued to the
same workqueue_struct, instead discard the new interrupts.
All allocated amdgpu_dm_irq_handler_data are put into a single linked
list and will be reused after.
I believe this creates a possible concurrency between already
executing work item
and the new incoming one for which you allocate a new work item on
the fly. While
handle_hpd_irq is serialized with aconnector->hpd_lock I am seeing
that for handle_hpd_rx_irq
it's not locked for MST use case (which is the most frequently used
with this interrupt). Did you
verified that handle_hpd_rx_irq is reentrant ?
handle_hpd_rx_irq is put at a work queue. Its execution is serialized
by the work queue. So there is no reentrant.
You are using system_highpri_wq which has the property that it has
multiple workers thread pool spread across all the
active CPUs, see all work queue definitions here
https://elixir.bootlin.com/linux/v5.11-rc3/source/include/linux/workqueue.h#L358
I beleieve that what you saying about no chance of reentrnacy would be
correct if it would be same work item dequeued for execution
while previous instance is still running, see the explanation here -
https://elixir.bootlin.com/linux/v5.11-rc3/source/kernel/workqueue.c#L1435.
Non reentrancy is guaranteed only for the same work item. If you want
non reentrancy (full serializtion) for different work items you should
create
you own single threaded work-queue using create_singlethread_workqueue
Thank you. I think the easiest way is using aconnector->hpd_lock at
handle_hpd_rx_irq to lock for dc_link->type == dc_connection_mst_branch
case, right? I will do that at next version if you think it is ok.
I am not sure what are the consequences of of using hpd lock there with
regard to other locks acquired in DRM MST code during MST related HPD
transactions since
i haven't dealt with this for a very long time. Maybe Harry or Nick can advise
on this ?
Andrey
amdgpu_dm_irq_schedule_work does queuing of work(put
handle_hpd_rx_irq into work queue). The first call is
dm_irq_work_func, then call handle_hpd_rx_irq.
Signed-off-by: Xiaogang Chen
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 14 +--
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | 114
++---
2 files changed, 80 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index c9d82b9..730e540 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -69,18 +69,6 @@ struct common_irq_params {
};
/**
- * struct irq_list_head - Linked-list for low context IRQ handlers.
- *
- * @head: The list_head within &struct handler_data
- * @work: A work_struct containing the deferred handler work
- */
-struct irq_list_head {
- struct list_head head;
- /* In case this interrupt needs post-processing, 'work' will
be queued*/
- struct work_struct work;
-};
-
-/**
* struct dm_compressor_info - Buffer info used by frame buffer
compression
* @cpu_addr: MMIO cpu addr
* @bo_ptr: Pointer to the buffer object
@@ -270,7 +258,7 @@ struct amdgpu_display_manager {
* Note that handlers are called in the same order as they were
* registered (FIFO).
*/
- struct irq_list_head
irq_handler_list_low_tab[DAL_IRQ_SOURCES_NUMBER];
+ struct list_head
irq_handler_list_low_tab[DAL_IRQ_SOURCES_NUMBER];
/**
* @irq_handler_list_high_tab:
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
index 3577785..ada344a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
@@ -82,6 +82,7 @@ struct amdgpu_dm_irq_handler_data {
struct amdgpu_display_manager *dm;
/* DAL irq source which registered for this interrupt. */
enum dc_irq_source irq_source;
+ struct work_struct work;
};
#define DM_IRQ_TABLE_LOCK(adev, flags) \
@@ -111,20 +112,10 @@
[Bug 210321] /display/dc/dcn20/dcn20_resource.c:3240 dcn20_validate_bandwidth_fp+0x8b/0xd0 [amdgpu]
https://bugzilla.kernel.org/show_bug.cgi?id=210321 --- Comment #3 from Florian Evers (florian-ev...@gmx.de) --- Hi, new info: this "crash" can be reproduced very easily here on my system. It is enough to switch the screen off and on again to find the dump in the dmesg log. I did not test yet whether it happens during switching off or while switiching it back on, but I may test that using a second box. I first noticed that the crash never happens if I work or play on my computer, but if I come back after a pause I certainly found it in the logs. Thus I got the assumption that it happens during the power saving phase of the screen. Interestingly, using the power switch of the screen the dump can be triggered very easily and 100% reliably. Hope this helps! Regards, Florian -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm: Call shutdown conditionally
On Tue, Jan 19, 2021 at 10:49 PM Fabio Estevam wrote: > > Hi Daniel, > > On Tue, Jan 19, 2021 at 3:01 PM Daniel Vetter wrote: > > > Don't we need the same treatment for suspend/resume too? Also if you > > Yes, you are right. I have just tested suspend/resume and the problem > is there too: > > [ 69.708552] 8<--- cut here --- > [ 69.711970] Unable to handle kernel NULL pointer dereference at > virtual address > [ 69.720240] pgd = (ptrval) > [ 69.723000] [] *pgd=ca217831 > [ 69.726664] Internal error: Oops: 17 [#1] SMP ARM > [ 69.731387] Modules linked in: > [ 69.734463] CPU: 0 PID: 167 Comm: sh Not tainted > 5.11.0-rc3-next-20210118-dirty #383 > [ 69.742223] Hardware name: Freescale i.MX53 (Device Tree Support) > [ 69.748326] PC is at msm_atomic_commit_tail+0x50/0xb90 > [ 69.753505] LR is at commit_tail+0x9c/0x18c > [ 69.757705] pc : []lr : []psr: 6013 > [ 69.763982] sp : c28bfcd8 ip : fffa fp : c24c20a0 > [ 69.769217] r10: c0f82720 r9 : 0010 r8 : 3a62b298 > [ 69.774452] r7 : c23a3000 r6 : c2816c00 r5 : r4 : > [ 69.780990] r3 : c24c2c00 r2 : r1 : r0 : > [ 69.787529] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment > none > [ 69.794679] Control: 10c5387d Table: 72870019 DAC: 0051 > [ 69.800434] Process sh (pid: 167, stack limit = 0x(ptrval)) > [ 69.806019] Stack: (0xc28bfcd8 to 0xc28c) > [ 69.810391] fcc0: > 20bfa1e1 > [ 69.818584] fce0: 0010 8a7c54c5 > c2816c00 c23a3000 > [ 69.826778] fd00: 3a62b298 0010 c0f82720 c24c20a0 > c06e7218 c2816c00 > [ 69.834972] fd20: c23a3000 c2816c2c c16093d4 c17682f0 > c0e2920c > [ 69.843166] fd40: c12ca028 c23a3000 c23a3494 c2816c00 > c23a349c c24c2010 c06e74d4 > [ 69.851359] fd60: c23a3000 c2816480 c07050ec c24c2010 > c0e2943c c1609798 c296a880 > [ 69.859552] fd80: 0009 0001 c175f454 > c175f458 c1c669cc > [ 69.867745] fda0: c12c9acc 0001 0009 > c23a32e4 c23a32e4 > [ 69.875938] fdc0: c1609388 c28be000 c23a3000 c28be000 > c1765220 c17682f0 c06e84bc > [ 69.884132] fde0: c24c2138 c28be000 c1765220 c07e9f58 0010 > c176833c 0002 c0777850 > [ 69.892326] fe00: c1e08a9c 0002 0010 396ed042 > 0001 c1e08ac0 > [ 69.900519] fe20: c07ea57c c296ae28 c0e33ba0 > c1e08a9c 0003 c125a7c8 > [ 69.908714] fe40: c17fa154 c01954a8 c16093d4 0001 c1e08ac0 > c1609388 > [ 69.916907] fe60: c28bfe74 0003 c125a7c8 c17fa154 > 0001 c1e08ac0 > [ 69.925100] fe80: c01963a4 0003 c2a9f040 0003 > 0004 c1254a00 c01943b0 > [ 69.933294] fea0: 0004 c2901f10 c2a9f040 c2901f00 00d220f0 > c28bff78 c0374f0c > [ 69.941488] fec0: 00d220f0 c29488c0 > 0004 00d220f0 c28bff78 > [ 69.949681] fee0: c02c31c4 c0374e00 c2803000 c02c2bfc 0001 > c02c31c4 c2943bd0 > [ 69.957876] ff00: c02e7428 c17ee19c c296adc8 c2943bd0 > c0183a34 c2943bd0 c02e7428 > [ 69.966070] ff20: c28be000 c296a880 c1609798 c018ced8 c296adc8 > c0e33ba0 c17ee2de 6013 > [ 69.974264] ff40: 0001 c1609388 c17ee2de > c29488c0 c29488c0 00d220f0 > [ 69.982457] ff60: 0004 0004 00d20284 > c02c31c4 > [ 69.990651] ff80: c010019c c1609388 c1609798 0001 > 000d7b54 0004 c0100264 > [ 69.998844] ffa0: c28be000 c0100080 0001 0001 > 00d220f0 0004 > [ 70.007039] ffc0: 0001 000d7b54 0004 0004 > 0020 00d20410 00d20284 > [ 70.015232] ffe0: 000d7258 be831960 0001b93c b6ee97a0 6010 > 0001 > [ 70.023427] [] (msm_atomic_commit_tail) from [] > (commit_tail+0x9c/0x18c) > [ 70.031890] [] (commit_tail) from [] > (drm_atomic_helper_commit+0x1a0/0x1d4) > [ 70.040627] [] (drm_atomic_helper_commit) from > [] (drm_atomic_helper_disable_all+0x1c4/0x1d4) > [ 70.050913] [] (drm_atomic_helper_disable_all) from > [] (drm_atomic_helper_suspend+0xb8/0x170) > [ 70.061198] [] (drm_atomic_helper_suspend) from > [] (drm_mode_config_helper_suspend+0x24/0x58) > [ 70.071486] [] (drm_mode_config_helper_suspend) from > [] (dpm_prepare+0x1ac/0x7b0) > [ 70.080738] [] (dpm_prepare) from [] > (dpm_suspend_start+0x20/0x98) > [ 70.088679] [] (dpm_suspend_start) from [] > (suspend_devices_and_enter+0xfc/0xcb8) > [ 70.097931] [] (suspend_devices_and_enter) from > [] (pm_suspend+0x340/0x3e8) > [ 70.106651] [] (pm_suspend) from [] > (state_store+0x68/0xc8) > [ 70.113982] [] (state_store) from [] > (kernfs_fop_write+0x10c/0x22c) > [ 70.122016] [] (kernfs_fop_write) from [] > (vfs_write+0xc4/0x53c) > [ 70.129795] [] (vfs_write) from [] > (ksys_wri
Re: [PATCH v4 07/14] drm/amdgpu: Register IOMMU topology notifier per device.
On Tue, Jan 19, 2021 at 10:22 PM Andrey Grodzovsky
wrote:
>
>
> On 1/19/21 8:45 AM, Daniel Vetter wrote:
>
> On Tue, Jan 19, 2021 at 09:48:03AM +0100, Christian König wrote:
>
> Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
>
> Handle all DMA IOMMU gropup related dependencies before the
> group is removed.
>
> Signed-off-by: Andrey Grodzovsky
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu.h| 5
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 46
> ++
> drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h | 1 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 10 +++
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 ++
> 6 files changed, 65 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 478a7d8..2953420 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -51,6 +51,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> @@ -1041,6 +1042,10 @@ struct amdgpu_device {
> boolin_pci_err_recovery;
> struct pci_saved_state *pci_state;
> +
> + struct notifier_block nb;
> + struct blocking_notifier_head notifier;
> + struct list_head device_bo_list;
> };
> static inline struct amdgpu_device *drm_to_adev(struct drm_device *ddev)
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 45e23e3..e99f4f1 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -70,6 +70,8 @@
> #include
> #include
> +#include
> +
> MODULE_FIRMWARE("amdgpu/vega10_gpu_info.bin");
> MODULE_FIRMWARE("amdgpu/vega12_gpu_info.bin");
> MODULE_FIRMWARE("amdgpu/raven_gpu_info.bin");
> @@ -3200,6 +3202,39 @@ static const struct attribute *amdgpu_dev_attributes[]
> = {
> };
> +static int amdgpu_iommu_group_notifier(struct notifier_block *nb,
> + unsigned long action, void *data)
> +{
> + struct amdgpu_device *adev = container_of(nb, struct amdgpu_device, nb);
> + struct amdgpu_bo *bo = NULL;
> +
> + /*
> + * Following is a set of IOMMU group dependencies taken care of before
> + * device's IOMMU group is removed
> + */
> + if (action == IOMMU_GROUP_NOTIFY_DEL_DEVICE) {
> +
> + spin_lock(&ttm_bo_glob.lru_lock);
> + list_for_each_entry(bo, &adev->device_bo_list, bo) {
> + if (bo->tbo.ttm)
> + ttm_tt_unpopulate(bo->tbo.bdev, bo->tbo.ttm);
> + }
> + spin_unlock(&ttm_bo_glob.lru_lock);
>
> That approach won't work. ttm_tt_unpopulate() might sleep on an IOMMU lock.
>
> You need to use a mutex here or even better make sure you can access the
> device_bo_list without a lock in this moment.
>
> I'd also be worried about the notifier mutex getting really badly in the
> way.
>
> Plus I'm worried why we even need this, it sounds a bit like papering over
> the iommu subsystem. Assuming we clean up all our iommu mappings in our
> device hotunplug/unload code, why do we still need to have an additional
> iommu notifier on top, with all kinds of additional headaches? The iommu
> shouldn't clean up before the devices in its group have cleaned up.
>
> I think we need more info here on what the exact problem is first.
> -Daniel
>
>
> Originally I experienced the crash bellow on IOMMU enabled device, it
> happens post device removal from PCI topology -
> during shutting down of user client holding last reference to drm device file
> (X in my case).
> The crash is because by the time I get to this point struct
> device->iommu_group pointer is NULL
> already since the IOMMU group for the device is unset during PCI removal. So
> this contradicts what you said above
> that the iommu shouldn't clean up before the devices in its group have
> cleaned up.
> So instead of guessing when is the right place to place all IOMMU related
> cleanups it makes sense
> to get notification from IOMMU subsystem in the form of event
> IOMMU_GROUP_NOTIFY_DEL_DEVICE
> and use that place to do all the relevant cleanups.
Yeah that goes boom, but you shouldn't need this special iommu cleanup
handler. Making sure that all the dma-api mappings are gone needs to
be done as part of the device hotunplug, you can't delay that to the
last drm_device cleanup.
So I most of the patch here with pulling that out (should be outright
removed from the final release code even) is good, just not yet how
you call that new code. Probably these bits (aside from walking all
buffers and unpopulating the tt) should be done from the early_free
callback you're adding.
Also what I just realized: For normal unload you need to make sure the
hw is actually stopped first, before we unmap buffers. Otherwise
driver unload will likely result in wedged hw, probably not what you
want for debugging.
-Daniel
> Andrey
>
>
> [ 123.810074 < 28.126960>] BUG: kernel NULL pointer dereferenc
Re: [PATCH] drm/msm: Call shutdown conditionally
Hi Daniel, On Tue, Jan 19, 2021 at 3:01 PM Daniel Vetter wrote: > Don't we need the same treatment for suspend/resume too? Also if you Yes, you are right. I have just tested suspend/resume and the problem is there too: [ 69.708552] 8<--- cut here --- [ 69.711970] Unable to handle kernel NULL pointer dereference at virtual address [ 69.720240] pgd = (ptrval) [ 69.723000] [] *pgd=ca217831 [ 69.726664] Internal error: Oops: 17 [#1] SMP ARM [ 69.731387] Modules linked in: [ 69.734463] CPU: 0 PID: 167 Comm: sh Not tainted 5.11.0-rc3-next-20210118-dirty #383 [ 69.742223] Hardware name: Freescale i.MX53 (Device Tree Support) [ 69.748326] PC is at msm_atomic_commit_tail+0x50/0xb90 [ 69.753505] LR is at commit_tail+0x9c/0x18c [ 69.757705] pc : []lr : []psr: 6013 [ 69.763982] sp : c28bfcd8 ip : fffa fp : c24c20a0 [ 69.769217] r10: c0f82720 r9 : 0010 r8 : 3a62b298 [ 69.774452] r7 : c23a3000 r6 : c2816c00 r5 : r4 : [ 69.780990] r3 : c24c2c00 r2 : r1 : r0 : [ 69.787529] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 69.794679] Control: 10c5387d Table: 72870019 DAC: 0051 [ 69.800434] Process sh (pid: 167, stack limit = 0x(ptrval)) [ 69.806019] Stack: (0xc28bfcd8 to 0xc28c) [ 69.810391] fcc0: 20bfa1e1 [ 69.818584] fce0: 0010 8a7c54c5 c2816c00 c23a3000 [ 69.826778] fd00: 3a62b298 0010 c0f82720 c24c20a0 c06e7218 c2816c00 [ 69.834972] fd20: c23a3000 c2816c2c c16093d4 c17682f0 c0e2920c [ 69.843166] fd40: c12ca028 c23a3000 c23a3494 c2816c00 c23a349c c24c2010 c06e74d4 [ 69.851359] fd60: c23a3000 c2816480 c07050ec c24c2010 c0e2943c c1609798 c296a880 [ 69.859552] fd80: 0009 0001 c175f454 c175f458 c1c669cc [ 69.867745] fda0: c12c9acc 0001 0009 c23a32e4 c23a32e4 [ 69.875938] fdc0: c1609388 c28be000 c23a3000 c28be000 c1765220 c17682f0 c06e84bc [ 69.884132] fde0: c24c2138 c28be000 c1765220 c07e9f58 0010 c176833c 0002 c0777850 [ 69.892326] fe00: c1e08a9c 0002 0010 396ed042 0001 c1e08ac0 [ 69.900519] fe20: c07ea57c c296ae28 c0e33ba0 c1e08a9c 0003 c125a7c8 [ 69.908714] fe40: c17fa154 c01954a8 c16093d4 0001 c1e08ac0 c1609388 [ 69.916907] fe60: c28bfe74 0003 c125a7c8 c17fa154 0001 c1e08ac0 [ 69.925100] fe80: c01963a4 0003 c2a9f040 0003 0004 c1254a00 c01943b0 [ 69.933294] fea0: 0004 c2901f10 c2a9f040 c2901f00 00d220f0 c28bff78 c0374f0c [ 69.941488] fec0: 00d220f0 c29488c0 0004 00d220f0 c28bff78 [ 69.949681] fee0: c02c31c4 c0374e00 c2803000 c02c2bfc 0001 c02c31c4 c2943bd0 [ 69.957876] ff00: c02e7428 c17ee19c c296adc8 c2943bd0 c0183a34 c2943bd0 c02e7428 [ 69.966070] ff20: c28be000 c296a880 c1609798 c018ced8 c296adc8 c0e33ba0 c17ee2de 6013 [ 69.974264] ff40: 0001 c1609388 c17ee2de c29488c0 c29488c0 00d220f0 [ 69.982457] ff60: 0004 0004 00d20284 c02c31c4 [ 69.990651] ff80: c010019c c1609388 c1609798 0001 000d7b54 0004 c0100264 [ 69.998844] ffa0: c28be000 c0100080 0001 0001 00d220f0 0004 [ 70.007039] ffc0: 0001 000d7b54 0004 0004 0020 00d20410 00d20284 [ 70.015232] ffe0: 000d7258 be831960 0001b93c b6ee97a0 6010 0001 [ 70.023427] [] (msm_atomic_commit_tail) from [] (commit_tail+0x9c/0x18c) [ 70.031890] [] (commit_tail) from [] (drm_atomic_helper_commit+0x1a0/0x1d4) [ 70.040627] [] (drm_atomic_helper_commit) from [] (drm_atomic_helper_disable_all+0x1c4/0x1d4) [ 70.050913] [] (drm_atomic_helper_disable_all) from [] (drm_atomic_helper_suspend+0xb8/0x170) [ 70.061198] [] (drm_atomic_helper_suspend) from [] (drm_mode_config_helper_suspend+0x24/0x58) [ 70.071486] [] (drm_mode_config_helper_suspend) from [] (dpm_prepare+0x1ac/0x7b0) [ 70.080738] [] (dpm_prepare) from [] (dpm_suspend_start+0x20/0x98) [ 70.088679] [] (dpm_suspend_start) from [] (suspend_devices_and_enter+0xfc/0xcb8) [ 70.097931] [] (suspend_devices_and_enter) from [] (pm_suspend+0x340/0x3e8) [ 70.106651] [] (pm_suspend) from [] (state_store+0x68/0xc8) [ 70.113982] [] (state_store) from [] (kernfs_fop_write+0x10c/0x22c) [ 70.122016] [] (kernfs_fop_write) from [] (vfs_write+0xc4/0x53c) [ 70.129795] [] (vfs_write) from [] (ksys_write+0x60/0xec) [ 70.136952] [] (ksys_write) from [] (ret_fast_syscall+0x0/0x2c) [ 70.144630] Exception stack(0xc28bffa8 to 0xc28bfff0) [ 70.149697] ffa0: 0001 0001 00d220f0 0004 [ 70.157891] ffc0: 0001 000
Re: [PATCH v4 07/14] drm/amdgpu: Register IOMMU topology notifier per device.
On 1/19/21 8:45 AM, Daniel Vetter wrote:
On Tue, Jan 19, 2021 at 09:48:03AM +0100, Christian König wrote:
Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
Handle all DMA IOMMU gropup related dependencies before the
group is removed.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 5
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 46
++
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 10 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 ++
6 files changed, 65 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 478a7d8..2953420 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -51,6 +51,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1041,6 +1042,10 @@ struct amdgpu_device {
boolin_pci_err_recovery;
struct pci_saved_state *pci_state;
+
+ struct notifier_block nb;
+ struct blocking_notifier_head notifier;
+ struct list_headdevice_bo_list;
};
static inline struct amdgpu_device *drm_to_adev(struct drm_device *ddev)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 45e23e3..e99f4f1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -70,6 +70,8 @@
#include
#include
+#include
+
MODULE_FIRMWARE("amdgpu/vega10_gpu_info.bin");
MODULE_FIRMWARE("amdgpu/vega12_gpu_info.bin");
MODULE_FIRMWARE("amdgpu/raven_gpu_info.bin");
@@ -3200,6 +3202,39 @@ static const struct attribute *amdgpu_dev_attributes[] =
{
};
+static int amdgpu_iommu_group_notifier(struct notifier_block *nb,
+unsigned long action, void *data)
+{
+ struct amdgpu_device *adev = container_of(nb, struct amdgpu_device, nb);
+ struct amdgpu_bo *bo = NULL;
+
+ /*
+* Following is a set of IOMMU group dependencies taken care of before
+* device's IOMMU group is removed
+*/
+ if (action == IOMMU_GROUP_NOTIFY_DEL_DEVICE) {
+
+ spin_lock(&ttm_bo_glob.lru_lock);
+ list_for_each_entry(bo, &adev->device_bo_list, bo) {
+ if (bo->tbo.ttm)
+ ttm_tt_unpopulate(bo->tbo.bdev, bo->tbo.ttm);
+ }
+ spin_unlock(&ttm_bo_glob.lru_lock);
That approach won't work. ttm_tt_unpopulate() might sleep on an IOMMU lock.
You need to use a mutex here or even better make sure you can access the
device_bo_list without a lock in this moment.
I'd also be worried about the notifier mutex getting really badly in the
way.
Plus I'm worried why we even need this, it sounds a bit like papering over
the iommu subsystem. Assuming we clean up all our iommu mappings in our
device hotunplug/unload code, why do we still need to have an additional
iommu notifier on top, with all kinds of additional headaches? The iommu
shouldn't clean up before the devices in its group have cleaned up.
I think we need more info here on what the exact problem is first.
-Daniel
Originally I experienced the crash bellow on IOMMU enabled device, it happens
post device removal from PCI topology -
during shutting down of user client holding last reference to drm device file (X
in my case).
The crash is because by the time I get to this point struct device->iommu_group
pointer is NULL
already since the IOMMU group for the device is unset during PCI removal. So
this contradicts what you said above
that the iommu shouldn't clean up before the devices in its group have cleaned
up.
So instead of guessing when is the right place to place all IOMMU related
cleanups it makes sense
to get notification from IOMMU subsystem in the form of event
IOMMU_GROUP_NOTIFY_DEL_DEVICE
and use that place to do all the relevant cleanups.
Andrey
[ 123.810074 < 28.126960>] BUG: kernel NULL pointer dereference, address:
00c8
[ 123.810080 < 0.06>] #PF: supervisor read access in kernel mode
[ 123.810082 < 0.02>] #PF: error_code(0x) - not-present page
[ 123.810085 < 0.03>] PGD 0 P4D 0
[ 123.810089 < 0.04>] Oops: [#1] SMP NOPTI
[ 123.810094 < 0.05>] CPU: 5 PID: 1418 Comm: Xorg:shlo4 Tainted:
G O 5.9.0-rc2-dev+ #59
[ 123.810096 < 0.02>] Hardware name: System manufacturer System Product
Name/PRIME X470-PRO, BIOS 4406 02/28/2019
[ 123.810105 < 0.09>] *RIP: 0010:iommu_get_dma_domain*+0x10/0x20
[ 123.810108 < 0.03>] Code: b0 48 c7 87 98 00 00 00 00 00 00 00 31 c0 c3
b8 f4 ff ff ff eb a6 0f 1f 40 00 0f 1f 44 00 00 48 8b 87 d0 02 00 00 55 48 89 e5
<48> 8b 80 c8 00 00 00 5d c3
[RESEND][PATCH 2/3] dma-buf: heaps: Add a WARN_ON should the vmap_cnt go negative
We shouldn't vunmap more then we vmap, but if we do, make
sure we complain loudly.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Suggested-by: Suren Baghdasaryan
Signed-off-by: John Stultz
---
drivers/dma-buf/heaps/cma_heap.c| 1 +
drivers/dma-buf/heaps/system_heap.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
index 364fc2f3e499..0c76cbc3fb11 100644
--- a/drivers/dma-buf/heaps/cma_heap.c
+++ b/drivers/dma-buf/heaps/cma_heap.c
@@ -232,6 +232,7 @@ static void cma_heap_vunmap(struct dma_buf *dmabuf, struct
dma_buf_map *map)
struct cma_heap_buffer *buffer = dmabuf->priv;
mutex_lock(&buffer->lock);
+ WARN_ON(buffer->vmap_cnt == 0);
if (!--buffer->vmap_cnt) {
vunmap(buffer->vaddr);
buffer->vaddr = NULL;
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index 405351aad2a8..2321c91891f6 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -273,6 +273,7 @@ static void system_heap_vunmap(struct dma_buf *dmabuf,
struct dma_buf_map *map)
struct system_heap_buffer *buffer = dmabuf->priv;
mutex_lock(&buffer->lock);
+ WARN_ON(buffer->vmap_cnt == 0);
if (!--buffer->vmap_cnt) {
vunmap(buffer->vaddr);
buffer->vaddr = NULL;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND][PATCH 3/3] dma-buf: heaps: Rework heep allocation hooks to return struct dma_buf instead of fd
Every heap needs to create a dmabuf and then export it to a fd
via dma_buf_fd(), so to consolidate things a bit, have the heaps
just return a struct dmabuf * and let the top level
dma_heap_buffer_alloc() call handle creating the fd via
dma_buf_fd().
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
drivers/dma-buf/dma-heap.c | 14 +-
drivers/dma-buf/heaps/cma_heap.c| 22 +++---
drivers/dma-buf/heaps/system_heap.c | 21 +++--
include/linux/dma-heap.h| 12 ++--
4 files changed, 33 insertions(+), 36 deletions(-)
diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index afd22c9dbdcf..6b5db954569f 100644
--- a/drivers/dma-buf/dma-heap.c
+++ b/drivers/dma-buf/dma-heap.c
@@ -52,6 +52,9 @@ static int dma_heap_buffer_alloc(struct dma_heap *heap,
size_t len,
unsigned int fd_flags,
unsigned int heap_flags)
{
+ struct dma_buf *dmabuf;
+ int fd;
+
/*
* Allocations from all heaps have to begin
* and end on page boundaries.
@@ -60,7 +63,16 @@ static int dma_heap_buffer_alloc(struct dma_heap *heap,
size_t len,
if (!len)
return -EINVAL;
- return heap->ops->allocate(heap, len, fd_flags, heap_flags);
+ dmabuf = heap->ops->allocate(heap, len, fd_flags, heap_flags);
+ if (IS_ERR(dmabuf))
+ return PTR_ERR(dmabuf);
+
+ fd = dma_buf_fd(dmabuf, fd_flags);
+ if (fd < 0) {
+ dma_buf_put(dmabuf);
+ /* just return, as put will call release and that will free */
+ }
+ return fd;
}
static int dma_heap_open(struct inode *inode, struct file *file)
diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
index 0c76cbc3fb11..985c41ffd85b 100644
--- a/drivers/dma-buf/heaps/cma_heap.c
+++ b/drivers/dma-buf/heaps/cma_heap.c
@@ -272,10 +272,10 @@ static const struct dma_buf_ops cma_heap_buf_ops = {
.release = cma_heap_dma_buf_release,
};
-static int cma_heap_allocate(struct dma_heap *heap,
- unsigned long len,
- unsigned long fd_flags,
- unsigned long heap_flags)
+static struct dma_buf *cma_heap_allocate(struct dma_heap *heap,
+unsigned long len,
+unsigned long fd_flags,
+unsigned long heap_flags)
{
struct cma_heap *cma_heap = dma_heap_get_drvdata(heap);
struct cma_heap_buffer *buffer;
@@ -290,7 +290,7 @@ static int cma_heap_allocate(struct dma_heap *heap,
buffer = kzalloc(sizeof(*buffer), GFP_KERNEL);
if (!buffer)
- return -ENOMEM;
+ return ERR_PTR(-ENOMEM);
INIT_LIST_HEAD(&buffer->attachments);
mutex_init(&buffer->lock);
@@ -349,15 +349,7 @@ static int cma_heap_allocate(struct dma_heap *heap,
ret = PTR_ERR(dmabuf);
goto free_pages;
}
-
- ret = dma_buf_fd(dmabuf, fd_flags);
- if (ret < 0) {
- dma_buf_put(dmabuf);
- /* just return, as put will call release and that will free */
- return ret;
- }
-
- return ret;
+ return dmabuf;
free_pages:
kfree(buffer->pages);
@@ -366,7 +358,7 @@ static int cma_heap_allocate(struct dma_heap *heap,
free_buffer:
kfree(buffer);
- return ret;
+ return ERR_PTR(ret);
}
static const struct dma_heap_ops cma_heap_ops = {
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index 2321c91891f6..7b154424aeb3 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -332,10 +332,10 @@ static struct page *alloc_largest_available(unsigned long
size,
return NULL;
}
-static int system_heap_allocate(struct dma_heap *heap,
- unsigned long len,
- unsigned long fd_flags,
- unsigned long heap_flags)
+static struct dma_buf *system_heap_allocate(struct dma_heap *heap,
+ unsigned long len,
+ unsigned long fd_flags,
+ unsigned long heap_flags)
{
struct system_heap_buffer *buffer;
DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
@@ -350,7 +350,7 @@ static int system_heap_allocate(struct dma_heap *heap,
buffer = kzalloc(sizeof(*buffer),
[RESEND][PATCH 1/3] dma-buf: system_heap: Make sure to return an error if we abort
If we abort from the allocation due to a fatal_signal_pending(),
be sure we report an error so any return code paths don't trip
over the fact that the allocation didn't succeed.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Suggested-by: Suren Baghdasaryan
Signed-off-by: John Stultz
---
drivers/dma-buf/heaps/system_heap.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index 17e0e9a68baf..405351aad2a8 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -363,8 +363,10 @@ static int system_heap_allocate(struct dma_heap *heap,
* Avoid trying to allocate memory if the process
* has been killed by SIGKILL
*/
- if (fatal_signal_pending(current))
+ if (fatal_signal_pending(current)) {
+ ret = -EINTR;
goto free_buffer;
+ }
page = alloc_largest_available(size_remaining, max_order);
if (!page)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/2] drm/drm_vblank: set the dma-fence timestamp during send_vblank_event
On Fri, Jan 15, 2021 at 4:31 PM Veera Sundaram Sankaran wrote: > > The explicit out-fences in crtc are signaled as part of vblank event, > indicating all framebuffers present on the Atomic Commit request are > scanned out on the screen. Though the fence signal and the vblank event > notification happens at the same time, triggered by the same hardware > vsync event, the timestamp set in both are different. With drivers > supporting precise vblank timestamp the difference between the two > timestamps would be even higher. This might have an impact on use-mode > frameworks using these fence timestamps for purposes other than simple > buffer usage. For instance, the Android framework [1] uses the > retire-fences as an alternative to vblank when frame-updates are in > progress. Set the fence timestamp during send vblank event using a new > drm_send_event_timestamp_locked variant to avoid discrepancies. > > [1] https://android.googlesource.com/platform/frameworks/native/+/master/ > services/surfaceflinger/Scheduler/Scheduler.cpp#397 > > Changes in v2: > - Use drm_send_event_timestamp_locked to update fence timestamp > - add more information to commit text > > Changes in v3: > - use same backend helper function for variants of drm_send_event to > avoid code duplications > > Changes in v4: > - remove WARN_ON from drm_send_event_timestamp_locked > > Signed-off-by: Veera Sundaram Sankaran > --- Looks good, as expected no longer seeing the warning. Reviewed-by: John Stultz thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/2] dma-fence: allow signaling drivers to set fence timestamp
On Fri, Jan 15, 2021 at 4:31 PM Veera Sundaram Sankaran wrote: > > Some drivers have hardware capability to get the precise HW timestamp > of certain events based on which the fences are triggered. The delta > between the event HW timestamp & current HW reference timestamp can > be used to calculate the timestamp in kernel's CLOCK_MONOTONIC time > domain. This allows it to set accurate timestamp factoring out any > software and IRQ latencies. Add a timestamp variant of fence signal > function, dma_fence_signal_timestamp to allow drivers to update the > precise timestamp for fences. > > Changes in v2: > - Add a new fence signal variant instead of modifying fence struct > > Changes in v3: > - Add timestamp domain information to commit-text and > dma_fence_signal_timestamp documentation > > Signed-off-by: Veera Sundaram Sankaran > --- > drivers/dma-buf/dma-fence.c | 70 > - > include/linux/dma-fence.h | 3 ++ > 2 files changed, 66 insertions(+), 7 deletions(-) Thanks for respinning this! Reviewed-by: John Stultz -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 10/14] dmr/amdgpu: Move some sysfs attrs creation to default_attr
On Tue, Jan 19, 2021 at 02:04:48PM -0500, Alex Deucher wrote:
> On Tue, Jan 19, 2021 at 1:26 PM Greg KH wrote:
> >
> > On Tue, Jan 19, 2021 at 11:36:01AM -0500, Andrey Grodzovsky wrote:
> > >
> > > On 1/19/21 2:34 AM, Greg KH wrote:
> > > > On Mon, Jan 18, 2021 at 04:01:19PM -0500, Andrey Grodzovsky wrote:
> > > > > static struct pci_driver amdgpu_kms_pci_driver = {
> > > > > .name = DRIVER_NAME,
> > > > > .id_table = pciidlist,
> > > > > @@ -1595,6 +1607,7 @@ static struct pci_driver amdgpu_kms_pci_driver
> > > > > = {
> > > > > .shutdown = amdgpu_pci_shutdown,
> > > > > .driver.pm = &amdgpu_pm_ops,
> > > > > .err_handler = &amdgpu_pci_err_handler,
> > > > > + .driver.dev_groups = amdgpu_sysfs_groups,
> > > > Shouldn't this just be:
> > > > groups - amdgpu_sysfs_groups,
> > > >
> > > > Why go to the "driver root" here?
> > >
> > >
> > > Because I still didn't get to your suggestion to propose a patch to add
> > > groups to
> > > pci_driver, it's located in 'base' driver struct.
> >
> > You are a pci driver, you should never have to mess with the "base"
> > driver struct. Look at commit 92d50fc1602e ("PCI/IB: add support for
> > pci driver attribute groups") which got merged in 4.14, way back in
> > 2017 :)
>
> Per the previous discussion of this patch set:
> https://www.mail-archive.com/amd-gfx@lists.freedesktop.org/msg56019.html
Hey, at least I'm consistent :)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vmwgfx: Make sure we unpin no longer needed buffers
On Tue, Jan 19, 2021 at 8:35 PM Daniel Vetter wrote:
>
> On Tue, Jan 19, 2021 at 8:31 PM Zack Rusin wrote:
> >
> > We were not correctly unpinning no longer needed buffers. In particular
> > vmw_buffer_object, which is internally often pinned on creation wasn't
> > unpinned on destruction and none of the internal MOB buffers were
> > unpinned before being put back. Technically this existed for a
> > long time but 57fcd550eb15bce14a7154736379dfd4ed60ae81 introduced
Also this one should be replaced by the output of dim cite , but
I think dim doesn't check for these.
-Daniel
> > a WARN_ON which was filling up the kernel logs rather quickly.
> >
> > Quite frankly internal usage of vmw_buffer_object and in general
> > pinning needs to be refactored in vmwgfx but for now this makes
> > it work.
> >
> > Signed-off-by: Zack Rusin
> > Reviewed-by: Martin Krastev
> > Reviewed-by: Roland Scheidegger
> > Fixes: 57fcd550eb15bce14a7154736379dfd4ed60ae81
>
> dim will balk on this (or should at least)
>
> $ dim fixes
>
> should give you the recommend thing.
> -Daniel
>
> > ---
> > drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 2 ++
> > drivers/gpu/drm/vmwgfx/vmwgfx_mob.c | 4
> > 2 files changed, 6 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> > index b45becbb00f8..73225ab691e6 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> > @@ -1554,6 +1554,8 @@ static inline void vmw_bo_unreference(struct
> > vmw_buffer_object **buf)
> >
> > *buf = NULL;
> > if (tmp_buf != NULL) {
> > + if (tmp_buf->base.pin_count > 0)
> > + ttm_bo_unpin(&tmp_buf->base);
> > ttm_bo_put(&tmp_buf->base);
> > }
> > }
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
> > index 7f95ed6aa224..3c6e69f36767 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
> > @@ -277,6 +277,7 @@ static int vmw_otable_batch_setup(struct vmw_private
> > *dev_priv,
> > &batch->otables[i]);
> > }
> >
> > + ttm_bo_unpin(batch->otable_bo);
> > ttm_bo_put(batch->otable_bo);
> > batch->otable_bo = NULL;
> > return ret;
> > @@ -342,6 +343,7 @@ static void vmw_otable_batch_takedown(struct
> > vmw_private *dev_priv,
> > vmw_bo_fence_single(bo, NULL);
> > ttm_bo_unreserve(bo);
> >
> > + ttm_bo_unpin(batch->otable_bo);
> > ttm_bo_put(batch->otable_bo);
> > batch->otable_bo = NULL;
> > }
> > @@ -528,6 +530,7 @@ static void vmw_mob_pt_setup(struct vmw_mob *mob,
> > void vmw_mob_destroy(struct vmw_mob *mob)
> > {
> > if (mob->pt_bo) {
> > + ttm_bo_unpin(mob->pt_bo);
> > ttm_bo_put(mob->pt_bo);
> > mob->pt_bo = NULL;
> > }
> > @@ -643,6 +646,7 @@ int vmw_mob_bind(struct vmw_private *dev_priv,
> > out_no_cmd_space:
> > vmw_fifo_resource_dec(dev_priv);
> > if (pt_set_up) {
> > + ttm_bo_unpin(mob->pt_bo);
> > ttm_bo_put(mob->pt_bo);
> > mob->pt_bo = NULL;
> > }
> > --
> > 2.27.0
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vmwgfx: Make sure we unpin no longer needed buffers
On Tue, Jan 19, 2021 at 8:31 PM Zack Rusin wrote:
>
> We were not correctly unpinning no longer needed buffers. In particular
> vmw_buffer_object, which is internally often pinned on creation wasn't
> unpinned on destruction and none of the internal MOB buffers were
> unpinned before being put back. Technically this existed for a
> long time but 57fcd550eb15bce14a7154736379dfd4ed60ae81 introduced
> a WARN_ON which was filling up the kernel logs rather quickly.
>
> Quite frankly internal usage of vmw_buffer_object and in general
> pinning needs to be refactored in vmwgfx but for now this makes
> it work.
>
> Signed-off-by: Zack Rusin
> Reviewed-by: Martin Krastev
> Reviewed-by: Roland Scheidegger
> Fixes: 57fcd550eb15bce14a7154736379dfd4ed60ae81
dim will balk on this (or should at least)
$ dim fixes
should give you the recommend thing.
-Daniel
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 2 ++
> drivers/gpu/drm/vmwgfx/vmwgfx_mob.c | 4
> 2 files changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> index b45becbb00f8..73225ab691e6 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> @@ -1554,6 +1554,8 @@ static inline void vmw_bo_unreference(struct
> vmw_buffer_object **buf)
>
> *buf = NULL;
> if (tmp_buf != NULL) {
> + if (tmp_buf->base.pin_count > 0)
> + ttm_bo_unpin(&tmp_buf->base);
> ttm_bo_put(&tmp_buf->base);
> }
> }
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
> index 7f95ed6aa224..3c6e69f36767 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
> @@ -277,6 +277,7 @@ static int vmw_otable_batch_setup(struct vmw_private
> *dev_priv,
> &batch->otables[i]);
> }
>
> + ttm_bo_unpin(batch->otable_bo);
> ttm_bo_put(batch->otable_bo);
> batch->otable_bo = NULL;
> return ret;
> @@ -342,6 +343,7 @@ static void vmw_otable_batch_takedown(struct vmw_private
> *dev_priv,
> vmw_bo_fence_single(bo, NULL);
> ttm_bo_unreserve(bo);
>
> + ttm_bo_unpin(batch->otable_bo);
> ttm_bo_put(batch->otable_bo);
> batch->otable_bo = NULL;
> }
> @@ -528,6 +530,7 @@ static void vmw_mob_pt_setup(struct vmw_mob *mob,
> void vmw_mob_destroy(struct vmw_mob *mob)
> {
> if (mob->pt_bo) {
> + ttm_bo_unpin(mob->pt_bo);
> ttm_bo_put(mob->pt_bo);
> mob->pt_bo = NULL;
> }
> @@ -643,6 +646,7 @@ int vmw_mob_bind(struct vmw_private *dev_priv,
> out_no_cmd_space:
> vmw_fifo_resource_dec(dev_priv);
> if (pt_set_up) {
> + ttm_bo_unpin(mob->pt_bo);
> ttm_bo_put(mob->pt_bo);
> mob->pt_bo = NULL;
> }
> --
> 2.27.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211161] list_del corruption in ttm_pool_shrink
https://bugzilla.kernel.org/show_bug.cgi?id=211161 Benji Wiebe (benjiwieb...@gmail.com) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX --- Comment #4 from Benji Wiebe (benjiwieb...@gmail.com) --- It was happening regularly to me previously, but now using DRM master I haven't seen it happen once. Looks like you were right about it being fixed in those patches. Thanks! -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vmwgfx: Make sure we unpin no longer needed buffers
We were not correctly unpinning no longer needed buffers. In particular
vmw_buffer_object, which is internally often pinned on creation wasn't
unpinned on destruction and none of the internal MOB buffers were
unpinned before being put back. Technically this existed for a
long time but 57fcd550eb15bce14a7154736379dfd4ed60ae81 introduced
a WARN_ON which was filling up the kernel logs rather quickly.
Quite frankly internal usage of vmw_buffer_object and in general
pinning needs to be refactored in vmwgfx but for now this makes
it work.
Signed-off-by: Zack Rusin
Reviewed-by: Martin Krastev
Reviewed-by: Roland Scheidegger
Fixes: 57fcd550eb15bce14a7154736379dfd4ed60ae81
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 2 ++
drivers/gpu/drm/vmwgfx/vmwgfx_mob.c | 4
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index b45becbb00f8..73225ab691e6 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -1554,6 +1554,8 @@ static inline void vmw_bo_unreference(struct
vmw_buffer_object **buf)
*buf = NULL;
if (tmp_buf != NULL) {
+ if (tmp_buf->base.pin_count > 0)
+ ttm_bo_unpin(&tmp_buf->base);
ttm_bo_put(&tmp_buf->base);
}
}
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
index 7f95ed6aa224..3c6e69f36767 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
@@ -277,6 +277,7 @@ static int vmw_otable_batch_setup(struct vmw_private
*dev_priv,
&batch->otables[i]);
}
+ ttm_bo_unpin(batch->otable_bo);
ttm_bo_put(batch->otable_bo);
batch->otable_bo = NULL;
return ret;
@@ -342,6 +343,7 @@ static void vmw_otable_batch_takedown(struct vmw_private
*dev_priv,
vmw_bo_fence_single(bo, NULL);
ttm_bo_unreserve(bo);
+ ttm_bo_unpin(batch->otable_bo);
ttm_bo_put(batch->otable_bo);
batch->otable_bo = NULL;
}
@@ -528,6 +530,7 @@ static void vmw_mob_pt_setup(struct vmw_mob *mob,
void vmw_mob_destroy(struct vmw_mob *mob)
{
if (mob->pt_bo) {
+ ttm_bo_unpin(mob->pt_bo);
ttm_bo_put(mob->pt_bo);
mob->pt_bo = NULL;
}
@@ -643,6 +646,7 @@ int vmw_mob_bind(struct vmw_private *dev_priv,
out_no_cmd_space:
vmw_fifo_resource_dec(dev_priv);
if (pt_set_up) {
+ ttm_bo_unpin(mob->pt_bo);
ttm_bo_put(mob->pt_bo);
mob->pt_bo = NULL;
}
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/29] [Set 15] Finally rid W=1 warnings from GPU!
> On Jan 19, 2021, at 03:29, Lee Jones wrote: > > On Mon, 18 Jan 2021, Daniel Vetter wrote: > >> On Mon, Jan 18, 2021 at 03:09:45PM +, Lee Jones wrote: >>> On Mon, 18 Jan 2021, Daniel Vetter wrote: >>> On Fri, Jan 15, 2021 at 06:27:15PM +, Zack Rusin wrote: > >> On Jan 15, 2021, at 13:15, Lee Jones wrote: >> >> This set is part of a larger effort attempting to clean-up W=1 >> kernel builds, which are currently overwhelmingly riddled with >> niggly little warnings. >> >> Last set! All clean after this for; Arm, Arm64, PPC, MIPS and x86. > > Thanks! For all the vmwgfx bits: > Reviewed-by: Zack Rusin Ok I merged everything except vmwgfx (that's for Zack) and i915/nouveau (those generally go through other trees, pls holler if they're stuck). >>> >>> Thanks Daniel, you're a superstar! >>> >>> So Zack will take the vmwgfx parts? Despite providing a R-b? >> >> I only merge stuff that's defacto abandoned already. Everything else I try >> to offload to whomever actually cares :-) > > Understood. Thanks for the explanation. > > Hopefully Zack actually cares. :D hah, I do. I just pushed all of the changes to drm-misc-next. Let me know if I missed anything. Thanks! z ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 11/14] drm/amdgpu: Guard against write accesses after device removal
On 1/19/21 1:59 PM, Christian König wrote:
Am 19.01.21 um 19:22 schrieb Andrey Grodzovsky:
On 1/19/21 1:05 PM, Daniel Vetter wrote:
On Tue, Jan 19, 2021 at 4:35 PM Andrey Grodzovsky
wrote:
There is really no other way according to this article
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flwn.net%2FArticles%2F767885%2F&data=04%7C01%7CAndrey.Grodzovsky%40amd.com%7Cee61fb937d2d4baedf6f08d8bcac5b02%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637466795752297305%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=a9Y4ZMEVYaMP7IeMVxQgXGpAkDXSkedMAiWkyqwzEe8%3D&reserved=0
"A perfect solution seems nearly impossible though; we cannot acquire a
mutex on
the user
to prevent them from yanking a device and we cannot check for a presence
change
after every
device access for performance reasons. "
But I assumed srcu_read_lock should be pretty seamless performance wise, no ?
The read side is supposed to be dirt cheap, the write side is were we
just stall for all readers to eventually complete on their own.
Definitely should be much cheaper than mmio read, on the mmio write
side it might actually hurt a bit. Otoh I think those don't stall the
cpu by default when they're timing out, so maybe if the overhead is
too much for those, we could omit them?
Maybe just do a small microbenchmark for these for testing, with a
register that doesn't change hw state. So with and without
drm_dev_enter/exit, and also one with the hw plugged out so that we
have actual timeouts in the transactions.
-Daniel
So say writing in a loop to some harmless scratch register for many times
both for plugged
and unplugged case and measure total time delta ?
I think we should at least measure the following:
1. Writing X times to a scratch reg without your patch.
2. Writing X times to a scratch reg with your patch.
3. Writing X times to a scratch reg with the hardware physically disconnected.
I suggest to repeat that once for Polaris (or older) and once for Vega or Navi.
The SRBM on Polaris is meant to introduce some delay in each access, so it
might react differently then the newer hardware.
Christian.
Will do.
Andrey
Andrey
The other solution would be as I suggested to keep all the device IO ranges
reserved and system
memory pages unfreed until the device is finalized in the driver but Daniel
said
this would upset the PCI layer (the MMIO ranges reservation part).
Andrey
On 1/19/21 3:55 AM, Christian König wrote:
Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
This should prevent writing to memory or IO ranges possibly
already allocated for other uses after our device is removed.
Wow, that adds quite some overhead to every register access. I'm not sure we
can do this.
Christian.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 57
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 9
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 53 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h | 3 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 70
++
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 49 ++---
drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 16 ++-
drivers/gpu/drm/amd/amdgpu/psp_v12_0.c | 8 +---
drivers/gpu/drm/amd/amdgpu/psp_v3_1.c | 8 +---
9 files changed, 184 insertions(+), 89 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index e99f4f1..0a9d73c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -72,6 +72,8 @@
#include
+#include
+
MODULE_FIRMWARE("amdgpu/vega10_gpu_info.bin");
MODULE_FIRMWARE("amdgpu/vega12_gpu_info.bin");
MODULE_FIRMWARE("amdgpu/raven_gpu_info.bin");
@@ -404,13 +406,21 @@ uint8_t amdgpu_mm_rreg8(struct amdgpu_device *adev,
uint32_t offset)
*/
void amdgpu_mm_wreg8(struct amdgpu_device *adev, uint32_t offset, uint8_t
value)
{
+ int idx;
+
if (adev->in_pci_err_recovery)
return;
+
+ if (!drm_dev_enter(&adev->ddev, &idx))
+ return;
+
if (offset < adev->rmmio_size)
writeb(value, adev->rmmio + offset);
else
BUG();
+
+ drm_dev_exit(idx);
}
/**
@@ -427,9 +437,14 @@ void amdgpu_device_wreg(struct amdgpu_device *adev,
uint32_t reg, uint32_t v,
uint32_t acc_flags)
{
+ int idx;
+
if (adev->in_pci_err_recovery)
return;
+ if (!drm_dev_enter(&adev->ddev, &idx))
+ return;
+
if ((reg * 4) < adev->rmmio_size) {
if (!(acc_flags & AMDGPU_REGS_NO_KIQ) &&
amdgpu_sriov_runtime(adev) &&
@@ -444,6 +459,8 @@ void amdgpu_device_wreg(struct amdgpu_device *adev,
}
trace_amdgpu_device_wreg(adev->pdev->device, reg, v);
+
+ drm_dev_exit(idx);
Re: [PATCH v4 10/14] dmr/amdgpu: Move some sysfs attrs creation to default_attr
On 1/19/21 2:04 PM, Alex Deucher wrote:
On Tue, Jan 19, 2021 at 1:26 PM Greg KH wrote:
On Tue, Jan 19, 2021 at 11:36:01AM -0500, Andrey Grodzovsky wrote:
On 1/19/21 2:34 AM, Greg KH wrote:
On Mon, Jan 18, 2021 at 04:01:19PM -0500, Andrey Grodzovsky wrote:
static struct pci_driver amdgpu_kms_pci_driver = {
.name = DRIVER_NAME,
.id_table = pciidlist,
@@ -1595,6 +1607,7 @@ static struct pci_driver amdgpu_kms_pci_driver = {
.shutdown = amdgpu_pci_shutdown,
.driver.pm = &amdgpu_pm_ops,
.err_handler = &amdgpu_pci_err_handler,
+ .driver.dev_groups = amdgpu_sysfs_groups,
Shouldn't this just be:
groups - amdgpu_sysfs_groups,
Why go to the "driver root" here?
Because I still didn't get to your suggestion to propose a patch to add groups
to
pci_driver, it's located in 'base' driver struct.
You are a pci driver, you should never have to mess with the "base"
driver struct. Look at commit 92d50fc1602e ("PCI/IB: add support for
pci driver attribute groups") which got merged in 4.14, way back in
2017 :)
Per the previous discussion of this patch set:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mail-archive.com%2Famd-gfx%40lists.freedesktop.org%2Fmsg56019.html&data=04%7C01%7CAndrey.Grodzovsky%40amd.com%7C1b43efdc8a164169eee508d8bcad1ece%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637466799090087255%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=T462j96qC%2BXCZzgnJMG%2BbUEOG94GVuqkvTWfUB%2B3%2Fl8%3D&reserved=0
Alex
Got it, Next iteration I will include a patch like the above to pci-devel as
part of the series and will update this patch accordingly.
Andrey
driver.pm also looks odd, but I'm just going to ignore that for now...
thanks,
greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=04%7C01%7CAndrey.Grodzovsky%40amd.com%7C1b43efdc8a164169eee508d8bcad1ece%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637466799090087255%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=reQqTGFCsEXvHOmSt8c4B6idrotIS4Q69WKw%2FRtpAEg%3D&reserved=0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 10/14] dmr/amdgpu: Move some sysfs attrs creation to default_attr
On Tue, Jan 19, 2021 at 1:26 PM Greg KH wrote:
>
> On Tue, Jan 19, 2021 at 11:36:01AM -0500, Andrey Grodzovsky wrote:
> >
> > On 1/19/21 2:34 AM, Greg KH wrote:
> > > On Mon, Jan 18, 2021 at 04:01:19PM -0500, Andrey Grodzovsky wrote:
> > > > static struct pci_driver amdgpu_kms_pci_driver = {
> > > > .name = DRIVER_NAME,
> > > > .id_table = pciidlist,
> > > > @@ -1595,6 +1607,7 @@ static struct pci_driver amdgpu_kms_pci_driver = {
> > > > .shutdown = amdgpu_pci_shutdown,
> > > > .driver.pm = &amdgpu_pm_ops,
> > > > .err_handler = &amdgpu_pci_err_handler,
> > > > + .driver.dev_groups = amdgpu_sysfs_groups,
> > > Shouldn't this just be:
> > > groups - amdgpu_sysfs_groups,
> > >
> > > Why go to the "driver root" here?
> >
> >
> > Because I still didn't get to your suggestion to propose a patch to add
> > groups to
> > pci_driver, it's located in 'base' driver struct.
>
> You are a pci driver, you should never have to mess with the "base"
> driver struct. Look at commit 92d50fc1602e ("PCI/IB: add support for
> pci driver attribute groups") which got merged in 4.14, way back in
> 2017 :)
Per the previous discussion of this patch set:
https://www.mail-archive.com/amd-gfx@lists.freedesktop.org/msg56019.html
Alex
>
> driver.pm also looks odd, but I'm just going to ignore that for now...
>
> thanks,
>
> greg k-h
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 11/14] drm/amdgpu: Guard against write accesses after device removal
Am 19.01.21 um 19:22 schrieb Andrey Grodzovsky:
On 1/19/21 1:05 PM, Daniel Vetter wrote:
On Tue, Jan 19, 2021 at 4:35 PM Andrey Grodzovsky
wrote:
There is really no other way according to this article
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flwn.net%2FArticles%2F767885%2F&data=04%7C01%7CAndrey.Grodzovsky%40amd.com%7C7a1f5ae6a06f4661d47708d8bca4cb32%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637466763278674162%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QupsglO9WRuis8XRLBFIhl6miTXVOdAnk8oP4BfSclQ%3D&reserved=0
"A perfect solution seems nearly impossible though; we cannot
acquire a mutex on
the user
to prevent them from yanking a device and we cannot check for a
presence change
after every
device access for performance reasons. "
But I assumed srcu_read_lock should be pretty seamless performance
wise, no ?
The read side is supposed to be dirt cheap, the write side is were we
just stall for all readers to eventually complete on their own.
Definitely should be much cheaper than mmio read, on the mmio write
side it might actually hurt a bit. Otoh I think those don't stall the
cpu by default when they're timing out, so maybe if the overhead is
too much for those, we could omit them?
Maybe just do a small microbenchmark for these for testing, with a
register that doesn't change hw state. So with and without
drm_dev_enter/exit, and also one with the hw plugged out so that we
have actual timeouts in the transactions.
-Daniel
So say writing in a loop to some harmless scratch register for many
times both for plugged
and unplugged case and measure total time delta ?
I think we should at least measure the following:
1. Writing X times to a scratch reg without your patch.
2. Writing X times to a scratch reg with your patch.
3. Writing X times to a scratch reg with the hardware physically
disconnected.
I suggest to repeat that once for Polaris (or older) and once for Vega
or Navi.
The SRBM on Polaris is meant to introduce some delay in each access, so
it might react differently then the newer hardware.
Christian.
Andrey
The other solution would be as I suggested to keep all the device IO
ranges
reserved and system
memory pages unfreed until the device is finalized in the driver but
Daniel said
this would upset the PCI layer (the MMIO ranges reservation part).
Andrey
On 1/19/21 3:55 AM, Christian König wrote:
Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
This should prevent writing to memory or IO ranges possibly
already allocated for other uses after our device is removed.
Wow, that adds quite some overhead to every register access. I'm
not sure we
can do this.
Christian.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 57
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 9
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 53
+-
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h | 3 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 70
++
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 49
++---
drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 16 ++-
drivers/gpu/drm/amd/amdgpu/psp_v12_0.c | 8 +---
drivers/gpu/drm/amd/amdgpu/psp_v3_1.c | 8 +---
9 files changed, 184 insertions(+), 89 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index e99f4f1..0a9d73c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -72,6 +72,8 @@
#include
+#include
+
MODULE_FIRMWARE("amdgpu/vega10_gpu_info.bin");
MODULE_FIRMWARE("amdgpu/vega12_gpu_info.bin");
MODULE_FIRMWARE("amdgpu/raven_gpu_info.bin");
@@ -404,13 +406,21 @@ uint8_t amdgpu_mm_rreg8(struct amdgpu_device
*adev,
uint32_t offset)
*/
void amdgpu_mm_wreg8(struct amdgpu_device *adev, uint32_t
offset, uint8_t
value)
{
+ int idx;
+
if (adev->in_pci_err_recovery)
return;
+
+ if (!drm_dev_enter(&adev->ddev, &idx))
+ return;
+
if (offset < adev->rmmio_size)
writeb(value, adev->rmmio + offset);
else
BUG();
+
+ drm_dev_exit(idx);
}
/**
@@ -427,9 +437,14 @@ void amdgpu_device_wreg(struct amdgpu_device
*adev,
uint32_t reg, uint32_t v,
uint32_t acc_flags)
{
+ int idx;
+
if (adev->in_pci_err_recovery)
return;
+ if (!drm_dev_enter(&adev->ddev, &idx))
+ return;
+
if ((reg * 4) < adev->rmmio_size) {
if (!(acc_flags & AMDGPU_REGS_NO_KIQ) &&
amdgpu_sriov_runtime(adev) &&
@@ -444,6 +459,8 @@ void amdgpu_device_wreg(struct amdgpu_device
*adev,
}
trace_amdgpu_device_wreg(adev->pdev->device, reg, v);
+
+ drm_dev_exit(idx);
}
/*
@@ -454,9 +471,14 @@ void amdgpu_de
Re: [PATCH v3 1/3] drm/amd/display: Add module parameter for freesync video mode
On Tue, Jan 19, 2021 at 5:08 PM Pillai, Aurabindo wrote: > > [AMD Official Use Only - Internal Distribution Only] > > > Hi Daniel, > > Could you please be more specific about the _unsafe API options you mentioned > ? module_param_named_unsafe() Cheers, Daniel > > -- > > Thanks & Regards, > Aurabindo Pillai > > From: Daniel Vetter > Sent: Tuesday, January 19, 2021 8:11 AM > To: Pekka Paalanen > Cc: Pillai, Aurabindo ; amd-gfx list > ; dri-devel ; > Kazlauskas, Nicholas ; Wang, Chao-kai (Stylon) > ; Thai, Thong ; Sharma, Shashank > ; Lin, Wayne ; Deucher, Alexander > ; Koenig, Christian > Subject: Re: [PATCH v3 1/3] drm/amd/display: Add module parameter for > freesync video mode > > On Tue, Jan 19, 2021 at 9:35 AM Pekka Paalanen wrote: > > > > On Mon, 18 Jan 2021 09:36:47 -0500 > > Aurabindo Pillai wrote: > > > > > On Thu, 2021-01-14 at 11:14 +0200, Pekka Paalanen wrote: > > > > > > > > Hi, > > > > > > > > please document somewhere that ends up in git history (commit > > > > message, > > > > code comments, description of the parameter would be the best but > > > > maybe > > > > there isn't enough space?) what Christian König explained in > > > > > > > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fdri-devel%2F2020-December%2F291254.html&data=04%7C01%7Caurabindo.pillai%40amd.com%7C56ba07934c5c48e7ad7b08d8bc7bb4a9%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637466586800649481%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=GM0ZEM9JeFM5os13E1zlVy8Bn3D8Kxmo%2FajSG02WsGI%3D&reserved=0 > > > > > > > > that this is a stop-gap feature intended to be removed as soon as > > > > possible (when a better solution comes up, which could be years). > > > > > > > > So far I have not seen a single mention of this intention in your > > > > patch > > > > submissions, and I think it is very important to make known. > > > > > > Hi, > > > > > > Thanks for the headsup, I shall add the relevant info in the next > > > verison. > > > > > > > > > > > I also did not see an explanation of why this instead of > > > > manufacturing > > > > these video modes in userspace (an idea mentioned by Christian in the > > > > referenced email). I think that too should be part of a commit > > > > message. > > > > > > This is an opt-in feature, which shall be superseded by a better > > > solution. We also add a set of common modes for scaling similarly. > > > Userspace can still add whatever mode they want. So I dont see a reason > > > why this cant be in the kernel. > > > > Hi, > > > > sorry, I think that kind of thinking is backwards. There needs to be a > > reason to put something in the kernel, and if there is no reason, then > > it remains in userspace. So what's the reason to put this in the kernel? > > > > One example reason why this should not be in the kernel is that the set > > of video modes to manufacture is a kind of policy, which modes to add > > and which not. Userspace knows what modes it needs, and establishing > > the modes in the kernel instead is second-guessing what the userspace > > would want. So if userspace needs to manufacture modes in userspace > > anyway as some modes might be missed by the kernel, then why bother in > > the kernel to begin with? Why should the kernel play catch-up with what > > modes userspace wants when we already have everything userspace needs > > to make its own modes, even to add them to the kernel mode list? > > > > Does manufacturing these extra video modes to achieve fast timing > > changes require AMD hardware-specific knowledge, as opposed to the > > general VRR approach of simply adjusting the front porch? > > > > Something like this should also be documented in a commit message. Or > > if you insist that "no reason to not put this in the kernel" is reason > > enough, then write that down, because it does not seem obvious to me or > > others that this feature needs to be in the kernel. > > One reason might be debugging, if a feature is known to cause issues. > But imo in that case the knob should be using the _unsafe variants so > it taints the kernel, since otherwise we get stuck in this very cozy > place where kernel maintainers don't have to care much for bugs > "because it's off by default", but also not really care about > polishing the feature "since users can just enable it if they want > it". Just a slightly different flavour of what you're explaining above > already. > -Daniel > > > Thanks, > > pq > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fblog.ffwll.ch%2F&data=04%7C01%7Caurabindo.pillai%40amd.com%7C56ba07934c5c48e7ad7b08d8bc7bb4a9%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637466586800649481%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2isCpwa3V92TnO4njhe9cQjdWVdsV1GQMo7
Re: [PATCH v4 12/14] drm/scheduler: Job timeout handler returns status
Am 19.01.21 um 18:47 schrieb Luben Tuikov:
On 2021-01-19 2:53 a.m., Christian König wrote:
Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
From: Luben Tuikov
This patch does not change current behaviour.
The driver's job timeout handler now returns
status indicating back to the DRM layer whether
the task (job) was successfully aborted or whether
more time should be given to the task to complete.
Default behaviour as of this patch, is preserved,
except in obvious-by-comment case in the Panfrost
driver, as documented below.
All drivers which make use of the
drm_sched_backend_ops' .timedout_job() callback
have been accordingly renamed and return the
would've-been default value of
DRM_TASK_STATUS_ALIVE to restart the task's
timeout timer--this is the old behaviour, and
is preserved by this patch.
In the case of the Panfrost driver, its timedout
callback correctly first checks if the job had
completed in due time and if so, it now returns
DRM_TASK_STATUS_COMPLETE to notify the DRM layer
that the task can be moved to the done list, to be
freed later. In the other two subsequent checks,
the value of DRM_TASK_STATUS_ALIVE is returned, as
per the default behaviour.
A more involved driver's solutions can be had
in subequent patches.
v2: Use enum as the status of a driver's job
timeout callback method.
v4: (By Andrey Grodzovsky)
Replace DRM_TASK_STATUS_COMPLETE with DRM_TASK_STATUS_ENODEV
to enable a hint to the schduler for when NOT to rearm the
timeout timer.
As Lukas pointed out returning the job (or task) status doesn't make
much sense.
What we return here is the status of the scheduler.
I would either rename the enum or completely drop it and return a
negative error status.
Yes, that could be had.
Although, dropping the enum and returning [-1, 0], might
make the return status meaning vague. Using an enum with an appropriate
name, makes the intention clear to the next programmer.
Completely agree, but -ENODEV and 0 could work.
On the other hand using DRM_SCHED_* is perfectly fine with me as well.
Christian.
Now, Andrey did rename one of the enumerated values to
DRM_TASK_STATUS_ENODEV, perhaps the same but with:
enum drm_sched_status {
DRM_SCHED_STAT_NONE, /* Reserve 0 */
DRM_SCHED_STAT_NOMINAL,
DRM_SCHED_STAT_ENODEV,
};
and also renaming the enum to the above would be acceptable?
Regards,
Luben
Apart from that looks fine to me,
Christian.
Cc: Alexander Deucher
Cc: Andrey Grodzovsky
Cc: Christian König
Cc: Daniel Vetter
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Cc: Qiang Yu
Cc: Rob Herring
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: Eric Anholt
Reported-by: kernel test robot
Signed-off-by: Luben Tuikov
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 6 --
drivers/gpu/drm/etnaviv/etnaviv_sched.c | 10 +-
drivers/gpu/drm/lima/lima_sched.c | 4 +++-
drivers/gpu/drm/panfrost/panfrost_job.c | 9 ++---
drivers/gpu/drm/scheduler/sched_main.c | 4 +---
drivers/gpu/drm/v3d/v3d_sched.c | 32 +---
include/drm/gpu_scheduler.h | 17 ++---
7 files changed, 54 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index ff48101..a111326 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -28,7 +28,7 @@
#include "amdgpu.h"
#include "amdgpu_trace.h"
-static void amdgpu_job_timedout(struct drm_sched_job *s_job)
+static enum drm_task_status amdgpu_job_timedout(struct drm_sched_job *s_job)
{
struct amdgpu_ring *ring = to_amdgpu_ring(s_job->sched);
struct amdgpu_job *job = to_amdgpu_job(s_job);
@@ -41,7 +41,7 @@ static void amdgpu_job_timedout(struct drm_sched_job *s_job)
amdgpu_ring_soft_recovery(ring, job->vmid, s_job->s_fence->parent))
{
DRM_ERROR("ring %s timeout, but soft recovered\n",
s_job->sched->name);
- return;
+ return DRM_TASK_STATUS_ALIVE;
}
amdgpu_vm_get_task_info(ring->adev, job->pasid, &ti);
@@ -53,10 +53,12 @@ static void amdgpu_job_timedout(struct drm_sched_job *s_job)
if (amdgpu_device_should_recover_gpu(ring->adev)) {
amdgpu_device_gpu_recover(ring->adev, job);
+ return DRM_TASK_STATUS_ALIVE;
} else {
drm_sched_suspend_timeout(&ring->sched);
if (amdgpu_sriov_vf(adev))
adev->virt.tdr_debug = true;
+ return DRM_TASK_STATUS_ALIVE;
}
}
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index cd46c88..c495169 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -82,7 +82,8 @@ static struct dma_fence *etnaviv_sched_run_jo
Re: [PATCH v4 10/14] dmr/amdgpu: Move some sysfs attrs creation to default_attr
On Tue, Jan 19, 2021 at 11:36:01AM -0500, Andrey Grodzovsky wrote:
>
> On 1/19/21 2:34 AM, Greg KH wrote:
> > On Mon, Jan 18, 2021 at 04:01:19PM -0500, Andrey Grodzovsky wrote:
> > > static struct pci_driver amdgpu_kms_pci_driver = {
> > > .name = DRIVER_NAME,
> > > .id_table = pciidlist,
> > > @@ -1595,6 +1607,7 @@ static struct pci_driver amdgpu_kms_pci_driver = {
> > > .shutdown = amdgpu_pci_shutdown,
> > > .driver.pm = &amdgpu_pm_ops,
> > > .err_handler = &amdgpu_pci_err_handler,
> > > + .driver.dev_groups = amdgpu_sysfs_groups,
> > Shouldn't this just be:
> > groups - amdgpu_sysfs_groups,
> >
> > Why go to the "driver root" here?
>
>
> Because I still didn't get to your suggestion to propose a patch to add
> groups to
> pci_driver, it's located in 'base' driver struct.
You are a pci driver, you should never have to mess with the "base"
driver struct. Look at commit 92d50fc1602e ("PCI/IB: add support for
pci driver attribute groups") which got merged in 4.14, way back in
2017 :)
driver.pm also looks odd, but I'm just going to ignore that for now...
thanks,
greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 11/14] drm/amdgpu: Guard against write accesses after device removal
On 1/19/21 1:05 PM, Daniel Vetter wrote:
On Tue, Jan 19, 2021 at 4:35 PM Andrey Grodzovsky
wrote:
There is really no other way according to this article
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flwn.net%2FArticles%2F767885%2F&data=04%7C01%7CAndrey.Grodzovsky%40amd.com%7C7a1f5ae6a06f4661d47708d8bca4cb32%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637466763278674162%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QupsglO9WRuis8XRLBFIhl6miTXVOdAnk8oP4BfSclQ%3D&reserved=0
"A perfect solution seems nearly impossible though; we cannot acquire a mutex on
the user
to prevent them from yanking a device and we cannot check for a presence change
after every
device access for performance reasons. "
But I assumed srcu_read_lock should be pretty seamless performance wise, no ?
The read side is supposed to be dirt cheap, the write side is were we
just stall for all readers to eventually complete on their own.
Definitely should be much cheaper than mmio read, on the mmio write
side it might actually hurt a bit. Otoh I think those don't stall the
cpu by default when they're timing out, so maybe if the overhead is
too much for those, we could omit them?
Maybe just do a small microbenchmark for these for testing, with a
register that doesn't change hw state. So with and without
drm_dev_enter/exit, and also one with the hw plugged out so that we
have actual timeouts in the transactions.
-Daniel
So say writing in a loop to some harmless scratch register for many times both
for plugged
and unplugged case and measure total time delta ?
Andrey
The other solution would be as I suggested to keep all the device IO ranges
reserved and system
memory pages unfreed until the device is finalized in the driver but Daniel said
this would upset the PCI layer (the MMIO ranges reservation part).
Andrey
On 1/19/21 3:55 AM, Christian König wrote:
Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
This should prevent writing to memory or IO ranges possibly
already allocated for other uses after our device is removed.
Wow, that adds quite some overhead to every register access. I'm not sure we
can do this.
Christian.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 57
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c| 9
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c| 53 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h| 3 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 70
++
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 49 ++---
drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 16 ++-
drivers/gpu/drm/amd/amdgpu/psp_v12_0.c | 8 +---
drivers/gpu/drm/amd/amdgpu/psp_v3_1.c | 8 +---
9 files changed, 184 insertions(+), 89 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index e99f4f1..0a9d73c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -72,6 +72,8 @@
#include
+#include
+
MODULE_FIRMWARE("amdgpu/vega10_gpu_info.bin");
MODULE_FIRMWARE("amdgpu/vega12_gpu_info.bin");
MODULE_FIRMWARE("amdgpu/raven_gpu_info.bin");
@@ -404,13 +406,21 @@ uint8_t amdgpu_mm_rreg8(struct amdgpu_device *adev,
uint32_t offset)
*/
void amdgpu_mm_wreg8(struct amdgpu_device *adev, uint32_t offset, uint8_t
value)
{
+int idx;
+
if (adev->in_pci_err_recovery)
return;
+
+if (!drm_dev_enter(&adev->ddev, &idx))
+return;
+
if (offset < adev->rmmio_size)
writeb(value, adev->rmmio + offset);
else
BUG();
+
+drm_dev_exit(idx);
}
/**
@@ -427,9 +437,14 @@ void amdgpu_device_wreg(struct amdgpu_device *adev,
uint32_t reg, uint32_t v,
uint32_t acc_flags)
{
+int idx;
+
if (adev->in_pci_err_recovery)
return;
+if (!drm_dev_enter(&adev->ddev, &idx))
+return;
+
if ((reg * 4) < adev->rmmio_size) {
if (!(acc_flags & AMDGPU_REGS_NO_KIQ) &&
amdgpu_sriov_runtime(adev) &&
@@ -444,6 +459,8 @@ void amdgpu_device_wreg(struct amdgpu_device *adev,
}
trace_amdgpu_device_wreg(adev->pdev->device, reg, v);
+
+drm_dev_exit(idx);
}
/*
@@ -454,9 +471,14 @@ void amdgpu_device_wreg(struct amdgpu_device *adev,
void amdgpu_mm_wreg_mmio_rlc(struct amdgpu_device *adev,
uint32_t reg, uint32_t v)
{
+int idx;
+
if (adev->in_pci_err_recovery)
return;
+if (!drm_dev_enter(&adev->ddev, &idx))
+return;
+
if (amdgpu_sriov_fullaccess(adev) &&
adev->gfx.rlc.funcs &&
adev->gfx.rlc.funcs->is_rlcg_access_range) {
@@ -465,6 +487,8 @@ void amdgpu_mm_wreg_mmio_rlc(struct amdgpu_device *adev,
} else {
writel(
Re: [PATCH v4 00/14] RFC Support hot device unplug in amdgpu
On 1/19/21 1:08 PM, Daniel Vetter wrote: On Tue, Jan 19, 2021 at 6:31 PM Andrey Grodzovsky wrote: On 1/19/21 9:16 AM, Daniel Vetter wrote: On Mon, Jan 18, 2021 at 04:01:09PM -0500, Andrey Grodzovsky wrote: Until now extracting a card either by physical extraction (e.g. eGPU with thunderbolt connection or by emulation through syfs -> /sys/bus/pci/devices/device_id/remove) would cause random crashes in user apps. The random crashes in apps were mostly due to the app having mapped a device backed BO into its address space was still trying to access the BO while the backing device was gone. To answer this first problem Christian suggested to fix the handling of mapped memory in the clients when the device goes away by forcibly unmap all buffers the user processes has by clearing their respective VMAs mapping the device BOs. Then when the VMAs try to fill in the page tables again we check in the fault handlerif the device is removed and if so, return an error. This will generate a SIGBUS to the application which can then cleanly terminate.This indeed was done but this in turn created a problem of kernel OOPs were the OOPSes were due to the fact that while the app was terminating because of the SIGBUSit would trigger use after free in the driver by calling to accesses device structures that were already released from the pci remove sequence.This was handled by introducing a 'flush' sequence during device removal were we wait for drm file reference to drop to 0 meaning all user clients directly using this device terminated. v2: Based on discussions in the mailing list with Daniel and Pekka [1] and based on the document produced by Pekka from those discussions [2] the whole approach with returning SIGBUS and waiting for all user clients having CPU mapping of device BOs to die was dropped. Instead as per the document suggestion the device structures are kept alive until the last reference to the device is dropped by user client and in the meanwhile all existing and new CPU mappings of the BOs belonging to the device directly or by dma-buf import are rerouted to per user process dummy rw page.Also, I skipped the 'Requirements for KMS UAPI' section of [2] since i am trying to get the minimal set of requirements that still give useful solution to work and this is the'Requirements for Render and Cross-Device UAPI' section and so my test case is removing a secondary device, which is render only and is not involved in KMS. v3: More updates following comments from v2 such as removing loop to find DRM file when rerouting page faults to dummy page,getting rid of unnecessary sysfs handling refactoring and moving prevention of GPU recovery post device unplug from amdgpu to scheduler layer. On top of that added unplug support for the IOMMU enabled system. v4: Drop last sysfs hack and use sysfs default attribute. Guard against write accesses after device removal to avoid modifying released memory. Update dummy pages handling to on demand allocation and release through drm managed framework. Add return value to scheduler job TO handler (by Luben Tuikov) and use this in amdgpu for prevention of GPU recovery post device unplug Also rebase on top of drm-misc-mext instead of amd-staging-drm-next With these patches I am able to gracefully remove the secondary card using sysfs remove hook while glxgears is running off of secondary card (DRI_PRIME=1) without kernel oopses or hangs and keep working with the primary card or soft reset the device without hangs or oopses TODOs for followup work: Convert AMDGPU code to use devm (for hw stuff) and drmm (for sw stuff and allocations) (Daniel) Support plugging the secondary device back after unplug - currently still experiencing HW error on plugging back. Add support for 'Requirements for KMS UAPI' section of [2] - unplugging primary, display connected card. [1] - Discussions during v3 of the patchset https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.spinics.net%2Flists%2Famd-gfx%2Fmsg55576.html&data=04%7C01%7CAndrey.Grodzovsky%40amd.com%7C9055ea164ca14a0cbce108d8bca53d37%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637466765176719365%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AqqeqmhF%2BZ1%2BRwMgtpmfoW1gtEnLGxiy3U5OMm%2BBqk8%3D&reserved=0 [2] - drm/doc: device hot-unplug for userspace https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.spinics.net%2Flists%2Fdri-devel%2Fmsg259755.html&data=04%7C01%7CAndrey.Grodzovsky%40amd.com%7C9055ea164ca14a0cbce108d8bca53d37%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637466765176719365%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=oHHyRtTMTNQAnkzptG0B8%2FeeniU1z2DSca8L4yCYJcE%3D&reserved=0 [3] - Related gitlab ticket https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fdrm%2Famd%2F-%2Fissues%2F1081&data=04%7C01%7CAndrey.G
Re: [PATCH v4 00/14] RFC Support hot device unplug in amdgpu
On Tue, Jan 19, 2021 at 6:31 PM Andrey Grodzovsky wrote: > > > On 1/19/21 9:16 AM, Daniel Vetter wrote: > > On Mon, Jan 18, 2021 at 04:01:09PM -0500, Andrey Grodzovsky wrote: > >> Until now extracting a card either by physical extraction (e.g. eGPU with > >> thunderbolt connection or by emulation through syfs -> > >> /sys/bus/pci/devices/device_id/remove) > >> would cause random crashes in user apps. The random crashes in apps were > >> mostly due to the app having mapped a device backed BO into its address > >> space was still trying to access the BO while the backing device was gone. > >> To answer this first problem Christian suggested to fix the handling of > >> mapped > >> memory in the clients when the device goes away by forcibly unmap all > >> buffers the > >> user processes has by clearing their respective VMAs mapping the device > >> BOs. > >> Then when the VMAs try to fill in the page tables again we check in the > >> fault > >> handlerif the device is removed and if so, return an error. This will > >> generate a > >> SIGBUS to the application which can then cleanly terminate.This indeed was > >> done > >> but this in turn created a problem of kernel OOPs were the OOPSes were due > >> to the > >> fact that while the app was terminating because of the SIGBUSit would > >> trigger use > >> after free in the driver by calling to accesses device structures that > >> were already > >> released from the pci remove sequence.This was handled by introducing a > >> 'flush' > >> sequence during device removal were we wait for drm file reference to drop > >> to 0 > >> meaning all user clients directly using this device terminated. > >> > >> v2: > >> Based on discussions in the mailing list with Daniel and Pekka [1] and > >> based on the document > >> produced by Pekka from those discussions [2] the whole approach with > >> returning SIGBUS and > >> waiting for all user clients having CPU mapping of device BOs to die was > >> dropped. > >> Instead as per the document suggestion the device structures are kept > >> alive until > >> the last reference to the device is dropped by user client and in the > >> meanwhile all existing and new CPU mappings of the BOs > >> belonging to the device directly or by dma-buf import are rerouted to per > >> user > >> process dummy rw page.Also, I skipped the 'Requirements for KMS UAPI' > >> section of [2] > >> since i am trying to get the minimal set of requirements that still give > >> useful solution > >> to work and this is the'Requirements for Render and Cross-Device UAPI' > >> section and so my > >> test case is removing a secondary device, which is render only and is not > >> involved > >> in KMS. > >> > >> v3: > >> More updates following comments from v2 such as removing loop to find DRM > >> file when rerouting > >> page faults to dummy page,getting rid of unnecessary sysfs handling > >> refactoring and moving > >> prevention of GPU recovery post device unplug from amdgpu to scheduler > >> layer. > >> On top of that added unplug support for the IOMMU enabled system. > >> > >> v4: > >> Drop last sysfs hack and use sysfs default attribute. > >> Guard against write accesses after device removal to avoid modifying > >> released memory. > >> Update dummy pages handling to on demand allocation and release through > >> drm managed framework. > >> Add return value to scheduler job TO handler (by Luben Tuikov) and use > >> this in amdgpu for prevention > >> of GPU recovery post device unplug > >> Also rebase on top of drm-misc-mext instead of amd-staging-drm-next > >> > >> With these patches I am able to gracefully remove the secondary card using > >> sysfs remove hook while glxgears > >> is running off of secondary card (DRI_PRIME=1) without kernel oopses or > >> hangs and keep working > >> with the primary card or soft reset the device without hangs or oopses > >> > >> TODOs for followup work: > >> Convert AMDGPU code to use devm (for hw stuff) and drmm (for sw stuff and > >> allocations) (Daniel) > >> Support plugging the secondary device back after unplug - currently still > >> experiencing HW error on plugging back. > >> Add support for 'Requirements for KMS UAPI' section of [2] - unplugging > >> primary, display connected card. > >> > >> [1] - Discussions during v3 of the patchset > >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.spinics.net%2Flists%2Famd-gfx%2Fmsg55576.html&data=04%7C01%7Candrey.grodzovsky%40amd.com%7C4b12f8caf53645eaf0c608d8bc84d7fa%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637466626035281917%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=E73dK7r1OBt1T9UcSt6kYbxYk9LL22EgizbpvkjfZ0c%3D&reserved=0 > >> [2] - drm/doc: device hot-unplug for userspace > >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.spinics.net%2Flists%2Fdri-devel%2Fmsg259755.html&data=04%7C01%7Candrey.grodzovsky%40amd.com%7C4b12f8caf53645eaf0c60
Re: [PATCH v4 11/14] drm/amdgpu: Guard against write accesses after device removal
On Tue, Jan 19, 2021 at 4:35 PM Andrey Grodzovsky
wrote:
>
> There is really no other way according to this article
> https://lwn.net/Articles/767885/
>
> "A perfect solution seems nearly impossible though; we cannot acquire a mutex
> on
> the user
> to prevent them from yanking a device and we cannot check for a presence
> change
> after every
> device access for performance reasons. "
>
> But I assumed srcu_read_lock should be pretty seamless performance wise, no ?
The read side is supposed to be dirt cheap, the write side is were we
just stall for all readers to eventually complete on their own.
Definitely should be much cheaper than mmio read, on the mmio write
side it might actually hurt a bit. Otoh I think those don't stall the
cpu by default when they're timing out, so maybe if the overhead is
too much for those, we could omit them?
Maybe just do a small microbenchmark for these for testing, with a
register that doesn't change hw state. So with and without
drm_dev_enter/exit, and also one with the hw plugged out so that we
have actual timeouts in the transactions.
-Daniel
> The other solution would be as I suggested to keep all the device IO ranges
> reserved and system
> memory pages unfreed until the device is finalized in the driver but Daniel
> said
> this would upset the PCI layer (the MMIO ranges reservation part).
>
> Andrey
>
>
>
>
> On 1/19/21 3:55 AM, Christian König wrote:
> > Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
> >> This should prevent writing to memory or IO ranges possibly
> >> already allocated for other uses after our device is removed.
> >
> > Wow, that adds quite some overhead to every register access. I'm not sure we
> > can do this.
> >
> > Christian.
> >
> >>
> >> Signed-off-by: Andrey Grodzovsky
> >> ---
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 57
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c| 9
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c| 53 +-
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h| 3 ++
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 70
> >> ++
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 49 ++---
> >> drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 16 ++-
> >> drivers/gpu/drm/amd/amdgpu/psp_v12_0.c | 8 +---
> >> drivers/gpu/drm/amd/amdgpu/psp_v3_1.c | 8 +---
> >> 9 files changed, 184 insertions(+), 89 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >> index e99f4f1..0a9d73c 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >> @@ -72,6 +72,8 @@
> >> #include
> >> +#include
> >> +
> >> MODULE_FIRMWARE("amdgpu/vega10_gpu_info.bin");
> >> MODULE_FIRMWARE("amdgpu/vega12_gpu_info.bin");
> >> MODULE_FIRMWARE("amdgpu/raven_gpu_info.bin");
> >> @@ -404,13 +406,21 @@ uint8_t amdgpu_mm_rreg8(struct amdgpu_device *adev,
> >> uint32_t offset)
> >>*/
> >> void amdgpu_mm_wreg8(struct amdgpu_device *adev, uint32_t offset, uint8_t
> >> value)
> >> {
> >> +int idx;
> >> +
> >> if (adev->in_pci_err_recovery)
> >> return;
> >> +
> >> +if (!drm_dev_enter(&adev->ddev, &idx))
> >> +return;
> >> +
> >> if (offset < adev->rmmio_size)
> >> writeb(value, adev->rmmio + offset);
> >> else
> >> BUG();
> >> +
> >> +drm_dev_exit(idx);
> >> }
> >> /**
> >> @@ -427,9 +437,14 @@ void amdgpu_device_wreg(struct amdgpu_device *adev,
> >> uint32_t reg, uint32_t v,
> >> uint32_t acc_flags)
> >> {
> >> +int idx;
> >> +
> >> if (adev->in_pci_err_recovery)
> >> return;
> >> +if (!drm_dev_enter(&adev->ddev, &idx))
> >> +return;
> >> +
> >> if ((reg * 4) < adev->rmmio_size) {
> >> if (!(acc_flags & AMDGPU_REGS_NO_KIQ) &&
> >> amdgpu_sriov_runtime(adev) &&
> >> @@ -444,6 +459,8 @@ void amdgpu_device_wreg(struct amdgpu_device *adev,
> >> }
> >> trace_amdgpu_device_wreg(adev->pdev->device, reg, v);
> >> +
> >> +drm_dev_exit(idx);
> >> }
> >> /*
> >> @@ -454,9 +471,14 @@ void amdgpu_device_wreg(struct amdgpu_device *adev,
> >> void amdgpu_mm_wreg_mmio_rlc(struct amdgpu_device *adev,
> >>uint32_t reg, uint32_t v)
> >> {
> >> +int idx;
> >> +
> >> if (adev->in_pci_err_recovery)
> >> return;
> >> +if (!drm_dev_enter(&adev->ddev, &idx))
> >> +return;
> >> +
> >> if (amdgpu_sriov_fullaccess(adev) &&
> >> adev->gfx.rlc.funcs &&
> >> adev->gfx.rlc.funcs->is_rlcg_access_range) {
> >> @@ -465,6 +487,8 @@ void amdgpu_mm_wreg_mmio_rlc(struct amdgpu_device
> >> *adev,
> >> } else {
> >> writel(v, ((void __iomem *)adev->rmmio) + (reg * 4));
> >> }
> >> +
> >> +drm_dev_exit(idx);
> >> }
Re: [PATCH] drm/msm: Call shutdown conditionally
On Tue, Jan 19, 2021 at 6:47 PM Fabio Estevam wrote:
>
> Calling the drm_atomic_helper_shutdown() on i.MX5 leads to
> the following flow:
>
> [ 24.557742] [] (msm_atomic_commit_tail) from []
> (commit_tail+0xa4/0x1b0)
> [ 24.566349] [] (commit_tail) from []
> (drm_atomic_helper_commit+0x154/0x188)
> [ 24.575193] [] (drm_atomic_helper_commit) from
> [] (drm_atomic_helper_disable_all+0x154/0x1c0)
> [ 24.585599] [] (drm_atomic_helper_disable_all) from
> [] (drm_atomic_helper_shutdown+0x94/0x12c)
> [ 24.596094] [] (drm_atomic_helper_shutdown) from
>
> In the i.MX5 case, priv->kms is not populated (as i.MX5 does not use any
> of the Qualcomm display controllers), causing a NULL pointer
> dereference in msm_atomic_commit_tail():
>
> [ 24.268964] 8<--- cut here ---
> [ 24.274602] Unable to handle kernel NULL pointer dereference at
> virtual address
> [ 24.283434] pgd = (ptrval)
> [ 24.286387] [] *pgd=ca212831
> [ 24.290788] Internal error: Oops: 17 [#1] SMP ARM
> [ 24.295609] Modules linked in:
> [ 24.298777] CPU: 0 PID: 197 Comm: init Not tainted
> 5.11.0-rc2-next-20210111 #333
> [ 24.306276] Hardware name: Freescale i.MX53 (Device Tree Support)
> [ 24.312442] PC is at msm_atomic_commit_tail+0x54/0xb9c
> [ 24.317743] LR is at commit_tail+0xa4/0x1b0
>
> Fix the problem by calling drm_atomic_helper_shutdown() conditionally.
>
> Cc:
> Fixes: 9d5cbf5fe46e ("drm/msm: add shutdown support for display
> platform_driver")
> Suggested-by: Rob Clark
> Signed-off-by: Fabio Estevam
> ---
> drivers/gpu/drm/msm/msm_drv.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index 108c405e03dd..c082b72b9e3b 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -1311,7 +1311,8 @@ static void msm_pdev_shutdown(struct platform_device
> *pdev)
> {
> struct drm_device *drm = platform_get_drvdata(pdev);
>
> - drm_atomic_helper_shutdown(drm);
> + if (get_mdp_ver(pdev))
> + drm_atomic_helper_shutdown(drm);
Don't we need the same treatment for suspend/resume too? Also if you
feel like follow up patch to push this into the helpers with a
DRIVER_MODESET check like I described would be kinda neat.
-Daniel
> }
>
> static const struct of_device_id dt_match[] = {
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Reboot crash at msm_atomic_commit_tail
On Tue, Jan 19, 2021 at 6:36 PM Fabio Estevam wrote: > > Hi Rob, > > On Tue, Jan 19, 2021 at 1:40 PM Rob Clark wrote: > > > > I suppose we should do the drm_atomic_helper_shutdown() conditionally? > > This suggestion works, thanks. I will submit a patch shortly. I think the cleanest way to do this is 2 patches: - add checks for DRIVER_MODESET to these helpers (there's a function to check these flags) - filter out DRIVER_MODESET flag in drm_device.driver_features (this is used to substract features at load time so that the drm_device struct can stay const) There's probably other drivers that'd need the same treatment (but they don't use these helpers yet). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 12/14] drm/scheduler: Job timeout handler returns status
On 2021-01-19 2:53 a.m., Christian König wrote:
> Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
>> From: Luben Tuikov
>>
>> This patch does not change current behaviour.
>>
>> The driver's job timeout handler now returns
>> status indicating back to the DRM layer whether
>> the task (job) was successfully aborted or whether
>> more time should be given to the task to complete.
>>
>> Default behaviour as of this patch, is preserved,
>> except in obvious-by-comment case in the Panfrost
>> driver, as documented below.
>>
>> All drivers which make use of the
>> drm_sched_backend_ops' .timedout_job() callback
>> have been accordingly renamed and return the
>> would've-been default value of
>> DRM_TASK_STATUS_ALIVE to restart the task's
>> timeout timer--this is the old behaviour, and
>> is preserved by this patch.
>>
>> In the case of the Panfrost driver, its timedout
>> callback correctly first checks if the job had
>> completed in due time and if so, it now returns
>> DRM_TASK_STATUS_COMPLETE to notify the DRM layer
>> that the task can be moved to the done list, to be
>> freed later. In the other two subsequent checks,
>> the value of DRM_TASK_STATUS_ALIVE is returned, as
>> per the default behaviour.
>>
>> A more involved driver's solutions can be had
>> in subequent patches.
>>
>> v2: Use enum as the status of a driver's job
>> timeout callback method.
>>
>> v4: (By Andrey Grodzovsky)
>> Replace DRM_TASK_STATUS_COMPLETE with DRM_TASK_STATUS_ENODEV
>> to enable a hint to the schduler for when NOT to rearm the
>> timeout timer.
> As Lukas pointed out returning the job (or task) status doesn't make
> much sense.
>
> What we return here is the status of the scheduler.
>
> I would either rename the enum or completely drop it and return a
> negative error status.
Yes, that could be had.
Although, dropping the enum and returning [-1, 0], might
make the return status meaning vague. Using an enum with an appropriate
name, makes the intention clear to the next programmer.
Now, Andrey did rename one of the enumerated values to
DRM_TASK_STATUS_ENODEV, perhaps the same but with:
enum drm_sched_status {
DRM_SCHED_STAT_NONE, /* Reserve 0 */
DRM_SCHED_STAT_NOMINAL,
DRM_SCHED_STAT_ENODEV,
};
and also renaming the enum to the above would be acceptable?
Regards,
Luben
> Apart from that looks fine to me,
> Christian.
>
>
>> Cc: Alexander Deucher
>> Cc: Andrey Grodzovsky
>> Cc: Christian König
>> Cc: Daniel Vetter
>> Cc: Lucas Stach
>> Cc: Russell King
>> Cc: Christian Gmeiner
>> Cc: Qiang Yu
>> Cc: Rob Herring
>> Cc: Tomeu Vizoso
>> Cc: Steven Price
>> Cc: Alyssa Rosenzweig
>> Cc: Eric Anholt
>> Reported-by: kernel test robot
>> Signed-off-by: Luben Tuikov
>> Signed-off-by: Andrey Grodzovsky
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 6 --
>> drivers/gpu/drm/etnaviv/etnaviv_sched.c | 10 +-
>> drivers/gpu/drm/lima/lima_sched.c | 4 +++-
>> drivers/gpu/drm/panfrost/panfrost_job.c | 9 ++---
>> drivers/gpu/drm/scheduler/sched_main.c | 4 +---
>> drivers/gpu/drm/v3d/v3d_sched.c | 32
>> +---
>> include/drm/gpu_scheduler.h | 17 ++---
>> 7 files changed, 54 insertions(+), 28 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
>> index ff48101..a111326 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
>> @@ -28,7 +28,7 @@
>> #include "amdgpu.h"
>> #include "amdgpu_trace.h"
>>
>> -static void amdgpu_job_timedout(struct drm_sched_job *s_job)
>> +static enum drm_task_status amdgpu_job_timedout(struct drm_sched_job *s_job)
>> {
>> struct amdgpu_ring *ring = to_amdgpu_ring(s_job->sched);
>> struct amdgpu_job *job = to_amdgpu_job(s_job);
>> @@ -41,7 +41,7 @@ static void amdgpu_job_timedout(struct drm_sched_job
>> *s_job)
>> amdgpu_ring_soft_recovery(ring, job->vmid, s_job->s_fence->parent))
>> {
>> DRM_ERROR("ring %s timeout, but soft recovered\n",
>>s_job->sched->name);
>> -return;
>> +return DRM_TASK_STATUS_ALIVE;
>> }
>>
>> amdgpu_vm_get_task_info(ring->adev, job->pasid, &ti);
>> @@ -53,10 +53,12 @@ static void amdgpu_job_timedout(struct drm_sched_job
>> *s_job)
>>
>> if (amdgpu_device_should_recover_gpu(ring->adev)) {
>> amdgpu_device_gpu_recover(ring->adev, job);
>> +return DRM_TASK_STATUS_ALIVE;
>> } else {
>> drm_sched_suspend_timeout(&ring->sched);
>> if (amdgpu_sriov_vf(adev))
>> adev->virt.tdr_debug = true;
>> +return DRM_TASK_STATUS_ALIVE;
>> }
>> }
>>
>> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>> b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>> index cd46c88..c495169 100644
>> --- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>> +++ b/drivers/g
[PATCH] drm/msm: Call shutdown conditionally
Calling the drm_atomic_helper_shutdown() on i.MX5 leads to
the following flow:
[ 24.557742] [] (msm_atomic_commit_tail) from []
(commit_tail+0xa4/0x1b0)
[ 24.566349] [] (commit_tail) from []
(drm_atomic_helper_commit+0x154/0x188)
[ 24.575193] [] (drm_atomic_helper_commit) from
[] (drm_atomic_helper_disable_all+0x154/0x1c0)
[ 24.585599] [] (drm_atomic_helper_disable_all) from
[] (drm_atomic_helper_shutdown+0x94/0x12c)
[ 24.596094] [] (drm_atomic_helper_shutdown) from
In the i.MX5 case, priv->kms is not populated (as i.MX5 does not use any
of the Qualcomm display controllers), causing a NULL pointer
dereference in msm_atomic_commit_tail():
[ 24.268964] 8<--- cut here ---
[ 24.274602] Unable to handle kernel NULL pointer dereference at
virtual address
[ 24.283434] pgd = (ptrval)
[ 24.286387] [] *pgd=ca212831
[ 24.290788] Internal error: Oops: 17 [#1] SMP ARM
[ 24.295609] Modules linked in:
[ 24.298777] CPU: 0 PID: 197 Comm: init Not tainted 5.11.0-rc2-next-20210111
#333
[ 24.306276] Hardware name: Freescale i.MX53 (Device Tree Support)
[ 24.312442] PC is at msm_atomic_commit_tail+0x54/0xb9c
[ 24.317743] LR is at commit_tail+0xa4/0x1b0
Fix the problem by calling drm_atomic_helper_shutdown() conditionally.
Cc:
Fixes: 9d5cbf5fe46e ("drm/msm: add shutdown support for display
platform_driver")
Suggested-by: Rob Clark
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/msm/msm_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 108c405e03dd..c082b72b9e3b 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1311,7 +1311,8 @@ static void msm_pdev_shutdown(struct platform_device
*pdev)
{
struct drm_device *drm = platform_get_drvdata(pdev);
- drm_atomic_helper_shutdown(drm);
+ if (get_mdp_ver(pdev))
+ drm_atomic_helper_shutdown(drm);
}
static const struct of_device_id dt_match[] = {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Reboot crash at msm_atomic_commit_tail
Hi Rob, On Tue, Jan 19, 2021 at 1:40 PM Rob Clark wrote: > > I suppose we should do the drm_atomic_helper_shutdown() conditionally? This suggestion works, thanks. I will submit a patch shortly. Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 00/14] RFC Support hot device unplug in amdgpu
On 1/19/21 9:16 AM, Daniel Vetter wrote: On Mon, Jan 18, 2021 at 04:01:09PM -0500, Andrey Grodzovsky wrote: Until now extracting a card either by physical extraction (e.g. eGPU with thunderbolt connection or by emulation through syfs -> /sys/bus/pci/devices/device_id/remove) would cause random crashes in user apps. The random crashes in apps were mostly due to the app having mapped a device backed BO into its address space was still trying to access the BO while the backing device was gone. To answer this first problem Christian suggested to fix the handling of mapped memory in the clients when the device goes away by forcibly unmap all buffers the user processes has by clearing their respective VMAs mapping the device BOs. Then when the VMAs try to fill in the page tables again we check in the fault handlerif the device is removed and if so, return an error. This will generate a SIGBUS to the application which can then cleanly terminate.This indeed was done but this in turn created a problem of kernel OOPs were the OOPSes were due to the fact that while the app was terminating because of the SIGBUSit would trigger use after free in the driver by calling to accesses device structures that were already released from the pci remove sequence.This was handled by introducing a 'flush' sequence during device removal were we wait for drm file reference to drop to 0 meaning all user clients directly using this device terminated. v2: Based on discussions in the mailing list with Daniel and Pekka [1] and based on the document produced by Pekka from those discussions [2] the whole approach with returning SIGBUS and waiting for all user clients having CPU mapping of device BOs to die was dropped. Instead as per the document suggestion the device structures are kept alive until the last reference to the device is dropped by user client and in the meanwhile all existing and new CPU mappings of the BOs belonging to the device directly or by dma-buf import are rerouted to per user process dummy rw page.Also, I skipped the 'Requirements for KMS UAPI' section of [2] since i am trying to get the minimal set of requirements that still give useful solution to work and this is the'Requirements for Render and Cross-Device UAPI' section and so my test case is removing a secondary device, which is render only and is not involved in KMS. v3: More updates following comments from v2 such as removing loop to find DRM file when rerouting page faults to dummy page,getting rid of unnecessary sysfs handling refactoring and moving prevention of GPU recovery post device unplug from amdgpu to scheduler layer. On top of that added unplug support for the IOMMU enabled system. v4: Drop last sysfs hack and use sysfs default attribute. Guard against write accesses after device removal to avoid modifying released memory. Update dummy pages handling to on demand allocation and release through drm managed framework. Add return value to scheduler job TO handler (by Luben Tuikov) and use this in amdgpu for prevention of GPU recovery post device unplug Also rebase on top of drm-misc-mext instead of amd-staging-drm-next With these patches I am able to gracefully remove the secondary card using sysfs remove hook while glxgears is running off of secondary card (DRI_PRIME=1) without kernel oopses or hangs and keep working with the primary card or soft reset the device without hangs or oopses TODOs for followup work: Convert AMDGPU code to use devm (for hw stuff) and drmm (for sw stuff and allocations) (Daniel) Support plugging the secondary device back after unplug - currently still experiencing HW error on plugging back. Add support for 'Requirements for KMS UAPI' section of [2] - unplugging primary, display connected card. [1] - Discussions during v3 of the patchset https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.spinics.net%2Flists%2Famd-gfx%2Fmsg55576.html&data=04%7C01%7Candrey.grodzovsky%40amd.com%7C4b12f8caf53645eaf0c608d8bc84d7fa%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637466626035281917%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=E73dK7r1OBt1T9UcSt6kYbxYk9LL22EgizbpvkjfZ0c%3D&reserved=0 [2] - drm/doc: device hot-unplug for userspace https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.spinics.net%2Flists%2Fdri-devel%2Fmsg259755.html&data=04%7C01%7Candrey.grodzovsky%40amd.com%7C4b12f8caf53645eaf0c608d8bc84d7fa%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637466626035291908%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EAzrOrNd14IA6gjjCVi9mAQJQZbcrFQbRNC3bN9gVQc%3D&reserved=0 [3] - Related gitlab ticket https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fdrm%2Famd%2F-%2Fissues%2F1081&data=04%7C01%7Candrey.grodzovsky%40amd.com%7C4b12f8caf53645eaf0c608d8bc84d7fa%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63746662603
Re: [PATCH v2 5/7] drm/msm: Add dependency on io-pgtable-arm format module
On Mon, Jan 18, 2021 at 1:39 PM Will Deacon wrote: > > On Mon, Jan 18, 2021 at 01:16:03PM -0800, Rob Clark wrote: > > On Mon, Dec 21, 2020 at 4:44 PM Isaac J. Manjarres > > wrote: > > > > > > The MSM DRM driver depends on the availability of the ARM LPAE io-pgtable > > > format code to work properly. In preparation for having the io-pgtable > > > formats as modules, add a "pre" dependency with MODULE_SOFTDEP() to > > > ensure that the io-pgtable-arm format module is loaded before loading > > > the MSM DRM driver module. > > > > > > Signed-off-by: Isaac J. Manjarres > > > > Thanks, I've queued this up locally > > I don't plan to make the io-pgtable code modular, so please drop this patch. > > https://lore.kernel.org/r/20210106123428.GA1798@willie-the-truck Ok, done. Thanks BR, -R ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Reboot crash at msm_atomic_commit_tail
forgot to CC Krishna On Tue, Jan 19, 2021 at 8:34 AM Rob Clark wrote: > > On Mon, Jan 18, 2021 at 11:00 PM Daniel Vetter wrote: > > > > On Mon, Jan 18, 2021 at 11:00 PM Fabio Estevam wrote: > > > > > > On Mon, Jan 18, 2021 at 6:44 PM Fabio Estevam wrote: > > > > > > > > Adding some more folks in case anyone has any suggestions to fix this > > > > reboot hang. > > > > > > Not sure if this is a valid fix, but the change below makes reboot > > > works correctly. > > > > > > kmscube still works. > > > > > > --- a/drivers/gpu/drm/msm/msm_atomic.c > > > +++ b/drivers/gpu/drm/msm/msm_atomic.c > > > @@ -207,8 +207,12 @@ void msm_atomic_commit_tail(struct drm_atomic_state > > > *state) > > > struct msm_kms *kms = priv->kms; > > > struct drm_crtc *async_crtc = NULL; > > > unsigned crtc_mask = get_crtc_mask(state); > > > - bool async = kms->funcs->vsync_time && > > > - can_do_async(state, &async_crtc); > > > + bool async; > > > + > > > + if (!kms) > > > + return; > > > > That looks a bit like a hack papering over the real issue. > > > > From your report it sounds like earlier kernels worked, did you > > attempt bisecting? Also for regressions put regressions into the > > subject, it's the magic work that gets much more attention. > > the root issue is how are we doing KMS stuff on imx (where drm/msm is > only used for gpu).. which I think is this commit: > > -- > commit 9d5cbf5fe46e350715389d89d0c350d83289a102 > Author: Krishna Manikandan > AuthorDate: Mon Jun 1 16:33:22 2020 +0530 > Commit: Rob Clark > CommitDate: Tue Aug 18 08:09:01 2020 -0700 > > drm/msm: add shutdown support for display platform_driver > > Define shutdown callback for display drm driver, > so as to disable all the CRTCS when shutdown > notification is received by the driver. > > This change will turn off the timing engine so > that no display transactions are requested > while mmu translations are getting disabled > during reboot sequence. > > Signed-off-by: Krishna Manikandan > > Changes in v2: > - Remove NULL check from msm_pdev_shutdown (Stephen Boyd) > - Change commit text to reflect when this issue > was uncovered (Sai Prakash Ranjan) > > Signed-off-by: Rob Clark > -- > > I suppose we should do the drm_atomic_helper_shutdown() conditionally? > Or the helper should bail if there is no kms? > > BR, > -R > > > -Daniel > > > > > + > > > + async = kms->funcs->vsync_time && can_do_async(state, > > > &async_crtc); > > > > > > trace_msm_atomic_commit_tail_start(async, crtc_mask); > > > > > > Any comments? > > > > > > Thanks > > > ___ > > > dri-devel mailing list > > > dri-devel@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 10/14] dmr/amdgpu: Move some sysfs attrs creation to default_attr
On 1/19/21 2:34 AM, Greg KH wrote:
On Mon, Jan 18, 2021 at 04:01:19PM -0500, Andrey Grodzovsky wrote:
static struct pci_driver amdgpu_kms_pci_driver = {
.name = DRIVER_NAME,
.id_table = pciidlist,
@@ -1595,6 +1607,7 @@ static struct pci_driver amdgpu_kms_pci_driver = {
.shutdown = amdgpu_pci_shutdown,
.driver.pm = &amdgpu_pm_ops,
.err_handler = &amdgpu_pci_err_handler,
+ .driver.dev_groups = amdgpu_sysfs_groups,
Shouldn't this just be:
groups - amdgpu_sysfs_groups,
Why go to the "driver root" here?
Because I still didn't get to your suggestion to propose a patch to add groups
to
pci_driver, it's located in 'base' driver struct.
Andrey
Other than that tiny thing, looks good to me, nice cleanup!
greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Reboot crash at msm_atomic_commit_tail
On Mon, Jan 18, 2021 at 11:00 PM Daniel Vetter wrote: > > On Mon, Jan 18, 2021 at 11:00 PM Fabio Estevam wrote: > > > > On Mon, Jan 18, 2021 at 6:44 PM Fabio Estevam wrote: > > > > > > Adding some more folks in case anyone has any suggestions to fix this > > > reboot hang. > > > > Not sure if this is a valid fix, but the change below makes reboot > > works correctly. > > > > kmscube still works. > > > > --- a/drivers/gpu/drm/msm/msm_atomic.c > > +++ b/drivers/gpu/drm/msm/msm_atomic.c > > @@ -207,8 +207,12 @@ void msm_atomic_commit_tail(struct drm_atomic_state > > *state) > > struct msm_kms *kms = priv->kms; > > struct drm_crtc *async_crtc = NULL; > > unsigned crtc_mask = get_crtc_mask(state); > > - bool async = kms->funcs->vsync_time && > > - can_do_async(state, &async_crtc); > > + bool async; > > + > > + if (!kms) > > + return; > > That looks a bit like a hack papering over the real issue. > > From your report it sounds like earlier kernels worked, did you > attempt bisecting? Also for regressions put regressions into the > subject, it's the magic work that gets much more attention. the root issue is how are we doing KMS stuff on imx (where drm/msm is only used for gpu).. which I think is this commit: -- commit 9d5cbf5fe46e350715389d89d0c350d83289a102 Author: Krishna Manikandan AuthorDate: Mon Jun 1 16:33:22 2020 +0530 Commit: Rob Clark CommitDate: Tue Aug 18 08:09:01 2020 -0700 drm/msm: add shutdown support for display platform_driver Define shutdown callback for display drm driver, so as to disable all the CRTCS when shutdown notification is received by the driver. This change will turn off the timing engine so that no display transactions are requested while mmu translations are getting disabled during reboot sequence. Signed-off-by: Krishna Manikandan Changes in v2: - Remove NULL check from msm_pdev_shutdown (Stephen Boyd) - Change commit text to reflect when this issue was uncovered (Sai Prakash Ranjan) Signed-off-by: Rob Clark -- I suppose we should do the drm_atomic_helper_shutdown() conditionally? Or the helper should bail if there is no kms? BR, -R > -Daniel > > > + > > + async = kms->funcs->vsync_time && can_do_async(state, &async_crtc); > > > > trace_msm_atomic_commit_tail_start(async, crtc_mask); > > > > Any comments? > > > > Thanks > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/imx: ipuv3-plane: do not advertise YUV formats on planes without CSC
Hi Phillip, On Tue, Jan 19, 2021 at 11:08 AM Philipp Zabel wrote: > > Only planes that are displayed via the Display Processor (DP) path > support color space conversion. Limit formats on planes that are > shown via the direct Display Controller (DC) path to RGB. > > Reported-by: Fabio Estevam > Signed-off-by: Philipp Zabel With the IPU workaround you sent yesterday, I am able to play video with the correct colors. If I don't apply that patch and only apply this one, then the Gstreamer pipeline does not start: # gst-launch-1.0 filesrc -v location=/media/clip.mp4 ! qtdemux ! h264parse ! v4l2h264dec ! video/x-raw,format=NV12 ! kmssink Setting pipeline to PAUSED ... [ 14.836438] msm msm: [drm:adreno_request_fw] loaded qcom/yamato_pm4.fw from new location [ 14.847716] msm msm: [drm:adreno_request_fw] loaded qcom/yamato_pfp.fw from new location [ 16.103923] random: crng init done Pipeline is PREROLLING ... /GstPipeline:pipeline0/GstKMSSink:kmssink0: display-width = 1024 /GstPipeline:pipeline0/GstKMSSink:kmssink0: display-height = 576 WARNING: from element /GstPipeline:pipeline0/GstQTDemux:qtdemux0: Delayed linking failed. Additional debug info: gst/parse/grammar.y(540): gst_parse_no_more_pads (): /GstPipeline:pipeline0/GstQTDemux:qtdemux0: failed delayed linking some pad of GstQTDemux named qtdemux0 to some pad of GstH264Parse named h264parse0 ERROR: from element /GstPipeline:pipeline0/GstQTDemux:qtdemux0: Internal data stream error. Additional debug info: ../gst/isomp4/qtdemux.c(6545): gst_qtdemux_loop (): /GstPipeline:pipeline0/GstQTDemux:qtdemux0: streaming stopped, reason not-linked (-1) ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Freeing pipeline ... Any ideas? Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/3] drm/amd/display: Add module parameter for freesync video mode
[AMD Official Use Only - Internal Distribution Only] Hi Daniel, Could you please be more specific about the _unsafe API options you mentioned ? -- Thanks & Regards, Aurabindo Pillai From: Daniel Vetter Sent: Tuesday, January 19, 2021 8:11 AM To: Pekka Paalanen Cc: Pillai, Aurabindo ; amd-gfx list ; dri-devel ; Kazlauskas, Nicholas ; Wang, Chao-kai (Stylon) ; Thai, Thong ; Sharma, Shashank ; Lin, Wayne ; Deucher, Alexander ; Koenig, Christian Subject: Re: [PATCH v3 1/3] drm/amd/display: Add module parameter for freesync video mode On Tue, Jan 19, 2021 at 9:35 AM Pekka Paalanen wrote: > > On Mon, 18 Jan 2021 09:36:47 -0500 > Aurabindo Pillai wrote: > > > On Thu, 2021-01-14 at 11:14 +0200, Pekka Paalanen wrote: > > > > > > Hi, > > > > > > please document somewhere that ends up in git history (commit > > > message, > > > code comments, description of the parameter would be the best but > > > maybe > > > there isn't enough space?) what Christian König explained in > > > > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fdri-devel%2F2020-December%2F291254.html&data=04%7C01%7Caurabindo.pillai%40amd.com%7C56ba07934c5c48e7ad7b08d8bc7bb4a9%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637466586800649481%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=GM0ZEM9JeFM5os13E1zlVy8Bn3D8Kxmo%2FajSG02WsGI%3D&reserved=0 > > > > > > that this is a stop-gap feature intended to be removed as soon as > > > possible (when a better solution comes up, which could be years). > > > > > > So far I have not seen a single mention of this intention in your > > > patch > > > submissions, and I think it is very important to make known. > > > > Hi, > > > > Thanks for the headsup, I shall add the relevant info in the next > > verison. > > > > > > > > I also did not see an explanation of why this instead of > > > manufacturing > > > these video modes in userspace (an idea mentioned by Christian in the > > > referenced email). I think that too should be part of a commit > > > message. > > > > This is an opt-in feature, which shall be superseded by a better > > solution. We also add a set of common modes for scaling similarly. > > Userspace can still add whatever mode they want. So I dont see a reason > > why this cant be in the kernel. > > Hi, > > sorry, I think that kind of thinking is backwards. There needs to be a > reason to put something in the kernel, and if there is no reason, then > it remains in userspace. So what's the reason to put this in the kernel? > > One example reason why this should not be in the kernel is that the set > of video modes to manufacture is a kind of policy, which modes to add > and which not. Userspace knows what modes it needs, and establishing > the modes in the kernel instead is second-guessing what the userspace > would want. So if userspace needs to manufacture modes in userspace > anyway as some modes might be missed by the kernel, then why bother in > the kernel to begin with? Why should the kernel play catch-up with what > modes userspace wants when we already have everything userspace needs > to make its own modes, even to add them to the kernel mode list? > > Does manufacturing these extra video modes to achieve fast timing > changes require AMD hardware-specific knowledge, as opposed to the > general VRR approach of simply adjusting the front porch? > > Something like this should also be documented in a commit message. Or > if you insist that "no reason to not put this in the kernel" is reason > enough, then write that down, because it does not seem obvious to me or > others that this feature needs to be in the kernel. One reason might be debugging, if a feature is known to cause issues. But imo in that case the knob should be using the _unsafe variants so it taints the kernel, since otherwise we get stuck in this very cozy place where kernel maintainers don't have to care much for bugs "because it's off by default", but also not really care about polishing the feature "since users can just enable it if they want it". Just a slightly different flavour of what you're explaining above already. -Daniel > Thanks, > pq -- Daniel Vetter Software Engineer, Intel Corporation https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fblog.ffwll.ch%2F&data=04%7C01%7Caurabindo.pillai%40amd.com%7C56ba07934c5c48e7ad7b08d8bc7bb4a9%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637466586800649481%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2isCpwa3V92TnO4njhe9cQjdWVdsV1GQMo7WP7buVZI%3D&reserved=0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 12/17] PCI: Revoke mappings like devmem
On Tue, Jan 19, 2021 at 4:20 PM Greg Kroah-Hartman
wrote:
>
> On Tue, Jan 19, 2021 at 03:34:47PM +0100, Daniel Vetter wrote:
> > On Tue, Jan 19, 2021 at 3:32 PM Greg Kroah-Hartman
> > wrote:
> > >
> > > On Tue, Jan 19, 2021 at 09:17:55AM +0100, Daniel Vetter wrote:
> > > > On Fri, Nov 27, 2020 at 5:42 PM Daniel Vetter
> > > > wrote:
> > > > >
> > > > > Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims
> > > > > the region") /dev/kmem zaps ptes when the kernel requests exclusive
> > > > > acccess to an iomem region. And with CONFIG_IO_STRICT_DEVMEM, this is
> > > > > the default for all driver uses.
> > > > >
> > > > > Except there's two more ways to access PCI BARs: sysfs and proc mmap
> > > > > support. Let's plug that hole.
> > > > >
> > > > > For revoke_devmem() to work we need to link our vma into the same
> > > > > address_space, with consistent vma->vm_pgoff. ->pgoff is already
> > > > > adjusted, because that's how (io_)remap_pfn_range works, but for the
> > > > > mapping we need to adjust vma->vm_file->f_mapping. The cleanest way is
> > > > > to adjust this at at ->open time:
> > > > >
> > > > > - for sysfs this is easy, now that binary attributes support this. We
> > > > > just set bin_attr->mapping when mmap is supported
> > > > > - for procfs it's a bit more tricky, since procfs pci access has only
> > > > > one file per device, and access to a specific resources first needs
> > > > > to be set up with some ioctl calls. But mmap is only supported for
> > > > > the same resources as sysfs exposes with mmap support, and otherwise
> > > > > rejected, so we can set the mapping unconditionally at open time
> > > > > without harm.
> > > > >
> > > > > A special consideration is for arch_can_pci_mmap_io() - we need to
> > > > > make sure that the ->f_mapping doesn't alias between ioport and iomem
> > > > > space. There's only 2 ways in-tree to support mmap of ioports: generic
> > > > > pci mmap (ARCH_GENERIC_PCI_MMAP_RESOURCE), and sparc as the single
> > > > > architecture hand-rolling. Both approach support ioport mmap through a
> > > > > special pfn range and not through magic pte attributes. Aliasing is
> > > > > therefore not a problem.
> > > > >
> > > > > The only difference in access checks left is that sysfs PCI mmap does
> > > > > not check for CAP_RAWIO. I'm not really sure whether that should be
> > > > > added or not.
> > > > >
> > > > > Acked-by: Bjorn Helgaas
> > > > > Reviewed-by: Dan Williams
> > > > > Signed-off-by: Daniel Vetter
> > > > > Cc: Jason Gunthorpe
> > > > > Cc: Kees Cook
> > > > > Cc: Dan Williams
> > > > > Cc: Andrew Morton
> > > > > Cc: John Hubbard
> > > > > Cc: Jérôme Glisse
> > > > > Cc: Jan Kara
> > > > > Cc: Dan Williams
> > > > > Cc: Greg Kroah-Hartman
> > > > > Cc: linux...@kvack.org
> > > > > Cc: linux-arm-ker...@lists.infradead.org
> > > > > Cc: linux-samsung-...@vger.kernel.org
> > > > > Cc: linux-me...@vger.kernel.org
> > > > > Cc: Bjorn Helgaas
> > > > > Cc: linux-...@vger.kernel.org
> > > > > Signed-off-by: Daniel Vetter
> > > > > --
> > > > > v2:
> > > > > - Totally new approach: Adjust filp->f_mapping at open time. Note that
> > > > > this now works on all architectures, not just those support
> > > > > ARCH_GENERIC_PCI_MMAP_RESOURCE
> > > > > ---
> > > > > drivers/pci/pci-sysfs.c | 4
> > > > > drivers/pci/proc.c | 1 +
> > > > > 2 files changed, 5 insertions(+)
> > > > >
> > > > > diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> > > > > index d15c881e2e7e..3f1c31bc0b7c 100644
> > > > > --- a/drivers/pci/pci-sysfs.c
> > > > > +++ b/drivers/pci/pci-sysfs.c
> > > > > @@ -929,6 +929,7 @@ void pci_create_legacy_files(struct pci_bus *b)
> > > > > b->legacy_io->read = pci_read_legacy_io;
> > > > > b->legacy_io->write = pci_write_legacy_io;
> > > > > b->legacy_io->mmap = pci_mmap_legacy_io;
> > > > > + b->legacy_io->mapping = iomem_get_mapping();
> > > > > pci_adjust_legacy_attr(b, pci_mmap_io);
> > > > > error = device_create_bin_file(&b->dev, b->legacy_io);
> > > > > if (error)
> > > > > @@ -941,6 +942,7 @@ void pci_create_legacy_files(struct pci_bus *b)
> > > > > b->legacy_mem->size = 1024*1024;
> > > > > b->legacy_mem->attr.mode = 0600;
> > > > > b->legacy_mem->mmap = pci_mmap_legacy_mem;
> > > > > + b->legacy_io->mapping = iomem_get_mapping();
> > > >
> > > > Unlike the normal pci stuff below, the legacy files here go boom
> > > > because they're set up much earlier in the boot sequence. This only
> > > > affects HAVE_PCI_LEGACY architectures, which aren't that many. So what
> > > > should we do here now:
> > > > - drop the devmem revoke for these
> > > > - rework the init sequence somehow to set up these files a lot later
> > > > - redo the sysfs patch so that it doesn't take an address_space
> > > > pointer, but instead a callback to get at that (since at open time
> > > > everything is set up). I
Re: [PATCH] drm/syncobj: make lockdep complain on WAIT_FOR_SUBMIT v3
On Tue, Jan 19, 2021 at 02:05:09PM +0100, Daniel Vetter wrote:
> > diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
> > index b9e9adec73e8..6eb117c0d0f3 100644
> > --- a/include/linux/lockdep.h
> > +++ b/include/linux/lockdep.h
> > @@ -310,6 +310,10 @@ extern void lock_unpin_lock(struct lockdep_map *lock,
> > struct pin_cookie);
> > WARN_ON_ONCE(debug_locks && !lockdep_is_held(l)); \
> > } while (0)
> >
> > +#define lockdep_assert_none_held_once()do {
> > \
> > + WARN_ON_ONCE(debug_locks && current->lockdep_depth);\
> > + } while (0)
> > +
> > #define lockdep_recursing(tsk) ((tsk)->lockdep_recursion)
> >
> > #define lockdep_pin_lock(l)lock_pin_lock(&(l)->dep_map)
> > @@ -387,6 +391,7 @@ extern int lockdep_is_held(const void *);
> > #define lockdep_assert_held_write(l) do { (void)(l); } while (0)
> > #define lockdep_assert_held_read(l)do { (void)(l); } while (0)
> > #define lockdep_assert_held_once(l)do { (void)(l); } while (0)
> > +#define lockdep_assert_none_held_once()do { } while (0)
> >
> > #define lockdep_recursing(tsk) (0)
>
> ofc needs ack from Peter, but drm parts look all good to me.
Acked-by: Peter Zijlstra (Intel)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drivers/nouveau/kms/nv50-: Reject format modifiers for cursor planes
Gah, yes, good catch.
Reviewed-by: James Jones
On 1/18/21 5:54 PM, Lyude Paul wrote:
Nvidia hardware doesn't actually support using tiling formats with the
cursor plane, only linear is allowed. In the future, we should write a
testcase for this.
Fixes: c586f30bf74c ("drm/nouveau/kms: Add format mod prop to base/ovly/nvdisp")
Cc: James Jones
Cc: Martin Peres
Cc: Jeremy Cline
Cc: Simon Ser
Cc: # v5.8+
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
index ce451242f79e..271de3a63f21 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
@@ -702,6 +702,11 @@ nv50_wndw_init(struct nv50_wndw *wndw)
nvif_notify_get(&wndw->notify);
}
+static const u64 nv50_cursor_format_modifiers[] = {
+ DRM_FORMAT_MOD_LINEAR,
+ DRM_FORMAT_MOD_INVALID,
+};
+
int
nv50_wndw_new_(const struct nv50_wndw_func *func, struct drm_device *dev,
enum drm_plane_type type, const char *name, int index,
@@ -713,6 +718,7 @@ nv50_wndw_new_(const struct nv50_wndw_func *func, struct
drm_device *dev,
struct nvif_mmu *mmu = &drm->client.mmu;
struct nv50_disp *disp = nv50_disp(dev);
struct nv50_wndw *wndw;
+ const u64 *format_modifiers;
int nformat;
int ret;
@@ -728,10 +734,13 @@ nv50_wndw_new_(const struct nv50_wndw_func *func, struct drm_device *dev,
for (nformat = 0; format[nformat]; nformat++);
- ret = drm_universal_plane_init(dev, &wndw->plane, heads, &nv50_wndw,
- format, nformat,
- nouveau_display(dev)->format_modifiers,
- type, "%s-%d", name, index);
+ if (type == DRM_PLANE_TYPE_CURSOR)
+ format_modifiers = nv50_cursor_format_modifiers;
+ else
+ format_modifiers = nouveau_display(dev)->format_modifiers;
+
+ ret = drm_universal_plane_init(dev, &wndw->plane, heads, &nv50_wndw,
format, nformat,
+ format_modifiers, type, "%s-%d", name,
index);
if (ret) {
kfree(*pwndw);
*pwndw = NULL;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/amd/display: Add freesync video modes based on preferred modes
[Why]
While possible for userspace to create and add custom mode based off the
optimized mode for the connected display which differs only in front porch
timing, this patch set adds a list of common video modes in advance.
The list of common video refresh rates is small, well known and the optimized
mode has specific requirements to be able to enable HW frame doubling and
tripling so it makes most sense to create the modes that video players will need
in advance. The optimized mode matches the preferred mode resolution but has the
highest refresh rate available to enable the largest front porch extension.
[How]
Find the optimized mode and store it on the connector so we can check it
later during our optimized modeset.
Prepopulate the mode list with a list of common video mades based on the
optimized mode (but with a longer front porch) if the panel doesn't support a
variant of the mode natively.
Signed-off-by: Aurabindo Pillai
Acked-by: Christian König
Reviewed-by: Shashank Sharma
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 170 ++
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 2 +
2 files changed, 172 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 245bd1284e5f..aaef2fb528fd 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5174,6 +5174,59 @@ static void dm_enable_per_frame_crtc_master_sync(struct
dc_state *context)
set_master_stream(context->streams, context->stream_count);
}
+static struct drm_display_mode *
+get_highest_refresh_rate_mode(struct amdgpu_dm_connector *aconnector,
+ bool use_probed_modes)
+{
+ struct drm_display_mode *m, *m_pref = NULL;
+ u16 current_refresh, highest_refresh;
+ struct list_head *list_head = use_probed_modes ?
+
&aconnector->base.probed_modes :
+ &aconnector->base.modes;
+
+ if (aconnector->freesync_vid_base.clock != 0)
+ return &aconnector->freesync_vid_base;
+
+ /* Find the preferred mode */
+ list_for_each_entry (m, list_head, head) {
+ if (m->type & DRM_MODE_TYPE_PREFERRED) {
+ m_pref = m;
+ break;
+ }
+ }
+
+ if (!m_pref) {
+ /* Probably an EDID with no preferred mode. Fallback to first
entry */
+ m_pref = list_first_entry_or_null(
+ &aconnector->base.modes, struct drm_display_mode, head);
+ if (!m_pref) {
+ DRM_DEBUG_DRIVER("No preferred mode found in EDID\n");
+ return NULL;
+ }
+ }
+
+ highest_refresh = drm_mode_vrefresh(m_pref);
+
+ /*
+* Find the mode with highest refresh rate with same resolution.
+* For some monitors, preferred mode is not the mode with highest
+* supported refresh rate.
+*/
+ list_for_each_entry (m, list_head, head) {
+ current_refresh = drm_mode_vrefresh(m);
+
+ if (m->hdisplay == m_pref->hdisplay &&
+ m->vdisplay == m_pref->vdisplay &&
+ highest_refresh < current_refresh) {
+ highest_refresh = current_refresh;
+ m_pref = m;
+ }
+ }
+
+ aconnector->freesync_vid_base = *m_pref;
+ return m_pref;
+}
+
static struct dc_stream_state *
create_stream_for_sink(struct amdgpu_dm_connector *aconnector,
const struct drm_display_mode *drm_mode,
@@ -6999,6 +7052,122 @@ static void amdgpu_dm_connector_ddc_get_modes(struct
drm_connector *connector,
}
}
+static bool is_duplicate_mode(struct amdgpu_dm_connector *aconnector,
+ struct drm_display_mode *mode)
+{
+ struct drm_display_mode *m;
+
+ list_for_each_entry (m, &aconnector->base.probed_modes, head) {
+ if (drm_mode_equal(m, mode))
+ return true;
+ }
+
+ return false;
+}
+
+static uint add_fs_modes(struct amdgpu_dm_connector *aconnector,
+struct detailed_data_monitor_range *range)
+{
+ const struct drm_display_mode *m;
+ struct drm_display_mode *new_mode;
+ uint i;
+ uint32_t new_modes_count = 0;
+
+ /* Standard FPS values
+*
+* 23.976 - TV/NTSC
+* 24 - Cinema
+* 25 - TV/PAL
+* 29.97- TV/NTSC
+* 30 - TV/NTSC
+* 48 - Cinema HFR
+* 50 - TV/PAL
+* 60 - Commonly used
+* 48,72,96 - Multiples of 24
+*/
+ const uint32_t common_rates[] = { 23976, 24000, 25000, 29970, 3,
+48000, 5, 6000
[PATCH 3/3] drm/amd/display: Skip modeset for front porch change
[Why]
A seamless transition between modes can be performed if the new incoming
mode has the same timing parameters as the optimized mode on a display with a
variable vtotal min/max.
Smooth video playback usecases can be enabled with this seamless transition by
switching to a new mode which has a refresh rate matching the video.
[How]
Skip full modeset if userspace requested a compatible freesync mode which only
differs in the front porch timing from the current mode.
Signed-off-by: Aurabindo Pillai
Acked-by: Christian König
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 233 +++---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 1 +
2 files changed, 198 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index aaef2fb528fd..d66494cdd8c8 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -213,6 +213,9 @@ static bool amdgpu_dm_psr_disable_all(struct
amdgpu_display_manager *dm);
static const struct drm_format_info *
amd_get_format_info(const struct drm_mode_fb_cmd2 *cmd);
+static bool
+is_timing_unchanged_for_freesync(struct drm_crtc_state *old_crtc_state,
+struct drm_crtc_state *new_crtc_state);
/*
* dm_vblank_get_counter
*
@@ -4940,7 +4943,8 @@ static void fill_stream_properties_from_drm_display_mode(
const struct drm_connector *connector,
const struct drm_connector_state *connector_state,
const struct dc_stream_state *old_stream,
- int requested_bpc)
+ int requested_bpc,
+ bool is_in_modeset)
{
struct dc_crtc_timing *timing_out = &stream->timing;
const struct drm_display_info *info = &connector->display_info;
@@ -4995,19 +4999,28 @@ static void
fill_stream_properties_from_drm_display_mode(
timing_out->hdmi_vic = hv_frame.vic;
}
- timing_out->h_addressable = mode_in->crtc_hdisplay;
- timing_out->h_total = mode_in->crtc_htotal;
- timing_out->h_sync_width =
- mode_in->crtc_hsync_end - mode_in->crtc_hsync_start;
- timing_out->h_front_porch =
- mode_in->crtc_hsync_start - mode_in->crtc_hdisplay;
- timing_out->v_total = mode_in->crtc_vtotal;
- timing_out->v_addressable = mode_in->crtc_vdisplay;
- timing_out->v_front_porch =
- mode_in->crtc_vsync_start - mode_in->crtc_vdisplay;
- timing_out->v_sync_width =
- mode_in->crtc_vsync_end - mode_in->crtc_vsync_start;
- timing_out->pix_clk_100hz = mode_in->crtc_clock * 10;
+ if (is_in_modeset) {
+ timing_out->h_addressable = mode_in->hdisplay;
+ timing_out->h_total = mode_in->htotal;
+ timing_out->h_sync_width = mode_in->hsync_end -
mode_in->hsync_start;
+ timing_out->h_front_porch = mode_in->hsync_start -
mode_in->hdisplay;
+ timing_out->v_total = mode_in->vtotal;
+ timing_out->v_addressable = mode_in->vdisplay;
+ timing_out->v_front_porch = mode_in->vsync_start -
mode_in->vdisplay;
+ timing_out->v_sync_width = mode_in->vsync_end -
mode_in->vsync_start;
+ timing_out->pix_clk_100hz = mode_in->clock * 10;
+ } else {
+ timing_out->h_addressable = mode_in->crtc_hdisplay;
+ timing_out->h_total = mode_in->crtc_htotal;
+ timing_out->h_sync_width = mode_in->crtc_hsync_end -
mode_in->crtc_hsync_start;
+ timing_out->h_front_porch = mode_in->crtc_hsync_start -
mode_in->crtc_hdisplay;
+ timing_out->v_total = mode_in->crtc_vtotal;
+ timing_out->v_addressable = mode_in->crtc_vdisplay;
+ timing_out->v_front_porch = mode_in->crtc_vsync_start -
mode_in->crtc_vdisplay;
+ timing_out->v_sync_width = mode_in->crtc_vsync_end -
mode_in->crtc_vsync_start;
+ timing_out->pix_clk_100hz = mode_in->crtc_clock * 10;
+ }
+
timing_out->aspect_ratio = get_aspect_ratio(mode_in);
stream->output_color_space = get_output_color_space(timing_out);
@@ -5227,6 +5240,33 @@ get_highest_refresh_rate_mode(struct amdgpu_dm_connector
*aconnector,
return m_pref;
}
+static bool is_freesync_video_mode(struct drm_display_mode *mode,
+ struct amdgpu_dm_connector *aconnector)
+{
+ struct drm_display_mode *high_mode;
+ int timing_diff;
+
+ high_mode = get_highest_refresh_rate_mode(aconnector, false);
+ if (!high_mode || !mode)
+ return false;
+
+ timing_diff = high_mode->vtotal - mode->vtotal;
+
+ if (high_mode->clock == 0 || high_mode->clock != mode->clock ||
+ high_mode->hdisplay != mode->hdisplay ||
+ high_mode->vdisplay != mode->vdisplay ||
+ high_mode->hsync_start != mode->hsync_sta
Re: [PATCH 1/3] drivers/nouveau/kms/nv50-: Reject format modifiers for cursor planes
On Mon, Jan 18, 2021 at 08:54:12PM -0500, Lyude Paul wrote:
> Nvidia hardware doesn't actually support using tiling formats with the
> cursor plane, only linear is allowed. In the future, we should write a
> testcase for this.
There are a couple of old modifier/format sanity tests here:
https://patchwork.freedesktop.org/series/46876/
Couple of things missing that now came to my mind:
- test setplane/etc. rejects unsupported formats/modifiers even if
addfb allowed them, exactly for the case where only a subset of
planes support something
- validate the IN_FORMATS blob harder, eg. make sure each modifier
listed there supports at least one format. IIRC this was busted on
a few drivers last year, dunno if they got fixed or not. Hmm,
actually since this is now using the pre-parsed stuff I guess we
should just stick an assert into igt_fill_plane_format_mod() where
the blob gets parsed
>
> Fixes: c586f30bf74c ("drm/nouveau/kms: Add format mod prop to
> base/ovly/nvdisp")
> Cc: James Jones
> Cc: Martin Peres
> Cc: Jeremy Cline
> Cc: Simon Ser
> Cc: # v5.8+
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/nouveau/dispnv50/wndw.c | 17 +
> 1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
> b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
> index ce451242f79e..271de3a63f21 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
> @@ -702,6 +702,11 @@ nv50_wndw_init(struct nv50_wndw *wndw)
> nvif_notify_get(&wndw->notify);
> }
>
> +static const u64 nv50_cursor_format_modifiers[] = {
> + DRM_FORMAT_MOD_LINEAR,
> + DRM_FORMAT_MOD_INVALID,
> +};
> +
> int
> nv50_wndw_new_(const struct nv50_wndw_func *func, struct drm_device *dev,
> enum drm_plane_type type, const char *name, int index,
> @@ -713,6 +718,7 @@ nv50_wndw_new_(const struct nv50_wndw_func *func, struct
> drm_device *dev,
> struct nvif_mmu *mmu = &drm->client.mmu;
> struct nv50_disp *disp = nv50_disp(dev);
> struct nv50_wndw *wndw;
> + const u64 *format_modifiers;
> int nformat;
> int ret;
>
> @@ -728,10 +734,13 @@ nv50_wndw_new_(const struct nv50_wndw_func *func,
> struct drm_device *dev,
>
> for (nformat = 0; format[nformat]; nformat++);
>
> - ret = drm_universal_plane_init(dev, &wndw->plane, heads, &nv50_wndw,
> -format, nformat,
> -nouveau_display(dev)->format_modifiers,
> -type, "%s-%d", name, index);
> + if (type == DRM_PLANE_TYPE_CURSOR)
> + format_modifiers = nv50_cursor_format_modifiers;
> + else
> + format_modifiers = nouveau_display(dev)->format_modifiers;
> +
> + ret = drm_universal_plane_init(dev, &wndw->plane, heads, &nv50_wndw,
> format, nformat,
> +format_modifiers, type, "%s-%d", name,
> index);
> if (ret) {
> kfree(*pwndw);
> *pwndw = NULL;
> --
> 2.29.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/amd/display: Add module parameter for freesync video mode
[Why] This option shall be opt-in by default since it is a temporary solution until long term solution is agreed upon which may require userspace interface changes. There has been precedent of manufacturing modes in the kernel. In AMDGPU, the existing usage are for common modes and scaling modes. Other driver have a similar approach as well. [How] Adds a module parameter to enable freesync video mode modeset optimization. Enabling this mode allows the driver to skip a full modeset when a freesync compatible mode is requested by the userspace. This parameter will also add some additional modes that are within the connected monitor's VRR range corresponding to common video modes, which media players can use for a seamless experience while making use of freesync. Signed-off-by: Aurabindo Pillai Acked-by: Christian König Reviewed-by: Shashank Sharma --- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 12 2 files changed, 13 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h b/drivers/gpu/drm/amd/amdgpu/amdgpu.h index 100a431f0792..770e42fcaa62 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h @@ -177,6 +177,7 @@ extern int amdgpu_gpu_recovery; extern int amdgpu_emu_mode; extern uint amdgpu_smu_memory_pool_size; extern uint amdgpu_dc_feature_mask; +extern uint amdgpu_freesync_vid_mode; extern uint amdgpu_dc_debug_mask; extern uint amdgpu_dm_abm_level; extern struct amdgpu_mgpu_info mgpu_info; diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index b48d7a3c2a11..5c6dc8362e6d 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c @@ -158,6 +158,7 @@ int amdgpu_mes; int amdgpu_noretry = -1; int amdgpu_force_asic_type = -1; int amdgpu_tmz; +uint amdgpu_freesync_vid_mode; int amdgpu_reset_method = -1; /* auto */ int amdgpu_num_kcq = -1; @@ -786,6 +787,17 @@ module_param_named(abmlevel, amdgpu_dm_abm_level, uint, 0444); MODULE_PARM_DESC(tmz, "Enable TMZ feature (-1 = auto, 0 = off (default), 1 = on)"); module_param_named(tmz, amdgpu_tmz, int, 0444); +/** + * DOC: freesync_video (uint) + * Enabled the optimization to adjust front porch timing to achieve seamless mode change experience + * when setting a freesync supported mode for which full modeset is not needed. + * The default value: 0 (off). + */ +MODULE_PARM_DESC( + freesync_video, + "Enable freesync modesetting optimization feature (0 = off (default), 1 = on)"); +module_param_named(freesync_video, amdgpu_freesync_vid_mode, uint, 0444); + /** * DOC: reset_method (int) * GPU reset method (-1 = auto (default), 0 = legacy, 1 = mode0, 2 = mode1, 3 = mode2, 4 = baco) -- 2.30.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] Experimental freesync video mode optimization
Changes in V5 = * More info in commit messages on the rationale of changes being added to the kernel. * Minor fixes Changes in V4 = 1) Add module parameter for freesync video mode * Change module parameter name to freesync_video 2) Add freesync video modes based on preferred modes: * Cosmetic fixes * Added comments about all modes being added by the driver. 3) Skip modeset for front porch change * Added more conditions for checking freesync video mode Changes in V3 = 1) Add freesync video modes based on preferred modes: * Cache base freesync video mode during the first iteration to avoid iterating over modelist again later. * Add mode for 60 fps videos 2) Skip modeset for front porch change * Fixes for bug exposed by caching of modes. Changes in V2 = 1) Add freesync video modes based on preferred modes: * Remove check for connector type before adding freesync compatible modes as VRR support is being checked, and there is no reason to block freesync video support on eDP. * use drm_mode_equal() instead of creating same functionality. * Additional null pointer deference check * Removed unnecessary variables. * Cosmetic fixes. 2) Skip modeset for front porch change * Remove _FSV string being appended to freesync video modes so as to not define new policies or break existing application that might use the mode name to figure out mode resolution. * Remove unnecessary variables * Cosmetic fixes. -- This patchset enables freesync video mode usecase where the userspace can request a freesync compatible video mode such that switching to this mode does not trigger blanking. This feature is guarded by a module parameter which is disabled by default. Enabling this paramters adds additional modes to the driver modelist, and also enables the optimization to skip modeset when using one of these modes. -- Aurabindo Pillai (3): drm/amd/display: Add module parameter for freesync video mode drm/amd/display: Add freesync video modes based on preferred modes drm/amd/display: Skip modeset for front porch change drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 12 + .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 401 -- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 3 + 4 files changed, 382 insertions(+), 35 deletions(-) -- 2.30.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 11/14] drm/amdgpu: Guard against write accesses after device removal
The is also the possibility to have the drm_dev_enter/exit much more
high level.
E.g. we should it have anyway on every IOCTL and what remains are work
items, scheduler threads and interrupts.
Christian.
Am 19.01.21 um 16:35 schrieb Andrey Grodzovsky:
There is really no other way according to this article
https://lwn.net/Articles/767885/
"A perfect solution seems nearly impossible though; we cannot acquire
a mutex on the user
to prevent them from yanking a device and we cannot check for a
presence change after every
device access for performance reasons. "
But I assumed srcu_read_lock should be pretty seamless performance
wise, no ?
The other solution would be as I suggested to keep all the device IO
ranges reserved and system
memory pages unfreed until the device is finalized in the driver but
Daniel said this would upset the PCI layer (the MMIO ranges
reservation part).
Andrey
On 1/19/21 3:55 AM, Christian König wrote:
Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
This should prevent writing to memory or IO ranges possibly
already allocated for other uses after our device is removed.
Wow, that adds quite some overhead to every register access. I'm not
sure we can do this.
Christian.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 57
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 9
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 53
+-
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h | 3 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 70
++
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 49 ++---
drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 16 ++-
drivers/gpu/drm/amd/amdgpu/psp_v12_0.c | 8 +---
drivers/gpu/drm/amd/amdgpu/psp_v3_1.c | 8 +---
9 files changed, 184 insertions(+), 89 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index e99f4f1..0a9d73c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -72,6 +72,8 @@
#include
+#include
+
MODULE_FIRMWARE("amdgpu/vega10_gpu_info.bin");
MODULE_FIRMWARE("amdgpu/vega12_gpu_info.bin");
MODULE_FIRMWARE("amdgpu/raven_gpu_info.bin");
@@ -404,13 +406,21 @@ uint8_t amdgpu_mm_rreg8(struct amdgpu_device
*adev, uint32_t offset)
*/
void amdgpu_mm_wreg8(struct amdgpu_device *adev, uint32_t offset,
uint8_t value)
{
+ int idx;
+
if (adev->in_pci_err_recovery)
return;
+
+ if (!drm_dev_enter(&adev->ddev, &idx))
+ return;
+
if (offset < adev->rmmio_size)
writeb(value, adev->rmmio + offset);
else
BUG();
+
+ drm_dev_exit(idx);
}
/**
@@ -427,9 +437,14 @@ void amdgpu_device_wreg(struct amdgpu_device
*adev,
uint32_t reg, uint32_t v,
uint32_t acc_flags)
{
+ int idx;
+
if (adev->in_pci_err_recovery)
return;
+ if (!drm_dev_enter(&adev->ddev, &idx))
+ return;
+
if ((reg * 4) < adev->rmmio_size) {
if (!(acc_flags & AMDGPU_REGS_NO_KIQ) &&
amdgpu_sriov_runtime(adev) &&
@@ -444,6 +459,8 @@ void amdgpu_device_wreg(struct amdgpu_device *adev,
}
trace_amdgpu_device_wreg(adev->pdev->device, reg, v);
+
+ drm_dev_exit(idx);
}
/*
@@ -454,9 +471,14 @@ void amdgpu_device_wreg(struct amdgpu_device
*adev,
void amdgpu_mm_wreg_mmio_rlc(struct amdgpu_device *adev,
uint32_t reg, uint32_t v)
{
+ int idx;
+
if (adev->in_pci_err_recovery)
return;
+ if (!drm_dev_enter(&adev->ddev, &idx))
+ return;
+
if (amdgpu_sriov_fullaccess(adev) &&
adev->gfx.rlc.funcs &&
adev->gfx.rlc.funcs->is_rlcg_access_range) {
@@ -465,6 +487,8 @@ void amdgpu_mm_wreg_mmio_rlc(struct
amdgpu_device *adev,
} else {
writel(v, ((void __iomem *)adev->rmmio) + (reg * 4));
}
+
+ drm_dev_exit(idx);
}
/**
@@ -499,15 +523,22 @@ u32 amdgpu_io_rreg(struct amdgpu_device *adev,
u32 reg)
*/
void amdgpu_io_wreg(struct amdgpu_device *adev, u32 reg, u32 v)
{
+ int idx;
+
if (adev->in_pci_err_recovery)
return;
+ if (!drm_dev_enter(&adev->ddev, &idx))
+ return;
+
if ((reg * 4) < adev->rio_mem_size)
iowrite32(v, adev->rio_mem + (reg * 4));
else {
iowrite32((reg * 4), adev->rio_mem + (mmMM_INDEX * 4));
iowrite32(v, adev->rio_mem + (mmMM_DATA * 4));
}
+
+ drm_dev_exit(idx);
}
/**
@@ -544,14 +575,21 @@ u32 amdgpu_mm_rdoorbell(struct amdgpu_device
*adev, u32 index)
*/
void amdgpu_mm_wdoorbell(struct amdgpu_device *adev, u32 index,
u32 v)
{
+ int idx;
+
if (adev->in_pci_err_recovery)
return;
+ if (!drm_dev_enter(&adev->ddev, &idx))
+ return;
+
if (index < adev->doorbell.num_doorbells) {
Re: [PATCH v4 11/14] drm/amdgpu: Guard against write accesses after device removal
There is really no other way according to this article
https://lwn.net/Articles/767885/
"A perfect solution seems nearly impossible though; we cannot acquire a mutex on
the user
to prevent them from yanking a device and we cannot check for a presence change
after every
device access for performance reasons. "
But I assumed srcu_read_lock should be pretty seamless performance wise, no ?
The other solution would be as I suggested to keep all the device IO ranges
reserved and system
memory pages unfreed until the device is finalized in the driver but Daniel said
this would upset the PCI layer (the MMIO ranges reservation part).
Andrey
On 1/19/21 3:55 AM, Christian König wrote:
Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
This should prevent writing to memory or IO ranges possibly
already allocated for other uses after our device is removed.
Wow, that adds quite some overhead to every register access. I'm not sure we
can do this.
Christian.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 57
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 9
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 53 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h | 3 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 70 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 49 ++---
drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 16 ++-
drivers/gpu/drm/amd/amdgpu/psp_v12_0.c | 8 +---
drivers/gpu/drm/amd/amdgpu/psp_v3_1.c | 8 +---
9 files changed, 184 insertions(+), 89 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index e99f4f1..0a9d73c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -72,6 +72,8 @@
#include
+#include
+
MODULE_FIRMWARE("amdgpu/vega10_gpu_info.bin");
MODULE_FIRMWARE("amdgpu/vega12_gpu_info.bin");
MODULE_FIRMWARE("amdgpu/raven_gpu_info.bin");
@@ -404,13 +406,21 @@ uint8_t amdgpu_mm_rreg8(struct amdgpu_device *adev,
uint32_t offset)
*/
void amdgpu_mm_wreg8(struct amdgpu_device *adev, uint32_t offset, uint8_t
value)
{
+ int idx;
+
if (adev->in_pci_err_recovery)
return;
+
+ if (!drm_dev_enter(&adev->ddev, &idx))
+ return;
+
if (offset < adev->rmmio_size)
writeb(value, adev->rmmio + offset);
else
BUG();
+
+ drm_dev_exit(idx);
}
/**
@@ -427,9 +437,14 @@ void amdgpu_device_wreg(struct amdgpu_device *adev,
uint32_t reg, uint32_t v,
uint32_t acc_flags)
{
+ int idx;
+
if (adev->in_pci_err_recovery)
return;
+ if (!drm_dev_enter(&adev->ddev, &idx))
+ return;
+
if ((reg * 4) < adev->rmmio_size) {
if (!(acc_flags & AMDGPU_REGS_NO_KIQ) &&
amdgpu_sriov_runtime(adev) &&
@@ -444,6 +459,8 @@ void amdgpu_device_wreg(struct amdgpu_device *adev,
}
trace_amdgpu_device_wreg(adev->pdev->device, reg, v);
+
+ drm_dev_exit(idx);
}
/*
@@ -454,9 +471,14 @@ void amdgpu_device_wreg(struct amdgpu_device *adev,
void amdgpu_mm_wreg_mmio_rlc(struct amdgpu_device *adev,
uint32_t reg, uint32_t v)
{
+ int idx;
+
if (adev->in_pci_err_recovery)
return;
+ if (!drm_dev_enter(&adev->ddev, &idx))
+ return;
+
if (amdgpu_sriov_fullaccess(adev) &&
adev->gfx.rlc.funcs &&
adev->gfx.rlc.funcs->is_rlcg_access_range) {
@@ -465,6 +487,8 @@ void amdgpu_mm_wreg_mmio_rlc(struct amdgpu_device *adev,
} else {
writel(v, ((void __iomem *)adev->rmmio) + (reg * 4));
}
+
+ drm_dev_exit(idx);
}
/**
@@ -499,15 +523,22 @@ u32 amdgpu_io_rreg(struct amdgpu_device *adev, u32 reg)
*/
void amdgpu_io_wreg(struct amdgpu_device *adev, u32 reg, u32 v)
{
+ int idx;
+
if (adev->in_pci_err_recovery)
return;
+ if (!drm_dev_enter(&adev->ddev, &idx))
+ return;
+
if ((reg * 4) < adev->rio_mem_size)
iowrite32(v, adev->rio_mem + (reg * 4));
else {
iowrite32((reg * 4), adev->rio_mem + (mmMM_INDEX * 4));
iowrite32(v, adev->rio_mem + (mmMM_DATA * 4));
}
+
+ drm_dev_exit(idx);
}
/**
@@ -544,14 +575,21 @@ u32 amdgpu_mm_rdoorbell(struct amdgpu_device *adev, u32
index)
*/
void amdgpu_mm_wdoorbell(struct amdgpu_device *adev, u32 index, u32 v)
{
+ int idx;
+
if (adev->in_pci_err_recovery)
return;
+ if (!drm_dev_enter(&adev->ddev, &idx))
+ return;
+
if (index < adev->doorbell.num_doorbells) {
writel(v, adev->doorbell.ptr + index);
} else {
DRM_ERROR("writing beyond doorbell aperture: 0x%08x!\n", index);
}
+
+ drm_dev_exit(idx);
}
/**
@@ -588,14 +626,21 @@ u64 amdgpu_mm_rdoorbell64(struct amdgpu_device *adev,
u32 index)
Re: [PATCH v7 12/17] PCI: Revoke mappings like devmem
On Tue, Jan 19, 2021 at 03:34:47PM +0100, Daniel Vetter wrote:
> On Tue, Jan 19, 2021 at 3:32 PM Greg Kroah-Hartman
> wrote:
> >
> > On Tue, Jan 19, 2021 at 09:17:55AM +0100, Daniel Vetter wrote:
> > > On Fri, Nov 27, 2020 at 5:42 PM Daniel Vetter
> > > wrote:
> > > >
> > > > Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims
> > > > the region") /dev/kmem zaps ptes when the kernel requests exclusive
> > > > acccess to an iomem region. And with CONFIG_IO_STRICT_DEVMEM, this is
> > > > the default for all driver uses.
> > > >
> > > > Except there's two more ways to access PCI BARs: sysfs and proc mmap
> > > > support. Let's plug that hole.
> > > >
> > > > For revoke_devmem() to work we need to link our vma into the same
> > > > address_space, with consistent vma->vm_pgoff. ->pgoff is already
> > > > adjusted, because that's how (io_)remap_pfn_range works, but for the
> > > > mapping we need to adjust vma->vm_file->f_mapping. The cleanest way is
> > > > to adjust this at at ->open time:
> > > >
> > > > - for sysfs this is easy, now that binary attributes support this. We
> > > > just set bin_attr->mapping when mmap is supported
> > > > - for procfs it's a bit more tricky, since procfs pci access has only
> > > > one file per device, and access to a specific resources first needs
> > > > to be set up with some ioctl calls. But mmap is only supported for
> > > > the same resources as sysfs exposes with mmap support, and otherwise
> > > > rejected, so we can set the mapping unconditionally at open time
> > > > without harm.
> > > >
> > > > A special consideration is for arch_can_pci_mmap_io() - we need to
> > > > make sure that the ->f_mapping doesn't alias between ioport and iomem
> > > > space. There's only 2 ways in-tree to support mmap of ioports: generic
> > > > pci mmap (ARCH_GENERIC_PCI_MMAP_RESOURCE), and sparc as the single
> > > > architecture hand-rolling. Both approach support ioport mmap through a
> > > > special pfn range and not through magic pte attributes. Aliasing is
> > > > therefore not a problem.
> > > >
> > > > The only difference in access checks left is that sysfs PCI mmap does
> > > > not check for CAP_RAWIO. I'm not really sure whether that should be
> > > > added or not.
> > > >
> > > > Acked-by: Bjorn Helgaas
> > > > Reviewed-by: Dan Williams
> > > > Signed-off-by: Daniel Vetter
> > > > Cc: Jason Gunthorpe
> > > > Cc: Kees Cook
> > > > Cc: Dan Williams
> > > > Cc: Andrew Morton
> > > > Cc: John Hubbard
> > > > Cc: Jérôme Glisse
> > > > Cc: Jan Kara
> > > > Cc: Dan Williams
> > > > Cc: Greg Kroah-Hartman
> > > > Cc: linux...@kvack.org
> > > > Cc: linux-arm-ker...@lists.infradead.org
> > > > Cc: linux-samsung-...@vger.kernel.org
> > > > Cc: linux-me...@vger.kernel.org
> > > > Cc: Bjorn Helgaas
> > > > Cc: linux-...@vger.kernel.org
> > > > Signed-off-by: Daniel Vetter
> > > > --
> > > > v2:
> > > > - Totally new approach: Adjust filp->f_mapping at open time. Note that
> > > > this now works on all architectures, not just those support
> > > > ARCH_GENERIC_PCI_MMAP_RESOURCE
> > > > ---
> > > > drivers/pci/pci-sysfs.c | 4
> > > > drivers/pci/proc.c | 1 +
> > > > 2 files changed, 5 insertions(+)
> > > >
> > > > diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> > > > index d15c881e2e7e..3f1c31bc0b7c 100644
> > > > --- a/drivers/pci/pci-sysfs.c
> > > > +++ b/drivers/pci/pci-sysfs.c
> > > > @@ -929,6 +929,7 @@ void pci_create_legacy_files(struct pci_bus *b)
> > > > b->legacy_io->read = pci_read_legacy_io;
> > > > b->legacy_io->write = pci_write_legacy_io;
> > > > b->legacy_io->mmap = pci_mmap_legacy_io;
> > > > + b->legacy_io->mapping = iomem_get_mapping();
> > > > pci_adjust_legacy_attr(b, pci_mmap_io);
> > > > error = device_create_bin_file(&b->dev, b->legacy_io);
> > > > if (error)
> > > > @@ -941,6 +942,7 @@ void pci_create_legacy_files(struct pci_bus *b)
> > > > b->legacy_mem->size = 1024*1024;
> > > > b->legacy_mem->attr.mode = 0600;
> > > > b->legacy_mem->mmap = pci_mmap_legacy_mem;
> > > > + b->legacy_io->mapping = iomem_get_mapping();
> > >
> > > Unlike the normal pci stuff below, the legacy files here go boom
> > > because they're set up much earlier in the boot sequence. This only
> > > affects HAVE_PCI_LEGACY architectures, which aren't that many. So what
> > > should we do here now:
> > > - drop the devmem revoke for these
> > > - rework the init sequence somehow to set up these files a lot later
> > > - redo the sysfs patch so that it doesn't take an address_space
> > > pointer, but instead a callback to get at that (since at open time
> > > everything is set up). Imo rather ugly
> > > - ditch this part of the series (since there's not really any takers
> > > for the latter parts it might just not make sense to push for this)
> > > - something else?
> > >
> > > Bjorn, Greg, thoughts?
> >
> > What sysfs patch are you ref
Re: [PATCH v4 0/6] drm: Move struct drm_device.pdev to legacy
FYI patches 1 and 5 are now in drm-misc-next. Am 18.01.21 um 14:14 schrieb Thomas Zimmermann: I merged more patches into drm-misc-next. I'm mostly sending out v4 of this patchset to split the final patch into the core changes and the patch for moving pdev behind CONFIG_DRM_LEGACY. The former are required to fix a reported bug. [1] There's also a fix to vmwgfx. The pdev field in struct drm_device points to a PCI device structure and goes back to UMS-only days when all DRM drivers were for PCI devices. Meanwhile we also support USB, SPI and platform devices. Each of those uses the generic device stored in struct drm_device.dev. To reduce duplication and remove the special case of PCI, this patchset converts all modesetting drivers from pdev to dev and makes pdev a field for legacy UMS drivers. For PCI devices, the pointer in struct drm_device.dev can be upcasted to struct pci_device; or tested for PCI with dev_is_pci(). In several places the code can use the dev field directly. After converting all drivers and the DRM core, the pdev fields becomes only relevant for legacy drivers. In a later patchset, we may want to convert these as well and remove pdev entirely. v4: * merged several patches * moved core changes into separate patch * vmwgfx build fix v3: * merged several patches * fix one pdev reference in nouveau (Jeremy) * rebases v2: * move whitespace fixes into separate patches (Alex, Sam) * move i915 gt/ and gvt/ changes into separate patches (Joonas) [1] https://lore.kernel.org/dri-devel/7851c78c-8c57-3c84-cd49-a72703095...@suse.de/ Thomas Zimmermann (6): drm: Upcast struct drm_device.dev to struct pci_device; replace pdev drm/i915: Remove references to struct drm_device.pdev drm/i915/gt: Remove references to struct drm_device.pdev drm/i915/gvt: Remove references to struct drm_device.pdev drm/vmwgfx: Remove reference to struct drm_device.pdev drm: Move struct drm_device.pdev to legacy section drivers/gpu/drm/drm_agpsupport.c | 9 --- drivers/gpu/drm/drm_bufs.c| 4 +-- drivers/gpu/drm/drm_edid.c| 7 - drivers/gpu/drm/drm_irq.c | 12 + drivers/gpu/drm/drm_pci.c | 26 +++ drivers/gpu/drm/drm_vm.c | 2 +- drivers/gpu/drm/i915/display/intel_bios.c | 2 +- drivers/gpu/drm/i915/display/intel_cdclk.c| 14 +- drivers/gpu/drm/i915/display/intel_csr.c | 2 +- drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 2 +- drivers/gpu/drm/i915/display/intel_fbdev.c| 2 +- drivers/gpu/drm/i915/display/intel_gmbus.c| 2 +- .../gpu/drm/i915/display/intel_lpe_audio.c| 5 ++-- drivers/gpu/drm/i915/display/intel_opregion.c | 6 ++--- drivers/gpu/drm/i915/display/intel_overlay.c | 2 +- drivers/gpu/drm/i915/display/intel_panel.c| 4 +-- drivers/gpu/drm/i915/display/intel_quirks.c | 2 +- drivers/gpu/drm/i915/display/intel_sdvo.c | 2 +- drivers/gpu/drm/i915/display/intel_vga.c | 8 +++--- drivers/gpu/drm/i915/gem/i915_gem_phys.c | 6 ++--- drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 2 +- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +- drivers/gpu/drm/i915/gt/intel_ggtt.c | 10 +++ drivers/gpu/drm/i915/gt/intel_ppgtt.c | 2 +- drivers/gpu/drm/i915/gt/intel_rc6.c | 4 +-- drivers/gpu/drm/i915/gt/intel_region_lmem.c | 8 +++--- drivers/gpu/drm/i915/gt/intel_reset.c | 6 ++--- drivers/gpu/drm/i915/gvt/cfg_space.c | 5 ++-- drivers/gpu/drm/i915/gvt/firmware.c | 10 +++ drivers/gpu/drm/i915/gvt/gtt.c| 12 - drivers/gpu/drm/i915/gvt/gvt.c| 6 ++--- drivers/gpu/drm/i915/gvt/kvmgt.c | 4 +-- drivers/gpu/drm/i915/i915_debugfs.c | 2 +- drivers/gpu/drm/i915/i915_drv.c | 20 +++--- drivers/gpu/drm/i915/i915_drv.h | 2 +- drivers/gpu/drm/i915/i915_gem_gtt.c | 5 ++-- drivers/gpu/drm/i915/i915_getparam.c | 5 ++-- drivers/gpu/drm/i915/i915_gpu_error.c | 2 +- drivers/gpu/drm/i915/i915_irq.c | 6 ++--- drivers/gpu/drm/i915/i915_pmu.c | 2 +- drivers/gpu/drm/i915/i915_suspend.c | 4 +-- drivers/gpu/drm/i915/i915_switcheroo.c| 4 +-- drivers/gpu/drm/i915/i915_vgpu.c | 2 +- drivers/gpu/drm/i915/intel_device_info.c | 2 +- drivers/gpu/drm/i915/intel_runtime_pm.c | 2 +- drivers/gpu/drm/i915/intel_uncore.c | 4 +-- .../gpu/drm/i915/selftests/mock_gem_device.c | 1 - drivers/gpu/drm/i915/selftests/mock_gtt.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 1 - include/drm/drm_device.h | 6 ++--- 50 files changed, 137 insertions(+), 125 deletions(-) -- 2.29.2
Re: [PATCH v7 12/17] PCI: Revoke mappings like devmem
On Tue, Jan 19, 2021 at 3:32 PM Greg Kroah-Hartman
wrote:
>
> On Tue, Jan 19, 2021 at 09:17:55AM +0100, Daniel Vetter wrote:
> > On Fri, Nov 27, 2020 at 5:42 PM Daniel Vetter
> > wrote:
> > >
> > > Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims
> > > the region") /dev/kmem zaps ptes when the kernel requests exclusive
> > > acccess to an iomem region. And with CONFIG_IO_STRICT_DEVMEM, this is
> > > the default for all driver uses.
> > >
> > > Except there's two more ways to access PCI BARs: sysfs and proc mmap
> > > support. Let's plug that hole.
> > >
> > > For revoke_devmem() to work we need to link our vma into the same
> > > address_space, with consistent vma->vm_pgoff. ->pgoff is already
> > > adjusted, because that's how (io_)remap_pfn_range works, but for the
> > > mapping we need to adjust vma->vm_file->f_mapping. The cleanest way is
> > > to adjust this at at ->open time:
> > >
> > > - for sysfs this is easy, now that binary attributes support this. We
> > > just set bin_attr->mapping when mmap is supported
> > > - for procfs it's a bit more tricky, since procfs pci access has only
> > > one file per device, and access to a specific resources first needs
> > > to be set up with some ioctl calls. But mmap is only supported for
> > > the same resources as sysfs exposes with mmap support, and otherwise
> > > rejected, so we can set the mapping unconditionally at open time
> > > without harm.
> > >
> > > A special consideration is for arch_can_pci_mmap_io() - we need to
> > > make sure that the ->f_mapping doesn't alias between ioport and iomem
> > > space. There's only 2 ways in-tree to support mmap of ioports: generic
> > > pci mmap (ARCH_GENERIC_PCI_MMAP_RESOURCE), and sparc as the single
> > > architecture hand-rolling. Both approach support ioport mmap through a
> > > special pfn range and not through magic pte attributes. Aliasing is
> > > therefore not a problem.
> > >
> > > The only difference in access checks left is that sysfs PCI mmap does
> > > not check for CAP_RAWIO. I'm not really sure whether that should be
> > > added or not.
> > >
> > > Acked-by: Bjorn Helgaas
> > > Reviewed-by: Dan Williams
> > > Signed-off-by: Daniel Vetter
> > > Cc: Jason Gunthorpe
> > > Cc: Kees Cook
> > > Cc: Dan Williams
> > > Cc: Andrew Morton
> > > Cc: John Hubbard
> > > Cc: Jérôme Glisse
> > > Cc: Jan Kara
> > > Cc: Dan Williams
> > > Cc: Greg Kroah-Hartman
> > > Cc: linux...@kvack.org
> > > Cc: linux-arm-ker...@lists.infradead.org
> > > Cc: linux-samsung-...@vger.kernel.org
> > > Cc: linux-me...@vger.kernel.org
> > > Cc: Bjorn Helgaas
> > > Cc: linux-...@vger.kernel.org
> > > Signed-off-by: Daniel Vetter
> > > --
> > > v2:
> > > - Totally new approach: Adjust filp->f_mapping at open time. Note that
> > > this now works on all architectures, not just those support
> > > ARCH_GENERIC_PCI_MMAP_RESOURCE
> > > ---
> > > drivers/pci/pci-sysfs.c | 4
> > > drivers/pci/proc.c | 1 +
> > > 2 files changed, 5 insertions(+)
> > >
> > > diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> > > index d15c881e2e7e..3f1c31bc0b7c 100644
> > > --- a/drivers/pci/pci-sysfs.c
> > > +++ b/drivers/pci/pci-sysfs.c
> > > @@ -929,6 +929,7 @@ void pci_create_legacy_files(struct pci_bus *b)
> > > b->legacy_io->read = pci_read_legacy_io;
> > > b->legacy_io->write = pci_write_legacy_io;
> > > b->legacy_io->mmap = pci_mmap_legacy_io;
> > > + b->legacy_io->mapping = iomem_get_mapping();
> > > pci_adjust_legacy_attr(b, pci_mmap_io);
> > > error = device_create_bin_file(&b->dev, b->legacy_io);
> > > if (error)
> > > @@ -941,6 +942,7 @@ void pci_create_legacy_files(struct pci_bus *b)
> > > b->legacy_mem->size = 1024*1024;
> > > b->legacy_mem->attr.mode = 0600;
> > > b->legacy_mem->mmap = pci_mmap_legacy_mem;
> > > + b->legacy_io->mapping = iomem_get_mapping();
> >
> > Unlike the normal pci stuff below, the legacy files here go boom
> > because they're set up much earlier in the boot sequence. This only
> > affects HAVE_PCI_LEGACY architectures, which aren't that many. So what
> > should we do here now:
> > - drop the devmem revoke for these
> > - rework the init sequence somehow to set up these files a lot later
> > - redo the sysfs patch so that it doesn't take an address_space
> > pointer, but instead a callback to get at that (since at open time
> > everything is set up). Imo rather ugly
> > - ditch this part of the series (since there's not really any takers
> > for the latter parts it might just not make sense to push for this)
> > - something else?
> >
> > Bjorn, Greg, thoughts?
>
> What sysfs patch are you referring to here?
Currently in linux-next:
commit 74b30195395c406c787280a77ae55aed82dbbfc7 (HEAD ->
topic/iomem-mmap-vs-gup, drm/topic/iomem-mmap-vs-gup)
Author: Daniel Vetter
Date: Fri Nov 27 17:41:25 2020 +0100
sysfs: Support zapping of binary attr mmaps
Or the p
Re: [PATCH v7 12/17] PCI: Revoke mappings like devmem
On Tue, Jan 19, 2021 at 09:17:55AM +0100, Daniel Vetter wrote:
> On Fri, Nov 27, 2020 at 5:42 PM Daniel Vetter wrote:
> >
> > Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims
> > the region") /dev/kmem zaps ptes when the kernel requests exclusive
> > acccess to an iomem region. And with CONFIG_IO_STRICT_DEVMEM, this is
> > the default for all driver uses.
> >
> > Except there's two more ways to access PCI BARs: sysfs and proc mmap
> > support. Let's plug that hole.
> >
> > For revoke_devmem() to work we need to link our vma into the same
> > address_space, with consistent vma->vm_pgoff. ->pgoff is already
> > adjusted, because that's how (io_)remap_pfn_range works, but for the
> > mapping we need to adjust vma->vm_file->f_mapping. The cleanest way is
> > to adjust this at at ->open time:
> >
> > - for sysfs this is easy, now that binary attributes support this. We
> > just set bin_attr->mapping when mmap is supported
> > - for procfs it's a bit more tricky, since procfs pci access has only
> > one file per device, and access to a specific resources first needs
> > to be set up with some ioctl calls. But mmap is only supported for
> > the same resources as sysfs exposes with mmap support, and otherwise
> > rejected, so we can set the mapping unconditionally at open time
> > without harm.
> >
> > A special consideration is for arch_can_pci_mmap_io() - we need to
> > make sure that the ->f_mapping doesn't alias between ioport and iomem
> > space. There's only 2 ways in-tree to support mmap of ioports: generic
> > pci mmap (ARCH_GENERIC_PCI_MMAP_RESOURCE), and sparc as the single
> > architecture hand-rolling. Both approach support ioport mmap through a
> > special pfn range and not through magic pte attributes. Aliasing is
> > therefore not a problem.
> >
> > The only difference in access checks left is that sysfs PCI mmap does
> > not check for CAP_RAWIO. I'm not really sure whether that should be
> > added or not.
> >
> > Acked-by: Bjorn Helgaas
> > Reviewed-by: Dan Williams
> > Signed-off-by: Daniel Vetter
> > Cc: Jason Gunthorpe
> > Cc: Kees Cook
> > Cc: Dan Williams
> > Cc: Andrew Morton
> > Cc: John Hubbard
> > Cc: Jérôme Glisse
> > Cc: Jan Kara
> > Cc: Dan Williams
> > Cc: Greg Kroah-Hartman
> > Cc: linux...@kvack.org
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-samsung-...@vger.kernel.org
> > Cc: linux-me...@vger.kernel.org
> > Cc: Bjorn Helgaas
> > Cc: linux-...@vger.kernel.org
> > Signed-off-by: Daniel Vetter
> > --
> > v2:
> > - Totally new approach: Adjust filp->f_mapping at open time. Note that
> > this now works on all architectures, not just those support
> > ARCH_GENERIC_PCI_MMAP_RESOURCE
> > ---
> > drivers/pci/pci-sysfs.c | 4
> > drivers/pci/proc.c | 1 +
> > 2 files changed, 5 insertions(+)
> >
> > diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> > index d15c881e2e7e..3f1c31bc0b7c 100644
> > --- a/drivers/pci/pci-sysfs.c
> > +++ b/drivers/pci/pci-sysfs.c
> > @@ -929,6 +929,7 @@ void pci_create_legacy_files(struct pci_bus *b)
> > b->legacy_io->read = pci_read_legacy_io;
> > b->legacy_io->write = pci_write_legacy_io;
> > b->legacy_io->mmap = pci_mmap_legacy_io;
> > + b->legacy_io->mapping = iomem_get_mapping();
> > pci_adjust_legacy_attr(b, pci_mmap_io);
> > error = device_create_bin_file(&b->dev, b->legacy_io);
> > if (error)
> > @@ -941,6 +942,7 @@ void pci_create_legacy_files(struct pci_bus *b)
> > b->legacy_mem->size = 1024*1024;
> > b->legacy_mem->attr.mode = 0600;
> > b->legacy_mem->mmap = pci_mmap_legacy_mem;
> > + b->legacy_io->mapping = iomem_get_mapping();
>
> Unlike the normal pci stuff below, the legacy files here go boom
> because they're set up much earlier in the boot sequence. This only
> affects HAVE_PCI_LEGACY architectures, which aren't that many. So what
> should we do here now:
> - drop the devmem revoke for these
> - rework the init sequence somehow to set up these files a lot later
> - redo the sysfs patch so that it doesn't take an address_space
> pointer, but instead a callback to get at that (since at open time
> everything is set up). Imo rather ugly
> - ditch this part of the series (since there's not really any takers
> for the latter parts it might just not make sense to push for this)
> - something else?
>
> Bjorn, Greg, thoughts?
What sysfs patch are you referring to here?
thanks,
greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 00/14] RFC Support hot device unplug in amdgpu
On Mon, Jan 18, 2021 at 04:01:09PM -0500, Andrey Grodzovsky wrote: > Until now extracting a card either by physical extraction (e.g. eGPU with > thunderbolt connection or by emulation through syfs -> > /sys/bus/pci/devices/device_id/remove) > would cause random crashes in user apps. The random crashes in apps were > mostly due to the app having mapped a device backed BO into its address > space was still trying to access the BO while the backing device was gone. > To answer this first problem Christian suggested to fix the handling of > mapped > memory in the clients when the device goes away by forcibly unmap all buffers > the > user processes has by clearing their respective VMAs mapping the device BOs. > Then when the VMAs try to fill in the page tables again we check in the fault > handlerif the device is removed and if so, return an error. This will > generate a > SIGBUS to the application which can then cleanly terminate.This indeed was > done > but this in turn created a problem of kernel OOPs were the OOPSes were due to > the > fact that while the app was terminating because of the SIGBUSit would trigger > use > after free in the driver by calling to accesses device structures that were > already > released from the pci remove sequence.This was handled by introducing a > 'flush' > sequence during device removal were we wait for drm file reference to drop to > 0 > meaning all user clients directly using this device terminated. > > v2: > Based on discussions in the mailing list with Daniel and Pekka [1] and based > on the document > produced by Pekka from those discussions [2] the whole approach with > returning SIGBUS and > waiting for all user clients having CPU mapping of device BOs to die was > dropped. > Instead as per the document suggestion the device structures are kept alive > until > the last reference to the device is dropped by user client and in the > meanwhile all existing and new CPU mappings of the BOs > belonging to the device directly or by dma-buf import are rerouted to per > user > process dummy rw page.Also, I skipped the 'Requirements for KMS UAPI' section > of [2] > since i am trying to get the minimal set of requirements that still give > useful solution > to work and this is the'Requirements for Render and Cross-Device UAPI' > section and so my > test case is removing a secondary device, which is render only and is not > involved > in KMS. > > v3: > More updates following comments from v2 such as removing loop to find DRM > file when rerouting > page faults to dummy page,getting rid of unnecessary sysfs handling > refactoring and moving > prevention of GPU recovery post device unplug from amdgpu to scheduler layer. > On top of that added unplug support for the IOMMU enabled system. > > v4: > Drop last sysfs hack and use sysfs default attribute. > Guard against write accesses after device removal to avoid modifying released > memory. > Update dummy pages handling to on demand allocation and release through drm > managed framework. > Add return value to scheduler job TO handler (by Luben Tuikov) and use this > in amdgpu for prevention > of GPU recovery post device unplug > Also rebase on top of drm-misc-mext instead of amd-staging-drm-next > > With these patches I am able to gracefully remove the secondary card using > sysfs remove hook while glxgears > is running off of secondary card (DRI_PRIME=1) without kernel oopses or hangs > and keep working > with the primary card or soft reset the device without hangs or oopses > > TODOs for followup work: > Convert AMDGPU code to use devm (for hw stuff) and drmm (for sw stuff and > allocations) (Daniel) > Support plugging the secondary device back after unplug - currently still > experiencing HW error on plugging back. > Add support for 'Requirements for KMS UAPI' section of [2] - unplugging > primary, display connected card. > > [1] - Discussions during v3 of the patchset > https://www.spinics.net/lists/amd-gfx/msg55576.html > [2] - drm/doc: device hot-unplug for userspace > https://www.spinics.net/lists/dri-devel/msg259755.html > [3] - Related gitlab ticket > https://gitlab.freedesktop.org/drm/amd/-/issues/1081 btw have you tried this out with some of the igts we have? core_hotunplug is the one I'm thinking of. Might be worth to extend this for amdgpu specific stuff (like run some batches on it while hotunplugging). Since there's so many corner cases we need to test here (shared dma-buf, shared dma_fence) I think it would make sense to have a shared testcase across drivers. Only specific thing would be some hooks to keep the gpu busy in some fashion while we yank the driver. But just to get it started you can throw in entirely amdgpu specific subtests and just share some of the test code. -Daniel > > Andrey Grodzovsky (13): > drm/ttm: Remap all page faults to per process dummy page. > drm: Unamp the entire device address space on device unplug > drm/ttm
Re: [PATCH 4/4] drm/ttm: optimize ttm pool shrinker a bit
On Tue, Jan 19, 2021 at 01:18:21PM +0100, Christian König wrote:
> Only initialize the DMA coherent pools if they are used.
>
> Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/ttm/ttm_pool.c | 23 ---
> 1 file changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
> index 98ecb9c9842c..e0617717113f 100644
> --- a/drivers/gpu/drm/ttm/ttm_pool.c
> +++ b/drivers/gpu/drm/ttm/ttm_pool.c
> @@ -505,10 +505,12 @@ void ttm_pool_init(struct ttm_pool *pool, struct device
> *dev,
> pool->use_dma_alloc = use_dma_alloc;
> pool->use_dma32 = use_dma32;
>
> - for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
> - for (j = 0; j < MAX_ORDER; ++j)
> - ttm_pool_type_init(&pool->caching[i].orders[j],
> -pool, i, j);
> + if (use_dma_alloc) {
> + for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
> + for (j = 0; j < MAX_ORDER; ++j)
> + ttm_pool_type_init(&pool->caching[i].orders[j],
> +pool, i, j);
> + }
> }
> EXPORT_SYMBOL(ttm_pool_init);
>
> @@ -524,9 +526,11 @@ void ttm_pool_fini(struct ttm_pool *pool)
> {
> unsigned int i, j;
>
> - for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
> - for (j = 0; j < MAX_ORDER; ++j)
> - ttm_pool_type_fini(&pool->caching[i].orders[j]);
> + if (pool->use_dma_alloc) {
> + for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
> + for (j = 0; j < MAX_ORDER; ++j)
> + ttm_pool_type_fini(&pool->caching[i].orders[j]);
> + }
> }
> EXPORT_SYMBOL(ttm_pool_fini);
>
> @@ -631,6 +635,11 @@ int ttm_pool_debugfs(struct ttm_pool *pool, struct
> seq_file *m)
> {
> unsigned int i;
>
> + if (!pool->use_dma_alloc) {
> + seq_puts(m, "unused\n");
> + return 0;
> + }
> +
> ttm_pool_debugfs_header(m);
>
> spin_lock(&shrinker_lock);
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/imx: ipuv3-plane: do not advertise YUV formats on planes without CSC
Only planes that are displayed via the Display Processor (DP) path
support color space conversion. Limit formats on planes that are
shown via the direct Display Controller (DC) path to RGB.
Reported-by: Fabio Estevam
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/ipuv3-plane.c | 41 ---
1 file changed, 37 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 075508051b5f..c5ff966e2ceb 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -35,7 +35,7 @@ static inline struct ipu_plane *to_ipu_plane(struct drm_plane
*p)
return container_of(p, struct ipu_plane, base);
}
-static const uint32_t ipu_plane_formats[] = {
+static const uint32_t ipu_plane_all_formats[] = {
DRM_FORMAT_ARGB1555,
DRM_FORMAT_XRGB1555,
DRM_FORMAT_ABGR1555,
@@ -72,6 +72,31 @@ static const uint32_t ipu_plane_formats[] = {
DRM_FORMAT_BGRX_A8,
};
+static const uint32_t ipu_plane_rgb_formats[] = {
+ DRM_FORMAT_ARGB1555,
+ DRM_FORMAT_XRGB1555,
+ DRM_FORMAT_ABGR1555,
+ DRM_FORMAT_XBGR1555,
+ DRM_FORMAT_RGBA5551,
+ DRM_FORMAT_BGRA5551,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_RGBA,
+ DRM_FORMAT_RGBX,
+ DRM_FORMAT_BGRA,
+ DRM_FORMAT_BGRX,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_RGB565_A8,
+ DRM_FORMAT_BGR565_A8,
+ DRM_FORMAT_RGB888_A8,
+ DRM_FORMAT_BGR888_A8,
+ DRM_FORMAT_RGBX_A8,
+ DRM_FORMAT_BGRX_A8,
+};
+
static const uint64_t ipu_format_modifiers[] = {
DRM_FORMAT_MOD_LINEAR,
DRM_FORMAT_MOD_INVALID
@@ -822,16 +847,24 @@ struct ipu_plane *ipu_plane_init(struct drm_device *dev,
struct ipu_soc *ipu,
struct ipu_plane *ipu_plane;
const uint64_t *modifiers = ipu_format_modifiers;
unsigned int zpos = (type == DRM_PLANE_TYPE_PRIMARY) ? 0 : 1;
+ unsigned int format_count;
+ const uint32_t *formats;
int ret;
DRM_DEBUG_KMS("channel %d, dp flow %d, possible_crtcs=0x%x\n",
dma, dp, possible_crtcs);
+ if (dp == IPU_DP_FLOW_SYNC_BG || dp == IPU_DP_FLOW_SYNC_FG) {
+ formats = ipu_plane_all_formats;
+ format_count = ARRAY_SIZE(ipu_plane_all_formats);
+ } else {
+ formats = ipu_plane_rgb_formats;
+ format_count = ARRAY_SIZE(ipu_plane_rgb_formats);
+ }
ipu_plane = drmm_universal_plane_alloc(dev, struct ipu_plane, base,
possible_crtcs, &ipu_plane_funcs,
- ipu_plane_formats,
- ARRAY_SIZE(ipu_plane_formats),
- modifiers, type, NULL);
+ formats, format_count, modifiers,
+ type, NULL);
if (IS_ERR(ipu_plane)) {
DRM_ERROR("failed to allocate and initialize %s plane\n",
zpos ? "overlay" : "primary");
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm/ttm: add debugfs entry to test pool shrinker v2
On Tue, Jan 19, 2021 at 01:18:20PM +0100, Christian König wrote:
> Useful for testing.
>
> v2: add fs_reclaim_acquire()/_release()
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/ttm/ttm_pool.c | 53 ++
> 1 file changed, 35 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
> index 1d61e8fc0e81..98ecb9c9842c 100644
> --- a/drivers/gpu/drm/ttm/ttm_pool.c
> +++ b/drivers/gpu/drm/ttm/ttm_pool.c
> @@ -33,6 +33,7 @@
>
> #include
> #include
> +#include
>
> #ifdef CONFIG_X86
> #include
> @@ -529,6 +530,28 @@ void ttm_pool_fini(struct ttm_pool *pool)
> }
> EXPORT_SYMBOL(ttm_pool_fini);
>
> +/* As long as pages are available make sure to release at least one */
> +static unsigned long ttm_pool_shrinker_scan(struct shrinker *shrink,
> + struct shrink_control *sc)
> +{
> + unsigned long num_freed = 0;
> +
> + do
> + num_freed += ttm_pool_shrink();
> + while (!num_freed && atomic_long_read(&allocated_pages));
> +
> + return num_freed;
> +}
> +
> +/* Return the number of pages available or SHRINK_EMPTY if we have none */
> +static unsigned long ttm_pool_shrinker_count(struct shrinker *shrink,
> + struct shrink_control *sc)
> +{
> + unsigned long num_pages = atomic_long_read(&allocated_pages);
> +
> + return num_pages ? num_pages : SHRINK_EMPTY;
> +}
> +
> #ifdef CONFIG_DEBUG_FS
> /* Count the number of pages available in a pool_type */
> static unsigned int ttm_pool_type_count(struct ttm_pool_type *pt)
> @@ -633,29 +656,21 @@ int ttm_pool_debugfs(struct ttm_pool *pool, struct
> seq_file *m)
> }
> EXPORT_SYMBOL(ttm_pool_debugfs);
>
> -#endif
> -
> -/* As long as pages are available make sure to release at least one */
> -static unsigned long ttm_pool_shrinker_scan(struct shrinker *shrink,
> - struct shrink_control *sc)
> +/* Test the shrinker functions and dump the result */
> +static int ttm_pool_debugfs_shrink_show(struct seq_file *m, void *data)
> {
> - unsigned long num_freed = 0;
> + struct shrink_control sc = { .gfp_mask = GFP_NOFS };
>
> - do
> - num_freed += ttm_pool_shrink();
> - while (!num_freed && atomic_long_read(&allocated_pages));
> + fs_reclaim_acquire(GFP_KERNEL);
> + seq_printf(m, "%lu/%lu\n", ttm_pool_shrinker_count(&mm_shrinker, &sc),
> +ttm_pool_shrinker_scan(&mm_shrinker, &sc));
> + fs_reclaim_release(GFP_KERNEL);
>
> - return num_freed;
> + return 0;
> }
> +DEFINE_SHOW_ATTRIBUTE(ttm_pool_debugfs_shrink);
Shrinking everything is a bit a hammer, but probably the right size we
need for testing :-)
Reviewed-by: Daniel Vetter
>
> -/* Return the number of pages available or SHRINK_EMPTY if we have none */
> -static unsigned long ttm_pool_shrinker_count(struct shrinker *shrink,
> - struct shrink_control *sc)
> -{
> - unsigned long num_pages = atomic_long_read(&allocated_pages);
> -
> - return num_pages ? num_pages : SHRINK_EMPTY;
> -}
> +#endif
>
> /**
> * ttm_pool_mgr_init - Initialize globals
> @@ -688,6 +703,8 @@ int ttm_pool_mgr_init(unsigned long num_pages)
> #ifdef CONFIG_DEBUG_FS
> debugfs_create_file("page_pool", 0444, ttm_debugfs_root, NULL,
> &ttm_pool_debugfs_globals_fops);
> + debugfs_create_file("page_pool_shrink", 0400, ttm_debugfs_root, NULL,
> + &ttm_pool_debugfs_shrink_fops);
> #endif
>
> mm_shrinker.count_objects = ttm_pool_shrinker_count;
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] drm/ttm: add a debugfs file for the global page pools
On Tue, Jan 19, 2021 at 01:18:19PM +0100, Christian König wrote:
> Instead of printing this on the per device pool.
>
> Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
btw I think ttm should also set up the per-bdev debugfs stuff, feels silly
having that boilerplate. Same for the per-ttm_manager thing we have I
think.
-Daniel
> ---
> drivers/gpu/drm/ttm/ttm_pool.c | 70 --
> 1 file changed, 50 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
> index 7b2f60616750..1d61e8fc0e81 100644
> --- a/drivers/gpu/drm/ttm/ttm_pool.c
> +++ b/drivers/gpu/drm/ttm/ttm_pool.c
> @@ -42,6 +42,8 @@
> #include
> #include
>
> +#include "ttm_module.h"
> +
> /**
> * struct ttm_pool_dma - Helper object for coherent DMA mappings
> *
> @@ -543,6 +545,17 @@ static unsigned int ttm_pool_type_count(struct
> ttm_pool_type *pt)
> return count;
> }
>
> +/* Print a nice header for the order */
> +static void ttm_pool_debugfs_header(struct seq_file *m)
> +{
> + unsigned int i;
> +
> + seq_puts(m, "\t ");
> + for (i = 0; i < MAX_ORDER; ++i)
> + seq_printf(m, " ---%2u---", i);
> + seq_puts(m, "\n");
> +}
> +
> /* Dump information about the different pool types */
> static void ttm_pool_debugfs_orders(struct ttm_pool_type *pt,
> struct seq_file *m)
> @@ -554,6 +567,35 @@ static void ttm_pool_debugfs_orders(struct ttm_pool_type
> *pt,
> seq_puts(m, "\n");
> }
>
> +/* Dump the total amount of allocated pages */
> +static void ttm_pool_debugfs_footer(struct seq_file *m)
> +{
> + seq_printf(m, "\ntotal\t: %8lu of %8lu\n",
> +atomic_long_read(&allocated_pages), page_pool_size);
> +}
> +
> +/* Dump the information for the global pools */
> +static int ttm_pool_debugfs_globals_show(struct seq_file *m, void *data)
> +{
> + ttm_pool_debugfs_header(m);
> +
> + spin_lock(&shrinker_lock);
> + seq_puts(m, "wc\t:");
> + ttm_pool_debugfs_orders(global_write_combined, m);
> + seq_puts(m, "uc\t:");
> + ttm_pool_debugfs_orders(global_uncached, m);
> + seq_puts(m, "wc 32\t:");
> + ttm_pool_debugfs_orders(global_dma32_write_combined, m);
> + seq_puts(m, "uc 32\t:");
> + ttm_pool_debugfs_orders(global_dma32_uncached, m);
> + spin_unlock(&shrinker_lock);
> +
> + ttm_pool_debugfs_footer(m);
> +
> + return 0;
> +}
> +DEFINE_SHOW_ATTRIBUTE(ttm_pool_debugfs_globals);
> +
> /**
> * ttm_pool_debugfs - Debugfs dump function for a pool
> *
> @@ -566,23 +608,9 @@ int ttm_pool_debugfs(struct ttm_pool *pool, struct
> seq_file *m)
> {
> unsigned int i;
>
> - spin_lock(&shrinker_lock);
> -
> - seq_puts(m, "\t ");
> - for (i = 0; i < MAX_ORDER; ++i)
> - seq_printf(m, " ---%2u---", i);
> - seq_puts(m, "\n");
> -
> - seq_puts(m, "wc\t:");
> - ttm_pool_debugfs_orders(global_write_combined, m);
> - seq_puts(m, "uc\t:");
> - ttm_pool_debugfs_orders(global_uncached, m);
> -
> - seq_puts(m, "wc 32\t:");
> - ttm_pool_debugfs_orders(global_dma32_write_combined, m);
> - seq_puts(m, "uc 32\t:");
> - ttm_pool_debugfs_orders(global_dma32_uncached, m);
> + ttm_pool_debugfs_header(m);
>
> + spin_lock(&shrinker_lock);
> for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i) {
> seq_puts(m, "DMA ");
> switch (i) {
> @@ -598,12 +626,9 @@ int ttm_pool_debugfs(struct ttm_pool *pool, struct
> seq_file *m)
> }
> ttm_pool_debugfs_orders(pool->caching[i].orders, m);
> }
> -
> - seq_printf(m, "\ntotal\t: %8lu of %8lu\n",
> -atomic_long_read(&allocated_pages), page_pool_size);
> -
> spin_unlock(&shrinker_lock);
>
> + ttm_pool_debugfs_footer(m);
> return 0;
> }
> EXPORT_SYMBOL(ttm_pool_debugfs);
> @@ -660,6 +685,11 @@ int ttm_pool_mgr_init(unsigned long num_pages)
> ttm_uncached, i);
> }
>
> +#ifdef CONFIG_DEBUG_FS
> + debugfs_create_file("page_pool", 0444, ttm_debugfs_root, NULL,
> + &ttm_pool_debugfs_globals_fops);
> +#endif
> +
> mm_shrinker.count_objects = ttm_pool_shrinker_count;
> mm_shrinker.scan_objects = ttm_pool_shrinker_scan;
> mm_shrinker.seeks = 1;
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 01/14] drm/ttm: Remap all page faults to per process dummy page.
On Mon, Jan 18, 2021 at 04:01:10PM -0500, Andrey Grodzovsky wrote:
> On device removal reroute all CPU mappings to dummy page.
>
> v3:
> Remove loop to find DRM file and instead access it
> by vma->vm_file->private_data. Move dummy page installation
> into a separate function.
>
> v4:
> Map the entire BOs VA space into on demand allocated dummy page
> on the first fault for that BO.
>
> Signed-off-by: Andrey Grodzovsky
> ---
> drivers/gpu/drm/ttm/ttm_bo_vm.c | 82
> -
> include/drm/ttm/ttm_bo_api.h| 2 +
> 2 files changed, 83 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> index 6dc96cf..ed89da3 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> @@ -34,6 +34,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
> #include
> @@ -380,25 +382,103 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault
> *vmf,
> }
> EXPORT_SYMBOL(ttm_bo_vm_fault_reserved);
>
> +static void ttm_bo_release_dummy_page(struct drm_device *dev, void *res)
> +{
> + struct page *dummy_page = (struct page *)res;
> +
> + __free_page(dummy_page);
> +}
> +
> +vm_fault_t ttm_bo_vm_dummy_page(struct vm_fault *vmf, pgprot_t prot)
> +{
> + struct vm_area_struct *vma = vmf->vma;
> + struct ttm_buffer_object *bo = vma->vm_private_data;
> + struct ttm_bo_device *bdev = bo->bdev;
> + struct drm_device *ddev = bo->base.dev;
> + vm_fault_t ret = VM_FAULT_NOPAGE;
> + unsigned long address = vma->vm_start;
> + unsigned long num_prefault = (vma->vm_end - vma->vm_start) >>
> PAGE_SHIFT;
> + unsigned long pfn;
> + struct page *page;
> + int i;
> +
> + /*
> + * Wait for buffer data in transit, due to a pipelined
> + * move.
> + */
> + ret = ttm_bo_vm_fault_idle(bo, vmf);
> + if (unlikely(ret != 0))
> + return ret;
> +
> + /* Allocate new dummy page to map all the VA range in this VMA to it*/
> + page = alloc_page(GFP_KERNEL | __GFP_ZERO);
> + if (!page)
> + return VM_FAULT_OOM;
> +
> + pfn = page_to_pfn(page);
> +
> + /*
> + * Prefault the entire VMA range right away to avoid further faults
> + */
> + for (i = 0; i < num_prefault; ++i) {
> +
> + if (unlikely(address >= vma->vm_end))
> + break;
> +
> + if (vma->vm_flags & VM_MIXEDMAP)
> + ret = vmf_insert_mixed_prot(vma, address,
> + __pfn_to_pfn_t(pfn,
> PFN_DEV),
> + prot);
> + else
> + ret = vmf_insert_pfn_prot(vma, address, pfn, prot);
> +
> + /* Never error on prefaulted PTEs */
> + if (unlikely((ret & VM_FAULT_ERROR))) {
> + if (i == 0)
> + return VM_FAULT_NOPAGE;
> + else
> + break;
> + }
> +
> + address += PAGE_SIZE;
> + }
> +
> + /* Set the page to be freed using drmm release action */
> + if (drmm_add_action_or_reset(ddev, ttm_bo_release_dummy_page, page))
> + return VM_FAULT_OOM;
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(ttm_bo_vm_dummy_page);
I think we can lift this entire thing (once the ttm_bo_vm_fault_idle is
gone) to the drm level, since nothing ttm specific in here. Probably stuff
it into drm_gem.c (but really it's not even gem specific, it's fully
generic "replace this vma with dummy pages pls" function.
Aside from this nit I think the overall approach you have here is starting
to look good. Lots of work&polish, but imo we're getting there and can
start landing stuff soon.
-Daniel
> +
> vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
> {
> struct vm_area_struct *vma = vmf->vma;
> pgprot_t prot;
> struct ttm_buffer_object *bo = vma->vm_private_data;
> + struct drm_device *ddev = bo->base.dev;
> vm_fault_t ret;
> + int idx;
>
> ret = ttm_bo_vm_reserve(bo, vmf);
> if (ret)
> return ret;
>
> prot = vma->vm_page_prot;
> - ret = ttm_bo_vm_fault_reserved(vmf, prot, TTM_BO_VM_NUM_PREFAULT, 1);
> + if (drm_dev_enter(ddev, &idx)) {
> + ret = ttm_bo_vm_fault_reserved(vmf, prot,
> TTM_BO_VM_NUM_PREFAULT, 1);
> + drm_dev_exit(idx);
> + } else {
> + ret = ttm_bo_vm_dummy_page(vmf, prot);
> + }
> if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
> return ret;
>
> dma_resv_unlock(bo->base.resv);
>
> return ret;
> +
> + return ret;
> }
> EXPORT_SYMBOL(ttm_bo_vm_fault);
>
> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
> index e17be32..12fb240 100644
> --- a/include/drm/ttm/ttm_bo_api.h
> +++ b/includ
Re: [PATCH v4 07/14] drm/amdgpu: Register IOMMU topology notifier per device.
On Tue, Jan 19, 2021 at 09:48:03AM +0100, Christian König wrote:
> Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
> > Handle all DMA IOMMU gropup related dependencies before the
> > group is removed.
> >
> > Signed-off-by: Andrey Grodzovsky
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu.h| 5
> > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 46
> > ++
> > drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 2 +-
> > drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h | 1 +
> > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 10 +++
> > drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 ++
> > 6 files changed, 65 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > index 478a7d8..2953420 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > @@ -51,6 +51,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > @@ -1041,6 +1042,10 @@ struct amdgpu_device {
> > boolin_pci_err_recovery;
> > struct pci_saved_state *pci_state;
> > +
> > + struct notifier_block nb;
> > + struct blocking_notifier_head notifier;
> > + struct list_headdevice_bo_list;
> > };
> > static inline struct amdgpu_device *drm_to_adev(struct drm_device *ddev)
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > index 45e23e3..e99f4f1 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > @@ -70,6 +70,8 @@
> > #include
> > #include
> > +#include
> > +
> > MODULE_FIRMWARE("amdgpu/vega10_gpu_info.bin");
> > MODULE_FIRMWARE("amdgpu/vega12_gpu_info.bin");
> > MODULE_FIRMWARE("amdgpu/raven_gpu_info.bin");
> > @@ -3200,6 +3202,39 @@ static const struct attribute
> > *amdgpu_dev_attributes[] = {
> > };
> > +static int amdgpu_iommu_group_notifier(struct notifier_block *nb,
> > +unsigned long action, void *data)
> > +{
> > + struct amdgpu_device *adev = container_of(nb, struct amdgpu_device, nb);
> > + struct amdgpu_bo *bo = NULL;
> > +
> > + /*
> > +* Following is a set of IOMMU group dependencies taken care of before
> > +* device's IOMMU group is removed
> > +*/
> > + if (action == IOMMU_GROUP_NOTIFY_DEL_DEVICE) {
> > +
> > + spin_lock(&ttm_bo_glob.lru_lock);
> > + list_for_each_entry(bo, &adev->device_bo_list, bo) {
> > + if (bo->tbo.ttm)
> > + ttm_tt_unpopulate(bo->tbo.bdev, bo->tbo.ttm);
> > + }
> > + spin_unlock(&ttm_bo_glob.lru_lock);
>
> That approach won't work. ttm_tt_unpopulate() might sleep on an IOMMU lock.
>
> You need to use a mutex here or even better make sure you can access the
> device_bo_list without a lock in this moment.
I'd also be worried about the notifier mutex getting really badly in the
way.
Plus I'm worried why we even need this, it sounds a bit like papering over
the iommu subsystem. Assuming we clean up all our iommu mappings in our
device hotunplug/unload code, why do we still need to have an additional
iommu notifier on top, with all kinds of additional headaches? The iommu
shouldn't clean up before the devices in its group have cleaned up.
I think we need more info here on what the exact problem is first.
-Daniel
>
> Christian.
>
> > +
> > + if (adev->irq.ih.use_bus_addr)
> > + amdgpu_ih_ring_fini(adev, &adev->irq.ih);
> > + if (adev->irq.ih1.use_bus_addr)
> > + amdgpu_ih_ring_fini(adev, &adev->irq.ih1);
> > + if (adev->irq.ih2.use_bus_addr)
> > + amdgpu_ih_ring_fini(adev, &adev->irq.ih2);
> > +
> > + amdgpu_gart_dummy_page_fini(adev);
> > + }
> > +
> > + return NOTIFY_OK;
> > +}
> > +
> > +
> > /**
> >* amdgpu_device_init - initialize the driver
> >*
> > @@ -3304,6 +3339,8 @@ int amdgpu_device_init(struct amdgpu_device *adev,
> > INIT_WORK(&adev->xgmi_reset_work, amdgpu_device_xgmi_reset_func);
> > + INIT_LIST_HEAD(&adev->device_bo_list);
> > +
> > adev->gfx.gfx_off_req_count = 1;
> > adev->pm.ac_power = power_supply_is_system_supplied() > 0;
> > @@ -3575,6 +3612,15 @@ int amdgpu_device_init(struct amdgpu_device *adev,
> > if (amdgpu_device_cache_pci_state(adev->pdev))
> > pci_restore_state(pdev);
> > + BLOCKING_INIT_NOTIFIER_HEAD(&adev->notifier);
> > + adev->nb.notifier_call = amdgpu_iommu_group_notifier;
> > +
> > + if (adev->dev->iommu_group) {
> > + r = iommu_group_register_notifier(adev->dev->iommu_group,
> > &adev->nb);
> > + if (r)
> > + goto failed;
> > + }
> > +
> > return 0;
> > failed:
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
> >
Re: [PATCH 1/1] drm/atomic: put state on error path
On Tue, Jan 19, 2021 at 04:11:27AM -0800, Pan Bian wrote:
> Put the state before returning error code.
>
> Fixes: 44596b8c4750 ("drm/atomic: Unify conflicting encoder handling.")
>
> Signed-off-by: Pan Bian
Nice catch, patch merged to drm-misc-fixes with cc: stable.
-Daniel
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index ba1507036f26..4a8cbec832bc 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3021,7 +3021,7 @@ int drm_atomic_helper_set_config(struct drm_mode_set
> *set,
>
> ret = handle_conflicting_encoders(state, true);
> if (ret)
> - return ret;
> + goto fail;
>
> ret = drm_atomic_commit(state);
>
> --
> 2.17.1
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/ttm: optimize ttm pool shrinker a bit
On Tue, Jan 19, 2021 at 01:11:36PM +0100, Christian König wrote: > Am 07.01.21 um 17:38 schrieb Daniel Vetter: > > On Thu, Jan 07, 2021 at 01:49:45PM +0100, Christian König wrote: > > > Am 22.12.20 um 14:51 schrieb Daniel Vetter: > > > > On Fri, Dec 18, 2020 at 06:55:38PM +0100, Christian König wrote: > > > > > Only initialize the DMA coherent pools if they are used. > > > > > > > > > > Signed-off-by: Christian König > > > > Ah, just realized the answer to my question on patch 2: The pools are > > > > per-device, due to dma_alloc_coherent being per-device (but really > > > > mostly > > > > it isn't, but that's what we have to deal with fighting the dma-api > > > > abstraction). > > > > > > > > I think this would make a lot more sense if the shrinkers are per-pool > > > > (and also most of the debugfs files), since as-is in a multi-gpu system > > > > the first gpu's pool gets preferrentially thrashed. Which isn't a nice > > > > design. Splitting that into per gpu shrinkers means we get equal > > > > shrinking > > > > without having to maintain a global lru. This is how xfs seems to set up > > > > their shrinkers, and in general xfs people have a solid understanding of > > > > this stuff. > > > Well fairness and not trashing the first GPUs pool is the reason why I > > > implemented just one shrinker plus a global LRU. > > That's kinda defeating the point of how the core mm works. At least of how > > I'm understanding how it works. Imo we shouldn't try to re-implement this > > kind of balancing across different pools in our callback, since core mm > > tries pretty hard to equally shrink already (it only shrinks each shrinker > > a little bit each round, but does a lot of rounds under memory pressure). > > Correct, see the problem is that we don't want to shrink from each pool on > each round. > > E.g. we have something like 48 global pools and 36 for each device which > needs a DMA coherent pool. > > On each round we want to shrink only one cached item from one pool and not > 48. Hm if the pool is that small, then this feels like we're caching at the wrong level, and probably we should cache at the dma-api level. Or well, below that even. Either way that kind of design stuff should be captured in an overview DOC: kerneldoc imo. Also the point of shrinkers is that they really should be all sized equally, so if there's very little stuff in them, they shouldn't get shrunk on first round. Otoh if they're huge, they will be shrunk big time. So aside from fringe effects of rounding slightly different since it's all integers, did you actually measure a benefit here? Or is this more conjecture about how you think shrinkers work or don't work? > > Also maintaining your own global lru means global locking for the usual > > case of none-to-little memory contention, unecessarily wasting the fast > > path. > > No, the fast path doesn't need to take the global LRU lock. > > I've optimized this quite a bit by looking into the pools only once for each > power of two. > > > > In other words shrink_slab() just uses list_for_each_entry() on all > > > shrinkers. > > > > > > In the pool shrinker callback shrink one pool and move it to the end of > > > the > > > shrinker list. > > > > > > > Aside: I think it also would make tons of sense to split up your new ttm > > > > bo shrinker up into a per-device lru, and throw the global system memory > > > > lru out the window completely :-) Assuming we can indeed get rid of it, > > > > and vmwgfx doesn't need it somewhere still. > > > Yeah, I already have that as a patch set here, but I have this dependent > > > on > > > a larger rename of the device structures. > > Hm maybe include that in the next round, just for the bigger picture? > > Don't have to merge it all in one go, just want to make sure we agree on > > where we're going. > > I need to clean this set up quite a bit. Let's push this one here upstream > first. Hm yeah I guess we need to get somewhere first, but this feels a bit murky. I'll try and review more details for the next round at least. -Daniel > > > > > Aside from this lgtm, but I guess will change a bit with that shuffling. > > > Thanks for the review, going to send out a new version with the > > > fs_reclaim_acquire/release added in a minute. > > Cool. > > > > Cheers, Daniel > > Got distracted by bug fixes in the last two weeks, but really going to send > that out now :) > > Christian. > > > > > > Christian. > > > > > > > -Daniel > > > > > > > > > --- > > > > >drivers/gpu/drm/ttm/ttm_pool.c | 23 --- > > > > >1 file changed, 16 insertions(+), 7 deletions(-) > > > > > > > > > > diff --git a/drivers/gpu/drm/ttm/ttm_pool.c > > > > > b/drivers/gpu/drm/ttm/ttm_pool.c > > > > > index 1cdacd58753a..f09e34614226 100644 > > > > > --- a/drivers/gpu/drm/ttm/ttm_pool.c > > > > > +++ b/drivers/gpu/drm/ttm/ttm_pool.c > > > > > @@ -504,10 +504,12 @@ void ttm_pool_init(struct ttm_pool *pool, > > > > > struct device *dev, >
