[PATCH v3 4/4] drm/xe/FLR: Support PCIe FLR
PCI subsystem provides callbacks to inform the driver about a request to
do function level reset by user, initiated by writing to sysfs entry
/sys/bus/pci/devices/.../reset. This will allow the driver to handle FLR
without the need to do unbind and rebind as the driver needs to
reinitialize the device afresh post FLR.
v2:
1. separate out gt idle and pci save/restore to a separate patch (Lucas)
2. Fixed the warnings seen around xe_guc_submit_stop, xe_guc_puc_fini
v3: declare xe_pci_err_handlers as static(Michal)
Cc: Rodrigo Vivi
Cc: Lucas De Marchi
Cc: Michal Wajdeczko
Reviewed-by: Rodrigo Vivi
Signed-off-by: Aravind Iddamsetty
---
drivers/gpu/drm/xe/Makefile | 1 +
drivers/gpu/drm/xe/xe_device_types.h | 3 +
drivers/gpu/drm/xe/xe_guc_pc.c | 4 ++
drivers/gpu/drm/xe/xe_pci.c | 9 ++-
drivers/gpu/drm/xe/xe_pci.h | 2 +
drivers/gpu/drm/xe/xe_pci_err.c | 88
drivers/gpu/drm/xe/xe_pci_err.h | 13
7 files changed, 119 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/xe/xe_pci_err.c
create mode 100644 drivers/gpu/drm/xe/xe_pci_err.h
diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile
index 8bc62bfbc679..693971a1fac0 100644
--- a/drivers/gpu/drm/xe/Makefile
+++ b/drivers/gpu/drm/xe/Makefile
@@ -117,6 +117,7 @@ xe-y += xe_bb.o \
xe_module.o \
xe_pat.o \
xe_pci.o \
+ xe_pci_err.o \
xe_pcode.o \
xe_pm.o \
xe_preempt_fence.o \
diff --git a/drivers/gpu/drm/xe/xe_device_types.h
b/drivers/gpu/drm/xe/xe_device_types.h
index 0a66555229e9..8c749b378a92 100644
--- a/drivers/gpu/drm/xe/xe_device_types.h
+++ b/drivers/gpu/drm/xe/xe_device_types.h
@@ -465,6 +465,9 @@ struct xe_device {
/** @pci_state: PCI state of device */
struct pci_saved_state *pci_state;
+ /** @pci_device_is_reset: device went through PCIe FLR */
+ bool pci_device_is_reset;
+
/* private: */
#if IS_ENABLED(CONFIG_DRM_XE_DISPLAY)
diff --git a/drivers/gpu/drm/xe/xe_guc_pc.c b/drivers/gpu/drm/xe/xe_guc_pc.c
index 509649d0e65e..efba0fbe2f5c 100644
--- a/drivers/gpu/drm/xe/xe_guc_pc.c
+++ b/drivers/gpu/drm/xe/xe_guc_pc.c
@@ -902,6 +902,10 @@ static void xe_guc_pc_fini(struct drm_device *drm, void
*arg)
return;
}
+ /* We already have done this before going through a reset, so skip here
*/
+ if (xe->pci_device_is_reset)
+ return;
+
XE_WARN_ON(xe_force_wake_get(gt_to_fw(pc_to_gt(pc)), XE_FORCEWAKE_ALL));
XE_WARN_ON(xe_guc_pc_gucrc_disable(pc));
XE_WARN_ON(xe_guc_pc_stop(pc));
diff --git a/drivers/gpu/drm/xe/xe_pci.c b/drivers/gpu/drm/xe/xe_pci.c
index a62300990e19..b5a582afc9e7 100644
--- a/drivers/gpu/drm/xe/xe_pci.c
+++ b/drivers/gpu/drm/xe/xe_pci.c
@@ -23,6 +23,7 @@
#include "xe_macros.h"
#include "xe_mmio.h"
#include "xe_module.h"
+#include "xe_pci_err.h"
#include "xe_pci_types.h"
#include "xe_pm.h"
#include "xe_sriov.h"
@@ -738,7 +739,7 @@ static void xe_pci_remove(struct pci_dev *pdev)
pci_set_drvdata(pdev, NULL);
}
-static int xe_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
+int xe_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
{
const struct xe_device_desc *desc = (const void *)ent->driver_data;
const struct xe_subplatform_desc *subplatform_desc;
@@ -986,6 +987,11 @@ static const struct dev_pm_ops xe_pm_ops = {
};
#endif
+static const struct pci_error_handlers xe_pci_err_handlers = {
+ .reset_prepare = xe_pci_reset_prepare,
+ .reset_done = xe_pci_reset_done,
+};
+
static struct pci_driver xe_pci_driver = {
.name = DRIVER_NAME,
.id_table = pciidlist,
@@ -995,6 +1001,7 @@ static struct pci_driver xe_pci_driver = {
#ifdef CONFIG_PM_SLEEP
.driver.pm = &xe_pm_ops,
#endif
+ .err_handler = &xe_pci_err_handlers,
};
int xe_register_pci_driver(void)
diff --git a/drivers/gpu/drm/xe/xe_pci.h b/drivers/gpu/drm/xe/xe_pci.h
index 73b90a430d1f..9faf5380a09e 100644
--- a/drivers/gpu/drm/xe/xe_pci.h
+++ b/drivers/gpu/drm/xe/xe_pci.h
@@ -7,8 +7,10 @@
#define _XE_PCI_H_
struct pci_dev;
+struct pci_device_id;
int xe_register_pci_driver(void);
void xe_unregister_pci_driver(void);
void xe_load_pci_state(struct pci_dev *pdev);
+int xe_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent);
#endif
diff --git a/drivers/gpu/drm/xe/xe_pci_err.c b/drivers/gpu/drm/xe/xe_pci_err.c
new file mode 100644
index ..5306925ea2fa
--- /dev/null
+++ b/drivers/gpu/drm/xe/xe_pci_err.c
@@ -0,0 +1,88 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2024 Intel Corporation
+ */
+
+#include
+#include
+
+#include "xe_device.h"
+#include "xe_gt.h"
+#include "xe_gt_printk.h"
+#include "xe_pci.h"
+#include "xe_pci_err.h"
+#include "xe_pm.h"
+#include "xe_uc.h"
+
+/**
+ * xe_pci_reset_prepare - Called when user issued a PCIe reset
+ * via /sys/bus/pc
[PATCH v2 3/4] drm/xe: Extract xe_gt_idle() helper
This would be used in other places outside of gt_reset path.
v2:
1. Add kernel doc for xe_gt_idle (Michal)
2. fix return as no actual error is reported by xe_uc_stop (Himal)
Cc: Lucas De Marchi
Cc: Michal Wajdeczko
Cc: Himal Prasad Ghimiray
Reviewed-by: Rodrigo Vivi
Signed-off-by: Aravind Iddamsetty
---
drivers/gpu/drm/xe/xe_gt.c | 28 ++--
drivers/gpu/drm/xe/xe_gt.h | 1 +
2 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_gt.c b/drivers/gpu/drm/xe/xe_gt.c
index 491d0413de15..a24340219c30 100644
--- a/drivers/gpu/drm/xe/xe_gt.c
+++ b/drivers/gpu/drm/xe/xe_gt.c
@@ -629,6 +629,23 @@ static int do_gt_restart(struct xe_gt *gt)
return 0;
}
+/**
+ * xe_gt_idle: Idle the GT.
+ * @gt: The gt object
+ *
+ * Typically called before initiating any resets.
+ *
+ */
+void xe_gt_idle(struct xe_gt *gt)
+{
+ xe_gt_sanitize(gt);
+ xe_uc_gucrc_disable(>->uc);
+ xe_uc_stop_prepare(>->uc);
+ xe_gt_pagefault_reset(gt);
+ xe_uc_stop(>->uc);
+ xe_gt_tlb_invalidation_reset(gt);
+}
+
static int gt_reset(struct xe_gt *gt)
{
int err;
@@ -645,21 +662,12 @@ static int gt_reset(struct xe_gt *gt)
}
xe_pm_runtime_get(gt_to_xe(gt));
- xe_gt_sanitize(gt);
err = xe_force_wake_get(gt_to_fw(gt), XE_FORCEWAKE_ALL);
if (err)
goto err_msg;
- xe_uc_gucrc_disable(>->uc);
- xe_uc_stop_prepare(>->uc);
- xe_gt_pagefault_reset(gt);
-
- err = xe_uc_stop(>->uc);
- if (err)
- goto err_out;
-
- xe_gt_tlb_invalidation_reset(gt);
+ xe_gt_idle(gt);
err = do_gt_reset(gt);
if (err)
diff --git a/drivers/gpu/drm/xe/xe_gt.h b/drivers/gpu/drm/xe/xe_gt.h
index ed6ea8057e35..dcc1023d20e8 100644
--- a/drivers/gpu/drm/xe/xe_gt.h
+++ b/drivers/gpu/drm/xe/xe_gt.h
@@ -43,6 +43,7 @@ int xe_gt_resume(struct xe_gt *gt);
void xe_gt_reset_async(struct xe_gt *gt);
void xe_gt_sanitize(struct xe_gt *gt);
void xe_gt_remove(struct xe_gt *gt);
+void xe_gt_idle(struct xe_gt *gt);
/**
* xe_gt_any_hw_engine_by_reset_domain - scan the list of engines and return
the
--
2.25.1
[PATCH 2/4] drm/xe: Save and restore PCI state
Save and restore PCI states where ever needed.
Cc: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
Signed-off-by: Aravind Iddamsetty
---
drivers/gpu/drm/xe/xe_device_types.h | 3 ++
drivers/gpu/drm/xe/xe_pci.c | 48 ++--
drivers/gpu/drm/xe/xe_pci.h | 4 ++-
3 files changed, 51 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_device_types.h
b/drivers/gpu/drm/xe/xe_device_types.h
index 8244b177a6a3..0a66555229e9 100644
--- a/drivers/gpu/drm/xe/xe_device_types.h
+++ b/drivers/gpu/drm/xe/xe_device_types.h
@@ -462,6 +462,9 @@ struct xe_device {
/** @needs_flr_on_fini: requests function-reset on fini */
bool needs_flr_on_fini;
+ /** @pci_state: PCI state of device */
+ struct pci_saved_state *pci_state;
+
/* private: */
#if IS_ENABLED(CONFIG_DRM_XE_DISPLAY)
diff --git a/drivers/gpu/drm/xe/xe_pci.c b/drivers/gpu/drm/xe/xe_pci.c
index fb20c9828563..a62300990e19 100644
--- a/drivers/gpu/drm/xe/xe_pci.c
+++ b/drivers/gpu/drm/xe/xe_pci.c
@@ -393,6 +393,41 @@ MODULE_DEVICE_TABLE(pci, pciidlist);
#undef INTEL_VGA_DEVICE
+static bool xe_save_pci_state(struct pci_dev *pdev)
+{
+ struct xe_device *xe = pci_get_drvdata(pdev);
+
+ if (pci_save_state(pdev))
+ return false;
+
+ kfree(xe->pci_state);
+
+ xe->pci_state = pci_store_saved_state(pdev);
+ if (!xe->pci_state) {
+ drm_err(&xe->drm, "Failed to store PCI saved state\n");
+ return false;
+ }
+
+ return true;
+}
+
+void xe_load_pci_state(struct pci_dev *pdev)
+{
+ struct xe_device *xe = pci_get_drvdata(pdev);
+ int ret;
+
+ if (!xe->pci_state)
+ return;
+
+ ret = pci_load_saved_state(pdev, xe->pci_state);
+ if (ret) {
+ drm_warn(&xe->drm, "Failed to load PCI state err:%d\n", ret);
+ return;
+ }
+
+ pci_restore_state(pdev);
+}
+
/* is device_id present in comma separated list of ids */
static bool device_id_in_list(u16 device_id, const char *devices, bool
negative)
{
@@ -698,6 +733,8 @@ static void xe_pci_remove(struct pci_dev *pdev)
xe_device_remove(xe);
xe_pm_runtime_fini(xe);
+
+ kfree(xe->pci_state);
pci_set_drvdata(pdev, NULL);
}
@@ -798,6 +835,9 @@ static int xe_pci_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
drm_dbg(&xe->drm, "d3cold: capable=%s\n",
str_yes_no(xe->d3cold.capable));
+ if (xe_save_pci_state(pdev))
+ pci_restore_state(pdev);
+
return 0;
err_driver_cleanup:
@@ -849,7 +889,7 @@ static int xe_pci_suspend(struct device *dev)
*/
d3cold_toggle(pdev, D3COLD_ENABLE);
- pci_save_state(pdev);
+ xe_save_pci_state(pdev);
pci_disable_device(pdev);
return 0;
@@ -873,6 +913,8 @@ static int xe_pci_resume(struct device *dev)
pci_set_master(pdev);
+ xe_load_pci_state(pdev);
+
err = xe_pm_resume(pdev_to_xe_device(pdev));
if (err)
return err;
@@ -890,7 +932,7 @@ static int xe_pci_runtime_suspend(struct device *dev)
if (err)
return err;
- pci_save_state(pdev);
+ xe_save_pci_state(pdev);
if (xe->d3cold.allowed) {
d3cold_toggle(pdev, D3COLD_ENABLE);
@@ -915,7 +957,7 @@ static int xe_pci_runtime_resume(struct device *dev)
if (err)
return err;
- pci_restore_state(pdev);
+ xe_load_pci_state(pdev);
if (xe->d3cold.allowed) {
err = pci_enable_device(pdev);
diff --git a/drivers/gpu/drm/xe/xe_pci.h b/drivers/gpu/drm/xe/xe_pci.h
index 611c1209b14c..73b90a430d1f 100644
--- a/drivers/gpu/drm/xe/xe_pci.h
+++ b/drivers/gpu/drm/xe/xe_pci.h
@@ -6,7 +6,9 @@
#ifndef _XE_PCI_H_
#define _XE_PCI_H_
+struct pci_dev;
+
int xe_register_pci_driver(void);
void xe_unregister_pci_driver(void);
-
+void xe_load_pci_state(struct pci_dev *pdev);
#endif
--
2.25.1
[PATCH v3 1/4] drm: add devm release action
In scenarios where drm_dev_put is directly called by driver we want to
release devm_drm_dev_init_release action associated with struct
drm_device.
v2: Directly expose the original function, instead of introducing a
helper (Rodrigo)
v3: add kernel-doc (Maxime Ripard)
Cc: Maxime Ripard
Cc: Thomas Hellstr_m
Cc: Rodrigo Vivi
Reviewed-by: Rodrigo Vivi
Signed-off-by: Aravind Iddamsetty
---
drivers/gpu/drm/drm_drv.c | 13 +
include/drm/drm_drv.h | 2 ++
2 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 243cacb3575c..9d0409165f1e 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -714,6 +714,19 @@ static int devm_drm_dev_init(struct device *parent,
devm_drm_dev_init_release, dev);
}
+/**
+ * devm_drm_dev_release_action - Call the final release action of the device
+ * @dev: DRM device
+ *
+ * In scenarios where drm_dev_put is directly called by driver we want to
release
+ * devm_drm_dev_init_release action associated with struct drm_device.
+ */
+void devm_drm_dev_release_action(struct drm_device *dev)
+{
+ devm_release_action(dev->dev, devm_drm_dev_init_release, dev);
+}
+EXPORT_SYMBOL(devm_drm_dev_release_action);
+
void *__devm_drm_dev_alloc(struct device *parent,
const struct drm_driver *driver,
size_t size, size_t offset)
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 8878260d7529..fa9123684874 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -444,6 +444,8 @@ struct drm_driver {
const struct file_operations *fops;
};
+void devm_drm_dev_release_action(struct drm_device *dev);
+
void *__devm_drm_dev_alloc(struct device *parent,
const struct drm_driver *driver,
size_t size, size_t offset);
--
2.25.1
[PATCH v4 0/4] drm/xe: Support PCIe FLR
PCI subsystem provides callbacks to inform the driver about a request to do function level reset by user, initiated by writing to sysfs entry /sys/bus/pci/devices/.../reset. This will allow the driver to handle FLR without the need to do unbind and rebind as the driver needs to reinitialize the device afresh post FLR. v4: add kernel-doc v3: Trivial fix v2: 1. Directly expose the devm_drm_dev_release_action instead of introducing a helper (Rodrigo) 2. separate out gt idle and pci save/restore to a separate patch (Lucas) 3. Fixed the warnings seen around xe_guc_submit_stop, xe_guc_puc_fini Rodrigo, retaining your r-b's since there are no functional changes. Cc: Rodrigo Vivi Cc: Lucas De Marchi dmesg snip showing FLR recovery: [ 590.486336] xe :4d:00.0: enabling device (0140 -> 0142) [ 590.506933] xe :4d:00.0: [drm] Using GuC firmware from xe/pvc_guc_70.20.0.bin version 70.20.0 [ 590.542355] xe :4d:00.0: [drm] Using GuC firmware from xe/pvc_guc_70.20.0.bin version 70.20.0 [ 590.578532] xe :4d:00.0: [drm] VISIBLE VRAM: 0x2020, 0x0020 [ 590.578556] xe :4d:00.0: [drm] VRAM[0, 0]: Actual physical size 0x0010, usable size exclude stolen 0x000fff00, CPU accessible size 0x000fff00 [ 590.578560] xe :4d:00.0: [drm] VRAM[0, 0]: DPA range: [0x-10], io range: [0x2020-202fff00] [ 590.578585] xe :4d:00.0: [drm] VRAM[1, 1]: Actual physical size 0x0010, usable size exclude stolen 0x000fff00, CPU accessible size 0x000fff00 [ 590.578589] xe :4d:00.0: [drm] VRAM[1, 1]: DPA range: [0x0010-20], io range: [0x2030-203fff00] [ 590.578592] xe :4d:00.0: [drm] Total VRAM: 0x2020, 0x0020 [ 590.578594] xe :4d:00.0: [drm] Available VRAM: 0x2020, 0x001ffe00 [ 590.738899] xe :4d:00.0: [drm] GT0: CCS_MODE=0 config:0040, num_engines:1, num_slices:4 [ 590.889991] xe :4d:00.0: [drm] GT1: CCS_MODE=0 config:0040, num_engines:1, num_slices:4 [ 590.892835] [drm] Initialized xe 1.1.0 20201103 for :4d:00.0 on minor 1 [ 590.900215] xe :9a:00.0: enabling device (0140 -> 0142) [ 590.915991] xe :9a:00.0: [drm] Using GuC firmware from xe/pvc_guc_70.20.0.bin version 70.20.0 [ 590.957450] xe :9a:00.0: [drm] Using GuC firmware from xe/pvc_guc_70.20.0.bin version 70.20.0 [ 590.989863] xe :9a:00.0: [drm] VISIBLE VRAM: 0x20e0, 0x0020 [ 590.989888] xe :9a:00.0: [drm] VRAM[0, 0]: Actual physical size 0x0010, usable size exclude stolen 0x000fff00, CPU accessible size 0x000fff00 [ 590.989893] xe :9a:00.0: [drm] VRAM[0, 0]: DPA range: [0x-10], io range: [0x20e0-20efff00] [ 590.989918] xe :9a:00.0: [drm] VRAM[1, 1]: Actual physical size 0x0010, usable size exclude stolen 0x000fff00, CPU accessible size 0x000fff00 [ 590.989921] xe :9a:00.0: [drm] VRAM[1, 1]: DPA range: [0x0010-20], io range: [0x20f0-2000] [ 590.989924] xe :9a:00.0: [drm] Total VRAM: 0x20e0, 0x0020 [ 590.989927] xe :9a:00.0: [drm] Available VRAM: 0x20e0, 0x001ffe00 [ 591.142061] xe :9a:00.0: [drm] GT0: CCS_MODE=0 config:0040, num_engines:1, num_slices:4 [ 591.293505] xe :9a:00.0: [drm] GT1: CCS_MODE=0 config:0040, num_engines:1, num_slices:4 [ 591.295487] [drm] Initialized xe 1.1.0 20201103 for :9a:00.0 on minor 2 [ 610.685993] Console: switching to colour dummy device 80x25 [ 610.686118] [IGT] xe_exec_basic: executing [ 610.755398] xe :4d:00.0: [drm] GT0: CCS_MODE=0 config:0040, num_engines:1, num_slices:4 [ 610.771783] xe :4d:00.0: [drm] GT1: CCS_MODE=0 config:0040, num_engines:1, num_slices:4 [ 610.773542] [IGT] xe_exec_basic: starting subtest once-basic [ 610.960251] [IGT] xe_exec_basic: finished subtest once-basic, SUCCESS [ 610.962741] [IGT] xe_exec_basic: exiting, ret=0 [ 610.977203] Console: switching to colour frame buffer device 128x48 [ 611.006675] xe_exec_basic (3237) used greatest stack depth: 11128 bytes left [ 644.682201] xe :4d:00.0: [drm] GT0: CCS_MODE=0 config:0040, num_engines:1, num_slices:4 [ 644.699060] xe :4d:00.0: [drm] GT1: CCS_MODE=0 config:0040, num_engines:1, num_slices:4 [ 644.699118] xe :4d:00.0: preparing for PCIe FLR reset [ 644.699149] xe :4d:00.0: [drm] removing device access to userspace [ 644.928577] xe :4d:00.0: PCI device went through FLR, reenabling the device [ 656.104233] xe :4d:00.0: [drm] Using GuC firmware from xe/pvc_guc_70.20.0.bin version 70.20.0 [ 656.149525] xe :4d:00.0: [drm] Using GuC firmware from xe/pvc_guc_70.20.0.bin version 70.20.0 [ 656.182711] xe :4d:00.0: [drm] VISIBLE VRAM: 0x2020, 0x0020 [ 656.1827
Re: [PATCH] drm/panfrost: Fix dma_resv deadlock at drm object pin time
On Sun, 21 Apr 2024 17:39:47 +0100
Adrián Larumbe wrote:
> When Panfrost must pin an object that is being prepared a dma-buf
> attachment for on behalf of another driver, the core drm gem object pinning
> code already takes a lock on the object's dma reservation.
>
> However, Panfrost GEM object's pinning callback would eventually try taking
> the lock on the same dma reservation when delegating pinning of the object
> onto the shmem subsystem, which led to a deadlock.
>
> This can be shown by enabling CONFIG_DEBUG_WW_MUTEX_SLOWPATH, which throws
> the following recursive locking situation:
>
> weston/3440 is trying to acquire lock:
> 00e235a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at:
> drm_gem_shmem_pin+0x34/0xb8 [drm_shmem_helper]
> but task is already holding lock:
> 00e235a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at:
> drm_gem_pin+0x2c/0x80 [drm]
>
> Fix it by assuming the object's reservation had already been locked by the
> time we reach panfrost_gem_pin.
>
> Cc: Thomas Zimmermann
> Cc: Dmitry Osipenko
> Cc: Boris Brezillon
> Cc: Steven Price
> Fixes: a78027847226 ("drm/gem: Acquire reservation lock in
> drm_gem_{pin/unpin}()")
> Signed-off-by: Adrián Larumbe
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/panfrost/panfrost_gem.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c
> b/drivers/gpu/drm/panfrost/panfrost_gem.c
> index d47b40b82b0b..6c26652d425d 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_gem.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
> @@ -192,7 +192,12 @@ static int panfrost_gem_pin(struct drm_gem_object *obj)
> if (bo->is_heap)
> return -EINVAL;
>
> - return drm_gem_shmem_pin(&bo->base);
> + /*
> + * Pinning can only happen in response to a prime attachment request
> from
> + * another driver, but that's already being handled by drm_gem_pin
> + */
> + drm_WARN_ON(obj->dev, obj->import_attach);
> + return drm_gem_shmem_pin_locked(&bo->base);
> }
>
> static enum drm_gem_object_status panfrost_gem_status(struct drm_gem_object
> *obj)
>
> base-commit: 04687bff66b8a4b22748aa7215d3baef0b318e5b
Re: [PATCH v3 5/8] drm/v3d: Reduce the alignment of the node allocation
Thanks Maíra, this patch is: Reviewed-by: Iago Toral Quiroga Iago El dom, 21-04-2024 a las 18:44 -0300, Maíra Canal escribió: > Currently, we are using an alignment of 128 kB to insert a node, > which > ends up wasting memory as we perform plenty of small BOs allocations > (<= 4 kB). We require that allocations are aligned to 128Kb so for > any > allocation smaller than that, we are wasting the difference. > > This implies that we cannot effectively use the whole 4 GB address > space > available for the GPU in the RPi 4. Currently, we can allocate up to > 32000 BOs of 4 kB (~140 MB) and 3000 BOs of 400 kB (~1,3 GB). This > can be > quite limiting for applications that have a high memory requirement, > such > as vkoverhead [1]. > > By reducing the page alignment to 4 kB, we can allocate up to 100 > BOs > of 4 kB (~4 GB) and 1 BOs of 400 kB (~4 GB). Moreover, by > performing > benchmarks, we were able to attest that reducing the page alignment > to > 4 kB can provide a general performance improvement in OpenGL > applications (e.g. glmark2). > > Therefore, this patch reduces the alignment of the node allocation to > 4 > kB, which will allow RPi users to explore the whole 4GB virtual > address space provided by the hardware. Also, this patch allow users > to > fully run vkoverhead in the RPi 4/5, solving the issue reported in > [1]. > > [1] https://github.com/zmike/vkoverhead/issues/14 > > Signed-off-by: Maíra Canal > --- > drivers/gpu/drm/v3d/v3d_bo.c | 2 +- > drivers/gpu/drm/v3d/v3d_drv.h | 2 -- > 2 files changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/v3d/v3d_bo.c > b/drivers/gpu/drm/v3d/v3d_bo.c > index a07ede668cc1..79e31c5299b1 100644 > --- a/drivers/gpu/drm/v3d/v3d_bo.c > +++ b/drivers/gpu/drm/v3d/v3d_bo.c > @@ -110,7 +110,7 @@ v3d_bo_create_finish(struct drm_gem_object *obj) > */ > ret = drm_mm_insert_node_generic(&v3d->mm, &bo->node, > obj->size >> > V3D_MMU_PAGE_SHIFT, > - GMP_GRANULARITY >> > V3D_MMU_PAGE_SHIFT, 0, 0); > + SZ_4K >> > V3D_MMU_PAGE_SHIFT, 0, 0); > spin_unlock(&v3d->mm_lock); > if (ret) > return ret; > diff --git a/drivers/gpu/drm/v3d/v3d_drv.h > b/drivers/gpu/drm/v3d/v3d_drv.h > index d2ce8222771a..17236ee23490 100644 > --- a/drivers/gpu/drm/v3d/v3d_drv.h > +++ b/drivers/gpu/drm/v3d/v3d_drv.h > @@ -17,8 +17,6 @@ struct clk; > struct platform_device; > struct reset_control; > > -#define GMP_GRANULARITY (128 * 1024) > - > #define V3D_MMU_PAGE_SHIFT 12 > > #define V3D_MAX_QUEUES (V3D_CPU + 1)
Re: [PATCH v2] mediatek: dsi: Correct calculation formula of PHY Timing
[PATCH] drm/panel-edp: Add panel CSOT MNB601LS1-1
Add support for the following panel:
CSOT MNB601LS1-1
Signed-off-by: Xuxin Xiong
---
drivers/gpu/drm/panel/panel-edp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
index d58f90bc48fb..5e0b1c94bc62 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -2036,6 +2036,8 @@ static const struct edp_panel_entry edp_panels[] = {
EDP_PANEL_ENTRY('C', 'S', 'O', 0x1200, &delay_200_500_e50,
"MNC207QS1-1"),
+ EDP_PANEL_ENTRY('C', 'S', 'W', 0x1100, &delay_200_500_e80_d50,
"MNB601LS1-1"),
+
EDP_PANEL_ENTRY('H', 'K', 'C', 0x2d51, &delay_200_500_e200, "Unknown"),
EDP_PANEL_ENTRY('H', 'K', 'C', 0x2d5b, &delay_200_500_e200, "Unknown"),
EDP_PANEL_ENTRY('H', 'K', 'C', 0x2d5c, &delay_200_500_e200,
"MB116AN01-2"),
--
2.40.1
[PATCH] drm/amdgpu: Fixup bad vram size on gmc v6 and v7
Some boards(like Oland PRO: 0x1002:0x6613) seem to have
garbage in the upper 16 bits of the vram size register,
kern log as follows:
[6.00] [drm] Detected VRAM RAM=2256537600M, BAR=256M
[6.007812] [drm] RAM width 64bits GDDR5
[6.031250] [drm] amdgpu: 2256537600M of VRAM memory ready
This is obviously not true, check for this and clamp the size
properly. Fixes boards reporting bogus amounts of vram,
kern log as follows:
[2.789062] [drm] Probable bad vram size: 0x86800800
[2.789062] [drm] Detected VRAM RAM=2048M, BAR=256M
[2.789062] [drm] RAM width 64bits GDDR5
[2.789062] [drm] amdgpu: 2048M of VRAM memory ready
Signed-off-by: Qiang Ma
---
drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 11 +--
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 13 ++---
2 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c
index 23b478639921..3703695f7789 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c
@@ -309,8 +309,15 @@ static int gmc_v6_0_mc_init(struct amdgpu_device *adev)
}
adev->gmc.vram_width = numchan * chansize;
/* size in MB on si */
- adev->gmc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
- adev->gmc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
+ tmp = RREG32(mmCONFIG_MEMSIZE);
+ /* some boards may have garbage in the upper 16 bits */
+ if (tmp & 0x) {
+ DRM_INFO("Probable bad vram size: 0x%08x\n", tmp);
+ if (tmp & 0x)
+ tmp &= 0x;
+ }
+ adev->gmc.mc_vram_size = tmp * 1024ULL * 1024ULL;
+ adev->gmc.real_vram_size = adev->gmc.mc_vram_size;
if (!(adev->flags & AMD_IS_APU)) {
r = amdgpu_device_resize_fb_bar(adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
index 3da7b6a2b00d..1df1fc578ff6 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
@@ -316,10 +316,10 @@ static void gmc_v7_0_mc_program(struct amdgpu_device
*adev)
static int gmc_v7_0_mc_init(struct amdgpu_device *adev)
{
int r;
+ u32 tmp;
adev->gmc.vram_width = amdgpu_atombios_get_vram_width(adev);
if (!adev->gmc.vram_width) {
- u32 tmp;
int chansize, numchan;
/* Get VRAM informations */
@@ -363,8 +363,15 @@ static int gmc_v7_0_mc_init(struct amdgpu_device *adev)
adev->gmc.vram_width = numchan * chansize;
}
/* size in MB on si */
- adev->gmc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
- adev->gmc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
+ tmp = RREG32(mmCONFIG_MEMSIZE);
+ /* some boards may have garbage in the upper 16 bits */
+ if (tmp & 0x) {
+ DRM_INFO("Probable bad vram size: 0x%08x\n", tmp);
+ if (tmp & 0x)
+ tmp &= 0x;
+ }
+ adev->gmc.mc_vram_size = tmp * 1024ULL * 1024ULL;
+ adev->gmc.real_vram_size = adev->gmc.mc_vram_size;
if (!(adev->flags & AMD_IS_APU)) {
r = amdgpu_device_resize_fb_bar(adev);
--
2.20.1
Re: [PATCH 3/7] ARM: configs: imx_v6_v7: Enable DRM_DW_HDMI
On Wed, Apr 03, 2024 at 12:56:21PM +0200, Maxime Ripard wrote:
> Commit 4fc8cb47fcfd ("drm/display: Move HDMI helpers into display-helper
> module") turned the DRM_DW_HDMI dependency of DRM_IMX_HDMI into a
> depends on which ended up disabling the driver in the defconfig. Make
> sure it's still enabled.
>
> Fixes: 4fc8cb47fcfd ("drm/display: Move HDMI helpers into display-helper
> module")
> Reported-by: Mark Brown
> Reported-by: Alexander Stein
> Signed-off-by: Maxime Ripard
Acked-by: Shawn Guo
Re: [PATCH 2/4] WIP: drm: Introduce rvkms
On Wed, 2024-03-27 at 21:06 +, Benno Lossin wrote:
> On 22.03.24 23:03, Lyude Paul wrote:
> > diff --git a/drivers/gpu/drm/rvkms/connector.rs
> > b/drivers/gpu/drm/rvkms/connector.rs
> > new file mode 100644
> > index 0..40f84d38437ee
> > --- /dev/null
> > +++ b/drivers/gpu/drm/rvkms/connector.rs
> > @@ -0,0 +1,55 @@
> > +// TODO: License and stuff
> > +// Contain's rvkms's drm_connector implementation
> > +
> > +use super::{RvkmsDriver, RvkmsDevice, MAX_RES, DEFAULT_RES};
> > +use kernel::{
> > + prelude::*,
> > + drm::{
> > + device::Device,
> > + kms::{
> > + connector::{self, ConnectorGuard},
> > + ModeConfigGuard
> > + }
> > + },
> > + prelude::*
> > +};
> > +use core::marker::PhantomPinned;
> > +
> > +#[pin_data]
> > +pub(crate) struct DriverConnector {
> > + #[pin]
> > + _p: PhantomPinned
> > +}
>
> This struct does not need to be annotated with `#[pin_data]`, this
> should just work:
>
> pub(crate) struct DriverConnector;
>
> > +
> > +pub(crate) type Connector = connector::Connector;
> > +
> > +impl connector::DriverConnector for DriverConnector {
> > + type Initializer = impl PinInit;
> > +
> > + type State = ConnectorState;
> > +
> > + type Driver = RvkmsDriver;
> > +
> > + type Args = ();
> > +
> > + fn new(dev: &Device, args: Self::Args) ->
> > Self::Initializer {
>
> And then here just return `Self`.
>
> This works, since there is a blanket impl `PinInit for T`.
>
> Looking at how you use this API, I am not sure if you actually need
> pin-init for the type that implements `DriverConnector`.
> Do you need to store eg `Mutex` or something else that needs
> pin-init in here in a more complex driver?
Most likely yes - a lot of drivers have various private locks contained
within their subclassed mode objects. I'm not sure we will in rvkms's
connector since vkms doesn't really do much with connectors - but we at
a minimum be using pinned types (spinlocks and hrtimers) in our
DriverCrtc implementation once I've started implementing support for
vblanks[1]
[1]
https://www.kernel.org/doc/html/v6.9-rc5/gpu/drm-kms.html?highlight=vblank#vertical-blanking
In nova (the main reason I'm working on rvkms in the first place),
we'll definitely have locks in our connectors and possibly other types.
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [PATCH 1/4] WIP: rust: Add basic KMS bindings
On Wed, 2024-03-27 at 20:50 +, Benno Lossin wrote:
> Hi,
>
> I just took a quick look and commented on the things that stuck
> out to me. Some general things:
> - several `unsafe` blocks have missing SAFETY comments,
> - missing documentation and examples.
This is really early on - so I had wanted to post a WIP before I
actually wrote up everything to make sure I'm going in the right
direction (I'm certainly not planning on leaving things undocumented
when this is actually ready for submission :).
>
> On 22.03.24 23:03, Lyude Paul wrote:
> > Signed-off-by: Lyude Paul
> > ---
> > rust/bindings/bindings_helper.h | 4 +
> > rust/helpers.c | 17 ++
> > rust/kernel/drm/device.rs | 2 +
> > rust/kernel/drm/drv.rs | 115 +++--
> > rust/kernel/drm/kms.rs | 146 +++
> > rust/kernel/drm/kms/connector.rs | 404
> > +++
> > rust/kernel/drm/kms/crtc.rs | 300 +++
> > rust/kernel/drm/kms/encoder.rs | 175 +
> > rust/kernel/drm/kms/plane.rs | 300 +++
> > rust/kernel/drm/mod.rs | 1 +
> > 10 files changed, 1448 insertions(+), 16 deletions(-)
>
> Please try to break this up into smaller patches. It makes review
> a lot easier!
I'll definitely try to do that next time!
>
> [...]
>
> > diff --git a/rust/kernel/drm/kms.rs b/rust/kernel/drm/kms.rs
> > new file mode 100644
> > index 0..b55d14415367a
> > --- /dev/null
> > +++ b/rust/kernel/drm/kms.rs
> > @@ -0,0 +1,146 @@
> > +// SPDX-License-Identifier: GPL-2.0 OR MIT
> > +
> > +//! KMS driver abstractions for rust.
> > +
> > +pub mod connector;
> > +pub mod crtc;
> > +pub mod encoder;
> > +pub mod plane;
> > +
> > +use crate::{
> > + drm::{drv, device::Device},
> > + prelude::*,
> > + types::ARef,
> > + private::Sealed
> > +};
> > +use core::{
> > + ops::Deref,
> > + ptr,
> > +};
> > +use bindings;
> > +
> > +#[derive(Copy, Clone)]
> > +pub struct ModeConfigInfo {
> > + /// The minimum (w, h) resolution this driver can support
> > + pub min_resolution: (i32, i32),
> > + /// The maximum (w, h) resolution this driver can support
> > + pub max_resolution: (i32, i32),
> > + /// The maximum (w, h) cursor size this driver can support
> > + pub max_cursor: (u32, u32),
> > + /// The preferred depth for dumb ioctls
> > + pub preferred_depth: u32,
> > +}
> > +
> > +// TODO: I am not totally sure about this. Ideally, I'd like a
> > nice way of hiding KMS-specific
> > +// functions for DRM drivers which don't implement KMS - so that
> > we don't have to have a bunch of
> > +// random modesetting functions all over the DRM device trait.
> > But, unfortunately I don't know of
> > +// any nice way of doing that yet :(
>
> I don't follow, can't you put the KMS specific functions into the
> KmsDriver trait?
I can, lol. I realized how that would work a little while after writing
this, so I'm not quite sure where my confusion was with this - so I'll
fix this on the next version I send out.
>
> > +
> > +/// An atomic KMS driver implementation
> > +pub trait KmsDriver: drv::Driver { }
> > +
> > +impl Device {
> > + pub fn mode_config_reset(&self) {
> > + // SAFETY: The previous build assertion ensures this can
> > only be called for devices with KMS
> > + // support, which means mode_config is initialized
> > + unsafe { bindings::drm_mode_config_reset(self.drm.get()) }
> > + }
> > +}
> > +
> > +/// Main trait for a modesetting object in DRM
> > +pub trait ModeObject: Sealed + Send + Sync {
> > + /// The parent driver for this ModeObject
> > + type Driver: KmsDriver;
> > +
> > + /// Return the `drv::Device` for this `ModeObject`
> > + fn drm_dev(&self) -> &Device;
> > +}
>
> [...]
>
> > diff --git a/rust/kernel/drm/kms/connector.rs
> > b/rust/kernel/drm/kms/connector.rs
> > new file mode 100644
> > index 0..88dfa946d306b
> > --- /dev/null
> > +++ b/rust/kernel/drm/kms/connector.rs
> > @@ -0,0 +1,404 @@
> > +// SPDX-License-Identifier: GPL-2.0 OR MIT
> > +
> > +//! Rust bindings for DRM connectors
> > +
> > +use crate::{
> > + bindings,
> > + sync::ArcBorrow,
> > + drm::{
> > + drv::{Driver, FEAT_MODESET},
> > + device::Device,
> > + },
> > + types::{AlwaysRefCounted, Opaque, ARef},
> > + prelude::*,
> > + init::Zeroable,
> > + error::{to_result, from_result},
> > + build_error,
> > +};
> > +use core::{
> > + marker::PhantomPinned,
> > + ptr::null_mut,
> > + mem,
> > + ptr::{self, NonNull},
> > + ffi::*,
> > + ops::Deref,
> > +};
> > +use super::{
> > + ModeObject,
> > + ModeConfigGuard,
> > + encoder::{Encoder, DriverEncoder},
> > + KmsDriver,
> > +};
> > +use macros::pin_data;
> > +
> > +// XXX: This is :\, figure out a better way at some point?
> > +pub use bindings::{
> > + DRM_MODE_CONNECTOR_Unknown,
> > + DRM_MODE_CONNECTOR_VGA,
>
Re: linux-next: build warning after merge of the amdgpu tree
Hi all,
On Tue, 30 Jan 2024 13:56:26 +1100 Stephen Rothwell
wrote:
>
> After merging the amdgpu tree, today's linux-next build (htmldocs)
> produced this warning:
>
> drivers/gpu/drm/amd/display/dc/link/hwss/link_hwss_dio.h:1: warning: no
> structured comments found
> drivers/gpu/drm/amd/display/dc/link/hwss/link_hwss_dio.h:1: warning: no
> structured comments found
>
> Introduced by commit
>
> d79833f34bdc ("Documentation/gpu: Add entry for the DIO component")
I am still seeing these warnings (as of last Friday) but the above
commit is now in Linus' tree.
--
Cheers,
Stephen Rothwell
pgpjzLd5zh2oL.pgp
Description: OpenPGP digital signature
Re: linux-next: build warning after merge of the amdgpu tree
Hi all,
On Tue, 30 Jan 2024 13:54:21 +1100 Stephen Rothwell
wrote:
>
> Hi all,
>
> After merging the amdgpu tree, today's linux-next build (htmldocs)
> produced this warning:
>
> drivers/gpu/drm/amd/display/dc/inc/hw/opp.h:1: warning: no structured
> comments found
> drivers/gpu/drm/amd/display/dc/inc/hw/opp.h:1: warning: no structured
> comments found
>
> Introduced by commit
>
> 0fba33311e63 ("Documentation/gpu: Add entry for OPP in the kernel doc")
I am still seeing these warnings (as of last Friday) but the above
commit is now in Linus' tree.
--
Cheers,
Stephen Rothwell
pgpoZAFiQ5XSz.pgp
Description: OpenPGP digital signature
Re: linux-next: build warnings after merge of the amdgpu tree
Hi all, On Tue, 30 Jan 2024 13:49:54 +1100 Stephen Rothwell wrote: > > After merging the amdgpu tree, today's linux-next build (htmldocs) > produced these warnings: > > drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:132: warning: Incorrect use of > kernel-doc format: * @@overlap_only: Whether overlapping of > different planes is allowed. > drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:132: warning: Incorrect use of > kernel-doc format: * @@overlap_only: Whether overlapping of > different planes is allowed. > drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:1: warning: no structured > comments found > drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:132: warning: Incorrect use of > kernel-doc format: * @@overlap_only: Whether overlapping of > different planes is allowed. > drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:162: warning: Function parameter > or struct member 'pre_multiplied_alpha' not described in 'mpcc_blnd_cfg' > drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:162: warning: Function parameter > or struct member 'overlap_only' not described in 'mpcc_blnd_cfg' > drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter > or struct member 'read_mpcc_state' not described in 'mpc_funcs' > drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter > or struct member 'mpc_init_single_inst' not described in 'mpc_funcs' > drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter > or struct member 'get_mpcc_for_dpp_from_secondary' not described in > 'mpc_funcs' > drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter > or struct member 'get_mpcc_for_dpp' not described in 'mpc_funcs' > drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter > or struct member 'wait_for_idle' not described in 'mpc_funcs' > drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter > or struct member 'assert_mpcc_idle_before_connect' not described in > 'mpc_funcs' > drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter > or struct member 'init_mpcc_list_from_hw' not described in 'mpc_funcs' > drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter > or struct member 'set_denorm' not described in 'mpc_funcs' > drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter > or struct member 'set_denorm_clamp' not described in 'mpc_funcs' > drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter > or struct member 'set_output_csc' not described in 'mpc_funcs' > drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter > or struct member 'set_ocsc_default' not described in 'mpc_funcs' > drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter > or struct member 'set_output_gamma' not described in 'mpc_funcs' > drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter > or struct member 'power_on_mpc_mem_pwr' not described in 'mpc_funcs' > drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter > or struct member 'set_dwb_mux' not described in 'mpc_funcs' > drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter > or struct member 'disable_dwb_mux' not described in 'mpc_funcs' > drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter > or struct member 'is_dwb_idle' not described in 'mpc_funcs' > drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter > or struct member 'set_out_rate_control' not described in 'mpc_funcs' > drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter > or struct member 'set_gamut_remap' not described in 'mpc_funcs' > drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter > or struct member 'program_1dlut' not described in 'mpc_funcs' > drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter > or struct member 'program_shaper' not described in 'mpc_funcs' > drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter > or struct member 'acquire_rmu' not described in 'mpc_funcs' > drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter > or struct member 'program_3dlut' not described in 'mpc_funcs' > drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter > or struct member 'release_rmu' not described in 'mpc_funcs' > drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter > or struct member 'get_mpc_out_mux' not described in 'mpc_funcs' > drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter > or struct member 'set_bg_color' not described in 'mpc_funcs' > drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:548: warning: Function parameter > or struct member 'set_mpc_mem_lp_mode' not described in 'mpc_funcs' > drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:132: warning: I
Re: [PATCH 1/3] drm/msm: don't clean up priv->kms prematurely
On Sat, Apr 20, 2024 at 04:02:00PM -0700, Abhinav Kumar wrote:
>
>
> On 4/19/2024 7:33 PM, Dmitry Baryshkov wrote:
> > MSM display drivers provide kms structure allocated during probe().
> > Don't clean up priv->kms field in case of an error. Otherwise probe
> > functions might fail after KMS probe deferral.
> >
>
> So just to understand this more, this will happen when master component
> probe (dpu) succeeded but other sub-component probe (dsi) deferred?
>
> Because if master component probe itself deferred it will allocate priv->kms
> again isnt it and we will not even hit here.
Master probing succeeds (so priv->kms is set), then kms_init fails at
runtime, during binding of the master device. This results in probe
deferral from the last component's component_add() function and reprobe
attempt when possible (once the next device is added or probed). However
as priv->kms is NULL, probe crashes.
>
> > Fixes: a2ab5d5bb6b1 ("drm/msm: allow passing struct msm_kms to
> > msm_drv_probe()")
> > Signed-off-by: Dmitry Baryshkov
> > ---
> > drivers/gpu/drm/msm/msm_kms.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_kms.c b/drivers/gpu/drm/msm/msm_kms.c
> > index af6a6fcb1173..6749f0fbca96 100644
> > --- a/drivers/gpu/drm/msm/msm_kms.c
> > +++ b/drivers/gpu/drm/msm/msm_kms.c
> > @@ -244,7 +244,6 @@ int msm_drm_kms_init(struct device *dev, const struct
> > drm_driver *drv)
> > ret = priv->kms_init(ddev);
> > if (ret) {
> > DRM_DEV_ERROR(dev, "failed to load kms\n");
> > - priv->kms = NULL;
> > return ret;
> > }
> >
--
With best wishes
Dmitry
Re: (subset) [PATCH v2 0/3] DisplayPort support for SM6350/SM7225
On Fri, 29 Mar 2024 08:45:53 +0100, Luca Weiss wrote: > Add the required changes to support DisplayPort (normally(?) available > via the USB-C connector) on the SM6350/SM7225 SoC. > > This has been tested on a Fairphone 4 smartphone with additional changes > not included in this series (mostly just wiring up TCPM and the SBU > mux). > > [...] Applied, thanks! [3/3] arm64: dts: qcom: sm6350: Add DisplayPort controller commit: 62f87a3cac4e70fa916914a359d3f045a5ad8b9b Best regards, -- Bjorn Andersson
linux-next: warning while fetching the drm tree
Hi all,
Fetching the drm tree produced this warning:
Commit
326e30e4624c ("drm/i915: Drop dead code for pvc")
added this unexpected file:
drivers/gpu/drm/i915/gt/intel_workarounds.c.rej
--
Cheers,
Stephen Rothwell
pgpp13acamnrT.pgp
Description: OpenPGP digital signature
[PATCH v3 8/8] drm/v3d: Add modparam for turning off Big/Super Pages
Add a modparam for turning off Big/Super Pages to make sure that if an
user doesn't want Big/Super Pages enabled, it can disabled it by setting
the modparam to false.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_drv.c | 8
drivers/gpu/drm/v3d/v3d_gemfs.c | 5 +
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c
index 3debf37e7d9b..bc8c8905112a 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.c
+++ b/drivers/gpu/drm/v3d/v3d_drv.c
@@ -36,6 +36,14 @@
#define DRIVER_MINOR 0
#define DRIVER_PATCHLEVEL 0
+bool super_pages = true;
+
+/* Only expose the `super_pages` modparam if THP is enabled. */
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+module_param_named(super_pages, super_pages, bool, 0400);
+MODULE_PARM_DESC(super_pages, "Enable/Disable Super Pages support.");
+#endif
+
static int v3d_get_param_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv)
{
diff --git a/drivers/gpu/drm/v3d/v3d_gemfs.c b/drivers/gpu/drm/v3d/v3d_gemfs.c
index 31cf5bd11e39..5fa08263cff2 100644
--- a/drivers/gpu/drm/v3d/v3d_gemfs.c
+++ b/drivers/gpu/drm/v3d/v3d_gemfs.c
@@ -11,6 +11,11 @@ void v3d_gemfs_init(struct v3d_dev *v3d)
char huge_opt[] = "huge=within_size";
struct file_system_type *type;
struct vfsmount *gemfs;
+ extern bool super_pages;
+
+ /* The user doesn't want to enable Super Pages */
+ if (!super_pages)
+ goto err;
/*
* By creating our own shmemfs mountpoint, we can pass in
--
2.44.0
[PATCH v3 7/8] drm/v3d: Use gemfs/THP in BO creation if available
Although Big/Super Pages could appear naturally, it would be quite hard
to have 1MB or 64KB allocated contiguously naturally. Therefore, we can
force the creation of large pages allocated contiguously by using a
mountpoint with "huge=within_size" enabled.
As V3D has a mountpoint with "huge=within_size" (if user has THP enabled),
use this mountpoint for BO creation if available. This will allow us to create
large pages allocated contiguously and make use of Big/Super Pages.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_bo.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_bo.c b/drivers/gpu/drm/v3d/v3d_bo.c
index 79e31c5299b1..16ac26c31c6b 100644
--- a/drivers/gpu/drm/v3d/v3d_bo.c
+++ b/drivers/gpu/drm/v3d/v3d_bo.c
@@ -94,6 +94,7 @@ v3d_bo_create_finish(struct drm_gem_object *obj)
struct v3d_dev *v3d = to_v3d_dev(obj->dev);
struct v3d_bo *bo = to_v3d_bo(obj);
struct sg_table *sgt;
+ u64 align;
int ret;
/* So far we pin the BO in the MMU for its lifetime, so use
@@ -103,6 +104,15 @@ v3d_bo_create_finish(struct drm_gem_object *obj)
if (IS_ERR(sgt))
return PTR_ERR(sgt);
+ if (!v3d->gemfs)
+ align = SZ_4K;
+ else if (obj->size >= SZ_1M)
+ align = SZ_1M;
+ else if (obj->size >= SZ_64K)
+ align = SZ_64K;
+ else
+ align = SZ_4K;
+
spin_lock(&v3d->mm_lock);
/* Allocate the object's space in the GPU's page tables.
* Inserting PTEs will happen later, but the offset is for the
@@ -110,7 +120,7 @@ v3d_bo_create_finish(struct drm_gem_object *obj)
*/
ret = drm_mm_insert_node_generic(&v3d->mm, &bo->node,
obj->size >> V3D_MMU_PAGE_SHIFT,
-SZ_4K >> V3D_MMU_PAGE_SHIFT, 0, 0);
+align >> V3D_MMU_PAGE_SHIFT, 0, 0);
spin_unlock(&v3d->mm_lock);
if (ret)
return ret;
@@ -130,10 +140,17 @@ struct v3d_bo *v3d_bo_create(struct drm_device *dev,
struct drm_file *file_priv,
size_t unaligned_size)
{
struct drm_gem_shmem_object *shmem_obj;
+ struct v3d_dev *v3d = to_v3d_dev(dev);
struct v3d_bo *bo;
int ret;
- shmem_obj = drm_gem_shmem_create(dev, unaligned_size);
+ /* Let the user opt out of allocating the BOs with THP */
+ if (v3d->gemfs)
+ shmem_obj = drm_gem_shmem_create_with_mnt(dev, unaligned_size,
+ v3d->gemfs);
+ else
+ shmem_obj = drm_gem_shmem_create(dev, unaligned_size);
+
if (IS_ERR(shmem_obj))
return ERR_CAST(shmem_obj);
bo = to_v3d_bo(&shmem_obj->base);
--
2.44.0
[PATCH v3 6/8] drm/v3d: Support Big/Super Pages when writing out PTEs
The V3D MMU also supports 64KB and 1MB pages, called big and super pages,
respectively. In order to set a 64KB page or 1MB page in the MMU, we need
to make sure that page table entries for all 4KB pages within a big/super
page must be correctly configured.
In order to create a big/super page, we need a contiguous memory region.
That's why we use a separate mountpoint with THP enabled. In order to
place the page table entries in the MMU, we iterate over the 16 4KB pages
(for big pages) or 256 4KB pages (for super pages) and insert the PTE.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_drv.h | 1 +
drivers/gpu/drm/v3d/v3d_mmu.c | 52 ++-
2 files changed, 40 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index 17236ee23490..79d8a1a059aa 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -18,6 +18,7 @@ struct platform_device;
struct reset_control;
#define V3D_MMU_PAGE_SHIFT 12
+#define V3D_PAGE_FACTOR (PAGE_SIZE >> V3D_MMU_PAGE_SHIFT)
#define V3D_MAX_QUEUES (V3D_CPU + 1)
diff --git a/drivers/gpu/drm/v3d/v3d_mmu.c b/drivers/gpu/drm/v3d/v3d_mmu.c
index 14f3af40d6f6..2e0b31e373b2 100644
--- a/drivers/gpu/drm/v3d/v3d_mmu.c
+++ b/drivers/gpu/drm/v3d/v3d_mmu.c
@@ -25,9 +25,16 @@
* superpage bit set.
*/
#define V3D_PTE_SUPERPAGE BIT(31)
+#define V3D_PTE_BIGPAGE BIT(30)
#define V3D_PTE_WRITEABLE BIT(29)
#define V3D_PTE_VALID BIT(28)
+static bool v3d_mmu_is_aligned(u32 page, u32 page_address, size_t alignment)
+{
+ return IS_ALIGNED(page, alignment >> V3D_MMU_PAGE_SHIFT) &&
+ IS_ALIGNED(page_address, alignment >> V3D_MMU_PAGE_SHIFT);
+}
+
static int v3d_mmu_flush_all(struct v3d_dev *v3d)
{
int ret;
@@ -87,19 +94,38 @@ void v3d_mmu_insert_ptes(struct v3d_bo *bo)
struct drm_gem_shmem_object *shmem_obj = &bo->base;
struct v3d_dev *v3d = to_v3d_dev(shmem_obj->base.dev);
u32 page = bo->node.start;
- u32 page_prot = V3D_PTE_WRITEABLE | V3D_PTE_VALID;
- struct sg_dma_page_iter dma_iter;
-
- for_each_sgtable_dma_page(shmem_obj->sgt, &dma_iter, 0) {
- dma_addr_t dma_addr = sg_page_iter_dma_address(&dma_iter);
- u32 page_address = dma_addr >> V3D_MMU_PAGE_SHIFT;
- u32 pte = page_prot | page_address;
- u32 i;
-
- BUG_ON(page_address + (PAGE_SIZE >> V3D_MMU_PAGE_SHIFT) >=
- BIT(24));
- for (i = 0; i < PAGE_SIZE >> V3D_MMU_PAGE_SHIFT; i++)
- v3d->pt[page++] = pte + i;
+ struct scatterlist *sgl;
+ unsigned int count;
+
+ for_each_sgtable_dma_sg(shmem_obj->sgt, sgl, count) {
+ dma_addr_t dma_addr = sg_dma_address(sgl);
+ u32 pfn = dma_addr >> V3D_MMU_PAGE_SHIFT;
+ unsigned int len = sg_dma_len(sgl);
+
+ while (len > 0) {
+ u32 page_prot = V3D_PTE_WRITEABLE | V3D_PTE_VALID;
+ u32 page_address = page_prot | pfn;
+ unsigned int i, page_size;
+
+ BUG_ON(pfn + V3D_PAGE_FACTOR >= BIT(24));
+
+ if (len >= SZ_1M && v3d_mmu_is_aligned(page,
page_address, SZ_1M)) {
+ page_size = SZ_1M;
+ page_address |= V3D_PTE_SUPERPAGE;
+ } else if (len >= SZ_64K && v3d_mmu_is_aligned(page,
page_address, SZ_64K)) {
+ page_size = SZ_64K;
+ page_address |= V3D_PTE_BIGPAGE;
+ } else {
+ page_size = SZ_4K;
+ }
+
+ for (i = 0; i < page_size >> V3D_MMU_PAGE_SHIFT; i++) {
+ v3d->pt[page++] = page_address + i;
+ pfn++;
+ }
+
+ len -= page_size;
+ }
}
WARN_ON_ONCE(page - bo->node.start !=
--
2.44.0
[PATCH v3 4/8] drm/gem: Create shmem GEM object in a given mountpoint
Create a function `drm_gem_shmem_create_with_mnt()`, similar to
`drm_gem_shmem_create()`, that has a mountpoint as a argument. This
function will create a shmem GEM object in a given tmpfs mountpoint.
This function will be useful for drivers that have a special mountpoint
with flags enabled.
Signed-off-by: Maíra Canal
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 30 ++
include/drm/drm_gem_shmem_helper.h | 3 +++
2 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 13bcdbfd..10b7c4c769a3 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -49,7 +49,8 @@ static const struct drm_gem_object_funcs drm_gem_shmem_funcs
= {
};
static struct drm_gem_shmem_object *
-__drm_gem_shmem_create(struct drm_device *dev, size_t size, bool private)
+__drm_gem_shmem_create(struct drm_device *dev, size_t size, bool private,
+ struct vfsmount *gemfs)
{
struct drm_gem_shmem_object *shmem;
struct drm_gem_object *obj;
@@ -76,7 +77,7 @@ __drm_gem_shmem_create(struct drm_device *dev, size_t size,
bool private)
drm_gem_private_object_init(dev, obj, size);
shmem->map_wc = false; /* dma-buf mappings use always
writecombine */
} else {
- ret = drm_gem_object_init(dev, obj, size);
+ ret = drm_gem_object_init_with_mnt(dev, obj, size, gemfs);
}
if (ret) {
drm_gem_private_object_fini(obj);
@@ -123,10 +124,31 @@ __drm_gem_shmem_create(struct drm_device *dev, size_t
size, bool private)
*/
struct drm_gem_shmem_object *drm_gem_shmem_create(struct drm_device *dev,
size_t size)
{
- return __drm_gem_shmem_create(dev, size, false);
+ return __drm_gem_shmem_create(dev, size, false, NULL);
}
EXPORT_SYMBOL_GPL(drm_gem_shmem_create);
+/**
+ * drm_gem_shmem_create_with_mnt - Allocate an object with the given size in a
+ * given mountpoint
+ * @dev: DRM device
+ * @size: Size of the object to allocate
+ * @gemfs: tmpfs mount where the GEM object will be created
+ *
+ * This function creates a shmem GEM object in a given tmpfs mountpoint.
+ *
+ * Returns:
+ * A struct drm_gem_shmem_object * on success or an ERR_PTR()-encoded negative
+ * error code on failure.
+ */
+struct drm_gem_shmem_object *drm_gem_shmem_create_with_mnt(struct drm_device
*dev,
+ size_t size,
+ struct vfsmount
*gemfs)
+{
+ return __drm_gem_shmem_create(dev, size, false, gemfs);
+}
+EXPORT_SYMBOL_GPL(drm_gem_shmem_create_with_mnt);
+
/**
* drm_gem_shmem_free - Free resources associated with a shmem GEM object
* @shmem: shmem GEM object to free
@@ -760,7 +782,7 @@ drm_gem_shmem_prime_import_sg_table(struct drm_device *dev,
size_t size = PAGE_ALIGN(attach->dmabuf->size);
struct drm_gem_shmem_object *shmem;
- shmem = __drm_gem_shmem_create(dev, size, true);
+ shmem = __drm_gem_shmem_create(dev, size, true, NULL);
if (IS_ERR(shmem))
return ERR_CAST(shmem);
diff --git a/include/drm/drm_gem_shmem_helper.h
b/include/drm/drm_gem_shmem_helper.h
index efbc9f27312b..d22e3fb53631 100644
--- a/include/drm/drm_gem_shmem_helper.h
+++ b/include/drm/drm_gem_shmem_helper.h
@@ -97,6 +97,9 @@ struct drm_gem_shmem_object {
container_of(obj, struct drm_gem_shmem_object, base)
struct drm_gem_shmem_object *drm_gem_shmem_create(struct drm_device *dev,
size_t size);
+struct drm_gem_shmem_object *drm_gem_shmem_create_with_mnt(struct drm_device
*dev,
+ size_t size,
+ struct vfsmount
*gemfs);
void drm_gem_shmem_free(struct drm_gem_shmem_object *shmem);
void drm_gem_shmem_put_pages(struct drm_gem_shmem_object *shmem);
--
2.44.0
[PATCH v3 5/8] drm/v3d: Reduce the alignment of the node allocation
Currently, we are using an alignment of 128 kB to insert a node, which ends up wasting memory as we perform plenty of small BOs allocations (<= 4 kB). We require that allocations are aligned to 128Kb so for any allocation smaller than that, we are wasting the difference. This implies that we cannot effectively use the whole 4 GB address space available for the GPU in the RPi 4. Currently, we can allocate up to 32000 BOs of 4 kB (~140 MB) and 3000 BOs of 400 kB (~1,3 GB). This can be quite limiting for applications that have a high memory requirement, such as vkoverhead [1]. By reducing the page alignment to 4 kB, we can allocate up to 100 BOs of 4 kB (~4 GB) and 1 BOs of 400 kB (~4 GB). Moreover, by performing benchmarks, we were able to attest that reducing the page alignment to 4 kB can provide a general performance improvement in OpenGL applications (e.g. glmark2). Therefore, this patch reduces the alignment of the node allocation to 4 kB, which will allow RPi users to explore the whole 4GB virtual address space provided by the hardware. Also, this patch allow users to fully run vkoverhead in the RPi 4/5, solving the issue reported in [1]. [1] https://github.com/zmike/vkoverhead/issues/14 Signed-off-by: Maíra Canal --- drivers/gpu/drm/v3d/v3d_bo.c | 2 +- drivers/gpu/drm/v3d/v3d_drv.h | 2 -- 2 files changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/v3d/v3d_bo.c b/drivers/gpu/drm/v3d/v3d_bo.c index a07ede668cc1..79e31c5299b1 100644 --- a/drivers/gpu/drm/v3d/v3d_bo.c +++ b/drivers/gpu/drm/v3d/v3d_bo.c @@ -110,7 +110,7 @@ v3d_bo_create_finish(struct drm_gem_object *obj) */ ret = drm_mm_insert_node_generic(&v3d->mm, &bo->node, obj->size >> V3D_MMU_PAGE_SHIFT, -GMP_GRANULARITY >> V3D_MMU_PAGE_SHIFT, 0, 0); +SZ_4K >> V3D_MMU_PAGE_SHIFT, 0, 0); spin_unlock(&v3d->mm_lock); if (ret) return ret; diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h index d2ce8222771a..17236ee23490 100644 --- a/drivers/gpu/drm/v3d/v3d_drv.h +++ b/drivers/gpu/drm/v3d/v3d_drv.h @@ -17,8 +17,6 @@ struct clk; struct platform_device; struct reset_control; -#define GMP_GRANULARITY (128 * 1024) - #define V3D_MMU_PAGE_SHIFT 12 #define V3D_MAX_QUEUES (V3D_CPU + 1) -- 2.44.0
[PATCH v3 0/8] drm/v3d: Enable Big and Super Pages
This series introduces support for big and super pages in V3D. The V3D MMU has support for 64KB and 1MB pages, called big pages and super pages, which are currently not used. Therefore, this patchset has the intention to enable big and super pages in V3D. The advantage of enabling big and super pages is that if any entry for a page within a big/super page is cached in the MMU, it will be used for the translation of all virtual addresses in the range of that super page without requiring fetching any other entries. Big/Super pages essentially mean a slightly better performance for users, especially in applications with high memory requirements (e.g. applications that use multiple large BOs). Using a Raspberry Pi 4 (with a PAGE_SIZE=4KB downstream kernel), when running traces from multiple applications, we were able to see the following improvements: fps_avg helped: warzone2100.70secs.1024x768.trace:1.98 -> 2.42 (22.19%) fps_avg helped: warzone2100.30secs.1024x768.trace:2 -> 2.45(21.96%) fps_avg helped: supertuxkart-menus_1024x768.trace:123.12 -> 128.39 (4.28%) fps_avg helped: vkQuake_capture_frames_1_through_1200_1280x720.gfxr: 61.26 -> 62.89 (2.67%) fps_avg helped: quake2-gles3-1280x720.trace: 63.42 -> 64.86 (2.27%) fps_avg helped: ue4_sun_temple_640x480.gfxr: 25.15 -> 25.63 (1.89%) fps_avg helped: ue4_shooter_game_high_quality_640x480.gfxr: 19.28 -> 19.61 (1.72%) fps_avg helped: ue4_shooter_game_shooting_high_quality_640x480.gfxr: 23.58 -> 23.91 (1.39%) fps_avg helped: quake3e_capture_frames_1_through_1800_1920x1080.gfxr: 61.40 -> 62.00 (0.96%) fps_avg helped: serious_sam_trace02_1280x720.gfxr:49.41 -> 49.84 (0.86%) fps_avg helped: supertuxkart-racing_1024x768.trace: 8.69 -> 8.74 (0.56%) fps_avg helped: sponza_demo01_800x600.gfxr: 17.55 -> 17.64 (0.50%) fps_avg helped: quake2-gl1.4-1280x720.trace: 36.43 -> 36.58 (0.43%) fps_avg helped: quake3e-1280x720.trace: 94.49 -> 94.87 (0.40%) fps_avg helped: sponza_demo02_800x600.gfxr: 19.79 -> 19.87 (0.39%) Using a Raspberry Pi 5 (with a PAGE_SIZE=16KB downstream kernel), when running traces from multiple applications, we were able to see the following improvements: fps_avg helped: warzone2100.30secs.1024x768.trace: 4.40 -> 4.95 (12.58%) fps_avg helped: vkQuake_capture_frames_1_through_1200_1280x720.gfxr: 135.05 -> 141.21 (4.56%) fps_avg helped: supertuxkart-menus_1024x768.trace: 291.73 -> 302.05 (3.54%) fps_avg helped: quake2-gles3-1280x720.trace: 148.90 -> 153.57 (3.13%) fps_avg helped: quake2-gl1.4-1280x720.trace: 82.60 -> 84.46 (2.25%) fps_avg helped: ue4_shooter_game_shooting_low_quality_640x480.gfxr: 49.59 -> 50.54 (1.92%) fps_avg helped: ue4_shooter_game_shooting_high_quality_640x480.gfxr: 51.03 -> 51.93 (1.76%) fps_avg helped: ue4_shooter_game_high_quality_640x480.gfxr: 31.15 -> 31.64 (1.60%) fps_avg helped: ue4_sun_temple_640x480.gfxr: 40.26 -> 40.88 (1.54%) fps_avg helped: sponza_demo01_800x600.gfxr: 43.23 -> 43.84 (1.40%) fps_avg helped: warzone2100.70secs.1024x768.trace: 4.36 -> 4.42 (1.39%) fps_avg helped: sponza_demo02_800x600.gfxr: 48.94 -> 49.51 (1.17%) fps_avg helped: quake3e_capture_frames_1_through_1800_1920x1080.gfxr: 162.11 -> 163.13 (0.63%) fps_avg helped: quake3e-1280x720.trace: 229.82 -> 231.00 (0.51%) fps_avg helped: supertuxkart-racing_1024x768.trace: 20.42 -> 20.48 (0.30%) fps_avg helped: quake3e_capture_frames_1800_through_2400_1920x1080.gfxr: 157.45 -> 157.61 (0.10%) fps_avg helped: serious_sam_trace02_1280x720.gfxr: 59.99 -> 60.02 (0.05%) This series also introduces changes in the GEM helpers, in order to enable V3D to have a separate mount point for shmfs GEM objects. Any feedback from the community about the changes in the GEM helpers is welcomed! v1 -> v2: https://lore.kernel.org/dri-devel/20240311100959.205545-1-mca...@igalia.com/ * [1/6] Add Iago's R-b to PATCH 1/5 (Iago Toral) * [2/6] Create a new function `drm_gem_object_init_with_mnt()` to define the shmfs mountpoint. Now, we don't touch a bunch of drivers, as `drm_gem_object_init()` preserves its signature. (Tvrtko Ursulin) * [3/6] Use `huge=within_size` instead of `huge=always`, in order to avoid OOM. This also allow us to move away from the 2MB hack. (Tvrtko Ursulin) * [3/6] Add Iago's R-b to
[PATCH v3 2/8] drm/gem: Create a drm_gem_object_init_with_mnt() function
For some applications, such as applications that uses huge pages, we might
want to have a different mountpoint, for which we pass mount flags that
better match our usecase.
Therefore, create a new function `drm_gem_object_init_with_mnt()` that
allow us to define the tmpfs mountpoint where the GEM object will be
created. If this parameter is NULL, then we fallback to `shmem_file_setup()`.
Signed-off-by: Maíra Canal
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/drm_gem.c | 34 ++
include/drm/drm_gem.h | 3 +++
2 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index d4bbc5d109c8..74ebe68e3d61 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -114,22 +114,32 @@ drm_gem_init(struct drm_device *dev)
}
/**
- * drm_gem_object_init - initialize an allocated shmem-backed GEM object
+ * drm_gem_object_init_with_mnt - initialize an allocated shmem-backed GEM
+ * object in a given shmfs mountpoint
+ *
* @dev: drm_device the object should be initialized for
* @obj: drm_gem_object to initialize
* @size: object size
+ * @gemfs: tmpfs mount where the GEM object will be created. If NULL, use
+ * the usual tmpfs mountpoint (`shm_mnt`).
*
* Initialize an already allocated GEM object of the specified size with
* shmfs backing store.
*/
-int drm_gem_object_init(struct drm_device *dev,
- struct drm_gem_object *obj, size_t size)
+int drm_gem_object_init_with_mnt(struct drm_device *dev,
+struct drm_gem_object *obj, size_t size,
+struct vfsmount *gemfs)
{
struct file *filp;
drm_gem_private_object_init(dev, obj, size);
- filp = shmem_file_setup("drm mm object", size, VM_NORESERVE);
+ if (gemfs)
+ filp = shmem_file_setup_with_mnt(gemfs, "drm mm object", size,
+VM_NORESERVE);
+ else
+ filp = shmem_file_setup("drm mm object", size, VM_NORESERVE);
+
if (IS_ERR(filp))
return PTR_ERR(filp);
@@ -137,6 +147,22 @@ int drm_gem_object_init(struct drm_device *dev,
return 0;
}
+EXPORT_SYMBOL(drm_gem_object_init_with_mnt);
+
+/**
+ * drm_gem_object_init - initialize an allocated shmem-backed GEM object
+ * @dev: drm_device the object should be initialized for
+ * @obj: drm_gem_object to initialize
+ * @size: object size
+ *
+ * Initialize an already allocated GEM object of the specified size with
+ * shmfs backing store.
+ */
+int drm_gem_object_init(struct drm_device *dev, struct drm_gem_object *obj,
+ size_t size)
+{
+ return drm_gem_object_init_with_mnt(dev, obj, size, NULL);
+}
EXPORT_SYMBOL(drm_gem_object_init);
/**
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index bae4865b2101..2ebf6e10cc44 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -472,6 +472,9 @@ void drm_gem_object_release(struct drm_gem_object *obj);
void drm_gem_object_free(struct kref *kref);
int drm_gem_object_init(struct drm_device *dev,
struct drm_gem_object *obj, size_t size);
+int drm_gem_object_init_with_mnt(struct drm_device *dev,
+struct drm_gem_object *obj, size_t size,
+struct vfsmount *gemfs);
void drm_gem_private_object_init(struct drm_device *dev,
struct drm_gem_object *obj, size_t size);
void drm_gem_private_object_fini(struct drm_gem_object *obj);
--
2.44.0
[PATCH v3 3/8] drm/v3d: Introduce gemfs
Create a separate "tmpfs" kernel mount for V3D. This will allow us to
move away from the shmemfs `shm_mnt` and gives the flexibility to do
things like set our own mount options. Here, the interest is to use
"huge=", which should allow us to enable the use of THP for our
shmem-backed objects.
Signed-off-by: Maíra Canal
Reviewed-by: Iago Toral Quiroga
---
drivers/gpu/drm/v3d/Makefile| 3 ++-
drivers/gpu/drm/v3d/v3d_drv.h | 9 +++
drivers/gpu/drm/v3d/v3d_gem.c | 3 +++
drivers/gpu/drm/v3d/v3d_gemfs.c | 46 +
4 files changed, 60 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/v3d/v3d_gemfs.c
diff --git a/drivers/gpu/drm/v3d/Makefile b/drivers/gpu/drm/v3d/Makefile
index b7d673f1153b..fcf710926057 100644
--- a/drivers/gpu/drm/v3d/Makefile
+++ b/drivers/gpu/drm/v3d/Makefile
@@ -13,7 +13,8 @@ v3d-y := \
v3d_trace_points.o \
v3d_sched.o \
v3d_sysfs.o \
- v3d_submit.o
+ v3d_submit.o \
+ v3d_gemfs.o
v3d-$(CONFIG_DEBUG_FS) += v3d_debugfs.o
diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index 1950c723dde1..d2ce8222771a 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -119,6 +119,11 @@ struct v3d_dev {
struct drm_mm mm;
spinlock_t mm_lock;
+ /*
+* tmpfs instance used for shmem backed objects
+*/
+ struct vfsmount *gemfs;
+
struct work_struct overflow_mem_work;
struct v3d_bin_job *bin_job;
@@ -519,6 +524,10 @@ void v3d_reset(struct v3d_dev *v3d);
void v3d_invalidate_caches(struct v3d_dev *v3d);
void v3d_clean_caches(struct v3d_dev *v3d);
+/* v3d_gemfs.c */
+void v3d_gemfs_init(struct v3d_dev *v3d);
+void v3d_gemfs_fini(struct v3d_dev *v3d);
+
/* v3d_submit.c */
void v3d_job_cleanup(struct v3d_job *job);
void v3d_job_put(struct v3d_job *job);
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index 66f4b78a6b2e..faefbe497e8d 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -287,6 +287,8 @@ v3d_gem_init(struct drm_device *dev)
v3d_init_hw_state(v3d);
v3d_mmu_set_page_table(v3d);
+ v3d_gemfs_init(v3d);
+
ret = v3d_sched_init(v3d);
if (ret) {
drm_mm_takedown(&v3d->mm);
@@ -304,6 +306,7 @@ v3d_gem_destroy(struct drm_device *dev)
struct v3d_dev *v3d = to_v3d_dev(dev);
v3d_sched_fini(v3d);
+ v3d_gemfs_fini(v3d);
/* Waiting for jobs to finish would need to be done before
* unregistering V3D.
diff --git a/drivers/gpu/drm/v3d/v3d_gemfs.c b/drivers/gpu/drm/v3d/v3d_gemfs.c
new file mode 100644
index ..31cf5bd11e39
--- /dev/null
+++ b/drivers/gpu/drm/v3d/v3d_gemfs.c
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Copyright (C) 2024 Raspberry Pi */
+
+#include
+#include
+
+#include "v3d_drv.h"
+
+void v3d_gemfs_init(struct v3d_dev *v3d)
+{
+ char huge_opt[] = "huge=within_size";
+ struct file_system_type *type;
+ struct vfsmount *gemfs;
+
+ /*
+* By creating our own shmemfs mountpoint, we can pass in
+* mount flags that better match our usecase. However, we
+* only do so on platforms which benefit from it.
+*/
+ if (!IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE))
+ goto err;
+
+ type = get_fs_type("tmpfs");
+ if (!type)
+ goto err;
+
+ gemfs = vfs_kern_mount(type, SB_KERNMOUNT, type->name, huge_opt);
+ if (IS_ERR(gemfs))
+ goto err;
+
+ v3d->gemfs = gemfs;
+ drm_info(&v3d->drm, "Using Transparent Hugepages\n");
+
+ return;
+
+err:
+ v3d->gemfs = NULL;
+ drm_notice(&v3d->drm,
+ "Transparent Hugepage support is recommended for optimal
performance on this platform!\n");
+}
+
+void v3d_gemfs_fini(struct v3d_dev *v3d)
+{
+ if (v3d->gemfs)
+ kern_unmount(v3d->gemfs);
+}
--
2.44.0
[PATCH v3 1/8] drm/v3d: Fix return if scheduler initialization fails
If the scheduler initialization fails, GEM initialization must fail as
well. Therefore, if `v3d_sched_init()` fails, free the DMA memory
allocated and return the error value in `v3d_gem_init()`.
Signed-off-by: Maíra Canal
Reviewed-by: Iago Toral Quiroga
---
drivers/gpu/drm/v3d/v3d_gem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index afc565078c78..66f4b78a6b2e 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -290,8 +290,9 @@ v3d_gem_init(struct drm_device *dev)
ret = v3d_sched_init(v3d);
if (ret) {
drm_mm_takedown(&v3d->mm);
- dma_free_coherent(v3d->drm.dev, 4096 * 1024, (void *)v3d->pt,
+ dma_free_coherent(v3d->drm.dev, pt_size, (void *)v3d->pt,
v3d->pt_paddr);
+ return ret;
}
return 0;
--
2.44.0
Re: [PATCH v2 0/3] Move blender setup from individual planes to crtc commit in sun4i-drm
Dne petek, 19. april 2024 ob 15:36:17 GMT +2 je Ondřej Jirman napisal(a): > Hi, > > On Sat, Feb 24, 2024 at 04:05:57PM GMT, megi xff wrote: > > From: Ondrej Jirman > > > > This series refactors blender setup from individual planes to a common > > place where it can be performed at once and is easier to reason about. > > > > In the process this fixes a few bugs that allowed blender pipes to be > > disabled while corresponding DRM planes were requested to be enabled. > > > > Please take a look. :) > > > > v2: > > - use regmap_write where possible > > - add review tags > > It would be nice to have this applied. Maxime, do you mind applying? Best regards, Jernej > > Kind regards, > o. > > > Thank you very much, > > Ondřej Jirman > > > > Ondrej Jirman (3): > > drm/sun4i: Unify sun8i_*_layer structs > > drm/sun4i: Add more parameters to sunxi_engine commit callback > > drm/sun4i: Fix layer zpos change/atomic modesetting > > > > drivers/gpu/drm/sun4i/sun4i_backend.c | 4 +- > > drivers/gpu/drm/sun4i/sun4i_crtc.c | 2 +- > > drivers/gpu/drm/sun4i/sun8i_mixer.c| 70 - > > drivers/gpu/drm/sun4i/sun8i_mixer.h| 20 ++ > > drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 85 +++-- > > drivers/gpu/drm/sun4i/sun8i_ui_layer.h | 20 ++ > > drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 86 +++--- > > drivers/gpu/drm/sun4i/sun8i_vi_layer.h | 20 ++ > > drivers/gpu/drm/sun4i/sunxi_engine.h | 13 +++- > > 9 files changed, 125 insertions(+), 195 deletions(-) > > >
Re: [PATCH v8 2/4] drm/bridge: add lvds controller support for sam9x7
On Sun, Apr 21, 2024 at 06:40:48AM +0530, Dharma Balasubiramani wrote: > Add a new LVDS controller driver for sam9x7 which does the following: > - Prepares and enables the LVDS Peripheral clock > - Defines its connector type as DRM_MODE_CONNECTOR_LVDS and adds itself > to the global bridge list. > - Identifies its output endpoint as panel and adds it to the encoder > display pipeline > - Enables the LVDS serializer > > Signed-off-by: Manikandan Muralidharan > Signed-off-by: Dharma Balasubiramani > Acked-by: Hari Prasath Gujulan Elango > --- > Changelog > v7 -> v8 > - Assign ret variable properly before checking it for err. > v6 -> v7 > - Remove setting encoder type from bridge driver. > - Drop clk_disable() from pm_runtime_get_sync() error handling. > - Use devm_clk_get() instead of prepared version. > - Hence use clk_prepare_enable() and clk_disable_unprepare(). > - Use devm_drm_of_get_bridge() instead of devm_drm_panel_bridge_add(). > - Add error check for devm_pm_runtime_enable(). > - Use dev_err() instead of DRM_DEV_ERROR() as it is deprecated. > - Add missing Acked-by tag. > v5 -> v6 > - No Changes. > v4 -> v5 > - Drop the unused variable 'format'. > - Use DRM wrapper for dev_err() to maintain uniformity. > - return -ENODEV instead of -EINVAL to maintain consistency with other DRM > bridge drivers. > v3 -> v4 > - No changes. > v2 ->v3 > - Correct Typo error "serializer". > - Consolidate get() and prepare() functions and use devm_clk_get_prepared(). > - Remove unused variable 'ret' in probe(). > - Use devm_pm_runtime_enable() and drop the mchp_lvds_remove(). > v1 -> v2 > - Drop 'res' variable and combine two lines into one. > - Handle deferred probe properly, use dev_err_probe(). > - Don't print anything on deferred probe. Dropped print. > - Remove the MODULE_ALIAS and add MODULE_DEVICE_TABLE(). > - symbol 'mchp_lvds_driver' was not declared. It should be static. > --- > drivers/gpu/drm/bridge/Kconfig | 7 + > drivers/gpu/drm/bridge/Makefile | 1 + > drivers/gpu/drm/bridge/microchip-lvds.c | 229 > 3 files changed, 237 insertions(+) > create mode 100644 drivers/gpu/drm/bridge/microchip-lvds.c > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
[PATCH] drm/panfrost: Fix dma_resv deadlock at drm object pin time
When Panfrost must pin an object that is being prepared a dma-buf
attachment for on behalf of another driver, the core drm gem object pinning
code already takes a lock on the object's dma reservation.
However, Panfrost GEM object's pinning callback would eventually try taking
the lock on the same dma reservation when delegating pinning of the object
onto the shmem subsystem, which led to a deadlock.
This can be shown by enabling CONFIG_DEBUG_WW_MUTEX_SLOWPATH, which throws
the following recursive locking situation:
weston/3440 is trying to acquire lock:
00e235a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at:
drm_gem_shmem_pin+0x34/0xb8 [drm_shmem_helper]
but task is already holding lock:
00e235a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at:
drm_gem_pin+0x2c/0x80 [drm]
Fix it by assuming the object's reservation had already been locked by the
time we reach panfrost_gem_pin.
Cc: Thomas Zimmermann
Cc: Dmitry Osipenko
Cc: Boris Brezillon
Cc: Steven Price
Fixes: a78027847226 ("drm/gem: Acquire reservation lock in
drm_gem_{pin/unpin}()")
Signed-off-by: Adrián Larumbe
---
drivers/gpu/drm/panfrost/panfrost_gem.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c
b/drivers/gpu/drm/panfrost/panfrost_gem.c
index d47b40b82b0b..6c26652d425d 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gem.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
@@ -192,7 +192,12 @@ static int panfrost_gem_pin(struct drm_gem_object *obj)
if (bo->is_heap)
return -EINVAL;
- return drm_gem_shmem_pin(&bo->base);
+ /*
+* Pinning can only happen in response to a prime attachment request
from
+* another driver, but that's already being handled by drm_gem_pin
+*/
+ drm_WARN_ON(obj->dev, obj->import_attach);
+ return drm_gem_shmem_pin_locked(&bo->base);
}
static enum drm_gem_object_status panfrost_gem_status(struct drm_gem_object
*obj)
base-commit: 04687bff66b8a4b22748aa7215d3baef0b318e5b
--
2.44.0
Re: [RFC][PATCH] drm: bridge: dw-mipi-dsi: Call modeset in modeset callback
On Sun, Apr 21, 2024 at 04:25:34PM GMT, Marek Vasut wrote:
> On 4/21/24 1:09 PM, Ondřej Jirman wrote:
> > Hi,
>
> Hi,
>
> > On Sun, Apr 21, 2024 at 02:22:35AM GMT, Marek Vasut wrote:
> > > Doing modeset in .atomic_pre_enable callback instead of dedicated
> > > .mode_set
> > > callback does not seem right. Undo this change, which was added as part of
> >
> > Actually no. If anything, mode_set callback should be dropped entirely:
> >
> > See
> > https://elixir.bootlin.com/linux/latest/source/include/drm/drm_bridge.h#L231
> >
> > It's deprecated, and enable callback should just use adjusted_mode:
> >
> > This is deprecated, do not use! New drivers shall set their mode in the
> > &drm_bridge_funcs.atomic_enable operation.
>
> This mentions new drivers ?
Yes.
> > > commit 05aa61334592 ("drm: bridge: dw-mipi-dsi: Fix enable/disable of DSI
> > > controller") as it breaks STM32MP15xx LTDC scanout (DSI)->TC358762
> > > DSI-to-DPI
> > > bridge->PT800480 DPI panel pipeline. The original fix for HX8394 panel
> > > likely
> > > requires HX8394 panel side fix instead.
> >
> > There's nothing wrong with the panel driver. And that commit is not fixing
> > issue
> > with the panel driver, just like the subject hints at. Look at the
> > referenced
> > commit, at "Before:" sequence specifically.
> >
> > dw_mipi_dsi_mode_set may be named *_mode_set or whatever, but it's basically
> > an enable function that turns on clocks, initalizes phy, etc. etc.
> >
> > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c#L998
> >
> > And if you check "Before:" sequence, you'll see that .mode_set callback is
> > just
> > called once at boot and never again. And it's
> > atomic(_pre)_enable/atomic(_post)_disable
> > callbacks that actually are called in ballanced way to enable/disable the
> > controller repeatedly ever after.
> >
> > Function dw_mipi_dsi_bridge_post_atomic_disable is the inverse of
> > dw_mipi_dsi_mode_set, it undoes everything that dw_mipi_dsi_mode_set does.
> >
> > You need to find root cause for your issue on STM32MP15xx instead of
> > reverting
> > fixes for resource use bugs in this driver.
>
> Actually, reverting commit 05aa61334592 ("drm: bridge: dw-mipi-dsi: Fix
> enable/disable of DSI controller") makes the STM32MP15xx work again like it
> used to since Linux 5.10 or so, so that commit breaks existing working use
> case.
It may simply be revealing bug elsewhere in the STM display stack.
> It seems it is sufficient to revert only this part of the commit to make the
> STM32MP15xx work as it used to, do you have any idea why ?
No, I don't have any STM based board. This revert reintroduces the bug that
causes this driver resource use failures after a simple blanking/unblnaking
cycle done via sysfs when using Linux VT.
It's quite likely reproducible on your board, too. It's pretty clear from the
code
why that happens and it will happen regardless of what panel you're using.
You can't expect to call pm_runtime_get once and pm_runtime_put 5 times and have
this driver work at all. The same thing for clk_enable_*/disable_* and so on.
You'll need to fix the issue you're seeing differently without the revert.
kind regards,
o.
Re: [PATCH V2 1/2] drm/bridge: samsung-dsim: Set P divider based on min/max of fin pll
On 2/12/24 12:09 AM, Adam Ford wrote:
The P divider should be set based on the min and max values of
the fin pll which may vary between different platforms.
These ranges are defined per platform, but hard-coded values
were used instead which resulted in a smaller range available
on the i.MX8M[MNP] than what was possible.
As noted by Frieder, there are descripencies between the reference
manuals of the Mini, Nano and Plus, so I reached out to my NXP
rep and got the following response regarding the varing notes
in the documentation.
"Yes it is definitely wrong, the one that is part of the NOTE in
MIPI_DPHY_M_PLLPMS register table against PMS_P, PMS_M and PMS_S is
not correct. I will report this to Doc team, the one customer should
be take into account is the Table 13-40 DPHY PLL Parameters and the
Note above."
With this patch, the clock rates now match the values used in NXP's
downstream kernel.
Fixes: 846307185f0f ("drm/bridge: samsung-dsim: update PLL reference clock")
Signed-off-by: Adam Ford
Reviewed-by: Frieder Schrempf
Tested-by: Frieder Schrempf
---
V2: Only update the commit message to reflect why these values
were chosen. No code change present
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
b/drivers/gpu/drm/bridge/samsung-dsim.c
index 95fedc68b0ae..8476650c477c 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -574,8 +574,8 @@ static unsigned long samsung_dsim_pll_find_pms(struct
samsung_dsim *dsi,
u16 _m, best_m;
u8 _s, best_s;
- p_min = DIV_ROUND_UP(fin, (12 * MHZ));
- p_max = fin / (6 * MHZ);
+ p_min = DIV_ROUND_UP(fin, (driver_data->pll_fin_max * MHZ));
The parenthesis around driver_data... are not needed.
With that fixed:
Reviewed-by: Marek Vasut
Re: [PATCH V2 2/2] drm/bridge: samsung-dsim: Fix porch calcalcuation rounding
On 2/12/24 12:09 AM, Adam Ford wrote:
When using video sync pulses, the HFP, HBP, and HSA are divided between
the available lanes if there is more than one lane. For certain
timings and lane configurations, the HFP may not be evenly divisible.
If the HFP is rounded down, it ends up being too small which can cause
some monitors to not sync properly. In these instances, adjust htotal
and hsync to round the HFP up, and recalculate the htotal.
Tested-by: Frieder Schrempf # Kontron BL i.MX8MM
with HDMI monitor
Signed-off-by: Adam Ford
---
V2: No changes
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
b/drivers/gpu/drm/bridge/samsung-dsim.c
index 8476650c477c..52939211fe93 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1606,6 +1606,27 @@ static int samsung_dsim_atomic_check(struct drm_bridge
*bridge,
adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC |
DRM_MODE_FLAG_PVSYNC);
}
+ /*
+* When using video sync pulses, the HFP, HBP, and HSA are divided
between
+* the available lanes if there is more than one lane. For certain
+* timings and lane configurations, the HFP may not be evenly divisible.
+* If the HFP is rounded down, it ends up being too small which can
cause
+* some monitors to not sync properly. In these instances, adjust htotal
+* and hsync to round the HFP up, and recalculate the htotal. Through
trial
+* and error, it appears that the HBP and HSA do not appearto need the
same
+* correction that HFP does.
+*/
+ if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE && dsi->lanes > 1)
{
Does this also apply to mode with sync events (I suspect it does), so
the condition here should likely be if (!...burst mode) , right ?
Re: [RFC][PATCH] drm: bridge: dw-mipi-dsi: Call modeset in modeset callback
On 4/21/24 1:09 PM, Ondřej Jirman wrote:
Hi,
Hi,
On Sun, Apr 21, 2024 at 02:22:35AM GMT, Marek Vasut wrote:
Doing modeset in .atomic_pre_enable callback instead of dedicated .mode_set
callback does not seem right. Undo this change, which was added as part of
Actually no. If anything, mode_set callback should be dropped entirely:
See https://elixir.bootlin.com/linux/latest/source/include/drm/drm_bridge.h#L231
It's deprecated, and enable callback should just use adjusted_mode:
This is deprecated, do not use! New drivers shall set their mode in the
&drm_bridge_funcs.atomic_enable operation.
This mentions new drivers ?
commit 05aa61334592 ("drm: bridge: dw-mipi-dsi: Fix enable/disable of DSI
controller") as it breaks STM32MP15xx LTDC scanout (DSI)->TC358762 DSI-to-DPI
bridge->PT800480 DPI panel pipeline. The original fix for HX8394 panel likely
requires HX8394 panel side fix instead.
There's nothing wrong with the panel driver. And that commit is not fixing issue
with the panel driver, just like the subject hints at. Look at the referenced
commit, at "Before:" sequence specifically.
dw_mipi_dsi_mode_set may be named *_mode_set or whatever, but it's basically
an enable function that turns on clocks, initalizes phy, etc. etc.
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c#L998
And if you check "Before:" sequence, you'll see that .mode_set callback is just
called once at boot and never again. And it's
atomic(_pre)_enable/atomic(_post)_disable
callbacks that actually are called in ballanced way to enable/disable the
controller repeatedly ever after.
Function dw_mipi_dsi_bridge_post_atomic_disable is the inverse of
dw_mipi_dsi_mode_set, it undoes everything that dw_mipi_dsi_mode_set does.
You need to find root cause for your issue on STM32MP15xx instead of reverting
fixes for resource use bugs in this driver.
Actually, reverting commit 05aa61334592 ("drm: bridge: dw-mipi-dsi: Fix
enable/disable of DSI controller") makes the STM32MP15xx work again like
it used to since Linux 5.10 or so, so that commit breaks existing
working use case.
It seems it is sufficient to revert only this part of the commit to make
the STM32MP15xx work as it used to, do you have any idea why ?
Re: [PATCH] drm/bridge: imx: Fix unmet depenency for PHY_FSL_SAMSUNG_HDMI_PHY
Hi Adam,
Thank you for the patch.
On Sat, Apr 20, 2024 at 06:28:31AM -0500, Adam Ford wrote:
> When enabling i.MX8MP DWC HDMI driver, it automatically selects
> PHY_FSL_SAMSUNG_HDMI_PHY, since it wont' work without the phy.
> This may cause some Kconfig warnings during various build tests.
> Fix this by implying the phy instead of selecting the phy.
>
> Fixes: 1f36d634670d ("drm/bridge: imx: add bridge wrapper driver for i.MX8MP
> DWC HDMI")
> Reported-by: kernel test robot
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202404190103.llm8ltup-...@intel.com/
> Signed-off-by: Adam Ford
>
> diff --git a/drivers/gpu/drm/bridge/imx/Kconfig
> b/drivers/gpu/drm/bridge/imx/Kconfig
> index 7687ed652df5..8f125c75050d 100644
> --- a/drivers/gpu/drm/bridge/imx/Kconfig
> +++ b/drivers/gpu/drm/bridge/imx/Kconfig
> @@ -9,7 +9,7 @@ config DRM_IMX8MP_DW_HDMI_BRIDGE
> depends on DRM_DW_HDMI
> depends on OF
> select DRM_IMX8MP_HDMI_PVI
This also looks wrong, even if in practice it will likely work because
DRM_IMX8MP_HDMI_PVI has no extra dependency compared to
DRM_IMX8MP_DW_HDMI_BRIDGE. Still, it would be good to fix it.
> - select PHY_FSL_SAMSUNG_HDMI_PHY
> + imply PHY_FSL_SAMSUNG_HDMI_PHY
> help
> Choose this to enable support for the internal HDMI encoder found
> on the i.MX8MP SoC.
--
Regards,
Laurent Pinchart
Re: [RFC][PATCH] drm: bridge: dw-mipi-dsi: Call modeset in modeset callback
Hi,
On Sun, Apr 21, 2024 at 02:22:35AM GMT, Marek Vasut wrote:
> Doing modeset in .atomic_pre_enable callback instead of dedicated .mode_set
> callback does not seem right. Undo this change, which was added as part of
Actually no. If anything, mode_set callback should be dropped entirely:
See https://elixir.bootlin.com/linux/latest/source/include/drm/drm_bridge.h#L231
It's deprecated, and enable callback should just use adjusted_mode:
This is deprecated, do not use! New drivers shall set their mode in the
&drm_bridge_funcs.atomic_enable operation.
> commit 05aa61334592 ("drm: bridge: dw-mipi-dsi: Fix enable/disable of DSI
> controller") as it breaks STM32MP15xx LTDC scanout (DSI)->TC358762 DSI-to-DPI
> bridge->PT800480 DPI panel pipeline. The original fix for HX8394 panel likely
> requires HX8394 panel side fix instead.
There's nothing wrong with the panel driver. And that commit is not fixing issue
with the panel driver, just like the subject hints at. Look at the referenced
commit, at "Before:" sequence specifically.
dw_mipi_dsi_mode_set may be named *_mode_set or whatever, but it's basically
an enable function that turns on clocks, initalizes phy, etc. etc.
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c#L998
And if you check "Before:" sequence, you'll see that .mode_set callback is just
called once at boot and never again. And it's
atomic(_pre)_enable/atomic(_post)_disable
callbacks that actually are called in ballanced way to enable/disable the
controller repeatedly ever after.
Function dw_mipi_dsi_bridge_post_atomic_disable is the inverse of
dw_mipi_dsi_mode_set, it undoes everything that dw_mipi_dsi_mode_set does.
You need to find root cause for your issue on STM32MP15xx instead of reverting
fixes for resource use bugs in this driver.
kind regards,
o.
> Fixes: 05aa61334592 ("drm: bridge: dw-mipi-dsi: Fix enable/disable of DSI
> controller")
> Signed-off-by: Marek Vasut
> ---
> Cc: Andrzej Hajda
> Cc: Biju Das
> Cc: Daniel Vetter
> Cc: David Airlie
> Cc: Douglas Anderson
> Cc: Jernej Skrabec
> Cc: Jonas Karlman
> Cc: Laurent Pinchart
> Cc: Liu Ying
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Neil Armstrong
> Cc: Ondrej Jirman
> Cc: Rob Herring
> Cc: Robert Foss
> Cc: Sam Ravnborg
> Cc: Thomas Zimmermann
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org
> ---
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 18 +++---
> 1 file changed, 3 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index 824fb3c65742e..ca5894393dba4 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -268,7 +268,6 @@ struct dw_mipi_dsi {
> struct dw_mipi_dsi *master; /* dual-dsi master ptr */
> struct dw_mipi_dsi *slave; /* dual-dsi slave ptr */
>
> - struct drm_display_mode mode;
> const struct dw_mipi_dsi_plat_data *plat_data;
> };
>
> @@ -1016,25 +1015,15 @@ static void dw_mipi_dsi_mode_set(struct dw_mipi_dsi
> *dsi,
> phy_ops->power_on(dsi->plat_data->priv_data);
> }
>
> -static void dw_mipi_dsi_bridge_atomic_pre_enable(struct drm_bridge *bridge,
> - struct drm_bridge_state
> *old_bridge_state)
> -{
> - struct dw_mipi_dsi *dsi = bridge_to_dsi(bridge);
> -
> - /* Power up the dsi ctl into a command mode */
> - dw_mipi_dsi_mode_set(dsi, &dsi->mode);
> - if (dsi->slave)
> - dw_mipi_dsi_mode_set(dsi->slave, &dsi->mode);
> -}
> -
> static void dw_mipi_dsi_bridge_mode_set(struct drm_bridge *bridge,
> const struct drm_display_mode *mode,
> const struct drm_display_mode
> *adjusted_mode)
> {
> struct dw_mipi_dsi *dsi = bridge_to_dsi(bridge);
>
> - /* Store the display mode for later use in pre_enable callback */
> - drm_mode_copy(&dsi->mode, adjusted_mode);
> + dw_mipi_dsi_mode_set(dsi, adjusted_mode);
> + if (dsi->slave)
> + dw_mipi_dsi_mode_set(dsi->slave, adjusted_mode);
> }
>
> static void dw_mipi_dsi_bridge_atomic_enable(struct drm_bridge *bridge,
> @@ -1090,7 +1079,6 @@ static const struct drm_bridge_funcs
> dw_mipi_dsi_bridge_funcs = {
> .atomic_get_input_bus_fmts =
> dw_mipi_dsi_bridge_atomic_get_input_bus_fmts,
> .atomic_check = dw_mipi_dsi_bridge_atomic_check,
> .atomic_reset = drm_atomic_helper_bridge_reset,
> - .atomic_pre_enable = dw_mipi_dsi_bridge_atomic_pre_enable,
> .atomic_enable = dw_mipi_dsi_bridge_atomic_enable,
> .atomic_post_disable= dw_mipi_dsi_bridge_post_atomic_disable,
> .mode_set = dw_mipi_dsi_bridge_mode_set,
> --
> 2.43.0
>
[PATCH v2][next] backlight: sky81452-backlight: Remove unnecessary call to of_node_get
`dev->of_node` already has a reference to the device_node and calling
of_node_get on it is unnecessary. All conresponding calls to
of_node_put are also removed.
Signed-off-by: Shresth Prasad
---
Changes in v2:
- Change commit header and body to better reflect changes
- Remove call to of_node_get entirely
drivers/video/backlight/sky81452-backlight.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/video/backlight/sky81452-backlight.c
b/drivers/video/backlight/sky81452-backlight.c
index eb18c6eb0ff0..e7cae32c8d96 100644
--- a/drivers/video/backlight/sky81452-backlight.c
+++ b/drivers/video/backlight/sky81452-backlight.c
@@ -182,7 +182,7 @@ static const struct attribute_group sky81452_bl_attr_group
= {
static struct sky81452_bl_platform_data *sky81452_bl_parse_dt(
struct device *dev)
{
- struct device_node *np = of_node_get(dev->of_node);
+ struct device_node *np = dev->of_node;
struct sky81452_bl_platform_data *pdata;
int num_entry;
unsigned int sources[6];
@@ -195,7 +195,6 @@ static struct sky81452_bl_platform_data
*sky81452_bl_parse_dt(
pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata) {
- of_node_put(np);
return ERR_PTR(-ENOMEM);
}
@@ -217,7 +216,6 @@ static struct sky81452_bl_platform_data
*sky81452_bl_parse_dt(
num_entry);
if (ret < 0) {
dev_err(dev, "led-sources node is invalid.\n");
- of_node_put(np);
return ERR_PTR(-EINVAL);
}
@@ -237,7 +235,6 @@ static struct sky81452_bl_platform_data
*sky81452_bl_parse_dt(
if (ret < 0)
pdata->boost_current_limit = 2750;
- of_node_put(np);
return pdata;
}
#else
--
2.44.0
Re: [PATCH] Revert "drm/etnaviv: Expose a few more chipspecs to userspace"
Agreed, thanks for doing this, Christian.
Reviewed-by: Tomeu Vizoso
Cheers,
Tomeu
On Sat, Apr 20, 2024 at 3:41 PM Christian Gmeiner
wrote:
>
> From: Christian Gmeiner
>
> This reverts commit 1dccdba084897443d116508a8ed71e0ac8a031a4.
>
> In userspace a different approach was choosen - hwdb. As a result, there
> is no need for these values.
>
> Signed-off-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 20 ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 12 -
> drivers/gpu/drm/etnaviv/etnaviv_hwdb.c | 34 --
> include/uapi/drm/etnaviv_drm.h | 5
> 4 files changed, 71 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index 734412aae94d..e47e5562535a 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -164,26 +164,6 @@ int etnaviv_gpu_get_param(struct etnaviv_gpu *gpu, u32
> param, u64 *value)
> *value = gpu->identity.eco_id;
> break;
>
> - case ETNAVIV_PARAM_GPU_NN_CORE_COUNT:
> - *value = gpu->identity.nn_core_count;
> - break;
> -
> - case ETNAVIV_PARAM_GPU_NN_MAD_PER_CORE:
> - *value = gpu->identity.nn_mad_per_core;
> - break;
> -
> - case ETNAVIV_PARAM_GPU_TP_CORE_COUNT:
> - *value = gpu->identity.tp_core_count;
> - break;
> -
> - case ETNAVIV_PARAM_GPU_ON_CHIP_SRAM_SIZE:
> - *value = gpu->identity.on_chip_sram_size;
> - break;
> -
> - case ETNAVIV_PARAM_GPU_AXI_SRAM_SIZE:
> - *value = gpu->identity.axi_sram_size;
> - break;
> -
> default:
> DBG("%s: invalid param: %u", dev_name(gpu->dev), param);
> return -EINVAL;
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> index 7d5e9158e13c..197e0037732e 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> @@ -54,18 +54,6 @@ struct etnaviv_chip_identity {
> /* Number of Neural Network cores. */
> u32 nn_core_count;
>
> - /* Number of MAD units per Neural Network core. */
> - u32 nn_mad_per_core;
> -
> - /* Number of Tensor Processing cores. */
> - u32 tp_core_count;
> -
> - /* Size in bytes of the SRAM inside the NPU. */
> - u32 on_chip_sram_size;
> -
> - /* Size in bytes of the SRAM across the AXI bus. */
> - u32 axi_sram_size;
> -
> /* Size of the vertex cache. */
> u32 vertex_cache_size;
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c
> b/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c
> index d8e7334de8ce..8665f2658d51 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c
> @@ -17,10 +17,6 @@ static const struct etnaviv_chip_identity
> etnaviv_chip_identities[] = {
> .thread_count = 128,
> .shader_core_count = 1,
> .nn_core_count = 0,
> - .nn_mad_per_core = 0,
> - .tp_core_count = 0,
> - .on_chip_sram_size = 0,
> - .axi_sram_size = 0,
> .vertex_cache_size = 8,
> .vertex_output_buffer_size = 1024,
> .pixel_pipes = 1,
> @@ -52,11 +48,6 @@ static const struct etnaviv_chip_identity
> etnaviv_chip_identities[] = {
> .register_max = 64,
> .thread_count = 256,
> .shader_core_count = 1,
> - .nn_core_count = 0,
> - .nn_mad_per_core = 0,
> - .tp_core_count = 0,
> - .on_chip_sram_size = 0,
> - .axi_sram_size = 0,
> .vertex_cache_size = 8,
> .vertex_output_buffer_size = 512,
> .pixel_pipes = 1,
> @@ -89,10 +80,6 @@ static const struct etnaviv_chip_identity
> etnaviv_chip_identities[] = {
> .thread_count = 512,
> .shader_core_count = 2,
> .nn_core_count = 0,
> - .nn_mad_per_core = 0,
> - .tp_core_count = 0,
> - .on_chip_sram_size = 0,
> - .axi_sram_size = 0,
> .vertex_cache_size = 16,
> .vertex_output_buffer_size = 1024,
> .pixel_pipes = 1,
> @@ -125,10 +112,6 @@ static const struct etnaviv_chip_identity
> etnaviv_chip_identities[] = {
> .thread_count = 512,
> .shader_core_count = 2,
> .nn_core_count = 0,
> - .nn_mad_per_core = 0,
> - .tp_core_count = 0,
> - .on_chip_sram_size = 0,
> - .axi_sram_size = 0,
> .vertex_cache_size = 16,
> .vertex_output_buffer_size = 1024,
> .pixel_pipes = 1,
> @@ -160,11
