[PATCH v12 01/13] drm/i915/guc: Update GuC ADS size for error capture lists
Update GuC ADS size allocation to include space for
the lists of error state capture register descriptors.
Then, populate GuC ADS with the lists of registers we want
GuC to report back to host on engine reset events. This list
should include global, engine-class and engine-instance
registers for every engine-class type on the current hardware.
Ensure we allocate a persistent store for the register lists
that are populated into ADS so that we don't need to allocate
memory during GT resets when GuC is reloaded and ADS population
happens again.
NOTE: Start with a sample static table of register lists to
layout the framework before adding real registers in subsequent
patch. This static register tables are a different format from
the ADS populated list.
Signed-off-by: Alan Previn
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h | 91 +
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 13 +-
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 9 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 127 +-
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 374 ++
.../gpu/drm/i915/gt/uc/intel_guc_capture.h| 22 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 8 +
8 files changed, 628 insertions(+), 17 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_capture.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a54e84e05466..d34f625221e2 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -184,6 +184,7 @@ i915-y += gt/uc/intel_uc.o \
gt/uc/intel_uc_fw.o \
gt/uc/intel_guc.o \
gt/uc/intel_guc_ads.o \
+ gt/uc/intel_guc_capture.o \
gt/uc/intel_guc_ct.o \
gt/uc/intel_guc_debugfs.o \
gt/uc/intel_guc_fw.o \
diff --git a/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
b/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
new file mode 100644
index ..919ed985f09a
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
@@ -0,0 +1,91 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2021-2022 Intel Corporation
+ */
+
+#ifndef _INTEL_GUC_CAPTURE_FWIF_H
+#define _INTEL_GUC_CAPTURE_FWIF_H
+
+#include
+#include "intel_guc_fwif.h"
+
+struct intel_guc;
+struct file;
+
+/**
+ * struct guc_debug_capture_list_header / struct guc_debug_capture_list
+ *
+ * As part of ADS registration, these header structures (followed by
+ * an array of 'struct guc_mmio_reg' entries) are used to register with
+ * GuC microkernel the list of registers we want it to dump out prior
+ * to a engine reset.
+ */
+struct guc_debug_capture_list_header {
+ u32 info;
+#define GUC_CAPTURELISTHDR_NUMDESCR GENMASK(15, 0)
+} __packed;
+
+struct guc_debug_capture_list {
+ struct guc_debug_capture_list_header header;
+ struct guc_mmio_reg regs[0];
+} __packed;
+
+/**
+ * struct __guc_mmio_reg_descr / struct __guc_mmio_reg_descr_group
+ *
+ * intel_guc_capture module uses these structures to maintain static
+ * tables (per unique platform) that consists of lists of registers
+ * (offsets, names, flags,...) that are used at the ADS regisration
+ * time as well as during runtime processing and reporting of error-
+ * capture states generated by GuC just prior to engine reset events.
+ */
+struct __guc_mmio_reg_descr {
+ i915_reg_t reg;
+ u32 flags;
+ u32 mask;
+ const char *regname;
+};
+
+struct __guc_mmio_reg_descr_group {
+ const struct __guc_mmio_reg_descr *list;
+ u32 num_regs;
+ u32 owner; /* see enum guc_capture_owner */
+ u32 type; /* see enum guc_capture_type */
+ u32 engine; /* as per MAX_ENGINE_CLASS */
+};
+
+/**
+ * struct __guc_capture_ads_cache
+ *
+ * A structure to cache register lists that were populated and registered
+ * with GuC at startup during ADS registration. This allows much quicker
+ * GuC resets without re-parsing all the tables for the given gt.
+ */
+struct __guc_capture_ads_cache {
+ bool is_valid;
+ void *ptr;
+ size_t size;
+ int status;
+};
+
+/**
+ * struct intel_guc_state_capture
+ *
+ * Internal context of the intel_guc_capture module.
+ */
+struct intel_guc_state_capture {
+ /**
+* @reglists: static table of register lists used for error-capture
state.
+*/
+ const struct __guc_mmio_reg_descr_group *reglists;
+
+ /**
+* @ads_cache: cached register lists that is ADS format ready
+*/
+ struct __guc_capture_ads_cache ads_cache[GUC_CAPTURE_LIST_INDEX_MAX]
+ [GUC_CAPTURE_LIST_TYPE_MAX]
+ [GUC_MAX_ENGINE_CLASSES];
+ void *ads_null_cache;
+};
+
+#endif /* _INTEL_GUC_CAPTURE_FW
[PATCH v12 04/13] drm/i915/guc: Add DG2 registers for GuC error state capture.
Add additional DG2 registers for GuC error state capture.
Signed-off-by: Alan Previn
Reviewed-by: Umesh Nerlige Ramappa
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 80 ++-
1 file changed, 77 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index 0f2b47139140..15fc36203463 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -285,20 +285,94 @@ guc_capture_alloc_steered_lists_xe_lpd(struct intel_guc
*guc,
guc->capture->extlists = extlists;
}
+static const struct __ext_steer_reg xehpg_extregs[] = {
+ {"XEHPG_INSTDONE_GEOM_SVG", XEHPG_INSTDONE_GEOM_SVG}
+};
+
+static bool __has_xehpg_extregs(u32 ipver)
+{
+ return (ipver >= IP_VER(12, 55));
+}
+
+static void
+guc_capture_alloc_steered_lists_xe_hpg(struct intel_guc *guc,
+ const struct __guc_mmio_reg_descr_group
*lists,
+ u32 ipver)
+{
+ struct intel_gt *gt = guc_to_gt(guc);
+ struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+ struct sseu_dev_info *sseu;
+ int slice, subslice, i, iter, num_steer_regs, num_tot_regs = 0;
+ const struct __guc_mmio_reg_descr_group *list;
+ struct __guc_mmio_reg_descr_group *extlists;
+ struct __guc_mmio_reg_descr *extarray;
+
+ /* In XE_LP / HPG we only have render-class steering registers during
error-capture */
+ list = guc_capture_get_one_list(lists, GUC_CAPTURE_LIST_INDEX_PF,
+ GUC_CAPTURE_LIST_TYPE_ENGINE_CLASS,
GUC_RENDER_CLASS);
+ /* skip if extlists was previously allocated */
+ if (!list || guc->capture->extlists)
+ return;
+
+ num_steer_regs = ARRAY_SIZE(xe_extregs);
+ if (__has_xehpg_extregs(ipver))
+ num_steer_regs += ARRAY_SIZE(xehpg_extregs);
+
+ sseu = >->info.sseu;
+ for_each_instdone_gslice_dss_xehp(i915, sseu, iter, slice, subslice) {
+ num_tot_regs += num_steer_regs;
+ }
+
+ if (!num_tot_regs)
+ return;
+
+ /* allocate an extra for an end marker */
+ extlists = kcalloc(2, sizeof(struct __guc_mmio_reg_descr_group),
GFP_KERNEL);
+ if (!extlists)
+ return;
+
+ if (__alloc_ext_regs(&extlists[0], list, num_tot_regs)) {
+ kfree(extlists);
+ return;
+ }
+
+ extarray = extlists[0].extlist;
+ for_each_instdone_gslice_dss_xehp(i915, sseu, iter, slice, subslice) {
+ for (i = 0; i < ARRAY_SIZE(xe_extregs); ++i) {
+ __fill_ext_reg(extarray, &xe_extregs[i], slice,
subslice);
+ ++extarray;
+ }
+ if (__has_xehpg_extregs(ipver)) {
+ for (i = 0; i < ARRAY_SIZE(xehpg_extregs); ++i) {
+ __fill_ext_reg(extarray, &xehpg_extregs[i],
slice, subslice);
+ ++extarray;
+ }
+ }
+ }
+
+ drm_dbg(&i915->drm, "GuC-capture found %d-ext-regs.\n", num_tot_regs);
+ guc->capture->extlists = extlists;
+}
+
static const struct __guc_mmio_reg_descr_group *
guc_capture_get_device_reglist(struct intel_guc *guc)
{
struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
- if (IS_TIGERLAKE(i915) || IS_ROCKETLAKE(i915) ||
- IS_ALDERLAKE_S(i915) || IS_ALDERLAKE_P(i915)) {
+ if (GRAPHICS_VER(i915) > 11) {
/*
* For certain engine classes, there are slice and subslice
* level registers requiring steering. We allocate and populate
* these at init time based on hw config add it as an extension
* list at the end of the pre-populated render list.
*/
- guc_capture_alloc_steered_lists_xe_lpd(guc, xe_lpd_lists);
+ if (IS_DG2(i915))
+ guc_capture_alloc_steered_lists_xe_hpg(guc,
xe_lpd_lists, IP_VER(12, 55));
+ else if (IS_XEHPSDV(i915))
+ guc_capture_alloc_steered_lists_xe_hpg(guc,
xe_lpd_lists, IP_VER(12, 50));
+ else
+ guc_capture_alloc_steered_lists_xe_lpd(guc,
xe_lpd_lists);
+
return xe_lpd_lists;
}
--
2.25.1
[PATCH v12 06/13] drm/i915/guc: Add GuC's error state capture output structures.
Add GuC's error capture output structures and definitions as how
they would appear in GuC log buffer's error capture subregion after
an error state capture G2H event notification.
Signed-off-by: Alan Previn
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h | 47 +++
1 file changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
b/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
index 6c199433945d..8824c5eba355 100644
--- a/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
@@ -55,6 +55,53 @@ struct __guc_mmio_reg_descr_group {
struct __guc_mmio_reg_descr *extlist; /* only used for steered
registers */
};
+/**
+ * struct guc_state_capture_header_t / struct guc_state_capture_t /
+ * guc_state_capture_group_header_t / guc_state_capture_group_t
+ *
+ * Prior to resetting engines that have hung or faulted, GuC microkernel
+ * reports the engine error-state (register values that was read) by
+ * logging them into the shared GuC log buffer using these hierarchy
+ * of structures.
+ */
+struct guc_state_capture_header_t {
+ u32 owner;
+#define CAP_HDR_CAPTURE_VFID GENMASK(7, 0)
+ u32 info;
+#define CAP_HDR_CAPTURE_TYPE GENMASK(3, 0) /* see enum guc_capture_type */
+#define CAP_HDR_ENGINE_CLASS GENMASK(7, 4) /* see GUC_MAX_ENGINE_CLASSES */
+#define CAP_HDR_ENGINE_INSTANCE GENMASK(11, 8)
+ u32 lrca; /* if type-instance, LRCA (address) that hung, else set to ~0
*/
+ u32 guc_id; /* if type-instance, context index of hung context, else
set to ~0 */
+ u32 num_mmios;
+#define CAP_HDR_NUM_MMIOS GENMASK(9, 0)
+} __packed;
+
+struct guc_state_capture_t {
+ struct guc_state_capture_header_t header;
+ struct guc_mmio_reg mmio_entries[0];
+} __packed;
+
+enum guc_capture_group_types {
+ GUC_STATE_CAPTURE_GROUP_TYPE_FULL,
+ GUC_STATE_CAPTURE_GROUP_TYPE_PARTIAL,
+ GUC_STATE_CAPTURE_GROUP_TYPE_MAX,
+};
+
+struct guc_state_capture_group_header_t {
+ u32 owner;
+#define CAP_GRP_HDR_CAPTURE_VFID GENMASK(7, 0)
+ u32 info;
+#define CAP_GRP_HDR_NUM_CAPTURES GENMASK(7, 0)
+#define CAP_GRP_HDR_CAPTURE_TYPE GENMASK(15, 8) /* guc_capture_group_types */
+} __packed;
+
+/* this is the top level structure where an error-capture dump starts */
+struct guc_state_capture_group_t {
+ struct guc_state_capture_group_header_t grp_header;
+ struct guc_state_capture_t capture_entries[0];
+} __packed;
+
/**
* struct __guc_capture_ads_cache
*
--
2.25.1
[PATCH v12 08/13] drm/i915/guc: Add capture region into intel_guc_log
GuC log buffer regions for debug-log-events, crash-dumps and
error-state-capture are all part of a single bo allocation that
also includes the guc_log_buffer_state structures. Now that we
support it, increase the size allocation for error-capture.
Since the error-capture region is accessed at non-deterministic
times (as part of GuC triggered context reset) while debug-log-
events region is accessed as part of relay logging or during
debugfs triggered dumps, move the mapping and unmapping of the
shared buffer into intel_guc_log_create and intel_guc_log_destroy
so that it's always mapped throughout life of GuC operation.
Additionally, while here, update the guc log region layout
diagram to follow the order according to the enum definition
as per the GuC interface.
NOTE: A future effort to visit (part of baseline code) is that
buf_addr should be updated to be a io_sys_map and use the
io_sys_map wrapper functions to access the various GuC log
buffer regions.
Signed-off-by: Alan Previn
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 59 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_log.h | 3 +-
2 files changed, 37 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
index 0d63c411080f..fe4b2d3f305d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
@@ -26,7 +26,8 @@ static void guc_log_copy_debuglogs_for_relay(struct
intel_guc_log *log);
static int guc_action_flush_log_complete(struct intel_guc *guc)
{
u32 action[] = {
- INTEL_GUC_ACTION_LOG_BUFFER_FILE_FLUSH_COMPLETE
+ INTEL_GUC_ACTION_LOG_BUFFER_FILE_FLUSH_COMPLETE,
+ GUC_DEBUG_LOG_BUFFER
};
return intel_guc_send(guc, action, ARRAY_SIZE(action));
@@ -137,7 +138,7 @@ static void guc_move_to_next_buf(struct intel_guc_log *log)
smp_wmb();
/* All data has been written, so now move the offset of sub buffer. */
- relay_reserve(log->relay.channel, log->vma->obj->base.size);
+ relay_reserve(log->relay.channel, log->vma->obj->base.size -
CAPTURE_BUFFER_SIZE);
/* Switch to the next sub buffer */
relay_flush(log->relay.channel);
@@ -213,7 +214,8 @@ static void _guc_log_copy_debuglogs_for_relay(struct
intel_guc_log *log)
goto out_unlock;
/* Get the pointer to shared GuC log buffer */
- log_buf_state = src_data = log->relay.buf_addr;
+ src_data = log->buf_addr;
+ log_buf_state = src_data;
/* Get the pointer to local buffer to store the logs */
log_buf_snapshot_state = dst_data = guc_get_write_buffer(log);
@@ -233,7 +235,8 @@ static void _guc_log_copy_debuglogs_for_relay(struct
intel_guc_log *log)
src_data += PAGE_SIZE;
dst_data += PAGE_SIZE;
- for (type = GUC_DEBUG_LOG_BUFFER; type < GUC_MAX_LOG_BUFFER; type++) {
+ /* For relay logging, we exclude error state capture */
+ for (type = GUC_DEBUG_LOG_BUFFER; type <= GUC_CRASH_DUMP_LOG_BUFFER;
type++) {
/*
* Make a copy of the state structure, inside GuC log buffer
* (which is uncached mapped), on the stack to avoid reading
@@ -311,23 +314,17 @@ static void copy_debug_logs_work(struct work_struct *work)
static int guc_log_relay_map(struct intel_guc_log *log)
{
- void *vaddr;
-
lockdep_assert_held(&log->relay.lock);
- if (!log->vma)
+ if (!log->vma || !log->buf_addr)
return -ENODEV;
/*
-* Create a WC (Uncached for read) vmalloc mapping of log
-* buffer pages, so that we can directly get the data
-* (up-to-date) from memory.
+* WC vmalloc mapping of log buffer pages was done at
+* GuC Log Init time, but lets keep a ref for book-keeping
*/
- vaddr = i915_gem_object_pin_map_unlocked(log->vma->obj, I915_MAP_WC);
- if (IS_ERR(vaddr))
- return PTR_ERR(vaddr);
-
- log->relay.buf_addr = vaddr;
+ i915_gem_object_get(log->vma->obj);
+ log->relay.buf_in_use = true;
return 0;
}
@@ -336,8 +333,8 @@ static void guc_log_relay_unmap(struct intel_guc_log *log)
{
lockdep_assert_held(&log->relay.lock);
- i915_gem_object_unpin_map(log->vma->obj);
- log->relay.buf_addr = NULL;
+ i915_gem_object_put(log->vma->obj);
+ log->relay.buf_in_use = false;
}
void intel_guc_log_init_early(struct intel_guc_log *log)
@@ -443,6 +440,7 @@ int intel_guc_log_create(struct intel_guc_log *log)
{
struct intel_guc *guc = log_to_guc(log);
struct i915_vma *vma;
+ void *vaddr;
u32 guc_log_size;
int ret;
@@ -450,20 +448,21 @@ int intel_guc_log_create(struct intel_guc_log *log)
/*
* GuC Log buffer Layout
+* (this ordering must follow "enum guc_log_buffer_type"
[PATCH v12 05/13] drm/i915/guc: Add Gen9 registers for GuC error state capture.
Abstract out a Gen9 register list as the default for all other
platforms we don't yet formally support GuC submission on.
Signed-off-by: Alan Previn
Reviewed-by: Umesh Nerlige Ramappa
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 82 +--
1 file changed, 59 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index 15fc36203463..f9612e45def6 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -22,15 +22,24 @@
* NOTE1: For engine-registers, GuC only needs the register offsets
*from the engine-mmio-base
*/
+#define COMMON_BASE_GLOBAL() \
+ {FORCEWAKE_MT, 0, 0, "FORCEWAKE"}
+
+#define COMMON_GEN9BASE_GLOBAL() \
+ {GEN8_FAULT_TLB_DATA0, 0, 0, "GEN8_FAULT_TLB_DATA0"}, \
+ {GEN8_FAULT_TLB_DATA1, 0, 0, "GEN8_FAULT_TLB_DATA1"}, \
+ {ERROR_GEN6, 0, 0, "ERROR_GEN6"}, \
+ {DONE_REG, 0, 0, "DONE_REG"}, \
+ {HSW_GTT_CACHE_EN, 0, 0, "HSW_GTT_CACHE_EN"}
+
#define COMMON_GEN12BASE_GLOBAL() \
{GEN12_FAULT_TLB_DATA0,0, 0, "GEN12_FAULT_TLB_DATA0"}, \
{GEN12_FAULT_TLB_DATA1,0, 0, "GEN12_FAULT_TLB_DATA1"}, \
- {FORCEWAKE_MT, 0, 0, "FORCEWAKE"}, \
{GEN12_AUX_ERR_DBG,0, 0, "AUX_ERR_DBG"}, \
{GEN12_GAM_DONE, 0, 0, "GAM_DONE"}, \
{GEN12_RING_FAULT_REG, 0, 0, "FAULT_REG"}
-#define COMMON_GEN12BASE_ENGINE_INSTANCE() \
+#define COMMON_BASE_ENGINE_INSTANCE() \
{RING_PSMI_CTL(0), 0, 0, "RC PSMI"}, \
{RING_ESR(0), 0, 0, "ESR"}, \
{RING_DMA_FADD(0), 0, 0, "RING_DMA_FADD_LDW"}, \
@@ -64,11 +73,13 @@
{GEN8_RING_PDP_LDW(0, 3), 0, 0, "PDP3_LDW"}, \
{GEN8_RING_PDP_UDW(0, 3), 0, 0, "PDP3_UDW"}
-#define COMMON_GEN12BASE_HAS_EU() \
+#define COMMON_BASE_HAS_EU() \
{EIR, 0, 0, "EIR"}
+#define COMMON_BASE_RENDER() \
+ {GEN7_SC_INSTDONE, 0, 0, "GEN7_SC_INSTDONE"}
+
#define COMMON_GEN12BASE_RENDER() \
- {GEN7_SC_INSTDONE, 0, 0, "GEN7_SC_INSTDONE"}, \
{GEN12_SC_INSTDONE_EXTRA, 0, 0, "GEN12_SC_INSTDONE_EXTRA"}, \
{GEN12_SC_INSTDONE_EXTRA2, 0, 0, "GEN12_SC_INSTDONE_EXTRA2"}
@@ -80,28 +91,26 @@
/* XE_LPD - Global */
static const struct __guc_mmio_reg_descr xe_lpd_global_regs[] = {
+ COMMON_BASE_GLOBAL(),
+ COMMON_GEN9BASE_GLOBAL(),
COMMON_GEN12BASE_GLOBAL(),
};
/* XE_LPD - Render / Compute Per-Class */
static const struct __guc_mmio_reg_descr xe_lpd_rc_class_regs[] = {
- COMMON_GEN12BASE_HAS_EU(),
+ COMMON_BASE_HAS_EU(),
+ COMMON_BASE_RENDER(),
COMMON_GEN12BASE_RENDER(),
};
-/* XE_LPD - Render / Compute Per-Engine-Instance */
+/* GEN9/XE_LPD - Render / Compute Per-Engine-Instance */
static const struct __guc_mmio_reg_descr xe_lpd_rc_inst_regs[] = {
- COMMON_GEN12BASE_ENGINE_INSTANCE(),
+ COMMON_BASE_ENGINE_INSTANCE(),
};
-/* XE_LPD - Media Decode/Encode Per-Class */
-static const struct __guc_mmio_reg_descr xe_lpd_vd_class_regs[] = {
- COMMON_GEN12BASE_ENGINE_INSTANCE(),
-};
-
-/* XE_LPD - Media Decode/Encode Per-Engine-Instance */
+/* GEN9/XE_LPD - Media Decode/Encode Per-Engine-Instance */
static const struct __guc_mmio_reg_descr xe_lpd_vd_inst_regs[] = {
- COMMON_GEN12BASE_ENGINE_INSTANCE(),
+ COMMON_BASE_ENGINE_INSTANCE(),
};
/* XE_LPD - Video Enhancement Per-Class */
@@ -109,18 +118,33 @@ static const struct __guc_mmio_reg_descr
xe_lpd_vec_class_regs[] = {
COMMON_GEN12BASE_VEC(),
};
-/* XE_LPD - Video Enhancement Per-Engine-Instance */
+/* GEN9/XE_LPD - Video Enhancement Per-Engine-Instance */
static const struct __guc_mmio_reg_descr xe_lpd_vec_inst_regs[] = {
- COMMON_GEN12BASE_ENGINE_INSTANCE(),
+ COMMON_BASE_ENGINE_INSTANCE(),
};
-/* XE_LPD - Blitter Per-Engine-Instance */
+/* GEN9/XE_LPD - Blitter Per-Engine-Instance */
static const struct __guc_mmio_reg_descr xe_lpd_blt_inst_regs[] = {
- COMMON_GEN12BASE_ENGINE_INSTANCE(),
+ COMMON_BASE_ENGINE_INSTANCE(),
};
-/* XE_LPD - Blitter Per-Class */
-/* XE_LPD - Media Decode/Encode Per-Class */
+/* GEN9 - Global */
+static const struct __guc_mmio_reg_descr default_global_regs[] = {
+ COMMON_BASE_GLOBAL(),
+ COMMON_GEN9BASE_GLOBAL(),
+};
+
+static const struct __guc_mmio_reg_descr default_rc_class_regs[] = {
+ COMMON_BASE_HAS_EU(),
+ COMMON_BASE_RENDER(),
+};
+
+/*
+ * Empty lists:
+ * GEN9/XE_LPD - Blitter Per-Class
+ * GEN9/XE_LPD - Media Decode/Encode Per-Class
+ * GEN9 - VEC Class
+ */
static const struct __guc_mmio_reg_descr empty_regs_list[] = {
};
@@ -137,6 +161,19 @@ static const struct __guc_mmio_reg_d
[PATCH v12 00/13] Add GuC Error Capture Support
This series: 1. Enables support of GuC to report error-state-capture using a list of MMIO registers the driver registers and GuC will dump, log and notify right before a GuC triggered engine-reset event. 2. Updates the ADS blob creation to register said lists of global, engine class and engine instance registers with GuC. 3. Defines tables of register lists that are global or engine class or engine instance in scope. 4. Updates usage and buffer-state data for the regions of the shared GuC log-buffer to accomdate both the existing relay logging of general debug logs along with the new error state capture usage. 5. Using a pool of preallocated memory, provide ability to extract and format the GuC reported register-capture data into chunks consistent with existing i915 error- state collection flows and structures. 6. Connects the i915_gpu_coredump reporting function to the GuC error capture module to print all GuC error state capture dumps that is reported. This is the 9th rev of changes in this series where the first 3 revs are RFC and revs #10 through to 12 are repeats Prior receipts of rvb's: - Patch #2, #3, #4, #5, #10, #11, #12, #13 have received R-v-b's from Umesh Nerlige Ramappa - Patch #1, #6, #7, #8, #9 has received an R-v-b from Matthew Brost . NOTE: some of these came in on the trybot series. https://patchwork.freedesktop.org/series/100831/ Changes from prior revs: v12:- Re-sending it because previous revs only got to intel-gfx, and only cover letter was in dri-devel. Also rebased again. v11:- Rebase again on latest drm-tip to fix merge error. v10:- Rebase on latest drm-tip again. Fix a number of checkpatch warnings and an error Reported-by: kernel test robot . v9: - Rebase on latest drm-tip to solve CI merge-build error. v8: - Fix a bug found by CI in rev7: Create a cached ADS capture list for null-header like the other lists. - Fixed a bug on the ggtt offset calculation in the ADS population loop. Thanks to Matt Brost. - Change the storage uses for initial allocation and caching of the ADS register lists so we only store a regular pointer instead of file handle. - Multiple improvements on code styling, variable names, comments and code reduction from Umesh suggestions across multiple patches. v7: - Rebased on lastest drm_tip that has the ADS now using shmem based ads_blob_write utilities. Stress test was performed with this patch included to fix a legacy bug: https://patchwork.freedesktop.org/series/100768/ v6: - In patch #1, ADS reg-list population, we now alloc regular memory to create the lists and cache them for simpler and faster use by GuC ADS module at init, suspend-resume and reset cycles. This was in response to review comments from Lucas De Marchi that also wanted to ensure the GuC ADS module owns the final copying into the ADS phyical memory. - Thanks to Jani Nikula for pointing out that patch #2 and #3 should ensure static tables as constant and dynamic lists should be allocated and cached but attached to the GT level for the case of multiple cards with different fusings for steered registers. These are addressed now along with multiple code style fixups (thanks to review comment from Umesh) and splitting the steered register list generation as a seperate patch. - The extraction functionality, Patch #10 and #11 (was patch #7), has fixed all of Umesh's review comments related to the code styling. Additionally, it was discovered during stress tests that the extraction function could be called by the ct processing thread at the same time as the start of a GT reset event. Thus, a redesign was done whereby the linked list of processed capture-output-nodes are allocated up front and reused throughout the driver's life to ensure no memory locks are taken during extraction. - For patch #6 (now 7, 8 and 9), updates to intel_guc_log was split into smaller chunks and the log_state structure was returned back to inside of the intel_guc_log struct as opposed to the intel_guc struct in prior rev. This is in response to review comments by Matt Brost. - #Patch 13 (previously #10) is mostly identical but addresses all of the code styling comments reviews from Umesh. v5: - Added Gen9->Gen11 register list for CI coverage that included Gen9 with GuC submission. - Redesigned the extraction of the GuC error-capture dumps by grouping them into complete per-engine-reset nodes. Complete here means each node includes the global, engine-class and engine-instance register
[PATCH v12 09/13] drm/i915/guc: Check sizing of guc_capture output
Add intel_guc_capture_output_min_size_est function to
provide a reasonable minimum size for error-capture
region before allocating the shared buffer.
Signed-off-by: Alan Previn
Reviewed-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 48 +++
.../gpu/drm/i915/gt/uc/intel_guc_capture.h| 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 7 ++-
3 files changed, 55 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index f9612e45def6..413d1c2e84d1 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -663,6 +663,54 @@ intel_guc_capture_getnullheader(struct intel_guc *guc,
return 0;
}
+#define GUC_CAPTURE_OVERBUFFER_MULTIPLIER 3
+int
+intel_guc_capture_output_min_size_est(struct intel_guc *guc)
+{
+ struct intel_gt *gt = guc_to_gt(guc);
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+ int worst_min_size = 0, num_regs = 0;
+ size_t tmp = 0;
+
+ /*
+* If every single engine-instance suffered a failure in quick
succession but
+* were all unrelated, then a burst of multiple error-capture events
would dump
+* registers for every one engine instance, one at a time. In this
case, GuC
+* would even dump the global-registers repeatedly.
+*
+* For each engine instance, there would be 1 x
guc_state_capture_group_t output
+* followed by 3 x guc_state_capture_t lists. The latter is how the
register
+* dumps are split across different register types (where the '3' are
global vs class
+* vs instance). Finally, let's multiply the whole thing by 3x (just so
we are
+* not limited to just 1 round of data in a worst case full register
dump log)
+*
+* NOTE: intel_guc_log that allocates the log buffer would round this
size up to
+* a power of two.
+*/
+
+ for_each_engine(engine, gt, id) {
+ worst_min_size += sizeof(struct
guc_state_capture_group_header_t) +
+ (3 * sizeof(struct
guc_state_capture_header_t));
+
+ if (!intel_guc_capture_getlistsize(guc, 0,
GUC_CAPTURE_LIST_TYPE_GLOBAL, 0, &tmp))
+ num_regs += tmp;
+
+ if (!intel_guc_capture_getlistsize(guc, 0,
GUC_CAPTURE_LIST_TYPE_ENGINE_CLASS,
+ engine->class, &tmp)) {
+ num_regs += tmp;
+ }
+ if (!intel_guc_capture_getlistsize(guc, 0,
GUC_CAPTURE_LIST_TYPE_ENGINE_INSTANCE,
+ engine->class, &tmp)) {
+ num_regs += tmp;
+ }
+ }
+
+ worst_min_size += (num_regs * sizeof(struct guc_mmio_reg));
+
+ return (worst_min_size * GUC_CAPTURE_OVERBUFFER_MULTIPLIER);
+}
+
static void
guc_capture_free_ads_cache(struct intel_guc_state_capture *gc)
{
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.h
index 8de7704e12eb..540d72079462 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.h
@@ -11,6 +11,7 @@
struct guc_gt_system_info;
struct intel_guc;
+int intel_guc_capture_output_min_size_est(struct intel_guc *guc);
int intel_guc_capture_getlist(struct intel_guc *guc, u32 owner, u32 type, u32
classid,
void **outptr);
int intel_guc_capture_getlistsize(struct intel_guc *guc, u32 owner, u32 type,
u32 classid,
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
index fe4b2d3f305d..ed05b1a04f9c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
@@ -7,10 +7,11 @@
#include
#include "gt/intel_gt.h"
+#include "intel_guc_capture.h"
+#include "intel_guc_log.h"
#include "i915_drv.h"
#include "i915_irq.h"
#include "i915_memcpy.h"
-#include "intel_guc_log.h"
static void guc_log_copy_debuglogs_for_relay(struct intel_guc_log *log);
@@ -466,6 +467,10 @@ int intel_guc_log_create(struct intel_guc_log *log)
* | Capture logs |
* +===+ + CAPTURE_SIZE
*/
+ if (intel_guc_capture_output_min_size_est(guc) > CAPTURE_BUFFER_SIZE)
+ DRM_WARN("GuC log buffer for state_capture maybe too small. %d
< %d\n",
+CAPTURE_BUFFER_SIZE,
intel_guc_capture_output_min_size_est(guc));
+
guc_log_size = PAGE_SIZE + CRASH_BUFFER_SIZE + DEBUG_BUFFER_SIZE +
CAPTURE_BUFFER_SIZE;
--
2.25.1
[PATCH v12 07/13] drm/i915/guc: Update GuC-log relay function names
For the sake of better code readibility, change previous
relay logging function names with "capture_logs" to
"copy_debug_logs" to differentiate from error capture
functions that will use a different region of the same buffer.
Signed-off-by: Alan Previn
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 35 --
1 file changed, 19 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
index a24dc6441872..0d63c411080f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
@@ -12,7 +12,7 @@
#include "i915_memcpy.h"
#include "intel_guc_log.h"
-static void guc_log_capture_logs(struct intel_guc_log *log);
+static void guc_log_copy_debuglogs_for_relay(struct intel_guc_log *log);
/**
* DOC: GuC firmware log
@@ -198,7 +198,7 @@ static unsigned int guc_get_log_buffer_size(enum
guc_log_buffer_type type)
return 0;
}
-static void guc_read_update_log_buffer(struct intel_guc_log *log)
+static void _guc_log_copy_debuglogs_for_relay(struct intel_guc_log *log)
{
unsigned int buffer_size, read_offset, write_offset, bytes_to_copy,
full_cnt;
struct guc_log_buffer_state *log_buf_state, *log_buf_snapshot_state;
@@ -223,7 +223,7 @@ static void guc_read_update_log_buffer(struct intel_guc_log
*log)
* Used rate limited to avoid deluge of messages, logs might be
* getting consumed by User at a slow rate.
*/
- DRM_ERROR_RATELIMITED("no sub-buffer to capture logs\n");
+ DRM_ERROR_RATELIMITED("no sub-buffer to copy general logs\n");
log->relay.full_count++;
goto out_unlock;
@@ -301,15 +301,15 @@ static void guc_read_update_log_buffer(struct
intel_guc_log *log)
mutex_unlock(&log->relay.lock);
}
-static void capture_logs_work(struct work_struct *work)
+static void copy_debug_logs_work(struct work_struct *work)
{
struct intel_guc_log *log =
container_of(work, struct intel_guc_log, relay.flush_work);
- guc_log_capture_logs(log);
+ guc_log_copy_debuglogs_for_relay(log);
}
-static int guc_log_map(struct intel_guc_log *log)
+static int guc_log_relay_map(struct intel_guc_log *log)
{
void *vaddr;
@@ -332,7 +332,7 @@ static int guc_log_map(struct intel_guc_log *log)
return 0;
}
-static void guc_log_unmap(struct intel_guc_log *log)
+static void guc_log_relay_unmap(struct intel_guc_log *log)
{
lockdep_assert_held(&log->relay.lock);
@@ -343,7 +343,7 @@ static void guc_log_unmap(struct intel_guc_log *log)
void intel_guc_log_init_early(struct intel_guc_log *log)
{
mutex_init(&log->relay.lock);
- INIT_WORK(&log->relay.flush_work, capture_logs_work);
+ INIT_WORK(&log->relay.flush_work, copy_debug_logs_work);
log->relay.started = false;
}
@@ -358,8 +358,11 @@ static int guc_log_relay_create(struct intel_guc_log *log)
lockdep_assert_held(&log->relay.lock);
GEM_BUG_ON(!log->vma);
-/* Keep the size of sub buffers same as shared log buffer */
- subbuf_size = log->vma->size;
+/*
+ * Keep the size of sub buffers same as shared log buffer
+ * but GuC log-events excludes the error-state-capture logs
+ */
+ subbuf_size = log->vma->size - CAPTURE_BUFFER_SIZE;
/*
* Store up to 8 snapshots, which is large enough to buffer sufficient
@@ -394,13 +397,13 @@ static void guc_log_relay_destroy(struct intel_guc_log
*log)
log->relay.channel = NULL;
}
-static void guc_log_capture_logs(struct intel_guc_log *log)
+static void guc_log_copy_debuglogs_for_relay(struct intel_guc_log *log)
{
struct intel_guc *guc = log_to_guc(log);
struct drm_i915_private *dev_priv = guc_to_gt(guc)->i915;
intel_wakeref_t wakeref;
- guc_read_update_log_buffer(log);
+ _guc_log_copy_debuglogs_for_relay(log);
/*
* Generally device is expected to be active only at this
@@ -566,7 +569,7 @@ int intel_guc_log_relay_open(struct intel_guc_log *log)
if (ret)
goto out_unlock;
- ret = guc_log_map(log);
+ ret = guc_log_relay_map(log);
if (ret)
goto out_relay;
@@ -616,8 +619,8 @@ void intel_guc_log_relay_flush(struct intel_guc_log *log)
with_intel_runtime_pm(guc_to_gt(guc)->uncore->rpm, wakeref)
guc_action_flush_log(guc);
- /* GuC would have updated log buffer by now, so capture it */
- guc_log_capture_logs(log);
+ /* GuC would have updated log buffer by now, so copy it */
+ guc_log_copy_debuglogs_for_relay(log);
}
/*
@@ -646,7 +649,7 @@ void intel_guc_log_relay_close(struct intel_guc_log *log)
mutex_lock(&log->relay.lock);
GEM_BUG_ON(!intel_guc_log_relay_created(log));
- guc_l
[PATCH v12 03/13] drm/i915/guc: Add XE_LP steered register lists support
Add the ability for runtime allocation and freeing of
steered register list extentions that depend on the
detected HW config fuses.
Signed-off-by: Alan Previn
Reviewed-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h | 9 +
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 176 --
2 files changed, 174 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
b/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
index 919ed985f09a..6c199433945d 100644
--- a/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
@@ -52,6 +52,7 @@ struct __guc_mmio_reg_descr_group {
u32 owner; /* see enum guc_capture_owner */
u32 type; /* see enum guc_capture_type */
u32 engine; /* as per MAX_ENGINE_CLASS */
+ struct __guc_mmio_reg_descr *extlist; /* only used for steered
registers */
};
/**
@@ -79,6 +80,14 @@ struct intel_guc_state_capture {
*/
const struct __guc_mmio_reg_descr_group *reglists;
+ /**
+* @extlists: allocated table of steered register lists used for
error-capture state.
+*
+* NOTE: steered registers have multiple instances depending on the HW
configuration
+* (slices or dual-sub-slices) and thus depends on HW fuses discovered
at startup
+*/
+ struct __guc_mmio_reg_descr_group *extlists;
+
/**
* @ads_cache: cached register lists that is ADS format ready
*/
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index 6152a23289e3..0f2b47139140 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -133,6 +133,7 @@ static const struct __guc_mmio_reg_descr empty_regs_list[]
= {
TO_GCAP_DEF_OWNER(regsowner), \
TO_GCAP_DEF_TYPE(regstype), \
class, \
+ NULL, \
}
/* List of lists */
@@ -150,28 +151,33 @@ static const struct __guc_mmio_reg_descr_group
xe_lpd_lists[] = {
};
static const struct __guc_mmio_reg_descr_group *
-guc_capture_get_device_reglist(struct intel_guc *guc)
+guc_capture_get_one_list(const struct __guc_mmio_reg_descr_group *reglists,
+u32 owner, u32 type, u32 id)
{
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+ int i;
- if (IS_TIGERLAKE(i915) || IS_ROCKETLAKE(i915) ||
- IS_ALDERLAKE_S(i915) || IS_ALDERLAKE_P(i915)) {
- return xe_lpd_lists;
+ if (!reglists)
+ return NULL;
+
+ for (i = 0; reglists[i].list; ++i) {
+ if (reglists[i].owner == owner && reglists[i].type == type &&
+ (reglists[i].engine == id || reglists[i].type ==
GUC_CAPTURE_LIST_TYPE_GLOBAL))
+ return ®lists[i];
}
return NULL;
}
-static const struct __guc_mmio_reg_descr_group *
-guc_capture_get_one_list(const struct __guc_mmio_reg_descr_group *reglists,
-u32 owner, u32 type, u32 id)
+static struct __guc_mmio_reg_descr_group *
+guc_capture_get_one_ext_list(struct __guc_mmio_reg_descr_group *reglists,
+u32 owner, u32 type, u32 id)
{
int i;
if (!reglists)
return NULL;
- for (i = 0; reglists[i].list; ++i) {
+ for (i = 0; reglists[i].extlist; ++i) {
if (reglists[i].owner == owner && reglists[i].type == type &&
(reglists[i].engine == id || reglists[i].type ==
GUC_CAPTURE_LIST_TYPE_GLOBAL))
return ®lists[i];
@@ -180,6 +186,127 @@ guc_capture_get_one_list(const struct
__guc_mmio_reg_descr_group *reglists,
return NULL;
}
+static void guc_capture_free_extlists(struct __guc_mmio_reg_descr_group
*reglists)
+{
+ int i = 0;
+
+ if (!reglists)
+ return;
+
+ while (reglists[i].extlist)
+ kfree(reglists[i++].extlist);
+}
+
+struct __ext_steer_reg {
+ const char *name;
+ i915_reg_t reg;
+};
+
+static const struct __ext_steer_reg xe_extregs[] = {
+ {"GEN7_SAMPLER_INSTDONE", GEN7_SAMPLER_INSTDONE},
+ {"GEN7_ROW_INSTDONE", GEN7_ROW_INSTDONE}
+};
+
+static void __fill_ext_reg(struct __guc_mmio_reg_descr *ext,
+ const struct __ext_steer_reg *extlist,
+ int slice_id, int subslice_id)
+{
+ ext->reg = extlist->reg;
+ ext->flags = FIELD_PREP(GUC_REGSET_STEERING_GROUP, slice_id);
+ ext->flags |= FIELD_PREP(GUC_REGSET_STEERING_INSTANCE, subslice_id);
+ ext->regname = extlist->name;
+}
+
+static int
+__alloc_ext_regs(struct __guc_mmio_reg_descr_group *newlist,
+const struct __guc_mmio_reg_descr_group *rootlist, int
num_regs)
+{
+ struct __guc_mmio_reg_descr *list;
+
+ list = kcalloc(num_regs, sizeof(struct __gu
[PATCH v12 02/13] drm/i915/guc: Add XE_LP static registers for GuC error capture.
Add device specific tables and register lists to cover different engines
class types for GuC error state capture for XE_LP products.
Signed-off-by: Alan Previn
Reviewed-by: Umesh Nerlige Ramappa
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 116 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 6 +-
2 files changed, 97 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index ebae0943f0a0..6152a23289e3 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -19,43 +19,109 @@
/*
* Define all device tables of GuC error capture register lists
- * NOTE: For engine-registers, GuC only needs the register offsets
- * from the engine-mmio-base
+ * NOTE1: For engine-registers, GuC only needs the register offsets
+ *from the engine-mmio-base
*/
+#define COMMON_GEN12BASE_GLOBAL() \
+ {GEN12_FAULT_TLB_DATA0,0, 0, "GEN12_FAULT_TLB_DATA0"}, \
+ {GEN12_FAULT_TLB_DATA1,0, 0, "GEN12_FAULT_TLB_DATA1"}, \
+ {FORCEWAKE_MT, 0, 0, "FORCEWAKE"}, \
+ {GEN12_AUX_ERR_DBG,0, 0, "AUX_ERR_DBG"}, \
+ {GEN12_GAM_DONE, 0, 0, "GAM_DONE"}, \
+ {GEN12_RING_FAULT_REG, 0, 0, "FAULT_REG"}
+
+#define COMMON_GEN12BASE_ENGINE_INSTANCE() \
+ {RING_PSMI_CTL(0), 0, 0, "RC PSMI"}, \
+ {RING_ESR(0), 0, 0, "ESR"}, \
+ {RING_DMA_FADD(0), 0, 0, "RING_DMA_FADD_LDW"}, \
+ {RING_DMA_FADD_UDW(0), 0, 0, "RING_DMA_FADD_UDW"}, \
+ {RING_IPEIR(0),0, 0, "IPEIR"}, \
+ {RING_IPEHR(0),0, 0, "IPEHR"}, \
+ {RING_INSTPS(0), 0, 0, "INSTPS"}, \
+ {RING_BBADDR(0), 0, 0, "RING_BBADDR_LOW32"}, \
+ {RING_BBADDR_UDW(0), 0, 0, "RING_BBADDR_UP32"}, \
+ {RING_BBSTATE(0), 0, 0, "BB_STATE"}, \
+ {CCID(0), 0, 0, "CCID"}, \
+ {RING_ACTHD(0),0, 0, "ACTHD_LDW"}, \
+ {RING_ACTHD_UDW(0),0, 0, "ACTHD_UDW"}, \
+ {RING_INSTPM(0), 0, 0, "INSTPM"}, \
+ {RING_INSTDONE(0), 0, 0, "INSTDONE"}, \
+ {RING_NOPID(0),0, 0, "RING_NOPID"}, \
+ {RING_START(0),0, 0, "START"}, \
+ {RING_HEAD(0), 0, 0, "HEAD"}, \
+ {RING_TAIL(0), 0, 0, "TAIL"}, \
+ {RING_CTL(0), 0, 0, "CTL"}, \
+ {RING_MI_MODE(0), 0, 0, "MODE"}, \
+ {RING_CONTEXT_CONTROL(0), 0, 0, "RING_CONTEXT_CONTROL"}, \
+ {RING_HWS_PGA(0), 0, 0, "HWS"}, \
+ {RING_MODE_GEN7(0),0, 0, "GFX_MODE"}, \
+ {GEN8_RING_PDP_LDW(0, 0), 0, 0, "PDP0_LDW"}, \
+ {GEN8_RING_PDP_UDW(0, 0), 0, 0, "PDP0_UDW"}, \
+ {GEN8_RING_PDP_LDW(0, 1), 0, 0, "PDP1_LDW"}, \
+ {GEN8_RING_PDP_UDW(0, 1), 0, 0, "PDP1_UDW"}, \
+ {GEN8_RING_PDP_LDW(0, 2), 0, 0, "PDP2_LDW"}, \
+ {GEN8_RING_PDP_UDW(0, 2), 0, 0, "PDP2_UDW"}, \
+ {GEN8_RING_PDP_LDW(0, 3), 0, 0, "PDP3_LDW"}, \
+ {GEN8_RING_PDP_UDW(0, 3), 0, 0, "PDP3_UDW"}
+
+#define COMMON_GEN12BASE_HAS_EU() \
+ {EIR, 0, 0, "EIR"}
+
+#define COMMON_GEN12BASE_RENDER() \
+ {GEN7_SC_INSTDONE, 0, 0, "GEN7_SC_INSTDONE"}, \
+ {GEN12_SC_INSTDONE_EXTRA, 0, 0, "GEN12_SC_INSTDONE_EXTRA"}, \
+ {GEN12_SC_INSTDONE_EXTRA2, 0, 0, "GEN12_SC_INSTDONE_EXTRA2"}
+
+#define COMMON_GEN12BASE_VEC() \
+ {GEN12_SFC_DONE(0),0, 0, "SFC_DONE[0]"}, \
+ {GEN12_SFC_DONE(1),0, 0, "SFC_DONE[1]"}, \
+ {GEN12_SFC_DONE(2),0, 0, "SFC_DONE[2]"}, \
+ {GEN12_SFC_DONE(3),0, 0, "SFC_DONE[3]"}
+
/* XE_LPD - Global */
static const struct __guc_mmio_reg_descr xe_lpd_global_regs[] = {
- {GEN12_RING_FAULT_REG, 0, 0, "GEN12_RING_FAULT_REG"}
+ COMMON_GEN12BASE_GLOBAL(),
};
/* XE_LPD - Render / Compute Per-Class */
static const struct __guc_mmio_reg_descr xe_lpd_rc_class_regs[] = {
- {EIR, 0, 0, "EIR"}
+ COMMON_GEN12BASE_HAS_EU(),
+ COMMON_GEN12BASE_RENDER(),
};
/* XE_LPD - Render / Compute Per-Engine-Instance */
static const struct __guc_mmio_reg_descr xe_lpd_rc_inst_regs[] = {
- {RING_HEAD(0), 0, 0, "RING_HEAD"},
- {RING_TAIL(0), 0, 0, "RING_TAIL"},
+ COMMON_GEN12BASE_ENGINE_INSTANCE(),
};
/* XE_LPD - Media Decode/Encode Per-Class */
static const struct __guc_mmio_reg_descr xe_lpd_vd_class_regs[] = {
+ COMMON_GEN12BASE_ENGINE_INSTANCE(),
};
/* XE_LPD - Media Decode/Encode Per-Engine-Instance */
static const struct __g
[PATCH v12 10/13] drm/i915/guc: Extract GuC error capture lists on G2H notification.
- Upon the G2H Notify-Err-Capture event, parse through the
GuC Log Buffer (error-capture-subregion) and generate one or
more capture-nodes. A single node represents a single "engine-
instance-capture-dump" and contains at least 3 register lists:
global, engine-class and engine-instance. An internal link
list is maintained to store one or more nodes.
- Because the link-list node generation happen before the call
to i915_gpu_codedump, duplicate global and engine-class register
lists for each engine-instance register dump if we find
dependent-engine resets in a engine-capture-group.
- When i915_gpu_coredump calls into capture_engine, (in a
subsequent patch) we detach the matching node (guc-id,
LRCA, etc) from the link list above and attach it to
i915_gpu_coredump's intel_engine_coredump structure when have
matching LRCA/guc-id/engine-instance.
Additional notes to be aware of:
- GuC generates the error capture dump into the GuC log buffer but
this buffer is one big log buffer with 3 independent subregions
within it. Each subregion is populated with different content
and used in different ways and timings but all regions operate
behave as independent ring buffers. Each guc-log subregion
(general-logs, crash-dump and error- capture) has it's own
guc_log_buffer_state that contain independent read and write
pointers.
Signed-off-by: Alan Previn
Reviewed-by: Umesh Nerlige Ramappa
---
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 7 +
drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h | 56 ++
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 561 +-
.../gpu/drm/i915/gt/uc/intel_guc_capture.h| 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 26 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_log.h| 4 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 10 +-
7 files changed, 652 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
index f9b3dd146a7e..9ad6df1b6fbc 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
@@ -172,4 +172,11 @@ enum intel_guc_sleep_state_status {
#define GUC_LOG_CONTROL_VERBOSITY_MASK (0xF << GUC_LOG_CONTROL_VERBOSITY_SHIFT)
#define GUC_LOG_CONTROL_DEFAULT_LOGGING(1 << 8)
+enum intel_guc_state_capture_event_status {
+ INTEL_GUC_STATE_CAPTURE_EVENT_STATUS_SUCCESS = 0x0,
+ INTEL_GUC_STATE_CAPTURE_EVENT_STATUS_NOSPACE = 0x1,
+};
+
+#define INTEL_GUC_STATE_CAPTURE_EVENT_STATUS_MASK 0x00FF
+
#endif /* _ABI_GUC_ACTIONS_ABI_H */
diff --git a/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
b/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
index 8824c5eba355..5d959e62d146 100644
--- a/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
@@ -12,6 +12,52 @@
struct intel_guc;
struct file;
+/**
+ * struct __guc_capture_bufstate
+ *
+ * Book-keeping structure used to track read and write pointers
+ * as we extract error capture data from the GuC-log-buffer's
+ * error-capture region as a stream of dwords.
+ */
+struct __guc_capture_bufstate {
+ u32 size;
+ void *data;
+ u32 rd;
+ u32 wr;
+};
+
+/**
+ * struct __guc_capture_parsed_output - extracted error capture node
+ *
+ * A single unit of extracted error-capture output data grouped together
+ * at an engine-instance level. We keep these nodes in a linked list.
+ * See outlist below.
+ */
+struct __guc_capture_parsed_output {
+ /*
+* A single set of 3 capture lists: a global-list
+* an engine-class-list and an engine-instance list.
+* outlist in __guc_capture_parsed_output will keep
+* a linked list of these nodes that will eventually
+* be detached from outlist and attached into to
+* i915_gpu_codedump in response to a context reset
+*/
+ struct list_head link;
+ bool is_partial;
+ u32 eng_class;
+ u32 eng_inst;
+ u32 guc_id;
+ u32 lrca;
+ struct gcap_reg_list_info {
+ u32 vfid;
+ u32 num_regs;
+ struct guc_mmio_reg *regs;
+ } reginfo[GUC_CAPTURE_LIST_TYPE_MAX];
+#define GCAP_PARSED_REGLIST_INDEX_GLOBAL BIT(GUC_CAPTURE_LIST_TYPE_GLOBAL)
+#define GCAP_PARSED_REGLIST_INDEX_ENGCLASS
BIT(GUC_CAPTURE_LIST_TYPE_ENGINE_CLASS)
+#define GCAP_PARSED_REGLIST_INDEX_ENGINST
BIT(GUC_CAPTURE_LIST_TYPE_ENGINE_INSTANCE)
+};
+
/**
* struct guc_debug_capture_list_header / struct guc_debug_capture_list
*
@@ -142,6 +188,16 @@ struct intel_guc_state_capture {
[GUC_CAPTURE_LIST_TYPE_MAX]
[GUC_MAX_ENGINE_CLASSES];
void *ads_null_cache;
+
+ /**
+* @outlist: allocated nodes with parsed engine-instance error capture
data
+*
+* A linked list of parsed GuC error-captur
[PATCH v12 13/13] drm/i915/guc: Print the GuC error capture output register list.
Print the GuC captured error state register list (string names
and values) when gpu_coredump_state printout is invoked via
the i915 debugfs for flushing the gpu error-state that was
captured prior.
Since GuC could have reported multiple engine register dumps
in a single notification event, parse the captured data
(appearing as a stream of structures) to identify each dump as
a different 'engine-capture-group-output'.
Finally, for each 'engine-capture-group-output' that is found,
verify if the engine register dump corresponds to the
engine_coredump content that was previously populated by the
i915_gpu_coredump function. That function would have copied
the context's vma's including the bacth buffer during the
G2H-context-reset notification that occurred earlier. Perform
this verification check by comparing guc_id, lrca and engine-
instance obtained from the 'engine-capture-group-output' vs a
copy of that same info taken during i915_gpu_coredump. If
they match, then print those vma's as well (such as the batch
buffers).
NOTE: the output format was verified using the gem_exec_capture
IGT test.
Signed-off-by: Alan Previn
Reviewed-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 +-
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 3 +
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 161 ++
.../gpu/drm/i915/gt/uc/intel_guc_capture.h| 2 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 6 +-
drivers/gpu/drm/i915/i915_debugfs.c | 1 +
drivers/gpu/drm/i915/i915_gpu_error.c | 16 +-
drivers/gpu/drm/i915/i915_gpu_error.h | 5 +
8 files changed, 183 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 8080479f27aa..151861afc4d2 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1702,9 +1702,7 @@ static void intel_engine_print_registers(struct
intel_engine_cs *engine,
drm_printf(m, "\tIPEHR: 0x%08x\n", ENGINE_READ(engine, IPEHR));
}
- if (intel_engine_uses_guc(engine)) {
- /* nothing to print yet */
- } else if (HAS_EXECLISTS(dev_priv)) {
+ if (HAS_EXECLISTS(dev_priv) && !intel_engine_uses_guc(engine)) {
struct i915_request * const *port, *rq;
const u32 *hws =
&engine->status_page.addr[I915_HWS_CSB_BUF0_INDEX];
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index de32367831c6..4e431c14b118 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -438,6 +438,9 @@ int intel_guc_engine_failure_process_msg(struct intel_guc
*guc,
int intel_guc_error_capture_process_msg(struct intel_guc *guc,
const u32 *msg, u32 len);
+struct intel_engine_cs *
+intel_guc_lookup_engine(struct intel_guc *guc, u8 guc_class, u8 instance);
+
void intel_guc_find_hung_context(struct intel_engine_cs *engine);
int intel_guc_global_policies_update(struct intel_guc *guc);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index 8f6031782d20..0a55871dad82 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -767,6 +767,21 @@ intel_guc_capture_output_min_size_est(struct intel_guc
*guc)
*intel_engine_coredump struct (if the
context and
*engine of the event notification matches
a node
*in the link list).
+ *
+ * User Sysfs / Debugfs
+ *
+ * --> i915_gpu_coredump_copy_to_buffer->
+ * L--> err_print_to_sgl --> err_print_gt
+ *L--> error_print_guc_captures
+ * L--> intel_guc_capture_print_node prints the
+ * register lists values of the attached node
+ * on the error-engine-dump being reported.
+ * L--> i915_reset_error_state ...
-->__i915_gpu_coredump_free
+ *L--> ... cleanup_gt -->
+ * L--> intel_guc_capture_free_node returns the
+ * capture-output-node back to the internal
+ * cachelist for reuse.
+ *
*/
static int guc_capture_buf_cnt(struct __guc_capture_bufstate *buf)
@@ -1384,9 +1399,155 @@ static void __guc_capture_process_output(struct
intel_guc *guc)
#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
+static const char *
+guc_capture_reg_to_str(const struct intel_guc *guc, u32 owner, u32 type,
+ u32 class, u32 id, u32 offset, u32 *is_ext)
+{
+ const struct __guc_mmio_reg_descr_group *reglists =
guc->capture
[PATCH v12 11/13] drm/i915/guc: Pre-allocate output nodes for extraction
In the rare but possible scenario where we are in the midst of
multiple GuC error-capture (and engine reset) events and the
user also triggers a forced full GT reset or the internal watchdog
triggers the same, intel_guc_submission_reset_prepare's call
to flush_work(&guc->ct.requests.worker) can cause the G2H message
handler to trigger intel_guc_capture_store_snapshot upon
receiving new G2H error-capture notifications. This can happen
despite the prior call to disable_submission(guc);. However,
there's no race-free way for intel_guc_capture_store_snapshot to
know that we are in the midst of a reset. That said, we can never
dynamically allocate the output nodes in this handler. Thus, we
shall pre-allocate a fixed number of empty nodes up front (at the
time of ADS registration) that we can consume from or return to
an internal cached list of nodes.
Signed-off-by: Alan Previn
Reviewed-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h | 19 +-
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 177 ++
2 files changed, 161 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
b/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
index 5d959e62d146..3624abfd22d1 100644
--- a/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
@@ -31,7 +31,7 @@ struct __guc_capture_bufstate {
*
* A single unit of extracted error-capture output data grouped together
* at an engine-instance level. We keep these nodes in a linked list.
- * See outlist below.
+ * See cachelist and outlist below.
*/
struct __guc_capture_parsed_output {
/*
@@ -190,7 +190,22 @@ struct intel_guc_state_capture {
void *ads_null_cache;
/**
-* @outlist: allocated nodes with parsed engine-instance error capture
data
+* @cachelist: Pool of pre-allocated nodes for error capture output
+*
+* We need this pool of pre-allocated nodes because we cannot
+* dynamically allocate new nodes when receiving the G2H notification
+* because the event handlers for all G2H event-processing is called
+* by the ct processing worker queue and when that queue is being
+* processed, there is no absoluate guarantee that we are not in the
+* midst of a GT reset operation (which doesn't allow allocations).
+*/
+ struct list_head cachelist;
+#define PREALLOC_NODES_MAX_COUNT (3 * GUC_MAX_ENGINE_CLASSES *
GUC_MAX_INSTANCES_PER_CLASS)
+#define PREALLOC_NODES_DEFAULT_NUMREGS 64
+ int max_mmio_per_node;
+
+ /**
+* @outlist: Pool of pre-allocated nodes for error capture output
*
* A linked list of parsed GuC error-capture output data before
* reporting with formatting via i915_gpu_coredump. Each node in this
linked list shall
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index 776221d525fd..0f3852591096 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -581,6 +581,8 @@ intel_guc_capture_getlistsize(struct intel_guc *guc, u32
owner, u32 type, u32 cl
return 0;
}
+static void guc_capture_create_prealloc_nodes(struct intel_guc *guc);
+
int
intel_guc_capture_getlist(struct intel_guc *guc, u32 owner, u32 type, u32
classid,
void **outptr)
@@ -601,6 +603,12 @@ intel_guc_capture_getlist(struct intel_guc *guc, u32
owner, u32 type, u32 classi
return cache->status;
}
+ /*
+* ADS population of input registers is a good
+* time to pre-allocate cachelist output nodes
+*/
+ guc_capture_create_prealloc_nodes(guc);
+
ret = intel_guc_capture_getlistsize(guc, owner, type, classid, &size);
if (ret) {
cache->is_valid = true;
@@ -741,7 +749,8 @@ intel_guc_capture_output_min_size_est(struct intel_guc *guc)
*err-state-captured register-list we find, we
alloc 'C':
* --> alloc C: A capture-output-node structure that includes misc
capture info along
* with 3 register list dumps (global, engine-class and
engine-instance)
- * This node is dynamically allocated and populated with the
error-capture
+ * This node is created from a pre-allocated list of blank
nodes in
+ * guc->capture->cachelist and populated with the
error-capture
* data from GuC and then it's added into
guc->capture->outlist linked
* list. This list is used for matchup and printout by
i915_gpu_coredump
* and err_print_gt, (when user invokes the error capture
sysfs).
@@ -901,19 +910,20 @@ guc_capture_delete_one_node(struct intel_guc *guc, struct
__guc_capture_parsed_o
}
static void
-guc_capture_delete_nodes(struct intel_guc
[PATCH v12 12/13] drm/i915/guc: Plumb GuC-capture into gpu_coredump
Add a flags parameter through all of the coredump creation
functions. Add a bitmask flag to indicate if the top
level gpu_coredump event is triggered in response to
a GuC context reset notification.
Using that flag, ensure all coredump functions that
read or print mmio-register values related to work submission
or command-streamer engines are skipped and replaced with
a calls guc-capture module equivalent functions to retrieve
or print the register dump.
While here, split out display related register reading
and printing into its own function that is called agnostic
to whether GuC had triggered the reset.
For now, introduce an empty printing function that can
filled in on a subsequent patch just to handle formatting.
Signed-off-by: Alan Previn
Reviewed-by: Umesh Nerlige Ramappa
---
.../drm/i915/gt/intel_execlists_submission.c | 4 +-
drivers/gpu/drm/i915/gt/intel_reset.c | 2 +-
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 70 +
.../gpu/drm/i915/gt/uc/intel_guc_capture.h| 9 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +-
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 266 --
drivers/gpu/drm/i915/i915_gpu_error.h | 30 +-
8 files changed, 288 insertions(+), 97 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index e1470bb60f34..738c120490fc 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -2236,11 +2236,11 @@ static struct execlists_capture *capture_regs(struct
intel_engine_cs *engine)
if (!cap->error)
goto err_cap;
- cap->error->gt = intel_gt_coredump_alloc(engine->gt, gfp);
+ cap->error->gt = intel_gt_coredump_alloc(engine->gt, gfp,
CORE_DUMP_FLAG_NONE);
if (!cap->error->gt)
goto err_gpu;
- cap->error->gt->engine = intel_engine_coredump_alloc(engine, gfp);
+ cap->error->gt->engine = intel_engine_coredump_alloc(engine, gfp,
CORE_DUMP_FLAG_NONE);
if (!cap->error->gt->engine)
goto err_gt;
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index a6ae213c7d89..f52015e79fdf 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -1319,7 +1319,7 @@ void intel_gt_handle_error(struct intel_gt *gt,
engine_mask &= gt->info.engine_mask;
if (flags & I915_ERROR_CAPTURE) {
- i915_capture_error_state(gt, engine_mask);
+ i915_capture_error_state(gt, engine_mask, CORE_DUMP_FLAG_NONE);
intel_gt_clear_error_registers(gt, engine_mask);
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index 0f3852591096..8f6031782d20 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -10,6 +10,7 @@
#include "gt/intel_engine_regs.h"
#include "gt/intel_gt.h"
#include "gt/intel_gt_regs.h"
+#include "gt/intel_lrc.h"
#include "guc_capture_fwif.h"
#include "intel_guc_capture.h"
#include "intel_guc_fwif.h"
@@ -754,6 +755,18 @@ intel_guc_capture_output_min_size_est(struct intel_guc
*guc)
* data from GuC and then it's added into
guc->capture->outlist linked
* list. This list is used for matchup and printout by
i915_gpu_coredump
* and err_print_gt, (when user invokes the error capture
sysfs).
+ *
+ * GUC --> notify context reset:
+ * -
+ * --> G2H CONTEXT RESET
+ * L--> guc_handle_context_reset --> i915_capture_error_state
+ * L--> i915_gpu_coredump(..IS_GUC_CAPTURE) -->
gt_record_engines
+ * --> capture_engine(..IS_GUC_CAPTURE)
+ * L--> intel_guc_capture_get_matching_node is
where
+ *detach C from internal linked list and
add it into
+ *intel_engine_coredump struct (if the
context and
+ *engine of the event notification matches
a node
+ *in the link list).
*/
static int guc_capture_buf_cnt(struct __guc_capture_bufstate *buf)
@@ -1369,6 +1382,63 @@ static void __guc_capture_process_output(struct
intel_guc *guc)
__guc_capture_flushlog_complete(guc);
}
+#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
+
+int intel_guc_capture_print_engine_node(struct drm_i915_error_state_buf *ebuf,
+ const struct intel_engine_coredump *ee)
+{
+ return 0;
+}
+
+#endif //CONFIG_DRM_I915_CAPTURE_ERROR
+
+void intel_guc_capture_free_node(struct intel_engine_coredump *ee)
+{
+ if (!ee || !ee->guc_ca
Re: [PATCH] drm/amd/display: Fixed the unused-but-set-variable warning
Dear Aashish,
Am 17.03.22 um 15:01 schrieb Aashish Sharma:
Thank you for your patch. If you are going to send a v2, please use
imperative mood. Maybe:
drm/amd/display: Fix unused-but-set-variable warning
Fixed this kernel test robot warning:
Maybe:
Fix the kernel test robot warning below:
drivers/gpu/drm/amd/amdgpu/../display/dmub/inc/dmub_cmd.h:2893:12:
warning: variable 'temp' set but not used [-Wunused-but-set-variable]
Replaced the assignment to the unused temp variable with READ_ONCE()
macro to flush the writes.
Replace …
Excuse my ignorance regarding `READ_ONCE()`, but is that the reason you
remove the volatile qualifier?
Some robots ask in their report to add a Found-by tag. If so, please add
one.
Signed-off-by: Aashish Sharma
---
drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h
b/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h
index 873ecd04e01d..b7981a781701 100644
--- a/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h
+++ b/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h
@@ -2913,13 +2913,12 @@ static inline void dmub_rb_flush_pending(const struct
dmub_rb *rb)
uint32_t wptr = rb->wrpt;
while (rptr != wptr) {
- uint64_t volatile *data = (uint64_t volatile *)((uint8_t
*)(rb->base_address) + rptr);
+ uint64_t *data = (uint64_t volatile *)((uint8_t
*)(rb->base_address) + rptr);
//uint64_t volatile *p = (uint64_t volatile *)data;
- uint64_t temp;
uint8_t i;
for (i = 0; i < DMUB_RB_CMD_SIZE / sizeof(uint64_t); i++)
- temp = *data++;
+ (void)READ_ONCE(*data++);
Did you verify, that the generated code is the same now, or what the
differences are. If it’s different from before, you should document in
the commit message, that it’s wanted, as otherwise, it’s an invasive
change just to fix a warning.
rptr += DMUB_RB_CMD_SIZE;
if (rptr >= rb->capacity)
Kind regards,
Paul
[PATCH] drm/i915: avoid concurrent writes to aux_inv
From: Fei Yang
GPU hangs have been observed when multiple engines write to the
same aux_inv register at the same time. To avoid this each engine
should only invalidate its own auxiliary table. The function
gen12_emit_flush_xcs() currently invalidate the auxiliary table for
all engines because the rq->engine is not necessarily the engine
eventually carrying out the request, and potentially the engine
could even be a virtual one (with engine->instance being -1).
With the MMIO remap feature, we can actually set bit 17 of MI_LRI
instruction and let the hardware to figure out the local aux_inv
register at runtime to avoid invalidating auxiliary table for all
engines.
Bspec: 45728
Cc: Stuart Summers
Cc: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Signed-off-by: Fei Yang
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 42 +---
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 1 +
2 files changed, 11 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 36148887c699..d440c5dfb6b7 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -165,30 +165,6 @@ static u32 preparser_disable(bool state)
return MI_ARB_CHECK | 1 << 8 | state;
}
-static i915_reg_t aux_inv_reg(const struct intel_engine_cs *engine)
-{
- static const i915_reg_t vd[] = {
- GEN12_VD0_AUX_NV,
- GEN12_VD1_AUX_NV,
- GEN12_VD2_AUX_NV,
- GEN12_VD3_AUX_NV,
- };
-
- static const i915_reg_t ve[] = {
- GEN12_VE0_AUX_NV,
- GEN12_VE1_AUX_NV,
- };
-
- if (engine->class == VIDEO_DECODE_CLASS)
- return vd[engine->instance];
-
- if (engine->class == VIDEO_ENHANCEMENT_CLASS)
- return ve[engine->instance];
-
- GEM_BUG_ON("unknown aux_inv reg\n");
- return INVALID_MMIO_REG;
-}
-
static u32 *gen12_emit_aux_table_inv(const i915_reg_t inv_reg, u32 *cs)
{
*cs++ = MI_LOAD_REGISTER_IMM(1);
@@ -296,7 +272,7 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
if (!HAS_FLAT_CCS(rq->engine->i915)) {
aux_inv = rq->engine->mask & ~BIT(BCS0);
if (aux_inv)
- cmd += 2 * hweight32(aux_inv) + 2;
+ cmd += 4;
}
}
@@ -329,14 +305,16 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32
mode)
*cs++ = 0; /* value */
if (aux_inv) { /* hsdes: 1809175790 */
- struct intel_engine_cs *engine;
- unsigned int tmp;
-
- *cs++ = MI_LOAD_REGISTER_IMM(hweight32(aux_inv));
- for_each_engine_masked(engine, rq->engine->gt, aux_inv, tmp) {
- *cs++ = i915_mmio_reg_offset(aux_inv_reg(engine));
- *cs++ = AUX_INV;
+ *cs++ = MI_LOAD_REGISTER_IMM(1) | MI_LRI_MMIO_REMAP_EN;
+ if (rq->engine->class == VIDEO_DECODE_CLASS) {
+ *cs++ = i915_mmio_reg_offset(GEN12_VD0_AUX_NV);
+ } else if (rq->engine->class == VIDEO_ENHANCEMENT_CLASS) {
+ *cs++ = i915_mmio_reg_offset(GEN12_VE0_AUX_NV);
+ } else {
+ GEM_BUG_ON("unknown aux_inv reg\n");
+ *cs++ = i915_mmio_reg_offset(INVALID_MMIO_REG);
}
+ *cs++ = AUX_INV;
*cs++ = MI_NOOP;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index d112ffd56418..2d150eec5c65 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -144,6 +144,7 @@
#define MI_LOAD_REGISTER_IMM(x)MI_INSTR(0x22, 2*(x)-1)
/* Gen11+. addr = base + (ctx_restore ? offset & GENMASK(12,2) : offset) */
#define MI_LRI_LRM_CS_MMIO REG_BIT(19)
+#define MI_LRI_MMIO_REMAP_EN (1 << 17)
#define MI_LRI_FORCE_POSTED (1<<12)
#define MI_LOAD_REGISTER_IMM_MAX_REGS (126)
#define MI_STORE_REGISTER_MEMMI_INSTR(0x24, 1)
--
2.25.1
[PATCH] drm/i915: avoid concurrent writes to aux_inv
From: Fei Yang
GPU hangs have been observed when multiple engines write to the
same aux_inv register at the same time. To avoid this each engine
should only invalidate its own auxiliary table. The function
gen12_emit_flush_xcs() currently invalidate the auxiliary table for
all engines because the rq->engine is not necessarily the engine
eventually carrying out the request, and potentially the engine
could even be a virtual one (with engine->instance being -1).
With the MMIO remap feature, we can actually set bit 17 of MI_LRI
instruction and let the hardware to figure out the local aux_inv
register at runtime to avoid invalidating auxiliary table for all
engines.
Bspec: 45728
Cc: Stuart Summers
Cc: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Signed-off-by: Fei Yang
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 42 +---
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 1 +
2 files changed, 11 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 36148887c699..af5daaf934b5 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -165,30 +165,6 @@ static u32 preparser_disable(bool state)
return MI_ARB_CHECK | 1 << 8 | state;
}
-static i915_reg_t aux_inv_reg(const struct intel_engine_cs *engine)
-{
- static const i915_reg_t vd[] = {
- GEN12_VD0_AUX_NV,
- GEN12_VD1_AUX_NV,
- GEN12_VD2_AUX_NV,
- GEN12_VD3_AUX_NV,
- };
-
- static const i915_reg_t ve[] = {
- GEN12_VE0_AUX_NV,
- GEN12_VE1_AUX_NV,
- };
-
- if (engine->class == VIDEO_DECODE_CLASS)
- return vd[engine->instance];
-
- if (engine->class == VIDEO_ENHANCEMENT_CLASS)
- return ve[engine->instance];
-
- GEM_BUG_ON("unknown aux_inv reg\n");
- return INVALID_MMIO_REG;
-}
-
static u32 *gen12_emit_aux_table_inv(const i915_reg_t inv_reg, u32 *cs)
{
*cs++ = MI_LOAD_REGISTER_IMM(1);
@@ -296,7 +272,7 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
if (!HAS_FLAT_CCS(rq->engine->i915)) {
aux_inv = rq->engine->mask & ~BIT(BCS0);
if (aux_inv)
- cmd += 2 * hweight32(aux_inv) + 2;
+ cmd += 4;
}
}
@@ -329,14 +305,16 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32
mode)
*cs++ = 0; /* value */
if (aux_inv) { /* hsdes: 1809175790 */
- struct intel_engine_cs *engine;
- unsigned int tmp;
-
- *cs++ = MI_LOAD_REGISTER_IMM(hweight32(aux_inv));
- for_each_engine_masked(engine, rq->engine->gt, aux_inv, tmp) {
- *cs++ = i915_mmio_reg_offset(aux_inv_reg(engine));
- *cs++ = AUX_INV;
+ *cs++ = MI_LOAD_REGISTER_IMM(1) | MI_LRI_MMIO_REMAP_EN;
+ if (rq->engine->class == VIDEO_DECODE_CLASS)
+ *cs++ = i915_mmio_reg_offset(GEN12_VD0_AUX_NV);
+ else if (rq->engine->class == VIDEO_ENHANCEMENT_CLASS)
+ *cs++ = i915_mmio_reg_offset(GEN12_VE0_AUX_NV);
+ else {
+ GEM_BUG_ON("unknown aux_inv reg\n");
+ *cs++ = i915_mmio_reg_offset(INVALID_MMIO_REG);
}
+ *cs++ = AUX_INV;
*cs++ = MI_NOOP;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index d112ffd56418..54fdf1882cae 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -144,6 +144,7 @@
#define MI_LOAD_REGISTER_IMM(x)MI_INSTR(0x22, 2*(x)-1)
/* Gen11+. addr = base + (ctx_restore ? offset & GENMASK(12,2) : offset) */
#define MI_LRI_LRM_CS_MMIO REG_BIT(19)
+#define MI_LRI_MMIO_REMAP_EN (1<<17)
#define MI_LRI_FORCE_POSTED (1<<12)
#define MI_LOAD_REGISTER_IMM_MAX_REGS (126)
#define MI_STORE_REGISTER_MEMMI_INSTR(0x24, 1)
--
2.25.1
[git pull] drm fixes for 5.17-final
Hi Linus, A few minor changes to finish things off, one mgag200 regression, imx fix and couple of panel changes. Regards, Dave. drm-fixes-2022-03-18: drm fixes for 5.17-rc9/final imx: - Don't test bus flags in atomic check mgag200: - Fix PLL setup on some models panel: - Fix bpp settings on Innolux G070Y2-L01 - Fix DRM_PANEL_EDP Kconfig dependencies The following changes since commit 09688c0166e76ce2fb85e86b9d99be8b0084cdf9: Linux 5.17-rc8 (2022-03-13 13:23:37 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-03-18 for you to fetch changes up to ca5a5761ac542691a6b3520b6c5c047cf63b4b8d: Merge tag 'drm-misc-fixes-2022-03-17' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2022-03-18 13:32:54 +1000) drm fixes for 5.17-rc9/final imx: - Don't test bus flags in atomic check mgag200: - Fix PLL setup on some models panel: - Fix bpp settings on Innolux G070Y2-L01 - Fix DRM_PANEL_EDP Kconfig dependencies Christoph Niedermaier (1): drm/imx: parallel-display: Remove bus flags check in imx_pd_bridge_atomic_check() Dave Airlie (1): Merge tag 'drm-misc-fixes-2022-03-17' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Jocelyn Falempe (1): drm/mgag200: Fix PLL setup for g200wb and g200ew Marek Vasut (1): drm/panel: simple: Fix Innolux G070Y2-L01 BPP settings Thomas Zimmermann (2): Merge drm/drm-fixes into drm-misc-fixes drm: Don't make DRM_PANEL_BRIDGE dependent on DRM_KMS_HELPERS drivers/gpu/drm/bridge/Kconfig | 2 +- drivers/gpu/drm/imx/parallel-display.c | 8 drivers/gpu/drm/mgag200/mgag200_pll.c | 6 +++--- drivers/gpu/drm/panel/Kconfig | 1 + drivers/gpu/drm/panel/panel-simple.c | 2 +- 5 files changed, 6 insertions(+), 13 deletions(-)
Re: [Freedreno] [PATCH 3/3] drm/msm/gpu: Remove mutex from wait_event condition
On Thu, 17 Mar 2022 14:07:45 -0700 Rob Clark wrote:
> On Thu, Mar 17, 2022 at 1:45 PM Akhil P Oommen
> wrote:
> >
> > On 3/11/2022 5:16 AM, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > The mutex wasn't really protecting anything before. Before the previous
> > > patch we could still be racing with the scheduler's kthread, as that is
> > > not necessarily frozen yet. Now that we've parked the sched threads,
> > > the only race is with jobs retiring, and that is harmless, ie.
> > >
> > > Signed-off-by: Rob Clark
> > > ---
> > > drivers/gpu/drm/msm/adreno/adreno_device.c | 11 +--
> > > 1 file changed, 1 insertion(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
> > > b/drivers/gpu/drm/msm/adreno/adreno_device.c
> > > index 0440a98988fc..661dfa7681fb 100644
> > > --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> > > +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> > > @@ -607,15 +607,6 @@ static int adreno_runtime_resume(struct device *dev)
> > > return gpu->funcs->pm_resume(gpu);
> > > }
> > >
> > > -static int active_submits(struct msm_gpu *gpu)
> > > -{
> > > - int active_submits;
> > > - mutex_lock(&gpu->active_lock);
> > > - active_submits = gpu->active_submits;
> > > - mutex_unlock(&gpu->active_lock);
> > I assumed that this lock here was to ensure proper barriers while
> > reading active_submits. Is that not required?
>
> There is a spinlock in prepare_to_wait_event() ahead of checking the
> condition, which AFAIU is a sufficient barrier
set_current_state() is instead - feel free to grep it in
Hillf
>
> BR,
> -R
>
> >
> > -Akhil.
> > > - return active_submits;
> > > -}
> > > -
> > > static int adreno_runtime_suspend(struct device *dev)
> > > {
> > > struct msm_gpu *gpu = dev_to_gpu(dev);
> > > @@ -669,7 +660,7 @@ static int adreno_system_suspend(struct device *dev)
> > > suspend_scheduler(gpu);
> > >
> > > remaining = wait_event_timeout(gpu->retire_event,
> > > -active_submits(gpu) == 0,
> > > +gpu->active_submits == 0,
> > > msecs_to_jiffies(1000));
> > > if (remaining == 0) {
> > > dev_err(dev, "Timeout waiting for GPU to suspend\n");
> >
Re: [PATCH 2/4] drm/gma500: Move gma_intel_crtc_funcs into gma_display.c
Hi Patrik, I love your patch! Perhaps something to improve: [auto build test WARNING on drm/drm-next] [also build test WARNING on drm-intel/for-linux-next drm-tip/drm-tip drm-exynos/exynos-drm-next tegra-drm/drm/tegra/for-next v5.17-rc8 next-20220317] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Patrik-Jakobsson/drm-gma500-Remove-unused-declarations-and-other-cruft/20220317-172741 base: git://anongit.freedesktop.org/drm/drm drm-next config: i386-randconfig-s002 (https://download.01.org/0day-ci/archive/20220318/202203181032.rqkgg9w3-...@intel.com/config) compiler: gcc-9 (Ubuntu 9.4.0-1ubuntu1~20.04) 9.4.0 reproduce: # apt-get install sparse # sparse version: v0.6.4-dirty # https://github.com/0day-ci/linux/commit/cdcc3ba62afbe456eb16b00d5df129abf8db5ca1 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Patrik-Jakobsson/drm-gma500-Remove-unused-declarations-and-other-cruft/20220317-172741 git checkout cdcc3ba62afbe456eb16b00d5df129abf8db5ca1 # save the config file to linux build tree mkdir build_dir make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=i386 SHELL=/bin/bash drivers/gpu/drm/gma500/ If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) >> drivers/gpu/drm/gma500/gma_display.c:175:5: sparse: sparse: symbol >> 'gma_crtc_gamma_set' was not declared. Should it be static? drivers/gpu/drm/gma500/gma_display.c:401:25: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void *tmp_dst @@ got unsigned char [noderef] [usertype] __iomem * @@ drivers/gpu/drm/gma500/gma_display.c:401:25: sparse: expected void *tmp_dst drivers/gpu/drm/gma500/gma_display.c:401:25: sparse: got unsigned char [noderef] [usertype] __iomem * >> drivers/gpu/drm/gma500/gma_display.c:322:5: sparse: sparse: symbol >> 'gma_crtc_cursor_set' was not declared. Should it be static? >> drivers/gpu/drm/gma500/gma_display.c:440:5: sparse: sparse: symbol >> 'gma_crtc_cursor_move' was not declared. Should it be static? Please review and possibly fold the followup patch. --- 0-DAY CI Kernel Test Service https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[RFC PATCH] drm/gma500: gma_crtc_gamma_set() can be static
drivers/gpu/drm/gma500/gma_display.c:175:5: warning: symbol
'gma_crtc_gamma_set' was not declared. Should it be static?
drivers/gpu/drm/gma500/gma_display.c:322:5: warning: symbol
'gma_crtc_cursor_set' was not declared. Should it be static?
drivers/gpu/drm/gma500/gma_display.c:440:5: warning: symbol
'gma_crtc_cursor_move' was not declared. Should it be static?
Reported-by: kernel test robot
Signed-off-by: kernel test robot
---
drivers/gpu/drm/gma500/gma_display.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/gma500/gma_display.c
b/drivers/gpu/drm/gma500/gma_display.c
index 832696ccfa9d0..8f6a8502b7756 100644
--- a/drivers/gpu/drm/gma500/gma_display.c
+++ b/drivers/gpu/drm/gma500/gma_display.c
@@ -172,9 +172,9 @@ void gma_crtc_load_lut(struct drm_crtc *crtc)
}
}
-int gma_crtc_gamma_set(struct drm_crtc *crtc, u16 *red, u16 *green, u16 *blue,
- u32 size,
- struct drm_modeset_acquire_ctx *ctx)
+static int gma_crtc_gamma_set(struct drm_crtc *crtc, u16 *red, u16 *green, u16
*blue,
+ u32 size,
+ struct drm_modeset_acquire_ctx *ctx)
{
gma_crtc_load_lut(crtc);
@@ -319,10 +319,10 @@ void gma_crtc_dpms(struct drm_crtc *crtc, int mode)
REG_WRITE(DSPARB, 0x3F3E);
}
-int gma_crtc_cursor_set(struct drm_crtc *crtc,
- struct drm_file *file_priv,
- uint32_t handle,
- uint32_t width, uint32_t height)
+static int gma_crtc_cursor_set(struct drm_crtc *crtc,
+ struct drm_file *file_priv,
+ uint32_t handle,
+ uint32_t width, uint32_t height)
{
struct drm_device *dev = crtc->dev;
struct drm_psb_private *dev_priv = to_drm_psb_private(dev);
@@ -437,7 +437,7 @@ int gma_crtc_cursor_set(struct drm_crtc *crtc,
return ret;
}
-int gma_crtc_cursor_move(struct drm_crtc *crtc, int x, int y)
+static int gma_crtc_cursor_move(struct drm_crtc *crtc, int x, int y)
{
struct drm_device *dev = crtc->dev;
struct gma_crtc *gma_crtc = to_gma_crtc(crtc);
[PATCH v6 7/7] drm/i915/gt: Adding new sysfs frequency attributes
From: Sujaritha Sundaresan
This patch adds the following new sysfs frequency attributes:
- punit_req_freq_mhz
- throttle_reason_status
- throttle_reason_pl1
- throttle_reason_pl2
- throttle_reason_pl4
- throttle_reason_thermal
- throttle_reason_prochot
- throttle_reason_ratl
- throttle_reason_vr_thermalert
- throttle_reason_vr_tdc
Signed-off-by: Sujaritha Sundaresan
Cc: Dale B Stimson
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 74 +
drivers/gpu/drm/i915/gt/intel_rps.c | 18 +
drivers/gpu/drm/i915/gt/intel_rps.h | 4 ++
drivers/gpu/drm/i915/i915_reg.h | 11 +++
4 files changed, 107 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
index b0a1ea95d028e..26cbfa6477d12 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
@@ -8,6 +8,7 @@
#include
#include "i915_drv.h"
+#include "i915_reg.h"
#include "i915_sysfs.h"
#include "intel_gt.h"
#include "intel_gt_regs.h"
@@ -493,6 +494,69 @@ static DEVICE_ATTR_RO(vlv_rpe_freq_mhz);
static const struct attribute * const gen6_rps_attrs[] = GEN6_RPS_ATTR;
static const struct attribute * const gen6_gt_attrs[] = GEN6_GT_ATTR;
+static ssize_t punit_req_freq_mhz_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buff)
+{
+ struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
+ u32 preq = intel_rps_read_punit_req_frequency(>->rps);
+
+ return sysfs_emit(buff, "%u\n", preq);
+}
+
+struct intel_gt_bool_throttle_attr {
+ struct attribute attr;
+ ssize_t (*show)(struct device *dev, struct device_attribute *attr,
+ char *buf);
+ i915_reg_t reg32;
+ u32 mask;
+};
+
+static ssize_t throttle_reason_bool_show(struct device *dev,
+struct device_attribute *attr,
+char *buff)
+{
+ struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
+ struct intel_gt_bool_throttle_attr *t_attr =
+ (struct intel_gt_bool_throttle_attr *) attr;
+ bool val = rps_read_mask_mmio(>->rps, t_attr->reg32, t_attr->mask);
+
+ return sysfs_emit(buff, "%u\n", val);
+}
+
+#define INTEL_GT_RPS_BOOL_ATTR_RO(sysfs_func__, mask__) \
+struct intel_gt_bool_throttle_attr attr_##sysfs_func__ = { \
+ .attr = { .name = __stringify(sysfs_func__), .mode = 0444 }, \
+ .show = throttle_reason_bool_show, \
+ .reg32 = GT0_PERF_LIMIT_REASONS, \
+ .mask = mask__, \
+}
+
+static DEVICE_ATTR_RO(punit_req_freq_mhz);
+static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_status,
GT0_PERF_LIMIT_REASONS_MASK);
+static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_pl1, POWER_LIMIT_1_MASK);
+static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_pl2, POWER_LIMIT_2_MASK);
+static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_pl4, POWER_LIMIT_4_MASK);
+static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_thermal, THERMAL_LIMIT_MASK);
+static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_prochot, PROCHOT_MASK);
+static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_ratl, RATL_MASK);
+static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_vr_thermalert,
VR_THERMALERT_MASK);
+static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_vr_tdc, VR_TDC_MASK);
+
+static const struct attribute *freq_attrs[] = {
+ &dev_attr_punit_req_freq_mhz.attr,
+ &attr_throttle_reason_status.attr,
+ &attr_throttle_reason_pl1.attr,
+ &attr_throttle_reason_pl2.attr,
+ &attr_throttle_reason_pl4.attr,
+ &attr_throttle_reason_thermal.attr,
+ &attr_throttle_reason_prochot.attr,
+ &attr_throttle_reason_ratl.attr,
+ &attr_throttle_reason_vr_thermalert.attr,
+ &attr_throttle_reason_vr_tdc.attr,
+ NULL
+};
+
static int intel_sysfs_rps_init(struct intel_gt *gt, struct kobject *kobj,
const struct attribute * const *attrs)
{
@@ -524,4 +588,14 @@ void intel_gt_sysfs_pm_init(struct intel_gt *gt, struct
kobject *kobj)
drm_warn(>->i915->drm,
"failed to create gt%u RPS sysfs files (%pe)",
gt->info.id, ERR_PTR(ret));
+
+ /* end of the legacy interfaces */
+ if (!is_object_gt(kobj))
+ return;
+
+ ret = sysfs_create_files(kobj, freq_attrs);
+ if (ret)
+ drm_warn(>->i915->drm,
+"failed to create gt%u throttle sysfs files (%pe)",
+gt->info.id, ERR_PTR(ret));
}
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
b/drivers/gpu/drm/i915/gt/intel_rps.c
index a9c13b1a30181..6c9fdf7906c50 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+
[PATCH v6 6/7] drm/i915/gt: Create per-tile RPS sysfs interfaces
Now tiles have their own sysfs interfaces under the gt/
directory. Because RPS is a property that can be configured on a
tile basis, then each tile should have its own interface
The new sysfs structure will have a similar layout for the 4 tile
case:
/sys/.../card0
├── gt
│ ├── gt0
│ │ ├── id
│ │ ├── rc6_enable
│ │ ├── rc6_residency_ms
│ │ ├── rps_act_freq_mhz
│ │ ├── rps_boost_freq_mhz
│ │ ├── rps_cur_freq_mhz
│ │ ├── rps_max_freq_mhz
│ │ ├── rps_min_freq_mhz
│ │ ├── rps_RP0_freq_mhz
│ │ ├── rps_RP1_freq_mhz
│ │ └── rps_RPn_freq_mhz
. .
. .
. .
│ └── gtN
│ ├── id
│ ├── rc6_enable
│ ├── rc6_residency_ms
│ ├── rps_act_freq_mhz
│ ├── rps_boost_freq_mhz
│ ├── rps_cur_freq_mhz
│ ├── rps_max_freq_mhz
│ ├── rps_min_freq_mhz
│ ├── rps_RP0_freq_mhz
│ ├── rps_RP1_freq_mhz
│ └── rps_RPn_freq_mhz
├── gt_act_freq_mhz -+
├── gt_boost_freq_mhz |
├── gt_cur_freq_mhz|Original interface
├── gt_max_freq_mhz+─-> kept as existing ABI;
├── gt_min_freq_mhz|it points to gt0/
├── gt_RP0_freq_mhz|
├── gt_RP1_freq_mhz|
└── gt_RPn_freq_mhz -+
The existing interfaces have been kept in their original location
to preserve the existing ABI. They act on all the GTs: when
writing they loop through all the GTs and write the information
on each interface. When reading they provide the average value
from all the GTs.
This patch is not really adding exposing new interfaces (new
ABI) other than adapting the existing one to more tiles. In any
case this new set of interfaces will be a basic tool for system
managers and administrators when using i915.
Signed-off-by: Andi Shyti
Signed-off-by: Lucas De Marchi
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Matt Roper
Cc: Sujaritha Sundaresan
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 283
drivers/gpu/drm/i915/i915_sysfs.c | 177
2 files changed, 283 insertions(+), 177 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
index 144b004e4de82..b0a1ea95d028e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
@@ -14,6 +14,7 @@
#include "intel_gt_sysfs.h"
#include "intel_gt_sysfs_pm.h"
#include "intel_rc6.h"
+#include "intel_rps.h"
#ifdef CONFIG_PM
enum intel_gt_sysfs_op {
@@ -21,6 +22,30 @@ enum intel_gt_sysfs_op {
INTEL_GT_SYSFS_MAX,
};
+static int
+sysfs_gt_attribute_w_func(struct device *dev, struct device_attribute *attr,
+ int (func)(struct intel_gt *gt, u32 val), u32 val)
+{
+ struct intel_gt *gt;
+ int ret;
+
+ if (!is_object_gt(&dev->kobj)) {
+ int i;
+ struct drm_i915_private *i915 = kdev_minor_to_i915(dev);
+
+ for_each_gt(gt, i915, i) {
+ ret = func(gt, val);
+ if (ret)
+ break;
+ }
+ } else {
+ gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
+ ret = func(gt, val);
+ }
+
+ return ret;
+}
+
static u32
sysfs_gt_attribute_r_func(struct device *dev, struct device_attribute *attr,
u32 (func)(struct intel_gt *gt),
@@ -62,6 +87,7 @@ sysfs_gt_attribute_r_func(struct device *dev, struct
device_attribute *attr,
#define sysfs_gt_attribute_r_min_func(d, a, f) \
sysfs_gt_attribute_r_func(d, a, f, INTEL_GT_SYSFS_MIN)
+/* Frequency interfaces will show the maximum frequency value */
#define sysfs_gt_attribute_r_max_func(d, a, f) \
sysfs_gt_attribute_r_func(d, a, f, INTEL_GT_SYSFS_MAX)
@@ -238,7 +264,264 @@ static void intel_sysfs_rc6_init(struct intel_gt *gt,
struct kobject *kobj)
}
#endif /* CONFIG_PM */
+static u32 __act_freq_mhz_show(struct intel_gt *gt)
+{
+ return intel_rps_read_actual_frequency(>->rps);
+}
+
+static ssize_t act_freq_mhz_show(struct device *dev,
+struct device_attribute *attr, char *buff)
+{
+ u32 actual_freq = sysfs_gt_attribute_r_max_func(dev, attr,
+ __act_freq_mhz_show);
+
+ return sysfs_emit(buff, "%u\n", actual_freq);
+}
+
+static u32 __cur_freq_mhz_show(struct intel_gt *gt)
+{
+ return intel_rps_get_requested_frequency(>->rps);
+}
+
+static ssize_t cur_freq_mhz_show(struct device *dev,
+struct device_attribute *attr, char *buff)
+{
+ u32 cur_freq = sysfs_gt_attribute_r
[PATCH v6 5/7] drm/i915/gt: Create per-tile RC6 sysfs interface
Now tiles have their own sysfs interfaces under the gt/
directory. Because RC6 is a property that can be configured on a
tile basis, then each tile should have its own interface
The new sysfs structure will have a similar layout for the 4 tile
case:
/sys/.../card0
├── gt
│ ├── gt0
│ │ ├── id
│ │ ├── rc6_enable
│ │ ├── rc6_residency_ms
. . .
. . .
. .
│ └── gtN
│ ├── id
│ ├── rc6_enable
│ ├── rc6_residency_ms
│ .
│ .
│
└── power/-+
├── rc6_enable|Original interface
├── rc6_residency_ms +-> kept as existing ABI;
. |it multiplexes over
. |the GTs
-+
The existing interfaces have been kept in their original location
to preserve the existing ABI. They act on all the GTs: when
reading they provide the average value from all the GTs.
This patch is not really adding exposing new interfaces (new
ABI) other than adapting the existing one to more tiles. In any
case this new set of interfaces will be a basic tool for system
managers and administrators when using i915.
Signed-off-by: Andi Shyti
Signed-off-by: Lucas De Marchi
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Matt Roper
Cc: Sujaritha Sundaresan
Cc: Tvrtko Ursulin
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gt/intel_gt_sysfs.c| 19 ++
drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 244
drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.h | 15 ++
drivers/gpu/drm/i915/i915_sysfs.c | 128 --
5 files changed, 279 insertions(+), 128 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 181d71d5ba3c0..bcc301351aa39 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -106,6 +106,7 @@ gt-y += \
gt/intel_gt_pm_irq.o \
gt/intel_gt_requests.o \
gt/intel_gt_sysfs.o \
+ gt/intel_gt_sysfs_pm.o \
gt/intel_gtt.o \
gt/intel_llc.o \
gt/intel_lrc.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
index d508319612944..8ec8bc660c8c2 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
@@ -13,6 +13,7 @@
#include "i915_sysfs.h"
#include "intel_gt.h"
#include "intel_gt_sysfs.h"
+#include "intel_gt_sysfs_pm.h"
#include "intel_gt_types.h"
#include "intel_rc6.h"
@@ -50,6 +51,11 @@ struct intel_gt *intel_gt_sysfs_get_drvdata(struct device
*dev,
return kobj_to_gt(kobj);
}
+static struct kobject *gt_get_parent_obj(struct intel_gt *gt)
+{
+ return >->i915->drm.primary->kdev->kobj;
+}
+
static ssize_t id_show(struct device *dev,
struct device_attribute *attr,
char *buf)
@@ -81,6 +87,17 @@ void intel_gt_sysfs_register(struct intel_gt *gt)
{
struct kobj_gt *kg;
+ /*
+* We need to make things right with the
+* ABI compatibility. The files were originally
+* generated under the parent directory.
+*
+* We generate the files only for gt 0
+* to avoid duplicates.
+*/
+ if (gt_is_root(gt))
+ intel_gt_sysfs_pm_init(gt, gt_get_parent_obj(gt));
+
kg = kzalloc(sizeof(*kg), GFP_KERNEL);
if (!kg)
goto exit_fail;
@@ -92,6 +109,8 @@ void intel_gt_sysfs_register(struct intel_gt *gt)
if (kobject_add(&kg->base, gt->i915->sysfs_gt, "gt%d", gt->info.id))
goto exit_kobj_put;
+ intel_gt_sysfs_pm_init(gt, &kg->base);
+
return;
exit_kobj_put:
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
new file mode 100644
index 0..144b004e4de82
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
@@ -0,0 +1,244 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include
+#include
+#include
+
+#include "i915_drv.h"
+#include "i915_sysfs.h"
+#include "intel_gt.h"
+#include "intel_gt_regs.h"
+#include "intel_gt_sysfs.h"
+#include "intel_gt_sysfs_pm.h"
+#include "intel_rc6.h"
+
+#ifdef CONFIG_PM
+enum intel_gt_sysfs_op {
+ INTEL_GT_SYSFS_MIN = 0,
+ INTEL_GT_SYSFS_MAX,
+};
+
+static u32
+sysfs_gt_attribute_r_func(struct device *dev, struct device_attribute *attr,
+ u32 (func)(struct intel_gt *gt),
+ enum intel_gt_sysfs_op op)
+{
+ struct intel_gt *gt;
+ u32 ret;
+
+ ret = (op == INTEL_GT_SYSFS_
[PATCH v6 4/7] drm/i915/gt: create per-tile sysfs interface
Now that we have tiles we want each of them to have its own
interface. A directory "gt/" is created under "cardN/" that will
contain as many diroctories as the tiles.
In the coming patches tile related interfaces will be added. For
now the sysfs gt structure simply has an id interface related
to the current tile count.
The directory structure will follow this scheme:
/sys/.../card0
└── gt
├── gt0
│ └── id
:
:
└─- gtN
└── id
This new set of interfaces will be a basic tool for system
managers and administrators when using i915.
Signed-off-by: Andi Shyti
Cc: Matt Roper
Cc: Sujaritha Sundaresan
Cc: Tvrtko Ursulin
Reviewed-by: Sujaritha Sundaresan
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/gt/intel_gt.c | 2 +
drivers/gpu/drm/i915/gt/intel_gt_sysfs.c | 103 +++
drivers/gpu/drm/i915/gt/intel_gt_sysfs.h | 34
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_sysfs.c| 7 +-
drivers/gpu/drm/i915/i915_sysfs.h| 3 +
scripts/extract-cert | Bin 0 -> 17952 bytes
8 files changed, 151 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
create mode 100755 scripts/extract-cert
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 1a771ee5b1d01..181d71d5ba3c0 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -105,6 +105,7 @@ gt-y += \
gt/intel_gt_pm_debugfs.o \
gt/intel_gt_pm_irq.o \
gt/intel_gt_requests.o \
+ gt/intel_gt_sysfs.o \
gt/intel_gtt.o \
gt/intel_llc.o \
gt/intel_lrc.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index f66139021049d..a68d3d3c41653 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -26,6 +26,7 @@
#include "intel_rc6.h"
#include "intel_renderstate.h"
#include "intel_rps.h"
+#include "intel_gt_sysfs.h"
#include "intel_uncore.h"
#include "shmem_utils.h"
@@ -458,6 +459,7 @@ void intel_gt_driver_register(struct intel_gt *gt)
intel_rps_driver_register(>->rps);
intel_gt_debugfs_register(gt);
+ intel_gt_sysfs_register(gt);
}
static int intel_gt_init_scratch(struct intel_gt *gt, unsigned int size)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
new file mode 100644
index 0..d508319612944
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
@@ -0,0 +1,103 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "i915_drv.h"
+#include "i915_sysfs.h"
+#include "intel_gt.h"
+#include "intel_gt_sysfs.h"
+#include "intel_gt_types.h"
+#include "intel_rc6.h"
+
+bool is_object_gt(struct kobject *kobj)
+{
+ return !strncmp(kobj->name, "gt", 2);
+}
+
+static struct intel_gt *kobj_to_gt(struct kobject *kobj)
+{
+ return container_of(kobj, struct kobj_gt, base)->gt;
+}
+
+struct intel_gt *intel_gt_sysfs_get_drvdata(struct device *dev,
+ const char *name)
+{
+ struct kobject *kobj = &dev->kobj;
+
+ /*
+* We are interested at knowing from where the interface
+* has been called, whether it's called from gt/ or from
+* the parent directory.
+* From the interface position it depends also the value of
+* the private data.
+* If the interface is called from gt/ then private data is
+* of the "struct intel_gt *" type, otherwise it's * a
+* "struct drm_i915_private *" type.
+*/
+ if (!is_object_gt(kobj)) {
+ struct drm_i915_private *i915 = kdev_minor_to_i915(dev);
+
+ return to_gt(i915);
+ }
+
+ return kobj_to_gt(kobj);
+}
+
+static ssize_t id_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
+
+ return sysfs_emit(buf, "%u\n", gt->info.id);
+}
+static DEVICE_ATTR_RO(id);
+
+static struct attribute *id_attrs[] = {
+ &dev_attr_id.attr,
+ NULL,
+};
+ATTRIBUTE_GROUPS(id);
+
+static void kobj_gt_release(struct kobject *kobj)
+{
+ kfree(kobj);
+}
+
+static struct kobj_type kobj_gt_type = {
+ .release = kobj_gt_release,
+ .sysfs_ops = &kobj_sysfs_ops,
+ .default_groups = id_groups,
+};
+
+void intel_gt_sysfs_register(struct intel_gt *gt)
+{
+ struct kobj_gt *kg;
+
+ kg = kzalloc(sizeof(*kg), GFP_KERNEL);
+ if (!kg)
+ goto exit_fail;
+
+ kobject_init(&kg->base, &kobj_gt_type);
[PATCH v6 3/7] drm/i915: Prepare for multiple GTs
From: Tvrtko Ursulin
On a multi-tile platform, each tile has its own registers + GGTT
space, and BAR 0 is extended to cover all of them.
Up to four GTs are supported in i915->gt[], with slot zero
shadowing the existing i915->gt0 to enable source compatibility
with legacy driver paths. A for_each_gt macro is added to iterate
over the GTs and will be used by upcoming patches that convert
various parts of the driver to be multi-gt aware.
Only the primary/root tile is initialized for now; the other
tiles will be detected and plugged in by future patches once the
necessary infrastructure is in place to handle them.
Signed-off-by: Abdiel Janulgue
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Matt Roper
Signed-off-by: Andi Shyti
Cc: Daniele Ceraolo Spurio
Cc: Joonas Lahtinen
Cc: Matthew Auld
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt.c| 133 --
drivers/gpu/drm/i915/gt/intel_gt.h| 17 ++-
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 9 +-
drivers/gpu/drm/i915/gt/intel_gt_types.h | 7 +
drivers/gpu/drm/i915/i915_driver.c| 28 ++--
drivers/gpu/drm/i915/i915_drv.h | 6 +
drivers/gpu/drm/i915/intel_memory_region.h| 3 +
drivers/gpu/drm/i915/intel_uncore.c | 11 +-
drivers/gpu/drm/i915/intel_uncore.h | 3 +-
.../gpu/drm/i915/selftests/mock_gem_device.c | 7 +-
10 files changed, 178 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 4c077b3c38b73..f66139021049d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -29,7 +29,7 @@
#include "intel_uncore.h"
#include "shmem_utils.h"
-void __intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private *i915)
+static void __intel_gt_init_early(struct intel_gt *gt)
{
spin_lock_init(>->irq_lock);
@@ -51,17 +51,23 @@ void __intel_gt_init_early(struct intel_gt *gt, struct
drm_i915_private *i915)
intel_rps_init_early(>->rps);
}
-void intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private *i915)
+/* Preliminary initialization of Tile 0 */
+void intel_root_gt_init_early(struct drm_i915_private *i915)
{
+ struct intel_gt *gt = to_gt(i915);
+
gt->i915 = i915;
gt->uncore = &i915->uncore;
+
+ __intel_gt_init_early(gt);
}
-int intel_gt_probe_lmem(struct intel_gt *gt)
+static int intel_gt_probe_lmem(struct intel_gt *gt)
{
struct drm_i915_private *i915 = gt->i915;
+ unsigned int instance = gt->info.id;
+ int id = INTEL_REGION_LMEM_0 + instance;
struct intel_memory_region *mem;
- int id;
int err;
mem = intel_gt_setup_lmem(gt);
@@ -76,9 +82,8 @@ int intel_gt_probe_lmem(struct intel_gt *gt)
return err;
}
- id = INTEL_REGION_LMEM_0;
-
mem->id = id;
+ mem->instance = instance;
intel_memory_region_set_name(mem, "local%u", mem->instance);
@@ -801,16 +806,21 @@ void intel_gt_driver_release(struct intel_gt *gt)
intel_gt_fini_buffer_pool(gt);
}
-void intel_gt_driver_late_release(struct intel_gt *gt)
+void intel_gt_driver_late_release(struct drm_i915_private *i915)
{
+ struct intel_gt *gt;
+ unsigned int id;
+
/* We need to wait for inflight RCU frees to release their grip */
rcu_barrier();
- intel_uc_driver_late_release(>->uc);
- intel_gt_fini_requests(gt);
- intel_gt_fini_reset(gt);
- intel_gt_fini_timelines(gt);
- intel_engines_free(gt);
+ for_each_gt(gt, i915, id) {
+ intel_uc_driver_late_release(>->uc);
+ intel_gt_fini_requests(gt);
+ intel_gt_fini_reset(gt);
+ intel_gt_fini_timelines(gt);
+ intel_engines_free(gt);
+ }
}
/**
@@ -1007,6 +1017,105 @@ void intel_gt_report_steering(struct drm_printer *p,
struct intel_gt *gt,
}
}
+static int intel_gt_tile_setup(struct intel_gt *gt, phys_addr_t phys_addr)
+{
+ int ret;
+
+ if (!gt_is_root(gt)) {
+ struct intel_uncore_mmio_debug *mmio_debug;
+ struct intel_uncore *uncore;
+
+ uncore = kzalloc(sizeof(*uncore), GFP_KERNEL);
+ if (!uncore)
+ return -ENOMEM;
+
+ mmio_debug = kzalloc(sizeof(*mmio_debug), GFP_KERNEL);
+ if (!mmio_debug) {
+ kfree(uncore);
+ return -ENOMEM;
+ }
+
+ gt->uncore = uncore;
+ gt->uncore->debug = mmio_debug;
+
+ __intel_gt_init_early(gt);
+ }
+
+ intel_uncore_init_early(gt->uncore, gt);
+
+ ret = intel_uncore_setup_mmio(gt->uncore, phys_addr);
+ if (ret)
+ return ret;
+
+ gt->phys_addr = phys_addr;
+
+ return 0;
+}
+
+static void
+i
[PATCH v6 2/7] drm/i915/gt: add gt_is_root() helper
The "gt_is_root(struct intel_gt *gt)" helper return true if the
gt is the root gt, which means that its id is 0. Return false
otherwise.
Suggested-by: Michal Wajdeczko
Signed-off-by: Andi Shyti
Reviewed-by: Michal Wajdeczko
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/i915/gt/intel_gt.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 996f8f3c17b95..ce471aa5c83d7 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -19,6 +19,11 @@ struct drm_printer;
##__VA_ARGS__); \
} while (0)
+static inline bool gt_is_root(struct intel_gt *gt)
+{
+ return !gt->info.id;
+}
+
static inline struct intel_gt *uc_to_gt(struct intel_uc *uc)
{
return container_of(uc, struct intel_gt, uc);
--
2.35.1
[PATCH v6 1/7] drm/i915: Rename INTEL_REGION_LMEM with INTEL_REGION_LMEM_0
With the upcoming multitile support each tile will have its own
local memory. Mark the current LMEM with the suffix '0' to
emphasise that it belongs to the root tile.
Suggested-by: Michal Wajdeczko
Signed-off-by: Andi Shyti
Reviewed-by: Michal Wajdeczko
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/i915/display/intel_fb.c | 2 +-
drivers/gpu/drm/i915/display/intel_fb_pin.c | 2 +-
drivers/gpu/drm/i915/display/intel_plane_initial.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 4 ++--
drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c | 6 +++---
drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c | 8
drivers/gpu/drm/i915/gt/intel_gt.c| 2 +-
drivers/gpu/drm/i915/intel_memory_region.c| 2 +-
drivers/gpu/drm/i915/intel_memory_region.h| 4 ++--
9 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
b/drivers/gpu/drm/i915/display/intel_fb.c
index 94c57facbb463..e9ad142ac40fa 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -1994,7 +1994,7 @@ intel_user_framebuffer_create(struct drm_device *dev,
/* object is backed with LMEM for discrete */
i915 = to_i915(obj->base.dev);
- if (HAS_LMEM(i915) && !i915_gem_object_can_migrate(obj,
INTEL_REGION_LMEM)) {
+ if (HAS_LMEM(i915) && !i915_gem_object_can_migrate(obj,
INTEL_REGION_LMEM_0)) {
/* object is "remote", not in local memory */
i915_gem_object_put(obj);
return ERR_PTR(-EREMOTE);
diff --git a/drivers/gpu/drm/i915/display/intel_fb_pin.c
b/drivers/gpu/drm/i915/display/intel_fb_pin.c
index a307b4993bcf3..bd6e7c98e751d 100644
--- a/drivers/gpu/drm/i915/display/intel_fb_pin.c
+++ b/drivers/gpu/drm/i915/display/intel_fb_pin.c
@@ -140,7 +140,7 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
if (!ret && phys_cursor)
ret = i915_gem_object_attach_phys(obj, alignment);
else if (!ret && HAS_LMEM(dev_priv))
- ret = i915_gem_object_migrate(obj, &ww, INTEL_REGION_LMEM);
+ ret = i915_gem_object_migrate(obj, &ww, INTEL_REGION_LMEM_0);
/* TODO: Do we need to sync when migration becomes async? */
if (!ret)
ret = i915_gem_object_pin_pages(obj);
diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c
b/drivers/gpu/drm/i915/display/intel_plane_initial.c
index 7979929bb6323..d10f27d0b7b09 100644
--- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
+++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
@@ -72,7 +72,7 @@ initial_plane_vma(struct drm_i915_private *i915,
}
phys_base = pte & I915_GTT_PAGE_MASK;
- mem = i915->mm.regions[INTEL_REGION_LMEM];
+ mem = i915->mm.regions[INTEL_REGION_LMEM_0];
/*
* We don't currently expect this to ever be placed in the
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
index ede084f36ca93..b2aaf620741e3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
@@ -102,7 +102,7 @@ __i915_gem_object_create_lmem_with_ps(struct
drm_i915_private *i915,
resource_size_t page_size,
unsigned int flags)
{
- return
i915_gem_object_create_region(i915->mm.regions[INTEL_REGION_LMEM],
+ return
i915_gem_object_create_region(i915->mm.regions[INTEL_REGION_LMEM_0],
size, page_size, flags);
}
@@ -137,6 +137,6 @@ i915_gem_object_create_lmem(struct drm_i915_private *i915,
resource_size_t size,
unsigned int flags)
{
- return
i915_gem_object_create_region(i915->mm.regions[INTEL_REGION_LMEM],
+ return
i915_gem_object_create_region(i915->mm.regions[INTEL_REGION_LMEM_0],
size, 0, flags);
}
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
index b071a58dd6daa..a342fd387d4ef 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
@@ -88,7 +88,7 @@ static int igt_dmabuf_import_self(void *arg)
static int igt_dmabuf_import_same_driver_lmem(void *arg)
{
struct drm_i915_private *i915 = arg;
- struct intel_memory_region *lmem = i915->mm.regions[INTEL_REGION_LMEM];
+ struct intel_memory_region *lmem =
i915->mm.regions[INTEL_REGION_LMEM_0];
struct drm_i915_gem_object *obj;
struct drm_gem_object *import;
struct dma_buf *dmabuf;
@@ -252,10 +252,10 @@ static int igt_dmabuf_import_same_driver_lmem_smem(void
*arg)
struct drm_i915_private *i915 = arg;
[PATCH v6 0/7] Introduce multitile support
Hi, This is the second series that prepares i915 to host multitile platforms. It introduces the for_each_gt() macro that loops over the tiles to perform per gt actions. This patch is a combination of two patches developed originally by Abdiel, who introduced some refactoring during probe, and then Tvrtko has added the necessary tools to start using the various tiles. The second patch re-organises the sysfs interface to expose the API for each of the GTs. I decided to prioritise this patch over others to unblock Sujaritha for further development. A third series will still follow this. Thanks Michal and Andrzej for the reviews and support! Thanks, Andi Patchwork: https://patchwork.freedesktop.org/series/98741/ Changelog = v5 -> v6 - address all Michal and Andrzej's reviews that consist mainly in code refactoring. v4 -> v5 - fixed Michal's reviews. - the sysfs patches have been split in 3 parts to make reviews easier. - Sujaritha's patch on pm throttle has been queued. - INTEL_REGION_LMEM has been renamed to INTEL_REGION_LMEM_0 - added the gt_is_root() helper - the sysfs files will be called intel_gt_sysfs_* instead of sysfs_gt_* v3 -> v4 - fixed Tvrtko's review: - remove the SYSFS_DEPRECATED_V2 mention from the commit log - reworded the error message when accessing deprecated files - errors in sysfs are printed as warnings as they are not fatal - the inline functions are moved to be out of line. and some other minor refactoring. v2 -> v3 - Added Matt and Sujaritha's r-b for patch 1 and 2. - Reworded the commit of patch 2 to underline the fact that the interface is useful also when used manually. v1 -> v2 - fixed a couple of coding style issues in patch 2. Andi Shyti (5): drm/i915: Rename INTEL_REGION_LMEM with INTEL_REGION_LMEM_0 drm/i915/gt: add gt_is_root() helper drm/i915/gt: create per-tile sysfs interface drm/i915/gt: Create per-tile RC6 sysfs interface drm/i915/gt: Create per-tile RPS sysfs interfaces Sujaritha Sundaresan (1): drm/i915/gt: Adding new sysfs frequency attributes Tvrtko Ursulin (1): drm/i915: Prepare for multiple GTs drivers/gpu/drm/i915/Makefile | 2 + drivers/gpu/drm/i915/display/intel_fb.c | 2 +- drivers/gpu/drm/i915/display/intel_fb_pin.c | 2 +- .../drm/i915/display/intel_plane_initial.c| 2 +- drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 4 +- .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 6 +- .../drm/i915/gem/selftests/i915_gem_migrate.c | 8 +- drivers/gpu/drm/i915/gt/intel_gt.c| 135 +++- drivers/gpu/drm/i915/gt/intel_gt.h| 22 +- drivers/gpu/drm/i915/gt/intel_gt_pm.c | 9 +- drivers/gpu/drm/i915/gt/intel_gt_sysfs.c | 122 drivers/gpu/drm/i915/gt/intel_gt_sysfs.h | 34 + drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 601 ++ drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.h | 15 + drivers/gpu/drm/i915/gt/intel_gt_types.h | 7 + drivers/gpu/drm/i915/gt/intel_rps.c | 18 + drivers/gpu/drm/i915/gt/intel_rps.h | 4 + drivers/gpu/drm/i915/i915_driver.c| 28 +- drivers/gpu/drm/i915/i915_drv.h | 8 + drivers/gpu/drm/i915/i915_reg.h | 11 + drivers/gpu/drm/i915/i915_sysfs.c | 310 + drivers/gpu/drm/i915/i915_sysfs.h | 3 + drivers/gpu/drm/i915/intel_memory_region.c| 2 +- drivers/gpu/drm/i915/intel_memory_region.h| 7 +- drivers/gpu/drm/i915/intel_uncore.c | 11 +- drivers/gpu/drm/i915/intel_uncore.h | 3 +- .../gpu/drm/i915/selftests/mock_gem_device.c | 7 +- scripts/extract-cert | Bin 0 -> 17952 bytes 28 files changed, 1017 insertions(+), 366 deletions(-) create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_sysfs.c create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_sysfs.h create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.h create mode 100755 scripts/extract-cert -- 2.35.1
[PATCH v4 2/4] drm: allow real encoder to be passed for drm_writeback_connector
For some vendor driver implementations, display hardware can
be shared between the encoder used for writeback and the physical
display.
In addition resources such as clocks and interrupts can
also be shared between writeback and the real encoder.
To accommodate such vendor drivers and hardware, allow
real encoder to be passed for drm_writeback_connector.
changes in v4:
- split the possible_crtcs change and the parts which should
belong to the addition of new API to the next change
Co-developed-by: Kandpal Suraj
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/drm_writeback.c | 12 +++-
drivers/gpu/drm/vc4/vc4_txp.c | 14 ++
include/drm/drm_writeback.h | 18 --
3 files changed, 33 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
index dc2ef12..a4c17d6 100644
--- a/drivers/gpu/drm/drm_writeback.c
+++ b/drivers/gpu/drm/drm_writeback.c
@@ -190,11 +190,13 @@ int drm_writeback_connector_init(struct drm_device *dev,
if (IS_ERR(blob))
return PTR_ERR(blob);
- drm_encoder_helper_add(&wb_connector->encoder, enc_helper_funcs);
+ drm_encoder_helper_add(wb_connector->encoder, enc_helper_funcs);
- wb_connector->encoder.possible_crtcs = possible_crtcs;
+ wb_connector->encoder = &wb_connector->internal_encoder;
- ret = drm_encoder_init(dev, &wb_connector->encoder,
+ wb_connector->encoder->possible_crtcs = possible_crtcs;
+
+ ret = drm_encoder_init(dev, wb_connector->encoder,
&drm_writeback_encoder_funcs,
DRM_MODE_ENCODER_VIRTUAL, NULL);
if (ret)
@@ -208,7 +210,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
goto connector_fail;
ret = drm_connector_attach_encoder(connector,
- &wb_connector->encoder);
+ wb_connector->encoder);
if (ret)
goto attach_fail;
@@ -237,7 +239,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
attach_fail:
drm_connector_cleanup(connector);
connector_fail:
- drm_encoder_cleanup(&wb_connector->encoder);
+ drm_encoder_cleanup(wb_connector->encoder);
fail:
drm_property_blob_put(blob);
return ret;
diff --git a/drivers/gpu/drm/vc4/vc4_txp.c b/drivers/gpu/drm/vc4/vc4_txp.c
index 3447eb6..341a9be5 100644
--- a/drivers/gpu/drm/vc4/vc4_txp.c
+++ b/drivers/gpu/drm/vc4/vc4_txp.c
@@ -151,6 +151,8 @@ struct vc4_txp {
struct platform_device *pdev;
+ struct drm_encoder drm_enc;
+
struct drm_writeback_connector connector;
void __iomem *regs;
@@ -159,7 +161,7 @@ struct vc4_txp {
static inline struct vc4_txp *encoder_to_vc4_txp(struct drm_encoder *encoder)
{
- return container_of(encoder, struct vc4_txp, connector.encoder);
+ return container_of(encoder, struct vc4_txp, drm_enc);
}
static inline struct vc4_txp *connector_to_vc4_txp(struct drm_connector *conn)
@@ -467,6 +469,7 @@ static int vc4_txp_bind(struct device *dev, struct device
*master, void *data)
struct vc4_txp *txp;
struct drm_crtc *crtc;
struct drm_encoder *encoder;
+ struct drm_writeback_connector *wb_conn;
int ret, irq;
irq = platform_get_irq(pdev, 0);
@@ -492,9 +495,12 @@ static int vc4_txp_bind(struct device *dev, struct device
*master, void *data)
txp->regset.regs = txp_regs;
txp->regset.nregs = ARRAY_SIZE(txp_regs);
- drm_connector_helper_add(&txp->connector.base,
+ wb_conn = &txp->connector;
+ wb_conn->encoder = &txp->drm_enc;
+
+ drm_connector_helper_add(&wb_conn->base,
&vc4_txp_connector_helper_funcs);
- ret = drm_writeback_connector_init(drm, &txp->connector,
+ ret = drm_writeback_connector_init(drm, wb_conn,
&vc4_txp_connector_funcs,
&vc4_txp_encoder_helper_funcs,
drm_fmts, ARRAY_SIZE(drm_fmts),
@@ -507,7 +513,7 @@ static int vc4_txp_bind(struct device *dev, struct device
*master, void *data)
if (ret)
return ret;
- encoder = &txp->connector.encoder;
+ encoder = txp->connector.encoder;
encoder->possible_crtcs = drm_crtc_mask(crtc);
ret = devm_request_irq(dev, irq, vc4_txp_interrupt, 0,
diff --git a/include/drm/drm_writeback.h b/include/drm/drm_writeback.h
index db6214f..c525b60 100644
--- a/include/drm/drm_writeback.h
+++ b/include/drm/drm_writeback.h
@@ -25,15 +25,29 @@ struct drm_writeback_connector {
struct drm_connector base;
/**
-* @encoder: Internal encoder used by the connector to fulfill
+* @encoder: handle to drm_encoder used by the connector to fulfill
*
[PATCH v4 4/4] drm/vc4: change vc4 driver to use drm_writeback_connector_init_with_encoder()
vc4 driver currently embeds the drm_encoder into struct vc4_txp
and later on uses container_of to retrieve the vc4_txp from
the drm_encoder.
Since drm_encoder has now been made a pointer inside
drm_writeback_connector, make vc4 driver use the new API
so that the embedded encoder model can be retained in the
driver and there is no change in functionality.
changes in v4:
- none
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/vc4/vc4_txp.c | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_txp.c b/drivers/gpu/drm/vc4/vc4_txp.c
index 341a9be5..3d24ef5 100644
--- a/drivers/gpu/drm/vc4/vc4_txp.c
+++ b/drivers/gpu/drm/vc4/vc4_txp.c
@@ -370,6 +370,10 @@ static const struct drm_encoder_helper_funcs
vc4_txp_encoder_helper_funcs = {
.disable = vc4_txp_encoder_disable,
};
+static const struct drm_encoder_funcs vc4_txp_encoder_funcs = {
+ .destroy = drm_encoder_cleanup,
+};
+
static int vc4_txp_enable_vblank(struct drm_crtc *crtc)
{
return 0;
@@ -498,15 +502,24 @@ static int vc4_txp_bind(struct device *dev, struct device
*master, void *data)
wb_conn = &txp->connector;
wb_conn->encoder = &txp->drm_enc;
+ drm_encoder_helper_add(wb_conn->encoder, &vc4_txp_encoder_helper_funcs);
+
+ ret = drm_encoder_init(drm, wb_conn->encoder,
+ &vc4_txp_encoder_funcs,
+ DRM_MODE_ENCODER_VIRTUAL, NULL);
+
+ if (ret)
+ return ret;
+
drm_connector_helper_add(&wb_conn->base,
&vc4_txp_connector_helper_funcs);
- ret = drm_writeback_connector_init(drm, wb_conn,
- &vc4_txp_connector_funcs,
- &vc4_txp_encoder_helper_funcs,
- drm_fmts, ARRAY_SIZE(drm_fmts),
- 0);
- if (ret)
+
+ ret = drm_writeback_connector_init_with_encoder(drm, wb_conn,
+ &vc4_txp_connector_funcs, drm_fmts,
ARRAY_SIZE(drm_fmts));
+ if (ret) {
+ drm_encoder_cleanup(wb_conn->encoder);
return ret;
+ }
ret = vc4_crtc_init(drm, vc4_crtc,
&vc4_txp_crtc_funcs, &vc4_txp_crtc_helper_funcs);
--
2.7.4
[PATCH v4 1/4] drm: allow passing possible_crtcs to drm_writeback_connector_init()
Clients of drm_writeback_connector_init() initialize the
possible_crtcs and then invoke the call to this API.
To simplify things, allow passing possible_crtcs as a parameter
to drm_writeback_connector_init() and make changes to the
other drm drivers to make them compatible with this change.
changes in v4:
- keep only changes related to possible_crtcs
- add line breaks after ARRAY_SIZE
- stop using temporary variables for possible_crtcs
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c | 3 +--
drivers/gpu/drm/arm/malidp_mw.c | 4 ++--
drivers/gpu/drm/drm_writeback.c | 6 +-
drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 4 ++--
drivers/gpu/drm/vc4/vc4_txp.c| 3 ++-
drivers/gpu/drm/vkms/vkms_writeback.c| 4 ++--
include/drm/drm_writeback.h | 2 +-
7 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
index e465cc4..40774e6 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
@@ -155,7 +155,6 @@ static int komeda_wb_connector_add(struct komeda_kms_dev
*kms,
kwb_conn->wb_layer = kcrtc->master->wb_layer;
wb_conn = &kwb_conn->base;
- wb_conn->encoder.possible_crtcs = BIT(drm_crtc_index(&kcrtc->base));
formats = komeda_get_layer_fourcc_list(&mdev->fmt_tbl,
kwb_conn->wb_layer->layer_type,
@@ -164,7 +163,7 @@ static int komeda_wb_connector_add(struct komeda_kms_dev
*kms,
err = drm_writeback_connector_init(&kms->base, wb_conn,
&komeda_wb_connector_funcs,
&komeda_wb_encoder_helper_funcs,
- formats, n_formats);
+ formats, n_formats,
BIT(drm_crtc_index(&kcrtc->base)));
komeda_put_fourcc_list(formats);
if (err) {
kfree(kwb_conn);
diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
index f5847a7..e54921d 100644
--- a/drivers/gpu/drm/arm/malidp_mw.c
+++ b/drivers/gpu/drm/arm/malidp_mw.c
@@ -212,7 +212,6 @@ int malidp_mw_connector_init(struct drm_device *drm)
if (!malidp->dev->hw->enable_memwrite)
return 0;
- malidp->mw_connector.encoder.possible_crtcs = 1 <<
drm_crtc_index(&malidp->crtc);
drm_connector_helper_add(&malidp->mw_connector.base,
&malidp_mw_connector_helper_funcs);
@@ -223,7 +222,8 @@ int malidp_mw_connector_init(struct drm_device *drm)
ret = drm_writeback_connector_init(drm, &malidp->mw_connector,
&malidp_mw_connector_funcs,
&malidp_mw_encoder_helper_funcs,
- formats, n_formats);
+ formats, n_formats,
+ (1 << drm_crtc_index(&malidp->crtc)));
kfree(formats);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
index dccf4504..dc2ef12 100644
--- a/drivers/gpu/drm/drm_writeback.c
+++ b/drivers/gpu/drm/drm_writeback.c
@@ -157,6 +157,7 @@ static const struct drm_encoder_funcs
drm_writeback_encoder_funcs = {
* @enc_helper_funcs: Encoder helper funcs vtable to be used by the internal
encoder
* @formats: Array of supported pixel formats for the writeback engine
* @n_formats: Length of the formats array
+ * @possible_crtcs: possible crtcs for the internal writeback encoder
*
* This function creates the writeback-connector-specific properties if they
* have not been already created, initializes the connector as
@@ -174,7 +175,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
struct drm_writeback_connector *wb_connector,
const struct drm_connector_funcs *con_funcs,
const struct drm_encoder_helper_funcs
*enc_helper_funcs,
-const u32 *formats, int n_formats)
+const u32 *formats, int n_formats, uint32_t
possible_crtcs)
{
struct drm_property_blob *blob;
struct drm_connector *connector = &wb_connector->base;
@@ -190,6 +191,9 @@ int drm_writeback_connector_init(struct drm_device *dev,
return PTR_ERR(blob);
drm_encoder_helper_add(&wb_connector->encoder, enc_helper_funcs);
+
+ wb_connector->encoder.possible_crtcs = possible_crtcs;
+
ret = drm_encoder_init(dev, &wb_connector->encoder,
[PATCH v4 3/4] drm: introduce drm_writeback_connector_init_with_encoder() API
For vendors drivers which pass an already allocated and
initialized encoder especially for cases where the encoder
hardware is shared OR the writeback encoder shares the resources
with the rest of the display pipeline introduce a new API,
drm_writeback_connector_init_with_encoder() which expects
an initialized encoder as a parameter and only sets up the
writeback connector.
changes in v4:
- removed the possible_crtcs part
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/drm_writeback.c | 147
include/drm/drm_writeback.h | 5 ++
2 files changed, 108 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
index a4c17d6..d0672f5 100644
--- a/drivers/gpu/drm/drm_writeback.c
+++ b/drivers/gpu/drm/drm_writeback.c
@@ -149,37 +149,15 @@ static const struct drm_encoder_funcs
drm_writeback_encoder_funcs = {
.destroy = drm_encoder_cleanup,
};
-/**
- * drm_writeback_connector_init - Initialize a writeback connector and its
properties
- * @dev: DRM device
- * @wb_connector: Writeback connector to initialize
- * @con_funcs: Connector funcs vtable
- * @enc_helper_funcs: Encoder helper funcs vtable to be used by the internal
encoder
- * @formats: Array of supported pixel formats for the writeback engine
- * @n_formats: Length of the formats array
- * @possible_crtcs: possible crtcs for the internal writeback encoder
- *
- * This function creates the writeback-connector-specific properties if they
- * have not been already created, initializes the connector as
- * type DRM_MODE_CONNECTOR_WRITEBACK, and correctly initializes the property
- * values. It will also create an internal encoder associated with the
- * drm_writeback_connector and set it to use the @enc_helper_funcs vtable for
- * the encoder helper.
- *
- * Drivers should always use this function instead of drm_connector_init() to
- * set up writeback connectors.
- *
- * Returns: 0 on success, or a negative error code
- */
-int drm_writeback_connector_init(struct drm_device *dev,
-struct drm_writeback_connector *wb_connector,
-const struct drm_connector_funcs *con_funcs,
-const struct drm_encoder_helper_funcs
*enc_helper_funcs,
-const u32 *formats, int n_formats, uint32_t
possible_crtcs)
+static int drm_writeback_connector_setup(struct drm_device *dev,
+ struct drm_writeback_connector *wb_connector,
+ const struct drm_connector_funcs *con_funcs, const u32 *formats,
+ int n_formats)
{
struct drm_property_blob *blob;
- struct drm_connector *connector = &wb_connector->base;
struct drm_mode_config *config = &dev->mode_config;
+ struct drm_connector *connector = &wb_connector->base;
+
int ret = create_writeback_properties(dev);
if (ret != 0)
@@ -187,20 +165,10 @@ int drm_writeback_connector_init(struct drm_device *dev,
blob = drm_property_create_blob(dev, n_formats * sizeof(*formats),
formats);
- if (IS_ERR(blob))
- return PTR_ERR(blob);
-
- drm_encoder_helper_add(wb_connector->encoder, enc_helper_funcs);
-
- wb_connector->encoder = &wb_connector->internal_encoder;
-
- wb_connector->encoder->possible_crtcs = possible_crtcs;
-
- ret = drm_encoder_init(dev, wb_connector->encoder,
- &drm_writeback_encoder_funcs,
- DRM_MODE_ENCODER_VIRTUAL, NULL);
- if (ret)
- goto fail;
+ if (IS_ERR(blob)) {
+ ret = PTR_ERR(blob);
+ return ret;
+ }
connector->interlace_allowed = 0;
@@ -239,13 +207,104 @@ int drm_writeback_connector_init(struct drm_device *dev,
attach_fail:
drm_connector_cleanup(connector);
connector_fail:
- drm_encoder_cleanup(wb_connector->encoder);
-fail:
drm_property_blob_put(blob);
return ret;
}
+
+/**
+ * drm_writeback_connector_init - Initialize a writeback connector and its
properties
+ * @dev: DRM device
+ * @wb_connector: Writeback connector to initialize
+ * @con_funcs: Connector funcs vtable
+ * @enc_helper_funcs: Encoder helper funcs vtable to be used by the internal
encoder
+ * @formats: Array of supported pixel formats for the writeback engine
+ * @n_formats: Length of the formats array
+ * @possible_crtcs: possible crtcs for the internal writeback encoder
+ *
+ * This function creates the writeback-connector-specific properties if they
+ * have not been already created, initializes the connector as
+ * type DRM_MODE_CONNECTOR_WRITEBACK, and correctly initializes the property
+ * values. It will also create an internal encoder associated with the
+ * drm_writeback_connector and set it to use the @enc_helper_funcs vtable for
+ * the encoder helper.
+ *
+ * Drivers
[PATCH v4 0/4] Allow drm_writeback_connector to accept pointer to drm_encoder
There are some vendor drivers for which the writeback encoder shares hardware resources such as clocks and interrupts with the rest of the display pipeline. In addition, there can be use-cases where the writeback encoder could be a shared encoder between the physical display path and the writeback path. To accommodate for such cases, change the drm_writeback_connector to accept a pointer to drm_encoder. For existing users of drm_writeback_connector there will not be any change in functionality due to this change. This approach was first posted by Suraj Kandpal here [1] for both encoder and connector. But after discussions [2], the consensus was reached to split this change for the drm_encoder first and the drm_connector part can be reworked in a subsequent change later. Validation of this change was done using igt_writeback tests on MSM based RB5 board using the changes posted here [3]. For all other chipsets, these changes were compile-tested. [1] https://patchwork.kernel.org/project/dri-devel/patch/20220202081702.22119-1-suraj.kand...@intel.com/ [2] https://patchwork.kernel.org/project/dri-devel/patch/20220202085429.22261-6-suraj.kand...@intel.com/ [3] https://patchwork.freedesktop.org/series/99724/ changes in v4: - split the changes more according to functionality Abhinav Kumar (4): drm: allow passing possible_crtcs to drm_writeback_connector_init() drm: allow real encoder to be passed for drm_writeback_connector drm: introduce drm_writeback_connector_init_with_encoder() API drm/vc4: change vc4 driver to use drm_writeback_connector_init_with_encoder() .../drm/arm/display/komeda/komeda_wb_connector.c | 3 +- drivers/gpu/drm/arm/malidp_mw.c| 4 +- drivers/gpu/drm/drm_writeback.c| 143 +++-- drivers/gpu/drm/rcar-du/rcar_du_writeback.c| 4 +- drivers/gpu/drm/vc4/vc4_txp.c | 36 -- drivers/gpu/drm/vkms/vkms_writeback.c | 4 +- include/drm/drm_writeback.h| 25 +++- 7 files changed, 161 insertions(+), 58 deletions(-) -- 2.7.4
Re: [PATCH v5 6/9] drm/msm/dp: wait for hpd high before any sink interaction
Quoting Sankeerth Billakanti (2022-03-16 10:35:51)
> The source device should ensure the sink is ready before
> proceeding to read the sink capability or performing any aux transactions.
> The sink will indicate its readiness by asserting the HPD line.
>
> The eDP sink requires power from the source and its HPD line will
> be asserted only after the panel is powered on. The panel power will be
> enabled from the panel-edp driver.
>
> The controller driver needs to wait for the hpd line to be asserted
> by the sink.
>
> Signed-off-by: Sankeerth Billakanti
> ---
> drivers/gpu/drm/msm/dp/dp_aux.c | 6 ++
> drivers/gpu/drm/msm/dp/dp_catalog.c | 23 +++
> drivers/gpu/drm/msm/dp/dp_catalog.h | 1 +
> drivers/gpu/drm/msm/dp/dp_reg.h | 7 ++-
> 4 files changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_aux.c b/drivers/gpu/drm/msm/dp/dp_aux.c
> index 6d36f63..2ddc303 100644
> --- a/drivers/gpu/drm/msm/dp/dp_aux.c
> +++ b/drivers/gpu/drm/msm/dp/dp_aux.c
> @@ -337,6 +337,12 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux *dp_aux,
> goto exit;
> }
>
> + ret = dp_catalog_aux_wait_for_hpd_connect_state(aux->catalog);
Why are we making aux transactions when hpd isn't asserted? Can we only
register the aux device once we know that state is "connected"? I'm
concerned that we're going to be possibly polling the connected bit up
to some amount of time (0x0003 usecs?) for each aux transfer when
that doesn't make any sense to keep checking. We should be able to check
it once, register aux, and then when disconnect happens we can
unregister aux.
> + if (ret) {
> + DRM_DEBUG_DP("DP sink not ready for aux transactions\n");
> + goto exit;
> + }
> +
> dp_aux_update_offset_and_segment(aux, msg);
> dp_aux_transfer_helper(aux, msg, true);
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
> b/drivers/gpu/drm/msm/dp/dp_catalog.c
> index fac815f..2c3b0f7 100644
> --- a/drivers/gpu/drm/msm/dp/dp_catalog.c
> +++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
> @@ -242,6 +242,29 @@ void dp_catalog_aux_update_cfg(struct dp_catalog
> *dp_catalog)
> phy_calibrate(phy);
> }
>
> +int dp_catalog_aux_wait_for_hpd_connect_state(struct dp_catalog *dp_catalog)
> +{
> + u32 state, hpd_en, timeout;
> + struct dp_catalog_private *catalog = container_of(dp_catalog,
> + struct dp_catalog_private, dp_catalog);
> +
> + hpd_en = dp_read_aux(catalog, REG_DP_DP_HPD_CTRL) &
> + DP_DP_HPD_CTRL_HPD_EN;
Use two lines
hpd_en = dp_read_aux();
hpd_en &= DP_DP_HPD_CTRL_HPD_EN;
> +
> + /* no-hpd case */
> + if (!hpd_en)
> + return 0;
> +
> + /* Poll for HPD connected status */
> + timeout = dp_read_aux(catalog, REG_DP_DP_HPD_EVENT_TIME_0) &
> + DP_HPD_CONNECT_TIME_MASK;
> +
> + return readl_poll_timeout(catalog->io->dp_controller.aux.base +
> + REG_DP_DP_HPD_INT_STATUS,
> + state, state &
> DP_DP_HPD_STATE_STATUS_CONNECTED,
> + 2000, timeout);
> +}
> +
> static void dump_regs(void __iomem *base, int len)
> {
> int i;
[Bug 215652] kernel 5.17-rc fail to load radeon DRM "modprobe: ERROR: could not insert 'radeon': Unknown symbol in module, or unknown parameter (see dmesg)"
https://bugzilla.kernel.org/show_bug.cgi?id=215652 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |OBSOLETE --- Comment #10 from Erhard F. (erhar...@mailbox.org) --- I did not get out a meaningful result out of my reverse bisect... But v5.17.0-rc7 abd v5.17.0-rc8 do not show this issue. So closing here. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: linux-next: manual merge of the drm tree with the drm-misc-fixes tree
Hi all,
On Fri, 18 Mar 2022 11:55:44 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/bridge/Kconfig
>
> between commit:
>
> 3c3384050d68 ("drm: Don't make DRM_PANEL_BRIDGE dependent on
> DRM_KMS_HELPERS")
>
> from the drm-misc-fixes tree and commit:
>
> 803abfd8dda5 ("drm: bridge: fix unmet dependency on DRM_KMS_HELPER for
> DRM_PANEL_BRIDGE")
>
> from the drm tree.
>
> I fixed it up (I just used the latter) and can carry the fix as
But that failed during configuration, so I went back and used the
former change.
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpW_ceeanihK.pgp
Description: OpenPGP digital signature
[PATCH v2] fbdev: defio: fix the pagelist corruption
Easily hit the below list corruption:
==
list_add corruption. prev->next should be next (c0ceb090), but
was ec604507edc8. (prev=ec604507edc8).
WARNING: CPU: 65 PID: 3959 at lib/list_debug.c:26
__list_add_valid+0x53/0x80
CPU: 65 PID: 3959 Comm: fbdev Tainted: G U
RIP: 0010:__list_add_valid+0x53/0x80
Call Trace:
fb_deferred_io_mkwrite+0xea/0x150
do_page_mkwrite+0x57/0xc0
do_wp_page+0x278/0x2f0
__handle_mm_fault+0xdc2/0x1590
handle_mm_fault+0xdd/0x2c0
do_user_addr_fault+0x1d3/0x650
exc_page_fault+0x77/0x180
? asm_exc_page_fault+0x8/0x30
asm_exc_page_fault+0x1e/0x30
RIP: 0033:0x7fd98fc8fad1
==
Figure out the race happens when one process is adding &page->lru into
the pagelist tail in fb_deferred_io_mkwrite(), another process is
re-initializing the same &page->lru in fb_deferred_io_fault(), which is
not protected by the lock.
This fix is to init all the page lists one time during initialization,
it not only fixes the list corruption, but also avoids INIT_LIST_HEAD()
redundantly.
V2: change "int i" to "unsigned int i" (Geert Uytterhoeven)
Fixes: 105a940416fc ("fbdev/defio: Early-out if page is already
enlisted")
Cc: Thomas Zimmermann
Cc: Geert Uytterhoeven
Reviewed-by: Javier Martinez Canillas
Reviewed-by: Thomas Zimmermann
Signed-off-by: Chuansheng Liu
---
drivers/video/fbdev/core/fb_defio.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/core/fb_defio.c
b/drivers/video/fbdev/core/fb_defio.c
index 98b0f23bf5e2..a1da54016c88 100644
--- a/drivers/video/fbdev/core/fb_defio.c
+++ b/drivers/video/fbdev/core/fb_defio.c
@@ -59,7 +59,6 @@ static vm_fault_t fb_deferred_io_fault(struct vm_fault *vmf)
printk(KERN_ERR "no mapping available\n");
BUG_ON(!page->mapping);
- INIT_LIST_HEAD(&page->lru);
page->index = vmf->pgoff;
vmf->page = page;
@@ -220,6 +219,8 @@ static void fb_deferred_io_work(struct work_struct *work)
void fb_deferred_io_init(struct fb_info *info)
{
struct fb_deferred_io *fbdefio = info->fbdefio;
+ struct page *page;
+ unsigned int i;
BUG_ON(!fbdefio);
mutex_init(&fbdefio->lock);
@@ -227,6 +228,12 @@ void fb_deferred_io_init(struct fb_info *info)
INIT_LIST_HEAD(&fbdefio->pagelist);
if (fbdefio->delay == 0) /* set a default of 1 s */
fbdefio->delay = HZ;
+
+ /* initialize all the page lists one time */
+ for (i = 0; i < info->fix.smem_len; i += PAGE_SIZE) {
+ page = fb_deferred_io_page(info, i);
+ INIT_LIST_HEAD(&page->lru);
+ }
}
EXPORT_SYMBOL_GPL(fb_deferred_io_init);
--
2.25.0.rc2
linux-next: manual merge of the drm tree with the drm-misc-fixes tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/bridge/Kconfig
between commit:
3c3384050d68 ("drm: Don't make DRM_PANEL_BRIDGE dependent on DRM_KMS_HELPERS")
from the drm-misc-fixes tree and commit:
803abfd8dda5 ("drm: bridge: fix unmet dependency on DRM_KMS_HELPER for
DRM_PANEL_BRIDGE")
from the drm tree.
I fixed it up (I just used the latter) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpC2CwERZrf4.pgp
Description: OpenPGP digital signature
Re: [PATCH 1/4] drm/gma500: Remove unused declarations and other cruft
Hi Patrik, I love your patch! Perhaps something to improve: [auto build test WARNING on drm/drm-next] [also build test WARNING on drm-intel/for-linux-next drm-tip/drm-tip drm-exynos/exynos-drm-next tegra-drm/drm/tegra/for-next v5.17-rc8 next-20220317] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Patrik-Jakobsson/drm-gma500-Remove-unused-declarations-and-other-cruft/20220317-172741 base: git://anongit.freedesktop.org/drm/drm drm-next config: i386-randconfig-s002 (https://download.01.org/0day-ci/archive/20220318/202203180839.vnefesvz-...@intel.com/config) compiler: gcc-9 (Ubuntu 9.4.0-1ubuntu1~20.04) 9.4.0 reproduce: # apt-get install sparse # sparse version: v0.6.4-dirty # https://github.com/0day-ci/linux/commit/0d50efabcb4ad52bd7a036e2542dbf51bbcf93b4 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Patrik-Jakobsson/drm-gma500-Remove-unused-declarations-and-other-cruft/20220317-172741 git checkout 0d50efabcb4ad52bd7a036e2542dbf51bbcf93b4 # save the config file to linux build tree mkdir build_dir make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=i386 SHELL=/bin/bash drivers/gpu/drm/gma500/ If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) >> drivers/gpu/drm/gma500/psb_drv.c:102:6: sparse: sparse: symbol 'psb_spank' >> was not declared. Should it be static? Please review and possibly fold the followup patch. --- 0-DAY CI Kernel Test Service https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[RFC PATCH] drm/gma500: psb_spank() can be static
drivers/gpu/drm/gma500/psb_drv.c:102:6: warning: symbol 'psb_spank' was not
declared. Should it be static?
Reported-by: kernel test robot
Signed-off-by: kernel test robot
---
drivers/gpu/drm/gma500/psb_drv.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index eeb681be9c955..e400b284ffd48 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -99,7 +99,7 @@ static const struct drm_ioctl_desc psb_ioctls[] = {
*
* Soft reset the graphics engine and then reload the necessary registers.
*/
-void psb_spank(struct drm_psb_private *dev_priv)
+static void psb_spank(struct drm_psb_private *dev_priv)
{
PSB_WSGX32(_PSB_CS_RESET_BIF_RESET | _PSB_CS_RESET_DPM_RESET |
_PSB_CS_RESET_TA_RESET | _PSB_CS_RESET_USE_RESET |
Re: [PATCH v5 1/9] arm64: dts: qcom: sc7280: rename edp_out label to mdss_edp_out
Hi, On Wed, Mar 16, 2022 at 10:36 AM Sankeerth Billakanti wrote: > > Rename the edp_out label in the sc7280 platform to mdss_edp_out > so that the nodes related to mdss are all grouped together in > the board specific files. > > Signed-off-by: Sankeerth Billakanti > --- > > Changes in v5: > - Change the order of patches > - Modify commit text > > arch/arm64/boot/dts/qcom/sc7280.dtsi | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Douglas Anderson
Re: [PATCH v6 5/5] arm64: dts: qcom: sm8250: remove assigned-clock-rate property for mdp clk
Hi, On Mon, Mar 14, 2022 at 7:47 AM Vinod Polimera wrote: > > Drop the assigned clock rate property and vote on the mdp clock as per > calculated value during the usecase. > > This patch is dependent on below patch > https://patchwork.kernel.org/patch/12774067/ > > Signed-off-by: Vinod Polimera > Reviewed-by: Stephen Boyd > --- > arch/arm64/boot/dts/qcom/sm8250.dtsi | 9 ++--- > 1 file changed, 2 insertions(+), 7 deletions(-) Similar comments to patch #2 about the commit message, but otherwise: Reviewed-by: Douglas Anderson
Re: [PATCH v6 4/5] arm64: dts: qcom: sdm845: remove assigned-clock-rate property for mdp clk
Hi, On Mon, Mar 14, 2022 at 7:47 AM Vinod Polimera wrote: > > Drop the assigned clock rate property and vote on the mdp clock as per > calculated value during the usecase. > > This patch is dependent on below patch > https://patchwork.kernel.org/patch/12774067/ > > Signed-off-by: Vinod Polimera > Reviewed-by: Stephen Boyd > --- > arch/arm64/boot/dts/qcom/sdm845.dtsi | 9 ++--- > 1 file changed, 2 insertions(+), 7 deletions(-) Similar comments to patch #2 about the commit message, but otherwise: Reviewed-by: Douglas Anderson
Re: [PATCH v6 3/5] arm64: dts: qcom: sm7180: remove assigned-clock-rate property for mdp clk
Hi, On Mon, Mar 14, 2022 at 7:47 AM Vinod Polimera wrote: > > Drop the assigned clock rate property and vote on the mdp clock as per > calculated value during the usecase. > > This patch is dependent on below patch > https://patchwork.kernel.org/patch/12774067/ > > Signed-off-by: Vinod Polimera > Reviewed-by: Stephen Boyd > --- > arch/arm64/boot/dts/qcom/sc7180.dtsi | 9 ++--- > 1 file changed, 2 insertions(+), 7 deletions(-) Similar comments to patch #2 about the commit message, but otherwise: Reviewed-by: Douglas Anderson
Re: [PATCH v6 2/5] arm64: dts: qcom: sm7280: remove assigned-clock-rate property for mdp clk
Hi,
On Mon, Mar 14, 2022 at 7:47 AM Vinod Polimera
wrote:
>
> Drop the assigned clock rate property and vote on the mdp clock as per
> calculated value during the usecase.
>
> This patch is dependent on below patch
> https://patchwork.kernel.org/patch/12774067/
Some nits on how you're referring to the dependent patch:
1. In the commit message it's really nice to also include the subject
line of the patch so someone looking at the commit after it lands can
more easily identify the patch you depend on.
2. It's better to use links that have the message ID in them. In the
past patchwork's magic IDs have been list.
So I'd write:
This patch is dependent on the patch ("drm/msm/disp/dpu1: set mdp clk
to the maximum frequency in opp table during probe") [1].
[1]
https://lore.kernel.org/r/1647269217-14064-2-git-send-email-quic_vpoli...@quicinc.com/
> Signed-off-by: Vinod Polimera
> Reviewed-by: Stephen Boyd
> ---
> arch/arm64/boot/dts/qcom/sc7280.dtsi | 9 ++---
> 1 file changed, 2 insertions(+), 7 deletions(-)
Reviewed-by: Douglas Anderson
Re: [PATCH v6 1/5] drm/msm/disp/dpu1: set mdp clk to the maximum frequency in opp table during probe
Hi,
On Mon, Mar 14, 2022 at 7:47 AM Vinod Polimera
wrote:
>
> use max clock during probe/bind sequence from the opp table.
> The clock will be scaled down when framework sends an update.
>
> Fixes: 25fdd5933("drm/msm: Add SDM845 DPU support")
The "Fixes:" format is a little wrong. Should have more digits and a
space before the parenthesis. AKA:
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
> Signed-off-by: Vinod Polimera
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 8
> 1 file changed, 8 insertions(+)
This looks good to me now other than the bad Fixes tag. I presume
you'll want to spin with the extra verbosity in the CL description
that Stephen asked for, though.
Reviewed-by: Douglas Anderson
[PATCH] drm/msm/dsi: Use connector directly in msm_dsi_manager_connector_init()
The member 'msm_dsi->connector' isn't assigned until
msm_dsi_manager_connector_init() returns (see msm_dsi_modeset_init() and
how it assigns the return value). Therefore this pointer is going to be
NULL here. Let's use 'connector' which is what was intended.
Cc: Dmitry Baryshkov
Cc: Sean Paul
Fixes: 6d5e78406991 ("drm/msm/dsi: Move dsi panel init into modeset init path")
Signed-off-by: Stephen Boyd
---
I don't know if this is superseeded by something else but I found this
while trying to use the connector from msm_dsi in this function.
drivers/gpu/drm/msm/dsi/dsi_manager.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 0c1b7dde377c..9f6af0f0fe00 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -638,7 +638,7 @@ struct drm_connector *msm_dsi_manager_connector_init(u8 id)
return connector;
fail:
- connector->funcs->destroy(msm_dsi->connector);
+ connector->funcs->destroy(connector);
return ERR_PTR(ret);
}
base-commit: 05afd57f4d34602a652fdaf58e0a2756b3c20fd4
--
https://chromeos.dev
Re: [PATCH v5 4/9] drm/panel-edp: add LQ140M1JW46 edp panel entry
Hi, On Wed, Mar 16, 2022 at 10:37 AM Sankeerth Billakanti wrote: > > Add panel identification entry for the sharp LQ140M1JW46 eDP panel > with power sequencing delay information. > > Signed-off-by: Sankeerth Billakanti > --- > drivers/gpu/drm/panel/panel-edp.c | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Douglas Anderson This is trivial and going through a different tree than everything else, so I'm just pushing it to drm-misc-next (which is setup to land things without regard to the merge window) without sitting on it. You can leave it out of future spins of this series. 9f493fd71d4b drm/panel-edp: add LQ140M1JW46 edp panel entry
Re: [PATCH 2/4] drm/gma500: Move gma_intel_crtc_funcs into gma_display.c
Hi Patrik,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on drm-intel/for-linux-next drm-tip/drm-tip
drm-exynos/exynos-drm-next tegra-drm/drm/tegra/for-next v5.17-rc8 next-20220317]
[cannot apply to airlied/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Patrik-Jakobsson/drm-gma500-Remove-unused-declarations-and-other-cruft/20220317-172741
base: git://anongit.freedesktop.org/drm/drm drm-next
config: i386-randconfig-a004
(https://download.01.org/0day-ci/archive/20220318/202203180730.btyhkeem-...@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project
a6ec1e3d798f8eab43fb3a91028c6ab04e115fcb)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/cdcc3ba62afbe456eb16b00d5df129abf8db5ca1
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Patrik-Jakobsson/drm-gma500-Remove-unused-declarations-and-other-cruft/20220317-172741
git checkout cdcc3ba62afbe456eb16b00d5df129abf8db5ca1
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=i386 SHELL=/bin/bash drivers/gpu/drm/gma500/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/gma500/gma_display.c:175:5: warning: no previous prototype
>> for function 'gma_crtc_gamma_set' [-Wmissing-prototypes]
int gma_crtc_gamma_set(struct drm_crtc *crtc, u16 *red, u16 *green, u16
*blue,
^
drivers/gpu/drm/gma500/gma_display.c:175:1: note: declare 'static' if the
function is not intended to be used outside of this translation unit
int gma_crtc_gamma_set(struct drm_crtc *crtc, u16 *red, u16 *green, u16
*blue,
^
static
>> drivers/gpu/drm/gma500/gma_display.c:322:5: warning: no previous prototype
>> for function 'gma_crtc_cursor_set' [-Wmissing-prototypes]
int gma_crtc_cursor_set(struct drm_crtc *crtc,
^
drivers/gpu/drm/gma500/gma_display.c:322:1: note: declare 'static' if the
function is not intended to be used outside of this translation unit
int gma_crtc_cursor_set(struct drm_crtc *crtc,
^
static
>> drivers/gpu/drm/gma500/gma_display.c:440:5: warning: no previous prototype
>> for function 'gma_crtc_cursor_move' [-Wmissing-prototypes]
int gma_crtc_cursor_move(struct drm_crtc *crtc, int x, int y)
^
drivers/gpu/drm/gma500/gma_display.c:440:1: note: declare 'static' if the
function is not intended to be used outside of this translation unit
int gma_crtc_cursor_move(struct drm_crtc *crtc, int x, int y)
^
static
3 warnings generated.
vim +/gma_crtc_gamma_set +175 drivers/gpu/drm/gma500/gma_display.c
2eff0b3359c097b Patrik Jakobsson 2013-07-05 174
7ea7728387820a2 Maarten Lankhorst 2016-06-07 @175 int
gma_crtc_gamma_set(struct drm_crtc *crtc, u16 *red, u16 *green, u16 *blue,
6d124ff845334bc Daniel Vetter 2017-04-03 176 u32 size,
6d124ff845334bc Daniel Vetter 2017-04-03 177 struct
drm_modeset_acquire_ctx *ctx)
2eff0b3359c097b Patrik Jakobsson 2013-07-05 178 {
2eff0b3359c097b Patrik Jakobsson 2013-07-05 179 gma_crtc_load_lut(crtc);
7ea7728387820a2 Maarten Lankhorst 2016-06-07 180
7ea7728387820a2 Maarten Lankhorst 2016-06-07 181 return 0;
2eff0b3359c097b Patrik Jakobsson 2013-07-05 182 }
2eff0b3359c097b Patrik Jakobsson 2013-07-05 183
98daaba0a7c36dc Lee Jones 2021-01-15 184 /*
2eff0b3359c097b Patrik Jakobsson 2013-07-05 185 * Sets the power management
mode of the pipe and plane.
2eff0b3359c097b Patrik Jakobsson 2013-07-05 186 *
2eff0b3359c097b Patrik Jakobsson 2013-07-05 187 * This code should probably
grow support for turning the cursor off and back
2eff0b3359c097b Patrik Jakobsson 2013-07-05 188 * on appropriately at the
same time as we're turning the pipe off/on.
2eff0b3359c097b Patrik Jakobsson 2013-07-05 189 */
2eff0b3359c097b Patrik Jakobsson 2013-07-05 190 void gma_crtc_dpms(struct
drm_crtc *crtc, int mode)
2eff0b3359c097b Patrik Jakobsson 2013-07-05 191 {
2eff0b3359c097b Patrik Jakobsson 2013-07-05 192 struct drm_device *dev
= crtc->dev;
f71635e893c3832 Thomas Zimmermann 2021-09-20 193 struct drm_psb_private
*dev_priv = to_drm_psb_private(dev);
6306865daf0283d Patrik Jakobsson 2013-07-22 19
[PATCH] drm/panel: ili9341: fix optional regulator handling
If the optional regulator lookup fails, reset the pointer to NULL.
Other functions such as mipi_dbi_poweron_reset_conditional() only do
a NULL pointer check and will otherwise dereference the error pointer.
Fixes: 5a04227326b04c15 ("drm/panel: Add ilitek ili9341 panel driver")
Signed-off-by: Daniel Mack
---
drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
index 2c3378a259b1..e1542451ef9d 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
@@ -612,8 +612,10 @@ static int ili9341_dbi_probe(struct spi_device *spi,
struct gpio_desc *dc,
int ret;
vcc = devm_regulator_get_optional(dev, "vcc");
- if (IS_ERR(vcc))
+ if (IS_ERR(vcc)) {
dev_err(dev, "get optional vcc failed\n");
+ vcc = NULL;
+ }
dbidev = devm_drm_dev_alloc(dev, &ili9341_dbi_driver,
struct mipi_dbi_dev, drm);
--
2.35.1
Re: [PATCH 2/4] drm/gma500: Move gma_intel_crtc_funcs into gma_display.c
Hi Patrik,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on drm-intel/for-linux-next drm-tip/drm-tip
drm-exynos/exynos-drm-next tegra-drm/drm/tegra/for-next v5.17-rc8 next-20220317]
[cannot apply to airlied/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Patrik-Jakobsson/drm-gma500-Remove-unused-declarations-and-other-cruft/20220317-172741
base: git://anongit.freedesktop.org/drm/drm drm-next
config: i386-randconfig-m021
(https://download.01.org/0day-ci/archive/20220318/202203180653.zas8yxub-...@intel.com/config)
compiler: gcc-9 (Ubuntu 9.4.0-1ubuntu1~20.04) 9.4.0
reproduce (this is a W=1 build):
#
https://github.com/0day-ci/linux/commit/cdcc3ba62afbe456eb16b00d5df129abf8db5ca1
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Patrik-Jakobsson/drm-gma500-Remove-unused-declarations-and-other-cruft/20220317-172741
git checkout cdcc3ba62afbe456eb16b00d5df129abf8db5ca1
# save the config file to linux build tree
mkdir build_dir
make W=1 O=build_dir ARCH=i386 SHELL=/bin/bash drivers/gpu/drm/gma500/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/gma500/gma_display.c:175:5: warning: no previous prototype
>> for 'gma_crtc_gamma_set' [-Wmissing-prototypes]
175 | int gma_crtc_gamma_set(struct drm_crtc *crtc, u16 *red, u16 *green,
u16 *blue,
| ^~
>> drivers/gpu/drm/gma500/gma_display.c:322:5: warning: no previous prototype
>> for 'gma_crtc_cursor_set' [-Wmissing-prototypes]
322 | int gma_crtc_cursor_set(struct drm_crtc *crtc,
| ^~~
>> drivers/gpu/drm/gma500/gma_display.c:440:5: warning: no previous prototype
>> for 'gma_crtc_cursor_move' [-Wmissing-prototypes]
440 | int gma_crtc_cursor_move(struct drm_crtc *crtc, int x, int y)
| ^~~~
vim +/gma_crtc_gamma_set +175 drivers/gpu/drm/gma500/gma_display.c
2eff0b3359c097 Patrik Jakobsson 2013-07-05 174
7ea7728387820a Maarten Lankhorst 2016-06-07 @175 int gma_crtc_gamma_set(struct
drm_crtc *crtc, u16 *red, u16 *green, u16 *blue,
6d124ff845334b Daniel Vetter 2017-04-03 176 u32 size,
6d124ff845334b Daniel Vetter 2017-04-03 177 struct
drm_modeset_acquire_ctx *ctx)
2eff0b3359c097 Patrik Jakobsson 2013-07-05 178 {
2eff0b3359c097 Patrik Jakobsson 2013-07-05 179gma_crtc_load_lut(crtc);
7ea7728387820a Maarten Lankhorst 2016-06-07 180
7ea7728387820a Maarten Lankhorst 2016-06-07 181return 0;
2eff0b3359c097 Patrik Jakobsson 2013-07-05 182 }
2eff0b3359c097 Patrik Jakobsson 2013-07-05 183
98daaba0a7c36d Lee Jones 2021-01-15 184 /*
2eff0b3359c097 Patrik Jakobsson 2013-07-05 185 * Sets the power management
mode of the pipe and plane.
2eff0b3359c097 Patrik Jakobsson 2013-07-05 186 *
2eff0b3359c097 Patrik Jakobsson 2013-07-05 187 * This code should probably
grow support for turning the cursor off and back
2eff0b3359c097 Patrik Jakobsson 2013-07-05 188 * on appropriately at the
same time as we're turning the pipe off/on.
2eff0b3359c097 Patrik Jakobsson 2013-07-05 189 */
2eff0b3359c097 Patrik Jakobsson 2013-07-05 190 void gma_crtc_dpms(struct
drm_crtc *crtc, int mode)
2eff0b3359c097 Patrik Jakobsson 2013-07-05 191 {
2eff0b3359c097 Patrik Jakobsson 2013-07-05 192struct drm_device *dev
= crtc->dev;
f71635e893c383 Thomas Zimmermann 2021-09-20 193struct drm_psb_private
*dev_priv = to_drm_psb_private(dev);
6306865daf0283 Patrik Jakobsson 2013-07-22 194struct gma_crtc
*gma_crtc = to_gma_crtc(crtc);
6306865daf0283 Patrik Jakobsson 2013-07-22 195int pipe =
gma_crtc->pipe;
2eff0b3359c097 Patrik Jakobsson 2013-07-05 196const struct psb_offset
*map = &dev_priv->regmap[pipe];
2eff0b3359c097 Patrik Jakobsson 2013-07-05 197u32 temp;
2eff0b3359c097 Patrik Jakobsson 2013-07-05 198
2eff0b3359c097 Patrik Jakobsson 2013-07-05 199/* XXX: When our
outputs are all unaware of DPMS modes other than off
2eff0b3359c097 Patrik Jakobsson 2013-07-05 200 * and on, we should
map those modes to DRM_MODE_DPMS_OFF in the CRTC.
2eff0b3359c097 Patrik Jakobsson 2013-07-05 201 */
2eff0b3359c097 Patrik Jakobsson 2013-07-05 202
2eff0b3359c097 Patrik Jakobsson 2013-07-05 203if (IS_CDV(dev))
75346fe9bc4c9b Patrik Jakobsson 2013-08-15 204
dev_priv->ops->disable_sr(dev);
2eff0b3359c09
[RFC] drm/msm: Add a way for userspace to allocate GPU iova
From: Rob Clark
The motivation at this point is mainly native userspace mesa driver in a
VM guest. The one remaining synchronous "hotpath" is buffer allocation,
because guest needs to wait to know the bo's iova before it can start
emitting cmdstream/state that references the new bo. By allocating the
iova in the guest userspace, we no longer need to wait for a response
from the host, but can just rely on the allocation request being
processed before the cmdstream submission. Allocation faulures (OoM,
etc) would just be treated as context-lost (ie. GL_GUILTY_CONTEXT_RESET)
or subsequent allocations (or readpix, etc) can raise GL_OUT_OF_MEMORY.
TODO bump uapi version, or combine w/ other changes that bump uapi
version
Signed-off-by: Rob Clark
---
So, I was initially planning on adding some extra guard-rails, ie.
some userspace opt-in and preventing mixing of kernel and userspace
allocated iova. Because in general mixing and matching userspace and
kernel allocated iova is not going to go over too well.
But the address-space is per drm_file, and I couldn't come up with
any scenario where, on a given drm device fd, we would be trying to
mix/match userspace doing kernel iova allocation vs userspace iova
allocation.
Ofc, now is a good time to prove me wrong ;-)
drivers/gpu/drm/msm/msm_drv.c | 21 +
drivers/gpu/drm/msm/msm_gem.c | 20
drivers/gpu/drm/msm/msm_gem.h | 2 ++
include/uapi/drm/msm_drm.h| 1 +
4 files changed, 44 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index a5eed5738ac8..7394312cf075 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -719,6 +719,23 @@ static int msm_ioctl_gem_info_iova(struct drm_device *dev,
return msm_gem_get_iova(obj, ctx->aspace, iova);
}
+static int msm_ioctl_gem_info_set_iova(struct drm_device *dev,
+ struct drm_file *file, struct drm_gem_object *obj,
+ uint64_t iova)
+{
+ struct msm_drm_private *priv = dev->dev_private;
+ struct msm_file_private *ctx = file->driver_priv;
+
+ if (!priv->gpu)
+ return -EINVAL;
+
+ /* Only supported if per-process address space is supported: */
+ if (priv->gpu->aspace == ctx->aspace)
+ return -EINVAL;
+
+ return msm_gem_set_iova(obj, ctx->aspace, iova);
+}
+
static int msm_ioctl_gem_info(struct drm_device *dev, void *data,
struct drm_file *file)
{
@@ -733,6 +750,7 @@ static int msm_ioctl_gem_info(struct drm_device *dev, void
*data,
switch (args->info) {
case MSM_INFO_GET_OFFSET:
case MSM_INFO_GET_IOVA:
+ case MSM_INFO_SET_IOVA:
/* value returned as immediate, not pointer, so len==0: */
if (args->len)
return -EINVAL;
@@ -757,6 +775,9 @@ static int msm_ioctl_gem_info(struct drm_device *dev, void
*data,
case MSM_INFO_GET_IOVA:
ret = msm_ioctl_gem_info_iova(dev, file, obj, &args->value);
break;
+ case MSM_INFO_SET_IOVA:
+ ret = msm_ioctl_gem_info_set_iova(dev, file, obj, args->value);
+ break;
case MSM_INFO_SET_NAME:
/* length check should leave room for terminating null: */
if (args->len >= sizeof(msm_obj->name)) {
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index a4f61972667b..41ae8d9c8b3c 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -510,6 +510,26 @@ int msm_gem_get_iova(struct drm_gem_object *obj,
return ret;
}
+/*
+ * Get the requested iova but don't pin it. Fails if the requested iova is
+ * not available. Doesn't need a put because iovas are currently valid for
+ * the life of the object
+ */
+int msm_gem_set_iova(struct drm_gem_object *obj,
+ struct msm_gem_address_space *aspace, uint64_t iova)
+{
+ int ret;
+ uint64_t assigned_iova;
+
+ msm_gem_lock(obj);
+ ret = get_iova_locked(obj, aspace, &assigned_iova,
+ iova >> PAGE_SHIFT,
+ (iova + obj->size) >> PAGE_SHIFT);
+ msm_gem_unlock(obj);
+
+ return ret;
+}
+
/* get iova without taking a reference, used in places where you have
* already done a 'msm_gem_get_and_pin_iova' or 'msm_gem_get_iova'
*/
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index 58e11c282928..40d839f61d15 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -112,6 +112,8 @@ struct msm_gem_object {
uint64_t msm_gem_mmap_offset(struct drm_gem_object *obj);
int msm_gem_get_iova(struct drm_gem_object *obj,
struct msm_gem_address_space *aspace, uint64_t *iova);
+int msm_gem_set_iova(struct drm_gem_object *obj,
+ struct msm_gem_address_space *aspace, uint64_t iova);
int msm_gem_get_and_pin_iova_range
Re: [PATCH 1/4] drm/gma500: Remove unused declarations and other cruft
Hi Patrik,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on drm-intel/for-linux-next drm-tip/drm-tip
drm-exynos/exynos-drm-next tegra-drm/drm/tegra/for-next v5.17-rc8 next-20220317]
[cannot apply to airlied/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Patrik-Jakobsson/drm-gma500-Remove-unused-declarations-and-other-cruft/20220317-172741
base: git://anongit.freedesktop.org/drm/drm drm-next
config: i386-randconfig-a011
(https://download.01.org/0day-ci/archive/20220318/202203180538.gwcm5aba-...@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project
a6ec1e3d798f8eab43fb3a91028c6ab04e115fcb)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/0d50efabcb4ad52bd7a036e2542dbf51bbcf93b4
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Patrik-Jakobsson/drm-gma500-Remove-unused-declarations-and-other-cruft/20220317-172741
git checkout 0d50efabcb4ad52bd7a036e2542dbf51bbcf93b4
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=i386 SHELL=/bin/bash drivers/gpu/drm/gma500/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/gma500/psb_drv.c:102:6: warning: no previous prototype for
>> function 'psb_spank' [-Wmissing-prototypes]
void psb_spank(struct drm_psb_private *dev_priv)
^
drivers/gpu/drm/gma500/psb_drv.c:102:1: note: declare 'static' if the
function is not intended to be used outside of this translation unit
void psb_spank(struct drm_psb_private *dev_priv)
^
static
drivers/gpu/drm/gma500/psb_drv.c:419:20: warning: unused function
'get_brightness' [-Wunused-function]
static inline void get_brightness(struct backlight_device *bd)
^
2 warnings generated.
vim +/psb_spank +102 drivers/gpu/drm/gma500/psb_drv.c
5c49fd3aa0ab02 Alan Cox 2011-11-03 95
5c209d8056b976 Patrik Jakobsson 2021-02-01 96 /**
5c209d8056b976 Patrik Jakobsson 2021-02-01 97 * psb_spank
- reset the 2D engine
5c209d8056b976 Patrik Jakobsson 2021-02-01 98 * @dev_priv: our PSB DRM
device
5c209d8056b976 Patrik Jakobsson 2021-02-01 99 *
5c209d8056b976 Patrik Jakobsson 2021-02-01 100 * Soft reset the graphics
engine and then reload the necessary registers.
5c209d8056b976 Patrik Jakobsson 2021-02-01 101 */
5c209d8056b976 Patrik Jakobsson 2021-02-01 @102 void psb_spank(struct
drm_psb_private *dev_priv)
5c209d8056b976 Patrik Jakobsson 2021-02-01 103 {
5c209d8056b976 Patrik Jakobsson 2021-02-01 104
PSB_WSGX32(_PSB_CS_RESET_BIF_RESET | _PSB_CS_RESET_DPM_RESET |
5c209d8056b976 Patrik Jakobsson 2021-02-01 105
_PSB_CS_RESET_TA_RESET | _PSB_CS_RESET_USE_RESET |
5c209d8056b976 Patrik Jakobsson 2021-02-01 106
_PSB_CS_RESET_ISP_RESET | _PSB_CS_RESET_TSP_RESET |
5c209d8056b976 Patrik Jakobsson 2021-02-01 107
_PSB_CS_RESET_TWOD_RESET, PSB_CR_SOFT_RESET);
5c209d8056b976 Patrik Jakobsson 2021-02-01 108
PSB_RSGX32(PSB_CR_SOFT_RESET);
5c209d8056b976 Patrik Jakobsson 2021-02-01 109
5c209d8056b976 Patrik Jakobsson 2021-02-01 110 msleep(1);
5c209d8056b976 Patrik Jakobsson 2021-02-01 111
5c209d8056b976 Patrik Jakobsson 2021-02-01 112 PSB_WSGX32(0,
PSB_CR_SOFT_RESET);
5c209d8056b976 Patrik Jakobsson 2021-02-01 113 wmb();
5c209d8056b976 Patrik Jakobsson 2021-02-01 114
PSB_WSGX32(PSB_RSGX32(PSB_CR_BIF_CTRL) | _PSB_CB_CTRL_CLEAR_FAULT,
5c209d8056b976 Patrik Jakobsson 2021-02-01 115
PSB_CR_BIF_CTRL);
5c209d8056b976 Patrik Jakobsson 2021-02-01 116 wmb();
5c209d8056b976 Patrik Jakobsson 2021-02-01 117 (void)
PSB_RSGX32(PSB_CR_BIF_CTRL);
5c209d8056b976 Patrik Jakobsson 2021-02-01 118
5c209d8056b976 Patrik Jakobsson 2021-02-01 119 msleep(1);
5c209d8056b976 Patrik Jakobsson 2021-02-01 120
PSB_WSGX32(PSB_RSGX32(PSB_CR_BIF_CTRL) & ~_PSB_CB_CTRL_CLEAR_FAULT,
5c209d8056b976 Patrik Jakobsson 2021-02-01 121
PSB_CR_BIF_CTRL);
5c209d8056b976 Patrik Jakobsson 2021-02-01 122 (void)
PSB_RSGX32(PSB_CR_BIF_CTRL);
5c209d8056b976 Patrik Jakobsson 2021-02-01 123
PSB_WSGX32(dev_priv->gtt.gatt_start, PSB_CR_BIF_TWOD_REQ_BASE);
5c209d8
[PATCH] drm/panel: ld9040: Register a backlight device
Register a backlight device to be able to switch between all the gamma
levels.
While this works, and improves the situation, on my device (Galaxy S2
I9100) the screen does not yet look as good as how it did under Android,
independently of the gamma setting. The blacks are washed and look grey,
while they did look perfectly black on Android thanks to the AMOLED
technology.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/panel/panel-samsung-ld9040.c | 40
1 file changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-samsung-ld9040.c
b/drivers/gpu/drm/panel/panel-samsung-ld9040.c
index c4b388850a13..0dd21a809309 100644
--- a/drivers/gpu/drm/panel/panel-samsung-ld9040.c
+++ b/drivers/gpu/drm/panel/panel-samsung-ld9040.c
@@ -8,6 +8,7 @@
* Andrzej Hajda
*/
+#include
#include
#include
#include
@@ -310,8 +311,40 @@ static int ld9040_parse_dt(struct ld9040 *ctx)
return 0;
}
+static int ld9040_bl_update_status(struct backlight_device *dev)
+{
+ struct ld9040 *ctx = dev_get_drvdata(&dev->dev);
+
+ ctx->brightness = dev->props.brightness;
+ ld9040_brightness_set(ctx);
+
+ return 0;
+}
+
+static int ld9040_bl_get_intensity(struct backlight_device *dev)
+{
+ if (dev->props.fb_blank == FB_BLANK_UNBLANK &&
+ dev->props.power == FB_BLANK_UNBLANK)
+ return dev->props.brightness;
+
+ return 0;
+}
+
+static const struct backlight_ops ld9040_bl_ops = {
+ .get_brightness = ld9040_bl_get_intensity,
+ .update_status = ld9040_bl_update_status,
+};
+
+static const struct backlight_properties ld9040_bl_props = {
+ .type = BACKLIGHT_RAW,
+ .scale = BACKLIGHT_SCALE_NON_LINEAR,
+ .max_brightness = ARRAY_SIZE(ld9040_gammas) - 1,
+ .brightness = ARRAY_SIZE(ld9040_gammas) - 1,
+};
+
static int ld9040_probe(struct spi_device *spi)
{
+ struct backlight_device *bldev;
struct device *dev = &spi->dev;
struct ld9040 *ctx;
int ret;
@@ -353,6 +386,13 @@ static int ld9040_probe(struct spi_device *spi)
drm_panel_init(&ctx->panel, dev, &ld9040_drm_funcs,
DRM_MODE_CONNECTOR_DPI);
+
+ bldev = devm_backlight_device_register(dev, dev_name(dev), dev,
+ ctx, &ld9040_bl_ops,
+ &ld9040_bl_props);
+ if (IS_ERR(bldev))
+ return PTR_ERR(bldev);
+
drm_panel_add(&ctx->panel);
return 0;
--
2.35.1
Re: [PATCH v5 5/9] drm/msm/dp: Add eDP support via aux_bus
Quoting Sankeerth Billakanti (2022-03-16 10:35:50)
> This patch adds support for generic eDP sink through aux_bus.
Please unindent commit text paragraphs. This isn't a book.
> The eDP/DP controller driver should support aux transactions originating
> from the panel-edp driver and hence should be initialized and ready.
>
> The panel bridge supporting the panel should be ready before
> the bridge connector is initialized. The generic panel probe needs the
> controller resources to be enabled to support aux tractions originating
s/tractions/transactions/
> from it. So, the host_init and phy_init are moved to execute before the
> panel probe.
>
> The host_init has to return early if the core is already
> initialized so that the regulator and clock votes for the controller
> resources are balanced.
>
> EV_HPD_INIT_SETUP needs to execute immediately to enable the
> interrupts for the aux transactions from panel-edp to get the modes
> supported.
There are a lot of things going on in this patch. Can it be split up?
>
> Signed-off-by: Sankeerth Billakanti
> ---
> drivers/gpu/drm/msm/dp/dp_display.c | 65
> +++--
> drivers/gpu/drm/msm/dp/dp_drm.c | 10 +++---
> drivers/gpu/drm/msm/dp/dp_parser.c | 21 +---
> drivers/gpu/drm/msm/dp/dp_parser.h | 1 +
> 4 files changed, 70 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
> b/drivers/gpu/drm/msm/dp/dp_display.c
> index 382b3aa..688bbed 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
>
> #include "msm_drv.h"
> #include "msm_kms.h"
> @@ -265,8 +266,6 @@ static int dp_display_bind(struct device *dev, struct
> device *master,
> goto end;
> }
>
> - dp->dp_display.next_bridge = dp->parser->next_bridge;
> -
> dp->aux->drm_dev = drm;
> rc = dp_aux_register(dp->aux);
> if (rc) {
> @@ -421,6 +420,11 @@ static void dp_display_host_init(struct
> dp_display_private *dp)
> dp->dp_display.connector_type, dp->core_initialized,
> dp->phy_initialized);
>
> + if (dp->core_initialized) {
> + DRM_DEBUG_DP("DP core already initialized\n");
> + return;
> + }
> +
> dp_power_init(dp->power, false);
> dp_ctrl_reset_irq_ctrl(dp->ctrl, true);
> dp_aux_init(dp->aux);
> @@ -433,6 +437,11 @@ static void dp_display_host_deinit(struct
> dp_display_private *dp)
> dp->dp_display.connector_type, dp->core_initialized,
> dp->phy_initialized);
>
> + if (!dp->core_initialized) {
> + DRM_DEBUG_DP("DP core not initialized\n");
> + return;
> + }
> +
> dp_ctrl_reset_irq_ctrl(dp->ctrl, false);
> dp_aux_deinit(dp->aux);
> dp_power_deinit(dp->power);
> @@ -1502,7 +1511,7 @@ void msm_dp_irq_postinstall(struct msm_dp *dp_display)
>
> dp_hpd_event_setup(dp);
>
> - dp_add_event(dp, EV_HPD_INIT_SETUP, 0, 100);
> + dp_add_event(dp, EV_HPD_INIT_SETUP, 0, 0);
> }
>
> void msm_dp_debugfs_init(struct msm_dp *dp_display, struct drm_minor *minor)
> @@ -1524,6 +1533,52 @@ void msm_dp_debugfs_init(struct msm_dp *dp_display,
> struct drm_minor *minor)
> }
> }
>
> +static int dp_display_get_next_bridge(struct msm_dp *dp)
> +{
> + int rc = 0;
Drop initialization.
> + struct dp_display_private *dp_priv;
> + struct device_node *aux_bus;
> + struct device *dev;
> +
> + dp_priv = container_of(dp, struct dp_display_private, dp_display);
> + dev = &dp_priv->pdev->dev;
> + aux_bus = of_get_child_by_name(dev->of_node, "aux-bus");
> +
> + if (aux_bus) {
> + dp_display_host_init(dp_priv);
> + dp_catalog_ctrl_hpd_config(dp_priv->catalog);
> + enable_irq(dp_priv->irq);
> + dp_display_host_phy_init(dp_priv);
> +
> + devm_of_dp_aux_populate_ep_devices(dp_priv->aux);
> +
> + disable_irq(dp_priv->irq);
Why do we disable irq?
> + }
The aux_bus node leaked.
> +
> + /*
> +* External bridges are mandatory for eDP interfaces: one has to
> +* provide at least an eDP panel (which gets wrapped into
> panel-bridge).
> +*
> +* For DisplayPort interfaces external bridges are optional, so
> +* silently ignore an error if one is not present (-ENODEV).
> +*/
> + rc = dp_parser_find_next_bridge(dp_priv->parser);
> + if (rc == -ENODEV) {
> + if (dp->connector_type == DRM_MODE_CONNECTOR_eDP) {
> + DRM_ERROR("eDP: next bridge is not present\n");
> + return rc;
> + }
> + } else if (rc) {
> + if (rc != -EPROBE_DEFER)
> + DRM_ERROR("
Re: [PATCH 4/4] drm/gma500: Cosmetic cleanup of irq code
On Thu, Mar 17, 2022 at 8:57 PM Thomas Zimmermann wrote:
>
> Hi Patrik
>
> Am 17.03.22 um 10:25 schrieb Patrik Jakobsson:
> > Use the gma_ prefix instead of psb_ since the code is common for all
> > chips. Various coding style fixes. Removal of unused code. Removal of
> > duplicate function declarations.
> >
> > Signed-off-by: Patrik Jakobsson
> > ---
> > drivers/gpu/drm/gma500/gma_display.c | 8 +--
> > drivers/gpu/drm/gma500/opregion.c| 5 +-
> > drivers/gpu/drm/gma500/power.c | 10 +--
> > drivers/gpu/drm/gma500/psb_drv.c | 2 +-
> > drivers/gpu/drm/gma500/psb_drv.h | 11
> > drivers/gpu/drm/gma500/psb_irq.c | 94 +++-
> > drivers/gpu/drm/gma500/psb_irq.h | 19 +++---
> > 7 files changed, 57 insertions(+), 92 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/gma500/gma_display.c
> > b/drivers/gpu/drm/gma500/gma_display.c
> > index 931ffb192fc4..1d7964c339f4 100644
> > --- a/drivers/gpu/drm/gma500/gma_display.c
> > +++ b/drivers/gpu/drm/gma500/gma_display.c
> > @@ -17,7 +17,7 @@
> > #include "framebuffer.h"
> > #include "gem.h"
> > #include "gma_display.h"
> > -#include "psb_drv.h"
> > +#include "psb_irq.h"
> > #include "psb_intel_drv.h"
> > #include "psb_intel_reg.h"
> >
> > @@ -572,9 +572,9 @@ const struct drm_crtc_funcs gma_crtc_funcs = {
> > .set_config = gma_crtc_set_config,
> > .destroy = gma_crtc_destroy,
> > .page_flip = gma_crtc_page_flip,
> > - .enable_vblank = psb_enable_vblank,
> > - .disable_vblank = psb_disable_vblank,
> > - .get_vblank_counter = psb_get_vblank_counter,
> > + .enable_vblank = gma_enable_vblank,
> > + .disable_vblank = gma_disable_vblank,
> > + .get_vblank_counter = gma_get_vblank_counter,
>
> I'd prefix these functions with gma_crtc_ to align their naming with the
> others. They are CRTC functions, after all.
Yes, that makes sense. I'll send a follow-up patch.
>
> Apart from that,
>
> Reviewed-by: Thomas Zimmermann
>
> Best regards
> Thomas
>
> > };
> >
> > /*
> > diff --git a/drivers/gpu/drm/gma500/opregion.c
> > b/drivers/gpu/drm/gma500/opregion.c
> > index fef04ff8c3a9..dc494df71a48 100644
> > --- a/drivers/gpu/drm/gma500/opregion.c
> > +++ b/drivers/gpu/drm/gma500/opregion.c
> > @@ -23,6 +23,7 @@
> >*/
> > #include
> > #include "psb_drv.h"
> > +#include "psb_irq.h"
> > #include "psb_intel_reg.h"
> >
> > #define PCI_ASLE 0xe4
> > @@ -217,8 +218,8 @@ void psb_intel_opregion_enable_asle(struct drm_device
> > *dev)
> > if (asle && system_opregion ) {
> > /* Don't do this on Medfield or other non PC like devices,
> > they
> > use the bit for something different altogether */
> > - psb_enable_pipestat(dev_priv, 0,
> > PIPE_LEGACY_BLC_EVENT_ENABLE);
> > - psb_enable_pipestat(dev_priv, 1,
> > PIPE_LEGACY_BLC_EVENT_ENABLE);
> > + gma_enable_pipestat(dev_priv, 0,
> > PIPE_LEGACY_BLC_EVENT_ENABLE);
> > + gma_enable_pipestat(dev_priv, 1,
> > PIPE_LEGACY_BLC_EVENT_ENABLE);
> >
> > asle->tche = ASLE_ALS_EN | ASLE_BLC_EN | ASLE_PFIT_EN
> > |
> > ASLE_PFMB_EN;
> > diff --git a/drivers/gpu/drm/gma500/power.c b/drivers/gpu/drm/gma500/power.c
> > index 6f917cfef65b..b91de6d36e41 100644
> > --- a/drivers/gpu/drm/gma500/power.c
> > +++ b/drivers/gpu/drm/gma500/power.c
> > @@ -201,7 +201,7 @@ int gma_power_suspend(struct device *_dev)
> > dev_err(dev->dev, "GPU hardware busy, cannot
> > suspend\n");
> > return -EBUSY;
> > }
> > - psb_irq_uninstall(dev);
> > + gma_irq_uninstall(dev);
> > gma_suspend_display(dev);
> > gma_suspend_pci(pdev);
> > }
> > @@ -223,8 +223,8 @@ int gma_power_resume(struct device *_dev)
> > mutex_lock(&power_mutex);
> > gma_resume_pci(pdev);
> > gma_resume_display(pdev);
> > - psb_irq_preinstall(dev);
> > - psb_irq_postinstall(dev);
> > + gma_irq_preinstall(dev);
> > + gma_irq_postinstall(dev);
> > mutex_unlock(&power_mutex);
> > return 0;
> > }
> > @@ -270,8 +270,8 @@ bool gma_power_begin(struct drm_device *dev, bool
> > force_on)
> > /* Ok power up needed */
> > ret = gma_resume_pci(pdev);
> > if (ret == 0) {
> > - psb_irq_preinstall(dev);
> > - psb_irq_postinstall(dev);
> > + gma_irq_preinstall(dev);
> > + gma_irq_postinstall(dev);
> > pm_runtime_get(dev->dev);
> > dev_priv->display_count++;
> > spin_unlock_irqrestore(&power_ctrl_lock, flags);
> > diff --git a/drivers/gpu/drm/gma500/psb_drv.c
> > b/drivers/gpu/drm/gma500/psb_drv.c
> > index e30b58184156..82d51e9821ad 100644
> > --- a/drivers/gpu/drm/gma500/psb_drv.c
> > +++ b/drivers/gpu/drm/gma500/psb_drv.c
> > @@ -380,7 +380,7 @@ static in
Re: [PATCH 1/4] drm/gma500: Remove unused declarations and other cruft
On Thu, Mar 17, 2022 at 8:44 PM Thomas Zimmermann wrote:
>
> Hi Patrik
Hi Thomas and Sam,
I have already pushed this series with Daniels ack so I'll address any
issues in follow-up patches.
Thanks for the extra eyes
>
> Am 17.03.22 um 10:25 schrieb Patrik Jakobsson:
> > Most of these are old leftovers from one of the driver merges. This is
> > all dead code.
> >
> > Signed-off-by: Patrik Jakobsson
> > ---
> > drivers/gpu/drm/gma500/psb_drv.h | 75 +---
> > 1 file changed, 1 insertion(+), 74 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/gma500/psb_drv.h
> > b/drivers/gpu/drm/gma500/psb_drv.h
> > index 553d03190ce1..66f61909a8c8 100644
> > --- a/drivers/gpu/drm/gma500/psb_drv.h
> > +++ b/drivers/gpu/drm/gma500/psb_drv.h
> > @@ -36,12 +36,6 @@
> > /* Append new drm mode definition here, align with libdrm definition */
> > #define DRM_MODE_SCALE_NO_SCALE 2
> >
> > -enum {
> > - CHIP_PSB_8108 = 0, /* Poulsbo */
> > - CHIP_PSB_8109 = 1, /* Poulsbo */
> > - CHIP_MRST_4100 = 2, /* Moorestown/Oaktrail */
> > -};
> > -
> > #define IS_PSB(drm) ((to_pci_dev((drm)->dev)->device & 0xfffe) == 0x8108)
> > #define IS_MRST(drm) ((to_pci_dev((drm)->dev)->device & 0xfff0) == 0x4100)
> > #define IS_CDV(drm) ((to_pci_dev((drm)->dev)->device & 0xfff0) == 0x0be0)
> > @@ -617,15 +611,7 @@ struct psb_ops {
> > int i2c_bus;/* I2C bus identifier for Moorestown */
> > };
> >
> > -
> > -
> > -extern int drm_crtc_probe_output_modes(struct drm_device *dev, int, int);
> > -extern int drm_pick_crtcs(struct drm_device *dev);
> > -
> > /* psb_irq.c */
> > -extern void psb_irq_uninstall_islands(struct drm_device *dev, int
> > hw_islands);
> > -extern int psb_vblank_wait2(struct drm_device *dev, unsigned int
> > *sequence);
> > -extern int psb_vblank_wait(struct drm_device *dev, unsigned int *sequence);
> > extern int psb_enable_vblank(struct drm_crtc *crtc);
> > extern void psb_disable_vblank(struct drm_crtc *crtc);
>
> The vblank enable/disable functions are also declared in psb_irq.h. The
> declarations here could be removed as well.
They get removed in patch 4/4 in this series.
>
> > void
> > @@ -636,17 +622,9 @@ psb_disable_pipestat(struct drm_psb_private *dev_priv,
> > int pipe, u32 mask);
> >
> > extern u32 psb_get_vblank_counter(struct drm_crtc *crtc);
> >
> > -/* framebuffer.c */
> > -extern int psbfb_probed(struct drm_device *dev);
> > -extern int psbfb_remove(struct drm_device *dev,
> > - struct drm_framebuffer *fb);
> > -/* psb_drv.c */
> > -extern void psb_spank(struct drm_psb_private *dev_priv);
>
> This function is still around in psb_drv.c. It should now be declared
> static.
Yes it should be static. I have a patch that renames this function
(psb_spank is a really bad name). I'll make it static in that patch.
>
> Best regards
> Thomas
>
> > -
> > -/* psb_reset.c */
> > +/* psb_lid.c */
> > extern void psb_lid_timer_init(struct drm_psb_private *dev_priv);
> > extern void psb_lid_timer_takedown(struct drm_psb_private *dev_priv);
> > -extern void psb_print_pagefault(struct drm_psb_private *dev_priv);
> >
> > /* modesetting */
> > extern void psb_modeset_init(struct drm_device *dev);
> > @@ -689,43 +667,7 @@ extern const struct psb_ops oaktrail_chip_ops;
> > /* cdv_device.c */
> > extern const struct psb_ops cdv_chip_ops;
> >
> > -/* Debug print bits setting */
> > -#define PSB_D_GENERAL (1 << 0)
> > -#define PSB_D_INIT(1 << 1)
> > -#define PSB_D_IRQ (1 << 2)
> > -#define PSB_D_ENTRY (1 << 3)
> > -/* debug the get H/V BP/FP count */
> > -#define PSB_D_HV (1 << 4)
> > -#define PSB_D_DBI_BF (1 << 5)
> > -#define PSB_D_PM (1 << 6)
> > -#define PSB_D_RENDER (1 << 7)
> > -#define PSB_D_REG (1 << 8)
> > -#define PSB_D_MSVDX (1 << 9)
> > -#define PSB_D_TOPAZ (1 << 10)
> > -
> > -extern int drm_idle_check_interval;
> > -
> > /* Utilities */
> > -static inline u32 MRST_MSG_READ32(int domain, uint port, uint offset)
> > -{
> > - int mcr = (0xD0<<24) | (port << 16) | (offset << 8);
> > - uint32_t ret_val = 0;
> > - struct pci_dev *pci_root = pci_get_domain_bus_and_slot(domain, 0, 0);
> > - pci_write_config_dword(pci_root, 0xD0, mcr);
> > - pci_read_config_dword(pci_root, 0xD4, &ret_val);
> > - pci_dev_put(pci_root);
> > - return ret_val;
> > -}
> > -static inline void MRST_MSG_WRITE32(int domain, uint port, uint offset,
> > - u32 value)
> > -{
> > - int mcr = (0xE0<<24) | (port << 16) | (offset << 8) | 0xF0;
> > - struct pci_dev *pci_root = pci_get_domain_bus_and_slot(domain, 0, 0);
> > - pci_write_config_dword(pci_root, 0xD4, value);
> > - pci_write_config_dword(pci_root, 0xD0, mcr);
> > - pci_dev_put(pci_root);
> > -}
> > -
> > static inline uint32_t REGISTER_READ(struct drm_device *dev, uint32_t reg)
> > {
> > struct drm_psb_private *dev_priv = to_d
Re: [PATCH v5 4/9] drm/panel-edp: add LQ140M1JW46 edp panel entry
Quoting Sankeerth Billakanti (2022-03-16 10:35:49) > Add panel identification entry for the sharp LQ140M1JW46 eDP panel > with power sequencing delay information. > > Signed-off-by: Sankeerth Billakanti > --- Reviewed-by: Stephen Boyd
Re: [PATCH v5 3/9] arm64: dts: qcom: sc7280: Enable backlight for eDP panel
Quoting Sankeerth Billakanti (2022-03-16 10:35:48)
> Enable backlight support for eDP panel on CRD platform for sc7280.
>
> Signed-off-by: Sankeerth Billakanti
> ---
>
> Changes in v5:
> - Separate out backlight nodes
>
> arch/arm64/boot/dts/qcom/sc7280-crd.dts | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> index 2df654e..16d1a5b 100644
> --- a/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> +++ b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> @@ -37,6 +37,15 @@
> pinctrl-0 = <&edp_panel_power>;
> };
>
> + edp_backlight: edp-backlight {
Does this also move to qcard.dtsi? Why can't this be combined with the
previous patch?
> + compatible = "pwm-backlight";
> +
> + power-supply = <&vreg_edp_bp>;
> + pwms = <&pm8350c_pwm 3 65535>;
> +
> + enable-gpios = <&pm8350c_gpios 7 GPIO_ACTIVE_HIGH>;
> + };
> +
> vreg_edp_bp: vreg-edp-bp-regulator {
> compatible = "regulator-fixed";
> regulator-name = "vreg_edp_bp";
> @@ -123,7 +132,9 @@ ap_ts_pen_1v8: &i2c13 {
> edp_panel: edp-panel {
> compatible = "edp-panel";
>
> + backlight = <&edp_backlight>;
> power-supply = <&edp_3v3_regulator>;
> +
Nitpick: Remove this newline from this hunk and put it in when
power-supply is introduced.
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -172,6 +183,13 @@ ap_ts_pen_1v8: &i2c13 {
> };
> };
>
> +&pm8350c_pwm {
> + status = "okay";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&edp_bl_pwm>;
I see the pinctrl is used now but it would be easier to review this
patch if the pinctrl was in this patch.
Re: [PATCH v5 2/9] arm64: dts: qcom: sc7280: Add support for eDP panel on CRD
Quoting Sankeerth Billakanti (2022-03-16 10:35:47)
> diff --git a/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> index e2efbdd..2df654e 100644
> --- a/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> +++ b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> @@ -7,6 +7,7 @@
>
> /dts-v1/;
>
> +#include
> #include "sc7280-idp.dtsi"
> #include "sc7280-idp-ec-h1.dtsi"
>
> @@ -21,6 +22,27 @@
> chosen {
> stdout-path = "serial0:115200n8";
> };
> +
> + edp_3v3_regulator: edp-3v3-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "edp_3v3_regulator";
> +
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> +
> + gpio = <&tlmm 80 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&edp_panel_power>;
> + };
> +
> + vreg_edp_bp: vreg-edp-bp-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "vreg_edp_bp";
> + regulator-always-on;
> + regulator-boot-on;
> + };
> };
>
> &apps_rsc {
> @@ -76,6 +98,58 @@ ap_ts_pen_1v8: &i2c13 {
> };
> };
>
> +&mdss {
> + status = "okay";
> +};
> +
> +&mdss_dp {
> + status = "okay";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&dp_hot_plug_det>;
> + data-lanes = <0 1>;
> + vdda-1p2-supply = <&vreg_l6b_1p2>;
> + vdda-0p9-supply = <&vreg_l1b_0p8>;
> +};
> +
> +&mdss_edp {
> + status = "okay";
> +
> + data-lanes = <0 1 2 3>;
Is this property necessary? It looks like the default.
> + vdda-1p2-supply = <&vreg_l6b_1p2>;
> + vdda-0p9-supply = <&vreg_l10c_0p8>;
> +
> + aux-bus {
Can this move to sc7280.dtsi and get a phandle?
> + edp_panel: edp-panel {
I'd prefer
edp_panel: panel {
because there's only one panel node at this level.
> + compatible = "edp-panel";
> +
> + power-supply = <&edp_3v3_regulator>;
This is board specific, but I thought it was on the qcard so we should
move this to sc7280-qcard.dtsi?
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@0 {
> + reg = <0>;
> + edp_panel_in: endpoint {
This can be shortened to
port {
edp_panel_in: endpoint {
according to panel-edp.yaml
> + remote-endpoint =
> <&mdss_edp_out>;
> + };
> + };
> + };
> + };
> + };
> +};
> +
> +&mdss_edp_out {
> + remote-endpoint = <&edp_panel_in>;
> +};
> +
> +&mdss_edp_phy {
> + status = "okay";
> +};
> +
> +&mdss_mdp {
> + status = "okay";
> +};
> +
> &nvme_3v3_regulator {
> gpio = <&tlmm 51 GPIO_ACTIVE_HIGH>;
> };
> @@ -84,7 +158,26 @@ ap_ts_pen_1v8: &i2c13 {
> pins = "gpio51";
> };
>
> +&pm8350c_gpios {
> + edp_bl_power: edp-bl-power {
Is this used in a later patch?
> + pins = "gpio7";
> + function = "normal";
> + qcom,drive-strength = ;
> + };
> +
> + edp_bl_pwm: edp-bl-pwm {
Is this used in a later patch? Can it be moved to the patch that uses
it?
> + pins = "gpio8";
> + function = "func1";
> + qcom,drive-strength = ;
> + };
> +};
> +
> &tlmm {
> + edp_panel_power: edp-panel-power {
> + pins = "gpio80";
> + function = "gpio";
function of gpio is unnecessary. Where is the bias and drive-strength
settings?
> + };
> +
> tp_int_odl: tp-int-odl {
> pins = "gpio7";
> function = "gpio";
> --
> 2.7.4
>
Re: [PATCH v5 1/9] arm64: dts: qcom: sc7280: rename edp_out label to mdss_edp_out
Quoting Sankeerth Billakanti (2022-03-16 10:35:46) > Rename the edp_out label in the sc7280 platform to mdss_edp_out > so that the nodes related to mdss are all grouped together in > the board specific files. > > Signed-off-by: Sankeerth Billakanti > --- Reviewed-by: Stephen Boyd
Re: [PATCH v6 1/5] drm/msm/disp/dpu1: set mdp clk to the maximum frequency in opp table during probe
Quoting Vinod Polimera (2022-03-14 07:46:53) > use max clock during probe/bind sequence from the opp table. > The clock will be scaled down when framework sends an update. Capitalize 'use'. Why is it important to use max frequency during probe/bind? Does not setting the clk rate during probe mean that we'll never use the max rate? Does it speed things up during probe?
Re: [Freedreno] [PATCH 3/3] drm/msm/gpu: Remove mutex from wait_event condition
On Thu, Mar 17, 2022 at 1:45 PM Akhil P Oommen wrote:
>
> On 3/11/2022 5:16 AM, Rob Clark wrote:
> > From: Rob Clark
> >
> > The mutex wasn't really protecting anything before. Before the previous
> > patch we could still be racing with the scheduler's kthread, as that is
> > not necessarily frozen yet. Now that we've parked the sched threads,
> > the only race is with jobs retiring, and that is harmless, ie.
> >
> > Signed-off-by: Rob Clark
> > ---
> > drivers/gpu/drm/msm/adreno/adreno_device.c | 11 +--
> > 1 file changed, 1 insertion(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
> > b/drivers/gpu/drm/msm/adreno/adreno_device.c
> > index 0440a98988fc..661dfa7681fb 100644
> > --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> > +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> > @@ -607,15 +607,6 @@ static int adreno_runtime_resume(struct device *dev)
> > return gpu->funcs->pm_resume(gpu);
> > }
> >
> > -static int active_submits(struct msm_gpu *gpu)
> > -{
> > - int active_submits;
> > - mutex_lock(&gpu->active_lock);
> > - active_submits = gpu->active_submits;
> > - mutex_unlock(&gpu->active_lock);
> I assumed that this lock here was to ensure proper barriers while
> reading active_submits. Is that not required?
There is a spinlock in prepare_to_wait_event() ahead of checking the
condition, which AFAIU is a sufficient barrier
BR,
-R
>
> -Akhil.
> > - return active_submits;
> > -}
> > -
> > static int adreno_runtime_suspend(struct device *dev)
> > {
> > struct msm_gpu *gpu = dev_to_gpu(dev);
> > @@ -669,7 +660,7 @@ static int adreno_system_suspend(struct device *dev)
> > suspend_scheduler(gpu);
> >
> > remaining = wait_event_timeout(gpu->retire_event,
> > -active_submits(gpu) == 0,
> > +gpu->active_submits == 0,
> > msecs_to_jiffies(1000));
> > if (remaining == 0) {
> > dev_err(dev, "Timeout waiting for GPU to suspend\n");
>
Re: [PATCH 1/4] drm/gma500: Remove unused declarations and other cruft
Hi Patrik,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on drm-intel/for-linux-next drm-tip/drm-tip
drm-exynos/exynos-drm-next tegra-drm/drm/tegra/for-next v5.17-rc8 next-20220317]
[cannot apply to airlied/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Patrik-Jakobsson/drm-gma500-Remove-unused-declarations-and-other-cruft/20220317-172741
base: git://anongit.freedesktop.org/drm/drm drm-next
config: i386-randconfig-m021
(https://download.01.org/0day-ci/archive/20220318/202203180409.kj2q4cgm-...@intel.com/config)
compiler: gcc-9 (Ubuntu 9.4.0-1ubuntu1~20.04) 9.4.0
reproduce (this is a W=1 build):
#
https://github.com/0day-ci/linux/commit/0d50efabcb4ad52bd7a036e2542dbf51bbcf93b4
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Patrik-Jakobsson/drm-gma500-Remove-unused-declarations-and-other-cruft/20220317-172741
git checkout 0d50efabcb4ad52bd7a036e2542dbf51bbcf93b4
# save the config file to linux build tree
mkdir build_dir
make W=1 O=build_dir ARCH=i386 SHELL=/bin/bash drivers/gpu/drm/gma500/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/gma500/psb_drv.c:102:6: warning: no previous prototype for
>> 'psb_spank' [-Wmissing-prototypes]
102 | void psb_spank(struct drm_psb_private *dev_priv)
| ^
vim +/psb_spank +102 drivers/gpu/drm/gma500/psb_drv.c
5c49fd3aa0ab02 Alan Cox 2011-11-03 95
5c209d8056b976 Patrik Jakobsson 2021-02-01 96 /**
5c209d8056b976 Patrik Jakobsson 2021-02-01 97 * psb_spank
- reset the 2D engine
5c209d8056b976 Patrik Jakobsson 2021-02-01 98 * @dev_priv: our PSB DRM
device
5c209d8056b976 Patrik Jakobsson 2021-02-01 99 *
5c209d8056b976 Patrik Jakobsson 2021-02-01 100 * Soft reset the graphics
engine and then reload the necessary registers.
5c209d8056b976 Patrik Jakobsson 2021-02-01 101 */
5c209d8056b976 Patrik Jakobsson 2021-02-01 @102 void psb_spank(struct
drm_psb_private *dev_priv)
5c209d8056b976 Patrik Jakobsson 2021-02-01 103 {
5c209d8056b976 Patrik Jakobsson 2021-02-01 104
PSB_WSGX32(_PSB_CS_RESET_BIF_RESET | _PSB_CS_RESET_DPM_RESET |
5c209d8056b976 Patrik Jakobsson 2021-02-01 105
_PSB_CS_RESET_TA_RESET | _PSB_CS_RESET_USE_RESET |
5c209d8056b976 Patrik Jakobsson 2021-02-01 106
_PSB_CS_RESET_ISP_RESET | _PSB_CS_RESET_TSP_RESET |
5c209d8056b976 Patrik Jakobsson 2021-02-01 107
_PSB_CS_RESET_TWOD_RESET, PSB_CR_SOFT_RESET);
5c209d8056b976 Patrik Jakobsson 2021-02-01 108
PSB_RSGX32(PSB_CR_SOFT_RESET);
5c209d8056b976 Patrik Jakobsson 2021-02-01 109
5c209d8056b976 Patrik Jakobsson 2021-02-01 110 msleep(1);
5c209d8056b976 Patrik Jakobsson 2021-02-01 111
5c209d8056b976 Patrik Jakobsson 2021-02-01 112 PSB_WSGX32(0,
PSB_CR_SOFT_RESET);
5c209d8056b976 Patrik Jakobsson 2021-02-01 113 wmb();
5c209d8056b976 Patrik Jakobsson 2021-02-01 114
PSB_WSGX32(PSB_RSGX32(PSB_CR_BIF_CTRL) | _PSB_CB_CTRL_CLEAR_FAULT,
5c209d8056b976 Patrik Jakobsson 2021-02-01 115
PSB_CR_BIF_CTRL);
5c209d8056b976 Patrik Jakobsson 2021-02-01 116 wmb();
5c209d8056b976 Patrik Jakobsson 2021-02-01 117 (void)
PSB_RSGX32(PSB_CR_BIF_CTRL);
5c209d8056b976 Patrik Jakobsson 2021-02-01 118
5c209d8056b976 Patrik Jakobsson 2021-02-01 119 msleep(1);
5c209d8056b976 Patrik Jakobsson 2021-02-01 120
PSB_WSGX32(PSB_RSGX32(PSB_CR_BIF_CTRL) & ~_PSB_CB_CTRL_CLEAR_FAULT,
5c209d8056b976 Patrik Jakobsson 2021-02-01 121
PSB_CR_BIF_CTRL);
5c209d8056b976 Patrik Jakobsson 2021-02-01 122 (void)
PSB_RSGX32(PSB_CR_BIF_CTRL);
5c209d8056b976 Patrik Jakobsson 2021-02-01 123
PSB_WSGX32(dev_priv->gtt.gatt_start, PSB_CR_BIF_TWOD_REQ_BASE);
5c209d8056b976 Patrik Jakobsson 2021-02-01 124 }
5c209d8056b976 Patrik Jakobsson 2021-02-01 125
---
0-DAY CI Kernel Test Service
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [PATCH] drm/panel: add CONFIG_DRM_KMS_HELPER dependencies
On Thu, Mar 17, 2022 at 8:15 PM Thomas Zimmermann wrote: > Am 16.03.22 um 21:59 schrieb Arnd Bergmann: > > On Wed, Mar 16, 2022 at 8:31 PM Thomas Zimmermann > > wrote: > > > > I was going for 'depends on' in the panel drivers because I saw the same > > being > > done for other panel drivers, and mixing the two methods causes dependency > > loops. I looked again now, and find that 'select DRM_KMS_HELPER' is more > > common for other drivers, and makes sense here because it is generally > > not user-selectable. > > > > The easiest replacement for my patch would then be to just use 'select > > DRM_KMS_HELPER' from CONFIG_DRM_MIPI_DBI, which makes it > > safer and more consistent with your change. If you like, I'll send an > > updated > > version. > > MIPI DBI is another helper and select is not transitive IIRC. So drivers > would still have to select KMS helpers as well. (?) Not sure what you mean here: if a driver selects DRM_MIPI_DBI, and DRM_MIPI_DBI selects DRM_KMS_HELPER, the leaf driver does not need to select DRM_KMS_HELPER because it is already selected. This is one of the major problems of overusing 'select' because you end up unable to turn things off. Maybe you are thinking of the case where DRM_MIPI_DBI depends on DRM_KMS_HELPER, and something selects DRM_MIPI_DBI. In this case, the dependency does /not/ get inherited by the leaf driver, it needs a copy of the dependency or it triggers a warning, which is what my patch intended. > More generally, I think you're right about making DRM helper libraries > using 'depends on' to link to other libraries. Drivers would at least > know which config symbols to select. A number of config rules would have > to be adapted to make that happen, I guess. Generally speaking, a problem with DRM is that it uses way too much 'select' to enforce other subsystems to be enabled, this is what causes DRM to have more problems with incorrect or circular dependencies, and the only way to avoid that is to be consistent about the dependencies: each symbol should only be referenced with either 'select' or 'depends on' but not both, and 'select' should ideally only be used on hidden symbols. > > One thing I'm not sure about is whether there is still use for ever having > > CONFIG_DRM without CONFIG_DRM_KMS_HELPER if it gets selected > > by almost every driver anyway. Is this actually a configuration that > > users rely on, or should we just remove the symbol completely and > > build the KMS helpers unconditionally? > > Best leave it as it is. i915 doesn't use it. And since it's a helper, it > should not be lumped together with core DRM code simply for reasons of > design. Ok > For DRM_KMS_HELPER itself, the mid-term plan is to move some of the code > into other modules. KMS helpers used to contain all kind of helpers, but > recently there's interest in reducing the minimum size of a built-in DRM > with minimal driver support. So the non-essential stuff needs to go into > modules for the more-sophisticated DRM drivers. Right, that makes sense. Arnd
Re: [Freedreno] [PATCH 3/3] drm/msm/gpu: Remove mutex from wait_event condition
On 3/11/2022 5:16 AM, Rob Clark wrote:
From: Rob Clark
The mutex wasn't really protecting anything before. Before the previous
patch we could still be racing with the scheduler's kthread, as that is
not necessarily frozen yet. Now that we've parked the sched threads,
the only race is with jobs retiring, and that is harmless, ie.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 0440a98988fc..661dfa7681fb 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -607,15 +607,6 @@ static int adreno_runtime_resume(struct device *dev)
return gpu->funcs->pm_resume(gpu);
}
-static int active_submits(struct msm_gpu *gpu)
-{
- int active_submits;
- mutex_lock(&gpu->active_lock);
- active_submits = gpu->active_submits;
- mutex_unlock(&gpu->active_lock);
I assumed that this lock here was to ensure proper barriers while
reading active_submits. Is that not required?
-Akhil.
- return active_submits;
-}
-
static int adreno_runtime_suspend(struct device *dev)
{
struct msm_gpu *gpu = dev_to_gpu(dev);
@@ -669,7 +660,7 @@ static int adreno_system_suspend(struct device *dev)
suspend_scheduler(gpu);
remaining = wait_event_timeout(gpu->retire_event,
- active_submits(gpu) == 0,
+ gpu->active_submits == 0,
msecs_to_jiffies(1000));
if (remaining == 0) {
dev_err(dev, "Timeout waiting for GPU to suspend\n");
Re: [PATCH] drm/amdgpu: fix off by one in amdgpu_gfx_kiq_acquire()
Applied. Thanks!
Alex
On Wed, Mar 16, 2022 at 4:42 AM Dan Carpenter wrote:
>
> This post-op should be a pre-op so that we do not pass -1 as the bit
> number to test_bit(). The current code will loop downwards from 63 to
> -1. After changing to a pre-op, it loops from 63 to 0.
>
> Fixes: 71c37505e7ea ("drm/amdgpu/gfx: move more common KIQ code to
> amdgpu_gfx.c")
> Signed-off-by: Dan Carpenter
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> index 8fe939976224..28a736c507bb 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> @@ -266,7 +266,7 @@ static int amdgpu_gfx_kiq_acquire(struct amdgpu_device
> *adev,
> * adev->gfx.mec.num_pipe_per_mec
> * adev->gfx.mec.num_queue_per_pipe;
>
> - while (queue_bit-- >= 0) {
> + while (--queue_bit >= 0) {
> if (test_bit(queue_bit, adev->gfx.mec.queue_bitmap))
> continue;
>
> --
> 2.20.1
>
Re: [PATCH 2/3] drm/msm/gpu: Park scheduler threads for system suspend
On Thu, Mar 17, 2022 at 12:50 PM Andrey Grodzovsky wrote: > > > On 2022-03-17 14:25, Rob Clark wrote: > > On Thu, Mar 17, 2022 at 11:10 AM Andrey Grodzovsky > > wrote: > >> > >> On 2022-03-17 13:35, Rob Clark wrote: > >>> On Thu, Mar 17, 2022 at 9:45 AM Christian König > >>> wrote: > Am 17.03.22 um 17:18 schrieb Rob Clark: > > On Thu, Mar 17, 2022 at 9:04 AM Christian König > > wrote: > >> Am 17.03.22 um 16:10 schrieb Rob Clark: > >>> [SNIP] > >>> userspace frozen != kthread frozen .. that is what this patch is > >>> trying to address, so we aren't racing between shutting down the hw > >>> and the scheduler shoveling more jobs at us. > >> Well exactly that's the problem. The scheduler is supposed to shoveling > >> more jobs at us until it is empty. > >> > >> Thinking more about it we will then keep some dma_fence instance > >> unsignaled and that is and extremely bad idea since it can lead to > >> deadlocks during suspend. > > Hmm, perhaps that is true if you need to migrate things out of vram? > > It is at least not a problem when vram is not involved. > No, it's much wider than that. > > See what can happen is that the memory management shrinkers want to wait > for a dma_fence during suspend. > >>> we don't wait on fences in shrinker, only purging or evicting things > >>> that are already ready. Actually, waiting on fences in shrinker path > >>> sounds like a pretty bad idea. > >>> > And if you stop the scheduler they will just wait forever. > > What you need to do instead is to drain the scheduler, e.g. call > drm_sched_entity_flush() with a proper timeout for each entity you have > created. > >>> yeah, it would work to drain the scheduler.. I guess that might be the > >>> more portable approach as far as generic solution for suspend. > >>> > >>> BR, > >>> -R > >> > >> I am not sure how this drains the scheduler ? Suppose we done the > >> waiting in drm_sched_entity_flush, > >> what prevents someone to push right away another job into the same > >> entity's queue right after that ? > >> Shouldn't we first disable further pushing of jobs into entity before we > >> wait for sched->job_scheduled ? > >> > > In the system suspend path, userspace processes will have already been > > frozen, so there should be no way to push more jobs to the scheduler, > > unless they are pushed from the kernel itself. > > > It was my suspicion but I wasn't sure about it. > > > > We don't do that in > > drm/msm, but maybe you need to to move things btwn vram and system > > memory? > > > Exactly, that was my main concern - if we use this method we have to use > it in a point in > suspend sequence when all the in kernel job submissions activity already > suspended > > > But even in that case, if the # of jobs you push is bounded I > > guess that is ok? > > Submissions to scheduler entities are using unbounded queue, the bounded > part is when > you extract next job from entity to submit to HW ring and it rejects if > submission limit reached (drm_sched_ready) > > In general - It looks to me at least that what we what we want her is > more of a drain operation then flush (i.e. > we first want to disable any further job submission to entity's queue > and then flush all in flight ones). As example > for this i was looking at flush_workqueue vs. drain_workqueue Would it be possible for amdgpu to, in the system suspend task, 1) first queue up all the jobs needed to migrate bos out of vram, and whatever other housekeeping jobs are needed 2) then drain gpu scheduler's queues 3) and then finally wait for jobs executing on GPU to complete BR, -R > Andrey > > > > > > BR, > > -R
Re: [PATCH] drm/amdgpu: Fix spelling mistake "regiser" -> "register"
Applied. Thanks!
Alex
On Tue, Mar 15, 2022 at 4:20 PM Colin Ian King wrote:
>
> There is a spelling mistake in a dev_error error message. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> index a025f080aa6a..9aa355a5ac3c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> @@ -919,7 +919,7 @@ static u32 amdgpu_virt_rlcg_reg_rw(struct amdgpu_device
> *adev, u32 offset, u32 v
> "wrong operation type, rlcg
> failed to program reg: 0x%05x\n", offset);
> } else if (tmp &
> AMDGPU_RLCG_REG_NOT_IN_RANGE) {
> dev_err(adev->dev,
> - "regiser is not in range,
> rlcg failed to program reg: 0x%05x\n", offset);
> + "register is not in range,
> rlcg failed to program reg: 0x%05x\n", offset);
> } else {
> dev_err(adev->dev,
> "unknown error type, rlcg
> failed to program reg: 0x%05x\n", offset);
> --
> 2.35.1
>
Re: [PATCH v4 4/4] dt-bindings: display/panel: Add Leadtek ltk035c5444t
Hi,
Le ven., mars 11 2022 at 18:02:40 +0100, Christophe Branchereau
a écrit :
Add binding for the leadtek ltk035c5444t, which is a 640x480
mipi-dbi over spi / 24-bit RGB panel based on the newvision
NV03052C chipset.
It is found in the Anbernic RG350M mips handheld.
Signed-off-by: Christophe Branchereau
Applied to drm-misc-next.
Thanks,
-Paul
---
.../display/panel/leadtek,ltk035c5444t.yaml | 59
+++
1 file changed, 59 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml
b/Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml
new file mode 100644
index ..817a9bed7d5a
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id:
http://devicetree.org/schemas/display/panel/leadtek,ltk035c5444t.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Leadtek ltk035c5444t 3.5" (640x480 pixels) 24-bit IPS LCD
panel
+
+maintainers:
+ - Paul Cercueil
+ - Christophe Branchereau
+
+allOf:
+ - $ref: panel-common.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+const: leadtek,ltk035c5444t
+
+ backlight: true
+ port: true
+ power-supply: true
+ reg: true
+ reset-gpios: true
+
+required:
+ - compatible
+ - power-supply
+ - reset-gpios
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+
+spi {
+#address-cells = <1>;
+#size-cells = <0>;
+panel@0 {
+compatible = "leadtek,ltk035c5444t";
+reg = <0>;
+
+spi-3wire;
+spi-max-frequency = <3125000>;
+
+reset-gpios = <&gpe 2 GPIO_ACTIVE_LOW>;
+
+backlight = <&backlight>;
+power-supply = <&vcc>;
+
+port {
+panel_input: endpoint {
+remote-endpoint = <&panel_output>;
+};
+};
+};
+};
--
2.35.1
Re: [PATCH 4/4] drm/gma500: Cosmetic cleanup of irq code
Hi Patrik
Am 17.03.22 um 10:25 schrieb Patrik Jakobsson:
Use the gma_ prefix instead of psb_ since the code is common for all
chips. Various coding style fixes. Removal of unused code. Removal of
duplicate function declarations.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/gma_display.c | 8 +--
drivers/gpu/drm/gma500/opregion.c| 5 +-
drivers/gpu/drm/gma500/power.c | 10 +--
drivers/gpu/drm/gma500/psb_drv.c | 2 +-
drivers/gpu/drm/gma500/psb_drv.h | 11
drivers/gpu/drm/gma500/psb_irq.c | 94 +++-
drivers/gpu/drm/gma500/psb_irq.h | 19 +++---
7 files changed, 57 insertions(+), 92 deletions(-)
diff --git a/drivers/gpu/drm/gma500/gma_display.c
b/drivers/gpu/drm/gma500/gma_display.c
index 931ffb192fc4..1d7964c339f4 100644
--- a/drivers/gpu/drm/gma500/gma_display.c
+++ b/drivers/gpu/drm/gma500/gma_display.c
@@ -17,7 +17,7 @@
#include "framebuffer.h"
#include "gem.h"
#include "gma_display.h"
-#include "psb_drv.h"
+#include "psb_irq.h"
#include "psb_intel_drv.h"
#include "psb_intel_reg.h"
@@ -572,9 +572,9 @@ const struct drm_crtc_funcs gma_crtc_funcs = {
.set_config = gma_crtc_set_config,
.destroy = gma_crtc_destroy,
.page_flip = gma_crtc_page_flip,
- .enable_vblank = psb_enable_vblank,
- .disable_vblank = psb_disable_vblank,
- .get_vblank_counter = psb_get_vblank_counter,
+ .enable_vblank = gma_enable_vblank,
+ .disable_vblank = gma_disable_vblank,
+ .get_vblank_counter = gma_get_vblank_counter,
I'd prefix these functions with gma_crtc_ to align their naming with the
others. They are CRTC functions, after all.
Apart from that,
Reviewed-by: Thomas Zimmermann
Best regards
Thomas
};
/*
diff --git a/drivers/gpu/drm/gma500/opregion.c
b/drivers/gpu/drm/gma500/opregion.c
index fef04ff8c3a9..dc494df71a48 100644
--- a/drivers/gpu/drm/gma500/opregion.c
+++ b/drivers/gpu/drm/gma500/opregion.c
@@ -23,6 +23,7 @@
*/
#include
#include "psb_drv.h"
+#include "psb_irq.h"
#include "psb_intel_reg.h"
#define PCI_ASLE 0xe4
@@ -217,8 +218,8 @@ void psb_intel_opregion_enable_asle(struct drm_device *dev)
if (asle && system_opregion ) {
/* Don't do this on Medfield or other non PC like devices, they
use the bit for something different altogether */
- psb_enable_pipestat(dev_priv, 0, PIPE_LEGACY_BLC_EVENT_ENABLE);
- psb_enable_pipestat(dev_priv, 1, PIPE_LEGACY_BLC_EVENT_ENABLE);
+ gma_enable_pipestat(dev_priv, 0, PIPE_LEGACY_BLC_EVENT_ENABLE);
+ gma_enable_pipestat(dev_priv, 1, PIPE_LEGACY_BLC_EVENT_ENABLE);
asle->tche = ASLE_ALS_EN | ASLE_BLC_EN | ASLE_PFIT_EN
| ASLE_PFMB_EN;
diff --git a/drivers/gpu/drm/gma500/power.c b/drivers/gpu/drm/gma500/power.c
index 6f917cfef65b..b91de6d36e41 100644
--- a/drivers/gpu/drm/gma500/power.c
+++ b/drivers/gpu/drm/gma500/power.c
@@ -201,7 +201,7 @@ int gma_power_suspend(struct device *_dev)
dev_err(dev->dev, "GPU hardware busy, cannot
suspend\n");
return -EBUSY;
}
- psb_irq_uninstall(dev);
+ gma_irq_uninstall(dev);
gma_suspend_display(dev);
gma_suspend_pci(pdev);
}
@@ -223,8 +223,8 @@ int gma_power_resume(struct device *_dev)
mutex_lock(&power_mutex);
gma_resume_pci(pdev);
gma_resume_display(pdev);
- psb_irq_preinstall(dev);
- psb_irq_postinstall(dev);
+ gma_irq_preinstall(dev);
+ gma_irq_postinstall(dev);
mutex_unlock(&power_mutex);
return 0;
}
@@ -270,8 +270,8 @@ bool gma_power_begin(struct drm_device *dev, bool force_on)
/* Ok power up needed */
ret = gma_resume_pci(pdev);
if (ret == 0) {
- psb_irq_preinstall(dev);
- psb_irq_postinstall(dev);
+ gma_irq_preinstall(dev);
+ gma_irq_postinstall(dev);
pm_runtime_get(dev->dev);
dev_priv->display_count++;
spin_unlock_irqrestore(&power_ctrl_lock, flags);
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index e30b58184156..82d51e9821ad 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -380,7 +380,7 @@ static int psb_driver_load(struct drm_device *dev, unsigned
long flags)
PSB_WVDC32(0x, PSB_INT_MASK_R);
spin_unlock_irqrestore(&dev_priv->irqmask_lock, irqflags);
- psb_irq_install(dev, pdev->irq);
+ gma_irq_install(dev, pdev->irq);
dev->max_vblank_count = 0xff; /* only 24 bits of frame count */
diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
index aed167af13c5..0ddfec1a0851 100644
--- a/drivers/gpu/drm/gma500/psb_drv.h
+++ b/driv
Re: [PATCH 2/3] drm/msm/gpu: Park scheduler threads for system suspend
On 2022-03-17 14:25, Rob Clark wrote: On Thu, Mar 17, 2022 at 11:10 AM Andrey Grodzovsky wrote: On 2022-03-17 13:35, Rob Clark wrote: On Thu, Mar 17, 2022 at 9:45 AM Christian König wrote: Am 17.03.22 um 17:18 schrieb Rob Clark: On Thu, Mar 17, 2022 at 9:04 AM Christian König wrote: Am 17.03.22 um 16:10 schrieb Rob Clark: [SNIP] userspace frozen != kthread frozen .. that is what this patch is trying to address, so we aren't racing between shutting down the hw and the scheduler shoveling more jobs at us. Well exactly that's the problem. The scheduler is supposed to shoveling more jobs at us until it is empty. Thinking more about it we will then keep some dma_fence instance unsignaled and that is and extremely bad idea since it can lead to deadlocks during suspend. Hmm, perhaps that is true if you need to migrate things out of vram? It is at least not a problem when vram is not involved. No, it's much wider than that. See what can happen is that the memory management shrinkers want to wait for a dma_fence during suspend. we don't wait on fences in shrinker, only purging or evicting things that are already ready. Actually, waiting on fences in shrinker path sounds like a pretty bad idea. And if you stop the scheduler they will just wait forever. What you need to do instead is to drain the scheduler, e.g. call drm_sched_entity_flush() with a proper timeout for each entity you have created. yeah, it would work to drain the scheduler.. I guess that might be the more portable approach as far as generic solution for suspend. BR, -R I am not sure how this drains the scheduler ? Suppose we done the waiting in drm_sched_entity_flush, what prevents someone to push right away another job into the same entity's queue right after that ? Shouldn't we first disable further pushing of jobs into entity before we wait for sched->job_scheduled ? In the system suspend path, userspace processes will have already been frozen, so there should be no way to push more jobs to the scheduler, unless they are pushed from the kernel itself. It was my suspicion but I wasn't sure about it. We don't do that in drm/msm, but maybe you need to to move things btwn vram and system memory? Exactly, that was my main concern - if we use this method we have to use it in a point in suspend sequence when all the in kernel job submissions activity already suspended But even in that case, if the # of jobs you push is bounded I guess that is ok? Submissions to scheduler entities are using unbounded queue, the bounded part is when you extract next job from entity to submit to HW ring and it rejects if submission limit reached (drm_sched_ready) In general - It looks to me at least that what we what we want her is more of a drain operation then flush (i.e. we first want to disable any further job submission to entity's queue and then flush all in flight ones). As example for this i was looking at flush_workqueue vs. drain_workqueue Andrey BR, -R
Re: [PATCH 3/4] drm/gma500: Don't store crtc_funcs in psb_ops
Am 17.03.22 um 10:25 schrieb Patrik Jakobsson:
The drm_crtc_funcs are all generic and no chip specific functions are
necessary. We can therefore directly put gma_crtc_funcs into the
drm_crtc.
Signed-off-by: Patrik Jakobsson
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/cdv_device.c| 1 -
drivers/gpu/drm/gma500/oaktrail_device.c | 1 -
drivers/gpu/drm/gma500/psb_device.c| 1 -
drivers/gpu/drm/gma500/psb_drv.h | 1 -
drivers/gpu/drm/gma500/psb_intel_display.c | 3 +--
5 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_device.c
b/drivers/gpu/drm/gma500/cdv_device.c
index 887c157d75f4..f854f58bcbb3 100644
--- a/drivers/gpu/drm/gma500/cdv_device.c
+++ b/drivers/gpu/drm/gma500/cdv_device.c
@@ -603,7 +603,6 @@ const struct psb_ops cdv_chip_ops = {
.errata = cdv_errata,
.crtc_helper = &cdv_intel_helper_funcs,
- .crtc_funcs = &gma_crtc_funcs,
.clock_funcs = &cdv_clock_funcs,
.output_init = cdv_output_init,
diff --git a/drivers/gpu/drm/gma500/oaktrail_device.c
b/drivers/gpu/drm/gma500/oaktrail_device.c
index 40f1bc736125..5923a9c89312 100644
--- a/drivers/gpu/drm/gma500/oaktrail_device.c
+++ b/drivers/gpu/drm/gma500/oaktrail_device.c
@@ -545,7 +545,6 @@ const struct psb_ops oaktrail_chip_ops = {
.chip_setup = oaktrail_chip_setup,
.chip_teardown = oaktrail_teardown,
.crtc_helper = &oaktrail_helper_funcs,
- .crtc_funcs = &gma_crtc_funcs,
.output_init = oaktrail_output_init,
diff --git a/drivers/gpu/drm/gma500/psb_device.c b/drivers/gpu/drm/gma500/psb_device.c
index e93e4191c0ca..59f325165667 100644
--- a/drivers/gpu/drm/gma500/psb_device.c
+++ b/drivers/gpu/drm/gma500/psb_device.c
@@ -329,7 +329,6 @@ const struct psb_ops psb_chip_ops = {
.chip_teardown = psb_chip_teardown,
.crtc_helper = &psb_intel_helper_funcs,
- .crtc_funcs = &gma_crtc_funcs,
.clock_funcs = &psb_clock_funcs,
.output_init = psb_output_init,
diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
index 88f44dbbc4eb..aed167af13c5 100644
--- a/drivers/gpu/drm/gma500/psb_drv.h
+++ b/drivers/gpu/drm/gma500/psb_drv.h
@@ -578,7 +578,6 @@ struct psb_ops {
/* Sub functions */
struct drm_crtc_helper_funcs const *crtc_helper;
- struct drm_crtc_funcs const *crtc_funcs;
const struct gma_clock_funcs *clock_funcs;
/* Setup hooks */
diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c
b/drivers/gpu/drm/gma500/psb_intel_display.c
index 6df62fe7c1e0..a99859b5b13a 100644
--- a/drivers/gpu/drm/gma500/psb_intel_display.c
+++ b/drivers/gpu/drm/gma500/psb_intel_display.c
@@ -488,8 +488,7 @@ void psb_intel_crtc_init(struct drm_device *dev, int pipe,
return;
}
- /* Set the CRTC operations from the chip specific data */
- drm_crtc_init(dev, &gma_crtc->base, dev_priv->ops->crtc_funcs);
+ drm_crtc_init(dev, &gma_crtc->base, &gma_crtc_funcs);
/* Set the CRTC clock functions from chip specific data */
gma_crtc->clock_funcs = dev_priv->ops->clock_funcs;
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH 2/4] drm/gma500: Move gma_intel_crtc_funcs into gma_display.c
Am 17.03.22 um 10:25 schrieb Patrik Jakobsson:
All functions live in gma_display.c already so move the vtable. Also
shorten the name to gma_crtc_funcs.
Signed-off-by: Patrik Jakobsson
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/cdv_device.c| 2 +-
drivers/gpu/drm/gma500/gma_display.c | 12
drivers/gpu/drm/gma500/gma_display.h | 10 ++
drivers/gpu/drm/gma500/oaktrail_device.c | 2 +-
drivers/gpu/drm/gma500/psb_device.c| 2 +-
drivers/gpu/drm/gma500/psb_drv.h | 2 --
drivers/gpu/drm/gma500/psb_intel_display.c | 12
7 files changed, 17 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_device.c
b/drivers/gpu/drm/gma500/cdv_device.c
index d7c6cca23e94..887c157d75f4 100644
--- a/drivers/gpu/drm/gma500/cdv_device.c
+++ b/drivers/gpu/drm/gma500/cdv_device.c
@@ -603,7 +603,7 @@ const struct psb_ops cdv_chip_ops = {
.errata = cdv_errata,
.crtc_helper = &cdv_intel_helper_funcs,
- .crtc_funcs = &gma_intel_crtc_funcs,
+ .crtc_funcs = &gma_crtc_funcs,
.clock_funcs = &cdv_clock_funcs,
.output_init = cdv_output_init,
diff --git a/drivers/gpu/drm/gma500/gma_display.c
b/drivers/gpu/drm/gma500/gma_display.c
index dd801404cf99..931ffb192fc4 100644
--- a/drivers/gpu/drm/gma500/gma_display.c
+++ b/drivers/gpu/drm/gma500/gma_display.c
@@ -565,6 +565,18 @@ int gma_crtc_set_config(struct drm_mode_set *set,
return ret;
}
+const struct drm_crtc_funcs gma_crtc_funcs = {
+ .cursor_set = gma_crtc_cursor_set,
+ .cursor_move = gma_crtc_cursor_move,
+ .gamma_set = gma_crtc_gamma_set,
+ .set_config = gma_crtc_set_config,
+ .destroy = gma_crtc_destroy,
+ .page_flip = gma_crtc_page_flip,
+ .enable_vblank = psb_enable_vblank,
+ .disable_vblank = psb_disable_vblank,
+ .get_vblank_counter = psb_get_vblank_counter,
+};
+
/*
* Save HW states of given crtc
*/
diff --git a/drivers/gpu/drm/gma500/gma_display.h
b/drivers/gpu/drm/gma500/gma_display.h
index 7bd6c1ee8b21..113cf048105e 100644
--- a/drivers/gpu/drm/gma500/gma_display.h
+++ b/drivers/gpu/drm/gma500/gma_display.h
@@ -58,15 +58,7 @@ extern bool gma_pipe_has_type(struct drm_crtc *crtc, int
type);
extern void gma_wait_for_vblank(struct drm_device *dev);
extern int gma_pipe_set_base(struct drm_crtc *crtc, int x, int y,
struct drm_framebuffer *old_fb);
-extern int gma_crtc_cursor_set(struct drm_crtc *crtc,
- struct drm_file *file_priv,
- uint32_t handle,
- uint32_t width, uint32_t height);
-extern int gma_crtc_cursor_move(struct drm_crtc *crtc, int x, int y);
extern void gma_crtc_load_lut(struct drm_crtc *crtc);
-extern int gma_crtc_gamma_set(struct drm_crtc *crtc, u16 *red, u16 *green,
- u16 *blue, u32 size,
- struct drm_modeset_acquire_ctx *ctx);
extern void gma_crtc_dpms(struct drm_crtc *crtc, int mode);
extern void gma_crtc_prepare(struct drm_crtc *crtc);
extern void gma_crtc_commit(struct drm_crtc *crtc);
@@ -83,6 +75,8 @@ extern int gma_crtc_set_config(struct drm_mode_set *set,
extern void gma_crtc_save(struct drm_crtc *crtc);
extern void gma_crtc_restore(struct drm_crtc *crtc);
+extern const struct drm_crtc_funcs gma_crtc_funcs;
+
extern void gma_encoder_prepare(struct drm_encoder *encoder);
extern void gma_encoder_commit(struct drm_encoder *encoder);
extern void gma_encoder_destroy(struct drm_encoder *encoder);
diff --git a/drivers/gpu/drm/gma500/oaktrail_device.c
b/drivers/gpu/drm/gma500/oaktrail_device.c
index 5c75eae630b5..40f1bc736125 100644
--- a/drivers/gpu/drm/gma500/oaktrail_device.c
+++ b/drivers/gpu/drm/gma500/oaktrail_device.c
@@ -545,7 +545,7 @@ const struct psb_ops oaktrail_chip_ops = {
.chip_setup = oaktrail_chip_setup,
.chip_teardown = oaktrail_teardown,
.crtc_helper = &oaktrail_helper_funcs,
- .crtc_funcs = &gma_intel_crtc_funcs,
+ .crtc_funcs = &gma_crtc_funcs,
.output_init = oaktrail_output_init,
diff --git a/drivers/gpu/drm/gma500/psb_device.c b/drivers/gpu/drm/gma500/psb_device.c
index 3030f18ba022..e93e4191c0ca 100644
--- a/drivers/gpu/drm/gma500/psb_device.c
+++ b/drivers/gpu/drm/gma500/psb_device.c
@@ -329,7 +329,7 @@ const struct psb_ops psb_chip_ops = {
.chip_teardown = psb_chip_teardown,
.crtc_helper = &psb_intel_helper_funcs,
- .crtc_funcs = &gma_intel_crtc_funcs,
+ .crtc_funcs = &gma_crtc_funcs,
.clock_funcs = &psb_clock_funcs,
.output_init = psb_output_init,
diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
index 66f61909a8c8..88f44dbbc4eb 100644
--- a/drivers/gpu/drm/gma500/psb_drv.h
+++ b/drivers/gpu/drm/gma500/psb_drv.h
@@ -13,7 +13,6 @@
#include
-#include "gma_display.h"
#include
Re: [PATCH 1/4] drm/gma500: Remove unused declarations and other cruft
Hi Patrik
Am 17.03.22 um 10:25 schrieb Patrik Jakobsson:
Most of these are old leftovers from one of the driver merges. This is
all dead code.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/psb_drv.h | 75 +---
1 file changed, 1 insertion(+), 74 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
index 553d03190ce1..66f61909a8c8 100644
--- a/drivers/gpu/drm/gma500/psb_drv.h
+++ b/drivers/gpu/drm/gma500/psb_drv.h
@@ -36,12 +36,6 @@
/* Append new drm mode definition here, align with libdrm definition */
#define DRM_MODE_SCALE_NO_SCALE 2
-enum {
- CHIP_PSB_8108 = 0, /* Poulsbo */
- CHIP_PSB_8109 = 1, /* Poulsbo */
- CHIP_MRST_4100 = 2, /* Moorestown/Oaktrail */
-};
-
#define IS_PSB(drm) ((to_pci_dev((drm)->dev)->device & 0xfffe) == 0x8108)
#define IS_MRST(drm) ((to_pci_dev((drm)->dev)->device & 0xfff0) == 0x4100)
#define IS_CDV(drm) ((to_pci_dev((drm)->dev)->device & 0xfff0) == 0x0be0)
@@ -617,15 +611,7 @@ struct psb_ops {
int i2c_bus;/* I2C bus identifier for Moorestown */
};
-
-
-extern int drm_crtc_probe_output_modes(struct drm_device *dev, int, int);
-extern int drm_pick_crtcs(struct drm_device *dev);
-
/* psb_irq.c */
-extern void psb_irq_uninstall_islands(struct drm_device *dev, int hw_islands);
-extern int psb_vblank_wait2(struct drm_device *dev, unsigned int *sequence);
-extern int psb_vblank_wait(struct drm_device *dev, unsigned int *sequence);
extern int psb_enable_vblank(struct drm_crtc *crtc);
extern void psb_disable_vblank(struct drm_crtc *crtc);
The vblank enable/disable functions are also declared in psb_irq.h. The
declarations here could be removed as well.
void
@@ -636,17 +622,9 @@ psb_disable_pipestat(struct drm_psb_private *dev_priv, int
pipe, u32 mask);
extern u32 psb_get_vblank_counter(struct drm_crtc *crtc);
-/* framebuffer.c */
-extern int psbfb_probed(struct drm_device *dev);
-extern int psbfb_remove(struct drm_device *dev,
- struct drm_framebuffer *fb);
-/* psb_drv.c */
-extern void psb_spank(struct drm_psb_private *dev_priv);
This function is still around in psb_drv.c. It should now be declared
static.
Best regards
Thomas
-
-/* psb_reset.c */
+/* psb_lid.c */
extern void psb_lid_timer_init(struct drm_psb_private *dev_priv);
extern void psb_lid_timer_takedown(struct drm_psb_private *dev_priv);
-extern void psb_print_pagefault(struct drm_psb_private *dev_priv);
/* modesetting */
extern void psb_modeset_init(struct drm_device *dev);
@@ -689,43 +667,7 @@ extern const struct psb_ops oaktrail_chip_ops;
/* cdv_device.c */
extern const struct psb_ops cdv_chip_ops;
-/* Debug print bits setting */
-#define PSB_D_GENERAL (1 << 0)
-#define PSB_D_INIT(1 << 1)
-#define PSB_D_IRQ (1 << 2)
-#define PSB_D_ENTRY (1 << 3)
-/* debug the get H/V BP/FP count */
-#define PSB_D_HV (1 << 4)
-#define PSB_D_DBI_BF (1 << 5)
-#define PSB_D_PM (1 << 6)
-#define PSB_D_RENDER (1 << 7)
-#define PSB_D_REG (1 << 8)
-#define PSB_D_MSVDX (1 << 9)
-#define PSB_D_TOPAZ (1 << 10)
-
-extern int drm_idle_check_interval;
-
/* Utilities */
-static inline u32 MRST_MSG_READ32(int domain, uint port, uint offset)
-{
- int mcr = (0xD0<<24) | (port << 16) | (offset << 8);
- uint32_t ret_val = 0;
- struct pci_dev *pci_root = pci_get_domain_bus_and_slot(domain, 0, 0);
- pci_write_config_dword(pci_root, 0xD0, mcr);
- pci_read_config_dword(pci_root, 0xD4, &ret_val);
- pci_dev_put(pci_root);
- return ret_val;
-}
-static inline void MRST_MSG_WRITE32(int domain, uint port, uint offset,
- u32 value)
-{
- int mcr = (0xE0<<24) | (port << 16) | (offset << 8) | 0xF0;
- struct pci_dev *pci_root = pci_get_domain_bus_and_slot(domain, 0, 0);
- pci_write_config_dword(pci_root, 0xD4, value);
- pci_write_config_dword(pci_root, 0xD0, mcr);
- pci_dev_put(pci_root);
-}
-
static inline uint32_t REGISTER_READ(struct drm_device *dev, uint32_t reg)
{
struct drm_psb_private *dev_priv = to_drm_psb_private(dev);
@@ -806,24 +748,9 @@ static inline void REGISTER_WRITE8(struct drm_device *dev,
#define PSB_WVDC32(_val, _offs) iowrite32(_val,
dev_priv->vdc_reg + (_offs))
#define PSB_RVDC32(_offs) ioread32(dev_priv->vdc_reg + (_offs))
-/* #define TRAP_SGX_PM_FAULT 1 */
-#ifdef TRAP_SGX_PM_FAULT
-#define PSB_RSGX32(_offs) \
-({ \
- if (inl(dev_priv->apm_base + PSB_APM_STS) & 0x3) { \
- pr_err("access sgx when it's off!! (READ) %s, %d\n", \
- __FILE__, __LINE__); \
- melay(1000);
Re: [PATCH 1/4] drm/gma500: Remove unused declarations and other cruft
Hi Patrik, On Thu, Mar 17, 2022 at 10:25:52AM +0100, Patrik Jakobsson wrote: > Most of these are old leftovers from one of the driver merges. This is > all dead code. Nice cleanups. For all four patches: Acked-by: Sam Ravnborg
Re: [PATCH,v2] drm/panel: Fix return value check in nt35950_probe()
On Thu, Mar 17, 2022 at 04:37:07PM +0800, Lu Wei wrote:
> In function nt35950_probe(), mipi_dsi_device_register_full() is called
> to create a MIPI DSI device. If it fails, a pointer encoded with an error
> will be returned, so use IS_ERR() to check the return value. Besides, use
> PTR_ERR to return the actual errno.
>
> Fixes: 623a3531e9cf ("drm/panel: Add driver for Novatek NT35950 DSI DriverIC
> panels")
> Signed-off-by: Lu Wei
Acked-by: Sam Ravnborg
Re: [PATCH] drm/panel: add CONFIG_DRM_KMS_HELPER dependencies
Hi Arnd Am 16.03.22 um 21:59 schrieb Arnd Bergmann: On Wed, Mar 16, 2022 at 8:31 PM Thomas Zimmermann wrote: Am 16.03.22 um 20:12 schrieb Thomas Zimmermann: Adding a dependency in all drivers that select DRM_MIPI_DBI avoids the problem for now, adding the dependency in DRM_MIPI_DBI as well should help make it easier to figure out why it breaks if someone forgets the dependency the next time. tristate -depends on DRM +depends on DRM_KMS_HELPER This symbol cannot be selected by users, so it's maybe not a good idea to depend on it. In fact, I've had to remove such a statement because it created a cyclic dependency. [1] I tried to explain above what I was thinking here: the added dependency is both a correct statement (DRM_MIPI_DBI depends on DRM_KMS_HELPER because it cannot be built without DRM_KMS_HELPER) and helpful as an indication what went wrong if we run into the same problem with a new driver, instead of the cryptic link failure you get something like WARNING: unmet direct dependencies detected for DRM_MIPI_DBI Depends on [m]: HAS_IOMEM [=y] && DRM_KMS_HELPER [=m] Selected by [y]: - DRM_PANEL_WIDECHIPS_WS2401 [=y] && HAS_IOMEM [=y] && DRM [=y] && DRM_PANEL [=y] && SPI [=y] && GPIOLIB [=y] && BACKLIGHT_CLASS_DEVICE [=y] Selected by [m]: - TINYDRM_ILI9225 [=m] && HAS_IOMEM [=y] && DRM [=y] && SPI [=y] [1] https://lore.kernel.org/dri-devel/20220315084559.23510-1-tzimmerm...@suse.de/ I was going for 'depends on' in the panel drivers because I saw the same being done for other panel drivers, and mixing the two methods causes dependency loops. I looked again now, and find that 'select DRM_KMS_HELPER' is more common for other drivers, and makes sense here because it is generally not user-selectable. The easiest replacement for my patch would then be to just use 'select DRM_KMS_HELPER' from CONFIG_DRM_MIPI_DBI, which makes it safer and more consistent with your change. If you like, I'll send an updated version. MIPI DBI is another helper and select is not transitive IIRC. So drivers would still have to select KMS helpers as well. (?) I just added my patch to drm-misc-fixes today and it should show up in upstream soon. Maybe just rebase your patch on top of it and if nothing breaks let's merge it as-is including the 'depends on'. You can add Acked-by: Thomas Zimmermann in this case. More generally, I think you're right about making DRM helper libraries using 'depends on' to link to other libraries. Drivers would at least know which config symbols to select. A number of config rules would have to be adapted to make that happen, I guess. One issue is that different submodules of DRM seem to use different logic for expressing such config dependencies. That's been an endless source of problems so far. One thing I'm not sure about is whether there is still use for ever having CONFIG_DRM without CONFIG_DRM_KMS_HELPER if it gets selected by almost every driver anyway. Is this actually a configuration that users rely on, or should we just remove the symbol completely and build the KMS helpers unconditionally? Best leave it as it is. i915 doesn't use it. And since it's a helper, it should not be lumped together with core DRM code simply for reasons of design. For DRM_KMS_HELPER itself, the mid-term plan is to move some of the code into other modules. KMS helpers used to contain all kind of helpers, but recently there's interest in reducing the minimum size of a built-in DRM with minimal driver support. So the non-essential stuff needs to go into modules for the more-sophisticated DRM drivers. Best regards Thomas Arnd -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
Re: [RFC PATCH 1/4] drm/amdkfd: Improve amdgpu_vm_handle_moved
Am 2022-03-17 um 04:21 schrieb Christian König:
Am 17.03.22 um 01:20 schrieb Felix Kuehling:
Let amdgpu_vm_handle_moved update all BO VA mappings of BOs reserved by
the caller. This will be useful for handling extra BO VA mappings in
KFD VMs that are managed through the render node API.
Yes, that change is on my TODO list for quite a while as well.
TODO: This may also allow simplification of amdgpu_cs_vm_handling. See
the TODO comment in the code.
No, that won't work just yet.
We need to change the TLB flush detection for that, but I'm already
working on those as well.
Your TLB flushing patch series looks good to me.
There is one other issue, though. amdgpu_vm_handle_moved doesn't update
the sync object, so I couldn't figure out I can wait for all the page
table updates to finish.
Regards,
Felix
Signed-off-by: Felix Kuehling
Please update the TODO, with that done: Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 18 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 3 ++-
4 files changed, 21 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index d162243d8e78..10941f0d8dde 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -826,6 +826,10 @@ static int amdgpu_cs_vm_handling(struct
amdgpu_cs_parser *p)
return r;
}
+ /* TODO: Is this loop still needed, or could this be handled by
+ * amdgpu_vm_handle_moved, now that it can handle all BOs that are
+ * reserved under p->ticket?
+ */
amdgpu_bo_list_for_each_entry(e, p->bo_list) {
/* ignore duplicates */
bo = ttm_to_amdgpu_bo(e->tv.bo);
@@ -845,7 +849,7 @@ static int amdgpu_cs_vm_handling(struct
amdgpu_cs_parser *p)
return r;
}
- r = amdgpu_vm_handle_moved(adev, vm);
+ r = amdgpu_vm_handle_moved(adev, vm, &p->ticket);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index 579adfafe4d0..50805613c38c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -414,7 +414,7 @@ amdgpu_dma_buf_move_notify(struct
dma_buf_attachment *attach)
r = amdgpu_vm_clear_freed(adev, vm, NULL);
if (!r)
- r = amdgpu_vm_handle_moved(adev, vm);
+ r = amdgpu_vm_handle_moved(adev, vm, ticket);
if (r && r != -EBUSY)
DRM_ERROR("Failed to invalidate VM page tables (%d))\n",
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index fc4563cf2828..726b42c6d606 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -2190,11 +2190,12 @@ int amdgpu_vm_clear_freed(struct
amdgpu_device *adev,
* PTs have to be reserved!
*/
int amdgpu_vm_handle_moved(struct amdgpu_device *adev,
- struct amdgpu_vm *vm)
+ struct amdgpu_vm *vm,
+ struct ww_acquire_ctx *ticket)
{
struct amdgpu_bo_va *bo_va, *tmp;
struct dma_resv *resv;
- bool clear;
+ bool clear, unlock;
int r;
list_for_each_entry_safe(bo_va, tmp, &vm->moved,
base.vm_status) {
@@ -2212,17 +2213,24 @@ int amdgpu_vm_handle_moved(struct
amdgpu_device *adev,
spin_unlock(&vm->invalidated_lock);
/* Try to reserve the BO to avoid clearing its ptes */
- if (!amdgpu_vm_debug && dma_resv_trylock(resv))
+ if (!amdgpu_vm_debug && dma_resv_trylock(resv)) {
clear = false;
+ unlock = true;
+ /* The caller is already holding the reservation lock */
+ } else if (ticket && dma_resv_locking_ctx(resv) == ticket) {
+ clear = false;
+ unlock = false;
/* Somebody else is using the BO right now */
- else
+ } else {
clear = true;
+ unlock = false;
+ }
r = amdgpu_vm_bo_update(adev, bo_va, clear, NULL);
if (r)
return r;
- if (!clear)
+ if (unlock)
dma_resv_unlock(resv);
spin_lock(&vm->invalidated_lock);
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
index a40a6a993bb0..120a76aaae75 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
@@ -396,7 +396,8 @@ int amdgpu_vm_clear_freed(struct amdgpu_device
*adev,
struct amdgpu_vm *vm,
struct dma_fence **fence);
int amdgpu_vm_handle_moved(struct amdgpu_device *adev,
- struct amdgpu_vm *vm);
+ struct amdgpu_vm *vm,
+ struct ww_acquire_ctx *ticket)
[PATCH v11 00/13] Add GuC Error Capture Support
This series: 1. Enables support of GuC to report error-state-capture using a list of MMIO registers the driver registers and GuC will dump, log and notify right before a GuC triggered engine-reset event. 2. Updates the ADS blob creation to register said lists of global, engine class and engine instance registers with GuC. 3. Defines tables of register lists that are global or engine class or engine instance in scope. 4. Updates usage and buffer-state data for the regions of the shared GuC log-buffer to accomdate both the existing relay logging of general debug logs along with the new error state capture usage. 5. Using a pool of preallocated memory, provide ability to extract and format the GuC reported register-capture data into chunks consistent with existing i915 error- state collection flows and structures. 6. Connects the i915_gpu_coredump reporting function to the GuC error capture module to print all GuC error state capture dumps that is reported. This is the 8th rev of this series with the first 3 revs labelled as RFC. Prior receipts of rvb's: - Patch #2, #3, #4, #5, #10, #11, #12, #13 have received R-v-b's from Umesh Nerlige Ramappa - Patch #6, #7, #8, #9 has received an R-v-b from Matthew Brost . NOTE: some of these came in on the trybot series. https://patchwork.freedesktop.org/series/100831/ Changes from prior revs: v11:- Rebase again on latest drm-tip to fix merge error. v10:- Rebase on latest drm-tip again. Fix a number of checkpatch warnings and an error Reported-by: kernel test robot . v9: - Rebase on latest drm-tip to solve CI merge-build error. v8: - Fix a bug found by CI in rev7: Create a cached ADS capture list for null-header like the other lists. - Fixed a bug on the ggtt offset calculation in the ADS population loop. Thanks to Matt Brost. - Change the storage uses for initial allocation and caching of the ADS register lists so we only store a regular pointer instead of file handle. - Multiple improvements on code styling, variable names, comments and code reduction from Umesh suggestions across multiple patches. v7: - Rebased on lastest drm_tip that has the ADS now using shmem based ads_blob_write utilities. Stress test was performed with this patch included to fix a legacy bug: https://patchwork.freedesktop.org/series/100768/ v6: - In patch #1, ADS reg-list population, we now alloc regular memory to create the lists and cache them for simpler and faster use by GuC ADS module at init, suspend-resume and reset cycles. This was in response to review comments from Lucas De Marchi that also wanted to ensure the GuC ADS module owns the final copying into the ADS phyical memory. - Thanks to Jani Nikula for pointing out that patch #2 and #3 should ensure static tables as constant and dynamic lists should be allocated and cached but attached to the GT level for the case of multiple cards with different fusings for steered registers. These are addressed now along with multiple code style fixups (thanks to review comment from Umesh) and splitting the steered register list generation as a seperate patch. - The extraction functionality, Patch #10 and #11 (was patch #7), has fixed all of Umesh's review comments related to the code styling. Additionally, it was discovered during stress tests that the extraction function could be called by the ct processing thread at the same time as the start of a GT reset event. Thus, a redesign was done whereby the linked list of processed capture-output-nodes are allocated up front and reused throughout the driver's life to ensure no memory locks are taken during extraction. - For patch #6 (now 7, 8 and 9), updates to intel_guc_log was split into smaller chunks and the log_state structure was returned back to inside of the intel_guc_log struct as opposed to the intel_guc struct in prior rev. This is in response to review comments by Matt Brost. - #Patch 13 (previously #10) is mostly identical but addresses all of the code styling comments reviews from Umesh. v5: - Added Gen9->Gen11 register list for CI coverage that included Gen9 with GuC submission. - Redesigned the extraction of the GuC error-capture dumps by grouping them into complete per-engine-reset nodes. Complete here means each node includes the global, engine-class and engine-instance register lists in a single structure. - Extraction is decoupled from the print-out. We now do the extraction immediately when receiving the G2H for error-capture no
Re: [PATCH v2] nvidia-wmi-ec-backlight: Add workarounds for confused firmware
On 3/17/22 12:35, Alex Deucher wrote: Sorry for jumping in here, but I can't seem to find the original thread with this comment. amdgpu_atombios_encoder_init_backlight() is not applicable to these systems. That is the old pre-DC code path. You want amdgpu_dm_register_backlight_device() for modern hardware. Oops, thanks for the correction. Alex Dinu: see the above for the correct code path to disable to test whether not registering the amdgpu backlight device helps. I have some other things to attend to, so it will be a little while before I can get you the instrumented driver I mentioned in one of my replies to Hans, but hopefully we'll be able to figure something out to actually switch the backlight control to EC without having to do a suspend/resume cycle.
[PATCH] drm/msm: Add missing put_task_struct() in debugfs path
From: Rob Clark
Fixes: 25faf2f2e065 ("drm/msm: Show process names in gem_describe")
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 02b9ae65a96a..a4f61972667b 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -926,6 +926,7 @@ void msm_gem_describe(struct drm_gem_object *obj, struct
seq_file *m,
get_pid_task(aspace->pid, PIDTYPE_PID);
if (task) {
comm = kstrdup(task->comm, GFP_KERNEL);
+ put_task_struct(task);
} else {
comm = NULL;
}
--
2.35.1
Re: [PATCH v2] nvidia-wmi-ec-backlight: Add workarounds for confused firmware
On 3/17/22 11:42, Hans de Goede wrote: Hi Daniel, On 3/17/22 14:28, Daniel Dadap wrote: On Mar 17, 2022, at 07:17, Hans de Goede wrote: Hi, On 3/16/22 21:33, Daniel Dadap wrote: Some notebook systems with EC-driven backlight control appear to have a firmware bug which causes the system to use GPU-driven backlight control upon a fresh boot, but then switches to EC-driven backlight control after completing a suspend/resume cycle. All the while, the firmware reports that the backlight is under EC control, regardless of what is actually controlling the backlight brightness. This leads to the following behavior: * nvidia-wmi-ec-backlight gets probed on a fresh boot, due to the WMI-wrapped ACPI method erroneously reporting EC control. * nvidia-wmi-ec-backlight does not work until after a suspend/resume cycle, due to the backlight control actually being GPU-driven. * GPU drivers also register their own backlight handlers: in the case of the notebook system where this behavior has been observed, both amdgpu and the NVIDIA proprietary driver register backlight handlers. * The GPU which has backlight control upon a fresh boot (amdgpu in the case observed so far) can successfully control the backlight through its backlight driver's sysfs interface, but stops working after the first suspend/resume cycle. * nvidia-wmi-ec-backlight is unable to control the backlight upon a fresh boot, but begins to work after the first suspend/resume cycle. * The GPU which does not have backlight control (NVIDIA in this case) is not able to control the backlight at any point while the system is in operation. On similar hybrid systems with an EC-controlled backlight, and AMD/NVIDIA iGPU/dGPU, the NVIDIA proprietary driver does not register its backlight handler. It has not been determined whether the non-functional handler registered by the NVIDIA driver is due to another firmware bug, or a bug in the NVIDIA driver. Since nvidia-wmi-ec-backlight registers as a BACKLIGHT_FIRMWARE type device, it takes precedence over the BACKLIGHT_RAW devices registered by the GPU drivers. This in turn leads to backlight control appearing to be non-functional until after completing a suspend/resume cycle. However, it is still possible to control the backlight through direct interaction with the working GPU driver's backlight sysfs interface. These systems also appear to have a second firmware bug which resets the EC's brightness level to 100% on resume, but leaves the state in the kernel at the pre-suspend level. This causes attempts to save and restore the backlight level across the suspend/resume cycle to fail, due to the level appearing not to change even though it did. In order to work around these issues, add a quirk table to detect systems that are known to show these behaviors. So far, there is only one known system that requires these workarounds, and both issues are present on that system, but the quirks are tracked separately to make it easier to add them to other systems which may exhibit one of the bugs, but not the other. The original systems that this driver was tested on during development do not exhibit either of these quirks. If a system with the "GPU driver has backlight control" quirk is detected, nvidia-wmi-ec-backlight will grab a reference to the working (when freshly booted) GPU backlight handler and relays any backlight brightness level change requests directed at the EC to also be applied to the GPU backlight interface. This leads to redundant updates directed at the GPU backlight driver after a suspend/resume cycle, but it does allow the EC backlight control to work when the system is freshly booted. Ugh, I'm really not a fan of the backlight proxy plan here. I have plans to clean-up the whole x86 backlight mess soon and an important part of that is to stop registering multiple backlight interfaces for the same panel/screen. Where as going with this workaround requires us to have 2 active backlight interfaces active. Also this will very likely work to (subtly) different backlight behavior before and after the first suspend/resume. I understand. Having multiple backlight devices for the same panel is indeed annoying. Out of curiosity, what is the plan for determining that multiple backlight interfaces are all supposed to control the same panel? ATM the kernel basically only supports a bunch of different methods to control the backlight of 1 internal panel. The plan is to tie this to the panel from a userspace pov by making the brightness + max_brightness properties on the drm_connector object for the internal-panel. The in kernel tying of the backlight device to the internal panel will be done hardcoded inside the drm driver(s) based on the drivers already knowing which connector is the internal panel. Okay. At the moment the other problem I am thinking about also makes a one-internal-panel assumption, and it's true for the particular hardware that I'm working with, but I di
Re: [PATCH 2/3] drm/msm/gpu: Park scheduler threads for system suspend
On Thu, Mar 17, 2022 at 11:10 AM Andrey Grodzovsky wrote: > > > On 2022-03-17 13:35, Rob Clark wrote: > > On Thu, Mar 17, 2022 at 9:45 AM Christian König > > wrote: > >> Am 17.03.22 um 17:18 schrieb Rob Clark: > >>> On Thu, Mar 17, 2022 at 9:04 AM Christian König > >>> wrote: > Am 17.03.22 um 16:10 schrieb Rob Clark: > > [SNIP] > > userspace frozen != kthread frozen .. that is what this patch is > > trying to address, so we aren't racing between shutting down the hw > > and the scheduler shoveling more jobs at us. > Well exactly that's the problem. The scheduler is supposed to shoveling > more jobs at us until it is empty. > > Thinking more about it we will then keep some dma_fence instance > unsignaled and that is and extremely bad idea since it can lead to > deadlocks during suspend. > >>> Hmm, perhaps that is true if you need to migrate things out of vram? > >>> It is at least not a problem when vram is not involved. > >> No, it's much wider than that. > >> > >> See what can happen is that the memory management shrinkers want to wait > >> for a dma_fence during suspend. > > we don't wait on fences in shrinker, only purging or evicting things > > that are already ready. Actually, waiting on fences in shrinker path > > sounds like a pretty bad idea. > > > >> And if you stop the scheduler they will just wait forever. > >> > >> What you need to do instead is to drain the scheduler, e.g. call > >> drm_sched_entity_flush() with a proper timeout for each entity you have > >> created. > > yeah, it would work to drain the scheduler.. I guess that might be the > > more portable approach as far as generic solution for suspend. > > > > BR, > > -R > > > I am not sure how this drains the scheduler ? Suppose we done the > waiting in drm_sched_entity_flush, > what prevents someone to push right away another job into the same > entity's queue right after that ? > Shouldn't we first disable further pushing of jobs into entity before we > wait for sched->job_scheduled ? > In the system suspend path, userspace processes will have already been frozen, so there should be no way to push more jobs to the scheduler, unless they are pushed from the kernel itself. We don't do that in drm/msm, but maybe you need to to move things btwn vram and system memory? But even in that case, if the # of jobs you push is bounded I guess that is ok? BR, -R
Re: [PATCH 2/3] drm/msm/gpu: Park scheduler threads for system suspend
On 2022-03-17 13:35, Rob Clark wrote: On Thu, Mar 17, 2022 at 9:45 AM Christian König wrote: Am 17.03.22 um 17:18 schrieb Rob Clark: On Thu, Mar 17, 2022 at 9:04 AM Christian König wrote: Am 17.03.22 um 16:10 schrieb Rob Clark: [SNIP] userspace frozen != kthread frozen .. that is what this patch is trying to address, so we aren't racing between shutting down the hw and the scheduler shoveling more jobs at us. Well exactly that's the problem. The scheduler is supposed to shoveling more jobs at us until it is empty. Thinking more about it we will then keep some dma_fence instance unsignaled and that is and extremely bad idea since it can lead to deadlocks during suspend. Hmm, perhaps that is true if you need to migrate things out of vram? It is at least not a problem when vram is not involved. No, it's much wider than that. See what can happen is that the memory management shrinkers want to wait for a dma_fence during suspend. we don't wait on fences in shrinker, only purging or evicting things that are already ready. Actually, waiting on fences in shrinker path sounds like a pretty bad idea. And if you stop the scheduler they will just wait forever. What you need to do instead is to drain the scheduler, e.g. call drm_sched_entity_flush() with a proper timeout for each entity you have created. yeah, it would work to drain the scheduler.. I guess that might be the more portable approach as far as generic solution for suspend. BR, -R I am not sure how this drains the scheduler ? Suppose we done the waiting in drm_sched_entity_flush, what prevents someone to push right away another job into the same entity's queue right after that ? Shouldn't we first disable further pushing of jobs into entity before we wait for sched->job_scheduled ? Andrey Regards, Christian. So this patch here is an absolute clear NAK from my side. If amdgpu is doing something similar that is a severe bug and needs to be addressed somehow. I think amdgpu's use of kthread_park is not related to suspend, but didn't look too closely. And perhaps the solution for this problem is more complex in the case of amdgpu, I'm not super familiar with the constraints there. But I think it is a fine solution for integrated GPUs. BR, -R Regards, Christian. BR, -R
[PATCH v2] drm/bridge: nwl-dsi: switch to devm_drm_of_get_bridge
The function "drm_of_find_panel_or_bridge" has been deprecated in
favor of "devm_drm_of_get_bridge".
Switch to the new function and reduce boilerplate.
Signed-off-by: José Expósito
---
v2: (Thanks to Liu Ying)
- Rebase on top of drm-misc-next
- Remove drm_of_panel_bridge_remove
---
drivers/gpu/drm/bridge/nwl-dsi.c | 23 ---
1 file changed, 4 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
index e34fb09b90b9..de62e3fc6a59 100644
--- a/drivers/gpu/drm/bridge/nwl-dsi.c
+++ b/drivers/gpu/drm/bridge/nwl-dsi.c
@@ -912,19 +912,11 @@ static int nwl_dsi_bridge_attach(struct drm_bridge
*bridge,
{
struct nwl_dsi *dsi = bridge_to_dsi(bridge);
struct drm_bridge *panel_bridge;
- struct drm_panel *panel;
- int ret;
-
- ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 1, 0, &panel,
- &panel_bridge);
- if (ret)
- return ret;
- if (panel) {
- panel_bridge = drm_panel_bridge_add(panel);
- if (IS_ERR(panel_bridge))
- return PTR_ERR(panel_bridge);
- }
+ panel_bridge = devm_drm_of_get_bridge(dsi->dev, dsi->dev->of_node,
+ 1, 0);
+ if (IS_ERR(panel_bridge))
+ return PTR_ERR(panel_bridge);
if (!panel_bridge)
return -EPROBE_DEFER;
@@ -932,12 +924,6 @@ static int nwl_dsi_bridge_attach(struct drm_bridge *bridge,
return drm_bridge_attach(bridge->encoder, panel_bridge, bridge, flags);
}
-static void nwl_dsi_bridge_detach(struct drm_bridge *bridge)
-{ struct nwl_dsi *dsi = bridge_to_dsi(bridge);
-
- drm_of_panel_bridge_remove(dsi->dev->of_node, 1, 0);
-}
-
static u32 *nwl_bridge_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
struct drm_bridge_state
*bridge_state,
struct drm_crtc_state
*crtc_state,
@@ -983,7 +969,6 @@ static const struct drm_bridge_funcs nwl_dsi_bridge_funcs =
{
.mode_set = nwl_dsi_bridge_mode_set,
.mode_valid = nwl_dsi_bridge_mode_valid,
.attach = nwl_dsi_bridge_attach,
- .detach = nwl_dsi_bridge_detach,
};
static int nwl_dsi_parse_dt(struct nwl_dsi *dsi)
--
2.25.1
Re: [PATCH 2/3] drm/msm/gpu: Park scheduler threads for system suspend
On 2022-03-17 12:04, Christian König wrote: Am 17.03.22 um 16:10 schrieb Rob Clark: [SNIP] userspace frozen != kthread frozen .. that is what this patch is trying to address, so we aren't racing between shutting down the hw and the scheduler shoveling more jobs at us. Well exactly that's the problem. The scheduler is supposed to shoveling more jobs at us until it is empty. Thinking more about it we will then keep some dma_fence instance unsignaled and that is and extremely bad idea since it can lead to deadlocks during suspend. So this patch here is an absolute clear NAK from my side. If amdgpu is doing something similar that is a severe bug and needs to be addressed somehow. From looking at latest amd-stagin-drm-next we only use directly kthread_park during in debugfs IB hooks. For S3 suspend (amdgpu_pmops_suspend) we will only flush all the HW fences (amdgpu_fence_wait_empty) so we don't freeze the scheduler thread and don't flush scheduler entities. Andrey Regards, Christian. BR, -R
Re: [PATCH v2 6/8] drm/shmem-helper: Add generic memory shrinker
On 3/17/22 20:32, Daniel Vetter wrote:
>> +static void drm_gem_shmem_update_purgeable_status(struct
>> drm_gem_shmem_object *shmem)
>> +{
>> +struct drm_gem_object *obj = &shmem->base;
>> +struct drm_gem_shmem_shrinker *gem_shrinker = obj->dev->shmem_shrinker;
>> +size_t page_count = obj->size >> PAGE_SHIFT;
>> +
>> +if (!gem_shrinker || obj->import_attach || !obj->funcs->purge)
>> +return;
>> +
>> +mutex_lock(&shmem->vmap_lock);
>> +mutex_lock(&shmem->pages_lock);
>> +mutex_lock(&gem_shrinker->lock);
> Uh this is just terrible I think.
>
> Can't we move shmem helpers over to reasonable locking, i.e. per-object
> dma_resv_lock for everything? I know it's a pile of work, but I think
> we're way past the point with things like this popping up where we should
> just bite that bullet.
>
> I discussed the full thing with Daniel Stone, but maybe a joint refresher
> on irc would be a good thing.
Aha! Perhaps I saw bits of that discussion, but it wasn't entirely clear
to me what was discussed in fact. Sounds like a good idea to try to use
the reservation lock everywhere, thank you for the suggestion.
Re: [PATCH v2 6/8] drm/shmem-helper: Add generic memory shrinker
On 3/17/22 19:13, Rob Clark wrote: ... + /* prevent racing with job submission code paths */ + if (!dma_resv_trylock(obj->resv)) + goto shrinker_lock; >>> >>> jfwiw, the trylock here is in the msm code isn't so much for madvise >>> (it is an error to submit jobs that reference DONTNEED objects), but >>> instead for the case of evicting WILLNEED but inactive objects to >>> swap. Ie. in the case that we need to move bo's back in to memory, we >>> don't want to unpin/evict a buffer that is later on the list for the >>> same job.. msm shrinker re-uses the same scan loop for both >>> inactive_dontneed (purge) and inactive_willneed (evict) >> >> I don't see connection between the objects on the shrinker's list and >> the job's BOs. Jobs indeed must not have any objects marked as DONTNEED, >> this case should never happen in practice, but we still need to protect >> from it. > > Hmm, let me try to explain with a simple example.. hopefully this makes sense. > > Say you have a job with two bo's, A and B.. bo A is not backed with > memory (either hasn't been used before or was evicted. Allocating > pages for A triggers shrinker. But B is still on the > inactive_willneed list, however it is already locked (because we don't > want to evict B to obtain backing pages for A). I see now what you're talking about, thanks. My intention of locking the reservations is different since eviction isn't supported by this v2. But we probably will be able to re-use this try_lock for protecting from swapping out job's BOs as well. >>> I suppose using trylock is not technically wrong, and it would be a >>> good idea if the shmem helpers supported eviction as well. But I >>> think in the madvise/purge case if you lose the trylock then there is >>> something else bad going on. >> >> This trylock is intended for protecting job's submission path from >> racing with madvise ioctl invocation followed by immediate purging of >> BOs while job is in a process of submission, i.e. it protects from a >> use-after-free. > > ahh, ok > >> If you'll lose this trylock, then shrinker can't use >> dma_resv_test_signaled() reliably anymore and shrinker may purge BO >> before job had a chance to add fence to the BO's reservation. >> >>> Anyways, from the PoV of minimizing lock contention when under memory >>> pressure, this all looks good to me. >> >> Thank you. I may try to add generic eviction support to the v3. > > eviction is a trickier thing to get right, I wouldn't blame you for > splitting that out into it's own patchset ;-) > > You probably also would want to make it a thing that is opt-in for > drivers using the shmem helpers I had the same thoughts, will see.
Re: [PATCH 1/6] drm: allow real encoder to be passed for drm_writeback_connector
Hi Daniel
On 3/17/2022 3:01 AM, Daniel Vetter wrote:
On Fri, Mar 11, 2022 at 10:05:53AM +0200, Laurent Pinchart wrote:
On Fri, Mar 11, 2022 at 10:46:13AM +0300, Dmitry Baryshkov wrote:
On Fri, 11 Mar 2022 at 04:50, Abhinav Kumar wrote:
For some vendor driver implementations, display hardware can
be shared between the encoder used for writeback and the physical
display.
In addition resources such as clocks and interrupts can
also be shared between writeback and the real encoder.
To accommodate such vendor drivers and hardware, allow
real encoder to be passed for drm_writeback_connector.
Co-developed-by: Kandpal Suraj
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/drm_writeback.c | 8
include/drm/drm_writeback.h | 13 +++--
2 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
index dccf4504..4dad687 100644
--- a/drivers/gpu/drm/drm_writeback.c
+++ b/drivers/gpu/drm/drm_writeback.c
@@ -189,8 +189,8 @@ int drm_writeback_connector_init(struct drm_device *dev,
if (IS_ERR(blob))
return PTR_ERR(blob);
- drm_encoder_helper_add(&wb_connector->encoder, enc_helper_funcs);
- ret = drm_encoder_init(dev, &wb_connector->encoder,
+ drm_encoder_helper_add(wb_connector->encoder, enc_helper_funcs);
+ ret = drm_encoder_init(dev, wb_connector->encoder,
&drm_writeback_encoder_funcs,
DRM_MODE_ENCODER_VIRTUAL, NULL);
If the encoder is provided by a separate driver, it might use a
different set of encoder funcs.
More than that, if the encoder is provided externally but doesn't have
custom operations, I don't really see the point of having an external
encoder in the first place.
Has this series been tested with a driver that needs to provide an
encoder, to make sure it fits the purpose ?
Also, can we not force all drivers to do this setup that don't need it? We
have a ton of kms drivers, forcing unnecessary busiwork on drivers is
really not good.
-Daniel
No, there will not be any requirement forced for existing drivers.
A new API will be exposed for new clients which setup the encoder.
I'd suggest checking whether the wb_connector->encoder is NULL here.
If it is, allocate one using drmm_kzalloc and init it.
If it is not NULL, assume that it has been initialized already, so
skip the drm_encoder_init() and just call the drm_encoder_helper_add()
if (ret)
@@ -204,7 +204,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
goto connector_fail;
ret = drm_connector_attach_encoder(connector,
- &wb_connector->encoder);
+ wb_connector->encoder);
if (ret)
goto attach_fail;
@@ -233,7 +233,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
attach_fail:
drm_connector_cleanup(connector);
connector_fail:
- drm_encoder_cleanup(&wb_connector->encoder);
+ drm_encoder_cleanup(wb_connector->encoder);
fail:
drm_property_blob_put(blob);
return ret;
diff --git a/include/drm/drm_writeback.h b/include/drm/drm_writeback.h
index 9697d27..0ba266e 100644
--- a/include/drm/drm_writeback.h
+++ b/include/drm/drm_writeback.h
@@ -25,13 +25,22 @@ struct drm_writeback_connector {
struct drm_connector base;
/**
-* @encoder: Internal encoder used by the connector to fulfill
+* @encoder: handle to drm_encoder used by the connector to fulfill
* the DRM framework requirements. The users of the
* @drm_writeback_connector control the behaviour of the @encoder
* by passing the @enc_funcs parameter to
drm_writeback_connector_init()
* function.
+*
+* For some vendor drivers, the hardware resources are shared between
+* writeback encoder and rest of the display pipeline.
+* To accommodate such cases, encoder is a handle to the real encoder
+* hardware.
+*
+* For current existing writeback users, this shall continue to be the
+* embedded encoder for the writeback connector.
+*
*/
- struct drm_encoder encoder;
+ struct drm_encoder *encoder;
/**
* @pixel_formats_blob_ptr:
--
Regards,
Laurent Pinchart
Re: [PATCH v2] nvidia-wmi-ec-backlight: Add workarounds for confused firmware
On Thu, Mar 17, 2022 at 12:42 PM Hans de Goede wrote: > > Hi Daniel, > > On 3/17/22 14:28, Daniel Dadap wrote: > > > >> On Mar 17, 2022, at 07:17, Hans de Goede wrote: > >> > >> Hi, > >> > >>> On 3/16/22 21:33, Daniel Dadap wrote: > >>> Some notebook systems with EC-driven backlight control appear to have a > >>> firmware bug which causes the system to use GPU-driven backlight control > >>> upon a fresh boot, but then switches to EC-driven backlight control > >>> after completing a suspend/resume cycle. All the while, the firmware > >>> reports that the backlight is under EC control, regardless of what is > >>> actually controlling the backlight brightness. > >>> > >>> This leads to the following behavior: > >>> > >>> * nvidia-wmi-ec-backlight gets probed on a fresh boot, due to the > >>> WMI-wrapped ACPI method erroneously reporting EC control. > >>> * nvidia-wmi-ec-backlight does not work until after a suspend/resume > >>> cycle, due to the backlight control actually being GPU-driven. > >>> * GPU drivers also register their own backlight handlers: in the case > >>> of the notebook system where this behavior has been observed, both > >>> amdgpu and the NVIDIA proprietary driver register backlight handlers. > >>> * The GPU which has backlight control upon a fresh boot (amdgpu in the > >>> case observed so far) can successfully control the backlight through > >>> its backlight driver's sysfs interface, but stops working after the > >>> first suspend/resume cycle. > >>> * nvidia-wmi-ec-backlight is unable to control the backlight upon a > >>> fresh boot, but begins to work after the first suspend/resume cycle. > >>> * The GPU which does not have backlight control (NVIDIA in this case) > >>> is not able to control the backlight at any point while the system > >>> is in operation. On similar hybrid systems with an EC-controlled > >>> backlight, and AMD/NVIDIA iGPU/dGPU, the NVIDIA proprietary driver > >>> does not register its backlight handler. It has not been determined > >>> whether the non-functional handler registered by the NVIDIA driver > >>> is due to another firmware bug, or a bug in the NVIDIA driver. > >>> > >>> Since nvidia-wmi-ec-backlight registers as a BACKLIGHT_FIRMWARE type > >>> device, it takes precedence over the BACKLIGHT_RAW devices registered > >>> by the GPU drivers. This in turn leads to backlight control appearing > >>> to be non-functional until after completing a suspend/resume cycle. > >>> However, it is still possible to control the backlight through direct > >>> interaction with the working GPU driver's backlight sysfs interface. > >>> > >>> These systems also appear to have a second firmware bug which resets > >>> the EC's brightness level to 100% on resume, but leaves the state in > >>> the kernel at the pre-suspend level. This causes attempts to save > >>> and restore the backlight level across the suspend/resume cycle to > >>> fail, due to the level appearing not to change even though it did. > >>> > >>> In order to work around these issues, add a quirk table to detect > >>> systems that are known to show these behaviors. So far, there is > >>> only one known system that requires these workarounds, and both > >>> issues are present on that system, but the quirks are tracked > >>> separately to make it easier to add them to other systems which > >>> may exhibit one of the bugs, but not the other. The original systems > >>> that this driver was tested on during development do not exhibit > >>> either of these quirks. > >>> > >>> If a system with the "GPU driver has backlight control" quirk is > >>> detected, nvidia-wmi-ec-backlight will grab a reference to the working > >>> (when freshly booted) GPU backlight handler and relays any backlight > >>> brightness level change requests directed at the EC to also be applied > >>> to the GPU backlight interface. This leads to redundant updates > >>> directed at the GPU backlight driver after a suspend/resume cycle, but > >>> it does allow the EC backlight control to work when the system is > >>> freshly booted. > >> > >> Ugh, I'm really not a fan of the backlight proxy plan here. I have > >> plans to clean-up the whole x86 backlight mess soon and an important part > >> of that is to stop registering multiple backlight interfaces for the > >> same panel/screen. > >> > >> Where as going with this workaround requires us to have 2 active > >> backlight interfaces active. Also this will very likely work to > >> (subtly) different backlight behavior before and after the first > >> suspend/resume. > > > > I understand. Having multiple backlight devices for the same panel is > > indeed annoying. Out of curiosity, what is the plan for determining that > > multiple backlight interfaces are all supposed to control the same panel? > > ATM the kernel basically only supports a bunch of different methods > to control the backlight of 1 internal panel. The plan is to tie this > to the panel from a userspace pov by making the brightn
Re: [PATCH 2/3] drm/msm/gpu: Park scheduler threads for system suspend
On Thu, Mar 17, 2022 at 9:45 AM Christian König wrote: > > Am 17.03.22 um 17:18 schrieb Rob Clark: > > On Thu, Mar 17, 2022 at 9:04 AM Christian König > > wrote: > >> Am 17.03.22 um 16:10 schrieb Rob Clark: > >>> [SNIP] > >>> userspace frozen != kthread frozen .. that is what this patch is > >>> trying to address, so we aren't racing between shutting down the hw > >>> and the scheduler shoveling more jobs at us. > >> Well exactly that's the problem. The scheduler is supposed to shoveling > >> more jobs at us until it is empty. > >> > >> Thinking more about it we will then keep some dma_fence instance > >> unsignaled and that is and extremely bad idea since it can lead to > >> deadlocks during suspend. > > Hmm, perhaps that is true if you need to migrate things out of vram? > > It is at least not a problem when vram is not involved. > > No, it's much wider than that. > > See what can happen is that the memory management shrinkers want to wait > for a dma_fence during suspend. we don't wait on fences in shrinker, only purging or evicting things that are already ready. Actually, waiting on fences in shrinker path sounds like a pretty bad idea. > And if you stop the scheduler they will just wait forever. > > What you need to do instead is to drain the scheduler, e.g. call > drm_sched_entity_flush() with a proper timeout for each entity you have > created. yeah, it would work to drain the scheduler.. I guess that might be the more portable approach as far as generic solution for suspend. BR, -R > Regards, > Christian. > > > > >> So this patch here is an absolute clear NAK from my side. If amdgpu is > >> doing something similar that is a severe bug and needs to be addressed > >> somehow. > > I think amdgpu's use of kthread_park is not related to suspend, but > > didn't look too closely. > > > > And perhaps the solution for this problem is more complex in the case > > of amdgpu, I'm not super familiar with the constraints there. But I > > think it is a fine solution for integrated GPUs. > > > > BR, > > -R > > > >> Regards, > >> Christian. > >> > >>> BR, > >>> -R > >>> >
Re: [PATCH v2 6/8] drm/shmem-helper: Add generic memory shrinker
On Tue, Mar 15, 2022 at 01:42:51AM +0300, Dmitry Osipenko wrote:
> Introduce a common DRM SHMEM shrinker. It allows to reduce code
> duplication among DRM drivers, it also handles complicated lockings
> for the drivers. This is initial version of the shrinker that covers
> basic needs of GPU drivers.
>
> This patch is based on a couple ideas borrowed from Rob's Clark MSM
> shrinker and Thomas' Zimmermann variant of SHMEM shrinker.
>
> GPU drivers that want to use generic DRM memory shrinker must support
> generic GEM reservations.
>
> Signed-off-by: Daniel Almeida
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c | 194 +
> include/drm/drm_device.h | 4 +
> include/drm/drm_gem.h | 11 ++
> include/drm/drm_gem_shmem_helper.h | 25
> 4 files changed, 234 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index 37009418cd28..35be2ee98f11 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -139,6 +139,9 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object
> *shmem)
> {
> struct drm_gem_object *obj = &shmem->base;
>
> + /* take out shmem GEM object from the memory shrinker */
> + drm_gem_shmem_madvise(shmem, 0);
> +
> WARN_ON(shmem->vmap_use_count);
>
> if (obj->import_attach) {
> @@ -163,6 +166,42 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object
> *shmem)
> }
> EXPORT_SYMBOL_GPL(drm_gem_shmem_free);
>
> +static void drm_gem_shmem_update_purgeable_status(struct
> drm_gem_shmem_object *shmem)
> +{
> + struct drm_gem_object *obj = &shmem->base;
> + struct drm_gem_shmem_shrinker *gem_shrinker = obj->dev->shmem_shrinker;
> + size_t page_count = obj->size >> PAGE_SHIFT;
> +
> + if (!gem_shrinker || obj->import_attach || !obj->funcs->purge)
> + return;
> +
> + mutex_lock(&shmem->vmap_lock);
> + mutex_lock(&shmem->pages_lock);
> + mutex_lock(&gem_shrinker->lock);
Uh this is just terrible I think.
Can't we move shmem helpers over to reasonable locking, i.e. per-object
dma_resv_lock for everything? I know it's a pile of work, but I think
we're way past the point with things like this popping up where we should
just bite that bullet.
I discussed the full thing with Daniel Stone, but maybe a joint refresher
on irc would be a good thing.
-Daniel
> +
> + if (shmem->madv < 0) {
> + list_del_init(&shmem->madv_list);
> + goto unlock;
> + } else if (shmem->madv > 0) {
> + if (!list_empty(&shmem->madv_list))
> + goto unlock;
> +
> + WARN_ON(gem_shrinker->shrinkable_count + page_count <
> page_count);
> + gem_shrinker->shrinkable_count += page_count;
> +
> + list_add_tail(&shmem->madv_list, &gem_shrinker->lru);
> + } else if (!list_empty(&shmem->madv_list)) {
> + list_del_init(&shmem->madv_list);
> +
> + WARN_ON(gem_shrinker->shrinkable_count < page_count);
> + gem_shrinker->shrinkable_count -= page_count;
> + }
> +unlock:
> + mutex_unlock(&gem_shrinker->lock);
> + mutex_unlock(&shmem->pages_lock);
> + mutex_unlock(&shmem->vmap_lock);
> +}
> +
> static int drm_gem_shmem_get_pages_locked(struct drm_gem_shmem_object *shmem)
> {
> struct drm_gem_object *obj = &shmem->base;
> @@ -366,6 +405,8 @@ int drm_gem_shmem_vmap(struct drm_gem_shmem_object *shmem,
> ret = drm_gem_shmem_vmap_locked(shmem, map);
> mutex_unlock(&shmem->vmap_lock);
>
> + drm_gem_shmem_update_purgeable_status(shmem);
> +
> return ret;
> }
> EXPORT_SYMBOL(drm_gem_shmem_vmap);
> @@ -409,6 +450,8 @@ void drm_gem_shmem_vunmap(struct drm_gem_shmem_object
> *shmem,
> mutex_lock(&shmem->vmap_lock);
> drm_gem_shmem_vunmap_locked(shmem, map);
> mutex_unlock(&shmem->vmap_lock);
> +
> + drm_gem_shmem_update_purgeable_status(shmem);
> }
> EXPORT_SYMBOL(drm_gem_shmem_vunmap);
>
> @@ -451,6 +494,8 @@ int drm_gem_shmem_madvise(struct drm_gem_shmem_object
> *shmem, int madv)
>
> mutex_unlock(&shmem->pages_lock);
>
> + drm_gem_shmem_update_purgeable_status(shmem);
> +
> return (madv >= 0);
> }
> EXPORT_SYMBOL(drm_gem_shmem_madvise);
> @@ -763,6 +808,155 @@ drm_gem_shmem_prime_import_sg_table(struct drm_device
> *dev,
> }
> EXPORT_SYMBOL_GPL(drm_gem_shmem_prime_import_sg_table);
>
> +static struct drm_gem_shmem_shrinker *
> +to_drm_shrinker(struct shrinker *shrinker)
> +{
> + return container_of(shrinker, struct drm_gem_shmem_shrinker, base);
> +}
> +
> +static unsigned long
> +drm_gem_shmem_shrinker_count_objects(struct shrinker *shrinker,
> + struct shrink_control *sc)
> +{
> + struct drm_gem_shmem_shrinker *gem_shrinker = to_drm_shrinker(shrinker);
> + u64 count = gem_shrinker->shrinkabl
Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event
On Thu, Mar 17, 2022 at 10:27 AM Daniel Vetter wrote: > > On Thu, Mar 17, 2022 at 08:40:51AM -0700, Rob Clark wrote: > > On Thu, Mar 17, 2022 at 2:29 AM Daniel Vetter wrote: > > > > > > On Thu, Mar 17, 2022 at 08:03:27AM +0100, Christian König wrote: > > > > Am 16.03.22 um 16:36 schrieb Rob Clark: > > > > > [SNIP] > > > > > just one point of clarification.. in the msm and i915 case it is > > > > > purely for debugging and telemetry (ie. sending crash logs back to > > > > > distro for analysis if user has crash reporting enabled).. it isn't > > > > > used for triggering any action like killing app or compositor. > > > > > > > > By the way, how does msm it's memory management for the devcoredumps? > > > > > > GFP_NORECLAIM all the way. It's purely best effort. > > > > > > Note that the fancy new plan for i915 discrete gpu is to only support gpu > > > crash dumps on non-recoverable gpu contexts, i.e. those that do not > > > continue to the next batch when something bad happens. This is what vk > > > wants and also what iris now uses (we do context recovery in userspace in > > > all cases), and non-recoverable contexts greatly simplify the crash dump > > > gather: Only thing you need to gather is the register state from hw > > > (before you reset it), all the batchbuffer bo and indirect state bo (in > > > i915 you can mark which bo to capture in the CS ioctl) can be captured in > > > a worker later on. Which for non-recoverable context is no issue, since > > > subsequent batchbuffers won't trample over any of these things. > > > > fwiw, we snapshot everything (cmdstream and bo's marked with dump > > flag, in addition to hw state) before resuming the GPU, so there is no > > danger of things being trampled. After state is captured and GPU > > reset, we "replay" the submits that were written into the ringbuffer > > after the faulting submit. GPU crashes should be a thing you don't > > need to try to optimize. > > Not sure why you think we optimize anything here? > > > (At some point, I'd like to use scheduler for the replay, and actually > > use drm_sched_stop()/etc.. but last time I looked there were still > > some sched bugs in that area which prevented me from deleting a bunch > > of code ;-)) > > Not sure about your hw, but at least on intel replaying tends to just > result in follow-on fun. And that holds even more so the more complex a > workload is. This is why vk just dies immediately and does not try to > replay anything, offloading it to the app. Same with arb robusteness. > Afaik it's really only media and classic gl which insist that the driver > stack somehow recover. At least for us, each submit must be self-contained (ie. not rely on previous GPU hw state), so in practice replay works out pretty well. The worst case is subsequent submits from same process fail as well (if they depended on something that crashing submit failed to write back to memory.. but in that case they just crash as well and we move on to the next one.. the recent gens (a5xx+ at least) are pretty good about quickly detecting problems and giving us an error irq. BR, -R > And recovering from a mess in userspace is a lot simpler than trying to > pull of the same magic in the kernel. Plus it also helps with a few of the > dma_fence rules, which is a nice bonus. > -Daniel > > > > > BR, > > -R > > > > > > > > And that way you can record the crashdump (or at least the big pieces like > > > all the indirect state stuff) with GFP_KERNEL. > > > > > > msm probably gets it wrong since embedded drivers have much less shrinker > > > and generally no mmu notifiers going on :-) > > > > > > > I mean it is strictly forbidden to allocate any memory in the GPU reset > > > > path. > > > > > > > > > I would however *strongly* recommend devcoredump support in other GPU > > > > > drivers (i915's thing pre-dates devcoredump by a lot).. I've used it > > > > > to debug and fix a couple obscure issues that I was not able to > > > > > reproduce by myself. > > > > > > > > Yes, completely agree as well. > > > > > > +1 > > > > > > Cheers, Daniel > > > -- > > > Daniel Vetter > > > Software Engineer, Intel Corporation > > > http://blog.ffwll.ch > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch
Re: [PATCH 2/3] drm/msm/gpu: Park scheduler threads for system suspend
On Thu, Mar 17, 2022 at 05:44:57PM +0100, Christian König wrote: > Am 17.03.22 um 17:18 schrieb Rob Clark: > > On Thu, Mar 17, 2022 at 9:04 AM Christian König > > wrote: > > > Am 17.03.22 um 16:10 schrieb Rob Clark: > > > > [SNIP] > > > > userspace frozen != kthread frozen .. that is what this patch is > > > > trying to address, so we aren't racing between shutting down the hw > > > > and the scheduler shoveling more jobs at us. > > > Well exactly that's the problem. The scheduler is supposed to shoveling > > > more jobs at us until it is empty. > > > > > > Thinking more about it we will then keep some dma_fence instance > > > unsignaled and that is and extremely bad idea since it can lead to > > > deadlocks during suspend. > > Hmm, perhaps that is true if you need to migrate things out of vram? > > It is at least not a problem when vram is not involved. > > No, it's much wider than that. > > See what can happen is that the memory management shrinkers want to wait for > a dma_fence during suspend. > > And if you stop the scheduler they will just wait forever. > > What you need to do instead is to drain the scheduler, e.g. call > drm_sched_entity_flush() with a proper timeout for each entity you have > created. Yeah I think properly flushing the scheduler and stopping it and cutting all drivers over to that sounds like the right approach. Generally suspend shouldn't be such a critical path that this will hurt us, all the other io queues get flushed too afaik. Resume is the thing that needs to go real fast. So a patch set to move all drivers that open code the kthread_park to the right scheduler function sounds like the right idea here to me. -Daniel > > Regards, > Christian. > > > > > > So this patch here is an absolute clear NAK from my side. If amdgpu is > > > doing something similar that is a severe bug and needs to be addressed > > > somehow. > > I think amdgpu's use of kthread_park is not related to suspend, but > > didn't look too closely. > > > > And perhaps the solution for this problem is more complex in the case > > of amdgpu, I'm not super familiar with the constraints there. But I > > think it is a fine solution for integrated GPUs. > > > > BR, > > -R > > > > > Regards, > > > Christian. > > > > > > > BR, > > > > -R > > > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event
On Thu, Mar 17, 2022 at 08:40:51AM -0700, Rob Clark wrote: > On Thu, Mar 17, 2022 at 2:29 AM Daniel Vetter wrote: > > > > On Thu, Mar 17, 2022 at 08:03:27AM +0100, Christian König wrote: > > > Am 16.03.22 um 16:36 schrieb Rob Clark: > > > > [SNIP] > > > > just one point of clarification.. in the msm and i915 case it is > > > > purely for debugging and telemetry (ie. sending crash logs back to > > > > distro for analysis if user has crash reporting enabled).. it isn't > > > > used for triggering any action like killing app or compositor. > > > > > > By the way, how does msm it's memory management for the devcoredumps? > > > > GFP_NORECLAIM all the way. It's purely best effort. > > > > Note that the fancy new plan for i915 discrete gpu is to only support gpu > > crash dumps on non-recoverable gpu contexts, i.e. those that do not > > continue to the next batch when something bad happens. This is what vk > > wants and also what iris now uses (we do context recovery in userspace in > > all cases), and non-recoverable contexts greatly simplify the crash dump > > gather: Only thing you need to gather is the register state from hw > > (before you reset it), all the batchbuffer bo and indirect state bo (in > > i915 you can mark which bo to capture in the CS ioctl) can be captured in > > a worker later on. Which for non-recoverable context is no issue, since > > subsequent batchbuffers won't trample over any of these things. > > fwiw, we snapshot everything (cmdstream and bo's marked with dump > flag, in addition to hw state) before resuming the GPU, so there is no > danger of things being trampled. After state is captured and GPU > reset, we "replay" the submits that were written into the ringbuffer > after the faulting submit. GPU crashes should be a thing you don't > need to try to optimize. Not sure why you think we optimize anything here? > (At some point, I'd like to use scheduler for the replay, and actually > use drm_sched_stop()/etc.. but last time I looked there were still > some sched bugs in that area which prevented me from deleting a bunch > of code ;-)) Not sure about your hw, but at least on intel replaying tends to just result in follow-on fun. And that holds even more so the more complex a workload is. This is why vk just dies immediately and does not try to replay anything, offloading it to the app. Same with arb robusteness. Afaik it's really only media and classic gl which insist that the driver stack somehow recover. And recovering from a mess in userspace is a lot simpler than trying to pull of the same magic in the kernel. Plus it also helps with a few of the dma_fence rules, which is a nice bonus. -Daniel > > BR, > -R > > > > > And that way you can record the crashdump (or at least the big pieces like > > all the indirect state stuff) with GFP_KERNEL. > > > > msm probably gets it wrong since embedded drivers have much less shrinker > > and generally no mmu notifiers going on :-) > > > > > I mean it is strictly forbidden to allocate any memory in the GPU reset > > > path. > > > > > > > I would however *strongly* recommend devcoredump support in other GPU > > > > drivers (i915's thing pre-dates devcoredump by a lot).. I've used it > > > > to debug and fix a couple obscure issues that I was not able to > > > > reproduce by myself. > > > > > > Yes, completely agree as well. > > > > +1 > > > > Cheers, Daniel > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v3 1/3] drm: allow real encoder to be passed for drm_writeback_connector
Hi Laurent
Thanks for the review.
On 3/17/2022 1:51 AM, Laurent Pinchart wrote:
Hi Abhinav,
Thank you for the patch.
On Wed, Mar 16, 2022 at 11:48:16AM -0700, Abhinav Kumar wrote:
For some vendor driver implementations, display hardware can
be shared between the encoder used for writeback and the physical
display.
In addition resources such as clocks and interrupts can
also be shared between writeback and the real encoder.
To accommodate such vendor drivers and hardware, allow
real encoder to be passed for drm_writeback_connector using a new
drm_writeback_connector_init_with_encoder() API.
The commit message doesn't match the commit.
Sorry, while splitting the change , I missed this part of the commit
text. Will fix it up.
In addition, to preserve the same call flows for the existing
users of drm_writeback_connector_init(), also allow passing
possible_crtcs as a parameter so that encoder can be initialized
with it.
changes in v3:
- allow passing possible_crtcs for existing users of
drm_writeback_connector_init()
- squash the vendor changes into the same commit so
that each patch in the series can compile individually
Co-developed-by: Kandpal Suraj
Signed-off-by: Abhinav Kumar
---
.../drm/arm/display/komeda/komeda_wb_connector.c | 3 +-
drivers/gpu/drm/arm/malidp_mw.c| 5 +-
drivers/gpu/drm/drm_writeback.c| 103 +
drivers/gpu/drm/rcar-du/rcar_du_writeback.c| 5 +-
drivers/gpu/drm/vc4/vc4_txp.c | 19 ++--
drivers/gpu/drm/vkms/vkms_writeback.c | 3 +-
include/drm/drm_writeback.h| 22 -
7 files changed, 103 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
index e465cc4..40774e6 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
@@ -155,7 +155,6 @@ static int komeda_wb_connector_add(struct komeda_kms_dev
*kms,
kwb_conn->wb_layer = kcrtc->master->wb_layer;
wb_conn = &kwb_conn->base;
- wb_conn->encoder.possible_crtcs = BIT(drm_crtc_index(&kcrtc->base));
formats = komeda_get_layer_fourcc_list(&mdev->fmt_tbl,
kwb_conn->wb_layer->layer_type,
@@ -164,7 +163,7 @@ static int komeda_wb_connector_add(struct komeda_kms_dev
*kms,
err = drm_writeback_connector_init(&kms->base, wb_conn,
&komeda_wb_connector_funcs,
&komeda_wb_encoder_helper_funcs,
- formats, n_formats);
+ formats, n_formats,
BIT(drm_crtc_index(&kcrtc->base)));
komeda_put_fourcc_list(formats);
if (err) {
kfree(kwb_conn);
diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
index f5847a7..b882066 100644
--- a/drivers/gpu/drm/arm/malidp_mw.c
+++ b/drivers/gpu/drm/arm/malidp_mw.c
@@ -208,11 +208,12 @@ int malidp_mw_connector_init(struct drm_device *drm)
struct malidp_drm *malidp = drm->dev_private;
u32 *formats;
int ret, n_formats;
+ uint32_t possible_crtcs;
if (!malidp->dev->hw->enable_memwrite)
return 0;
- malidp->mw_connector.encoder.possible_crtcs = 1 << drm_crtc_index(&malidp->crtc);
+ possible_crtcs = 1 << drm_crtc_index(&malidp->crtc);
drm_connector_helper_add(&malidp->mw_connector.base,
&malidp_mw_connector_helper_funcs);
@@ -223,7 +224,7 @@ int malidp_mw_connector_init(struct drm_device *drm)
ret = drm_writeback_connector_init(drm, &malidp->mw_connector,
&malidp_mw_connector_funcs,
&malidp_mw_encoder_helper_funcs,
- formats, n_formats);
+ formats, n_formats, possible_crtcs);
Do you need the local variable ?
Yes, we can dtop this. I just used this instead of "1 <<
drm_crtc_index(&malidp->crtc)" to simplify it.
No strong preference.
kfree(formats);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
index dccf4504..17c1471 100644
--- a/drivers/gpu/drm/drm_writeback.c
+++ b/drivers/gpu/drm/drm_writeback.c
@@ -149,36 +149,15 @@ static const struct drm_encoder_funcs
drm_writeback_encoder_funcs = {
.destroy = drm_encoder_cleanup,
};
-/**
- * drm_writeback_connector_init - Initialize a writeback connector and its
properties
- * @dev: DRM device
- * @wb_connector: Writeback connector to initialize
- * @con_funcs: Connector funcs vtable
- * @enc_helper_funcs: Encoder helper funcs v
Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event
On Thu, Mar 17, 2022 at 08:34:21AM -0700, Rob Clark wrote: > On Thu, Mar 17, 2022 at 2:29 AM Daniel Vetter wrote: > > > > On Thu, Mar 17, 2022 at 08:03:27AM +0100, Christian König wrote: > > > Am 16.03.22 um 16:36 schrieb Rob Clark: > > > > [SNIP] > > > > just one point of clarification.. in the msm and i915 case it is > > > > purely for debugging and telemetry (ie. sending crash logs back to > > > > distro for analysis if user has crash reporting enabled).. it isn't > > > > used for triggering any action like killing app or compositor. > > > > > > By the way, how does msm it's memory management for the devcoredumps? > > > > GFP_NORECLAIM all the way. It's purely best effort. > > We do one GEM obj allocation in the snapshot path (the hw has a > mechanism to snapshot it's own state into a gpu buffer.. not sure if > nice debugging functionality like that is a commentary on the blob > driver quality, but I'm not complaining) > > I suppose we could pre-allocate this buffer up-front.. but it doesn't > seem like a problem, ie. if allocation fails we just skip snapshotting > stuff that needs the hw crashdumper. I guess since vram is not > involved, perhaps that makes the situation a bit more straightforward. The problem is that you need to allocate with GFP_ATOMIC, instead of GFP_KERNEL, or things go very bad. The scheduler dma-fence annotations I've had (well still have them here) would catch this stuff, but thus far they got nowhere. > > Note that the fancy new plan for i915 discrete gpu is to only support gpu > > crash dumps on non-recoverable gpu contexts, i.e. those that do not > > continue to the next batch when something bad happens. This is what vk > > wants and also what iris now uses (we do context recovery in userspace in > > all cases), and non-recoverable contexts greatly simplify the crash dump > > gather: Only thing you need to gather is the register state from hw > > (before you reset it), all the batchbuffer bo and indirect state bo (in > > i915 you can mark which bo to capture in the CS ioctl) can be captured in > > a worker later on. Which for non-recoverable context is no issue, since > > subsequent batchbuffers won't trample over any of these things. > > > > And that way you can record the crashdump (or at least the big pieces like > > all the indirect state stuff) with GFP_KERNEL. > > > > msm probably gets it wrong since embedded drivers have much less shrinker > > and generally no mmu notifiers going on :-) > > Note that the bo's associated with the batch are still pinned at this > point, from the bo lifecycle the batch is still active. So from the > point of view of shrinker, there should be no interaction. We aren't > doing anything with mmu notifiers (yet), so not entirely sure offhand > the concern there. > > Currently we just use GFP_KERNEL and bail if allocation fails. Yeah you have a simple enough shrinker for this not to be a problem. The issue is that sooner or later things tend to not stay like that, and we're trying to have common rules for dma_fence to make sure everyone follows the same rules. -Daniel > > BR, > -R > > > > I mean it is strictly forbidden to allocate any memory in the GPU reset > > > path. > > > > > > > I would however *strongly* recommend devcoredump support in other GPU > > > > drivers (i915's thing pre-dates devcoredump by a lot).. I've used it > > > > to debug and fix a couple obscure issues that I was not able to > > > > reproduce by myself. > > > > > > Yes, completely agree as well. > > > > +1 > > > > Cheers, Daniel > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH -next] drm/bridge: it6505: Fix build error
Hey, Thanks for submitting this. I think this[1] patch should solve the issue you're seeing too. Can you confirm that[1] fixes your issues? [1] https://lore.kernel.org/all/YjJXnzJmDGsrZAXj@xps13/ Rob.
