Re: [PATCH] drm/amd/display: fix a possible NULL pointer dereference in bios_parser_get_src_obj()
On Mon, Oct 19, 2020 at 8:38 AM estherbdf <603571...@qq.com> wrote:
>
> [Why] the func bios_parser_get_src_obj () is similar to
> bios_parser_get_dst_obj () which is fixed by the
> commit("drm/amd/display: Banch of smatch error and warning
> fixes in DC").
> the symbol 'id' is uninitialized and it is not checked before dereference
> it,may lead to null pointer dereference.
> [How] Initialized variable explicitly with NULL and add sanitizer.
I think the current code is safe as is. get_src_obj_list() will
return 0 if *id_list is NULL and bios_parser_get_src_obj() checks if
number <= index.
Alex
>
> Signed-off-by: estherbdf <603571...@qq.com>
> ---
> drivers/gpu/drm/amd/display/dc/bios/bios_parser.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
> b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
> index 008d4d1..94c6cca 100644
> --- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
> +++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
> @@ -190,7 +190,7 @@ static enum bp_result bios_parser_get_src_obj(struct
> dc_bios *dcb,
> struct graphics_object_id *src_object_id)
> {
> uint32_t number;
> - uint16_t *id;
> + uint16_t *id = NULL;
> ATOM_OBJECT *object;
> struct bios_parser *bp = BP_FROM_DCB(dcb);
>
> @@ -206,7 +206,7 @@ static enum bp_result bios_parser_get_src_obj(struct
> dc_bios *dcb,
>
> number = get_src_obj_list(bp, object, );
>
> - if (number <= index)
> + if (number <= index || !id)
> return BP_RESULT_BADINPUT;
>
> *src_object_id = object_id_from_bios_object_id(id[index]);
> --
> 1.9.1
>
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm: allow drm_atomic_print_state() to accept any drm_printer
Currently drm_atomic_print_state() internally allocates and uses a
drm_info printer. Allow it to accept any drm_printer type so that
the API can be leveraged even for taking drm snapshot.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/drm_atomic.c| 17 -
drivers/gpu/drm/drm_atomic_uapi.c | 4 +++-
drivers/gpu/drm/drm_crtc_internal.h | 4 +++-
3 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 58527f151984..e7079a5f439c 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1,6 +1,7 @@
/*
* Copyright (C) 2014 Red Hat
* Copyright (C) 2014 Intel Corp.
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
@@ -1543,9 +1544,9 @@ int __drm_atomic_helper_set_config(struct drm_mode_set
*set,
}
EXPORT_SYMBOL(__drm_atomic_helper_set_config);
-void drm_atomic_print_state(const struct drm_atomic_state *state)
+void drm_atomic_print_state(const struct drm_atomic_state *state,
+ struct drm_printer *p)
{
- struct drm_printer p = drm_info_printer(state->dev->dev);
struct drm_plane *plane;
struct drm_plane_state *plane_state;
struct drm_crtc *crtc;
@@ -1554,17 +1555,23 @@ void drm_atomic_print_state(const struct
drm_atomic_state *state)
struct drm_connector_state *connector_state;
int i;
+ if (!p) {
+ DRM_ERROR("invalid drm printer\n");
+ return;
+ }
+
DRM_DEBUG_ATOMIC("checking %p\n", state);
for_each_new_plane_in_state(state, plane, plane_state, i)
- drm_atomic_plane_print_state(, plane_state);
+ drm_atomic_plane_print_state(p, plane_state);
for_each_new_crtc_in_state(state, crtc, crtc_state, i)
- drm_atomic_crtc_print_state(, crtc_state);
+ drm_atomic_crtc_print_state(p, crtc_state);
for_each_new_connector_in_state(state, connector, connector_state, i)
- drm_atomic_connector_print_state(, connector_state);
+ drm_atomic_connector_print_state(p, connector_state);
}
+EXPORT_SYMBOL(drm_atomic_print_state);
static void __drm_state_dump(struct drm_device *dev, struct drm_printer *p,
bool take_locks)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 25c269bc4681..d9ae86c92608 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -2,6 +2,7 @@
* Copyright (C) 2014 Red Hat
* Copyright (C) 2014 Intel Corp.
* Copyright (C) 2018 Intel Corp.
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
@@ -1294,6 +1295,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
struct drm_out_fence_state *fence_state;
int ret = 0;
unsigned int i, j, num_fences;
+ struct drm_printer p = drm_info_printer(dev->dev);
/* disallow for drivers not supporting atomic: */
if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
@@ -1413,7 +1415,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
ret = drm_atomic_nonblocking_commit(state);
} else {
if (drm_debug_enabled(DRM_UT_STATE))
- drm_atomic_print_state(state);
+ drm_atomic_print_state(state, );
ret = drm_atomic_commit(state);
}
diff --git a/drivers/gpu/drm/drm_crtc_internal.h
b/drivers/gpu/drm/drm_crtc_internal.h
index da96b2f64d7e..d34215366936 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -5,6 +5,7 @@
* Jesse Barnes
* Copyright © 2014 Intel Corporation
* Daniel Vetter
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
@@ -233,7 +234,8 @@ int __drm_atomic_helper_disable_plane(struct drm_plane
*plane,
int __drm_atomic_helper_set_config(struct drm_mode_set *set,
struct drm_atomic_state *state);
-void drm_atomic_print_state(const struct drm_atomic_state *state);
+void drm_atomic_print_state(const struct drm_atomic_state *state,
+ struct drm_printer *p);
/* drm_atomic_uapi.c */
int drm_atomic_connector_commit_dpms(struct drm_atomic_state *state,
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
[PATCH 2/4] disp/msm/dpu: add support to dump dpu registers
Add the dpu_dbg module which adds supports to dump dpu registers
which can be used in case of error conditions.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/Makefile | 2 +
drivers/gpu/drm/msm/disp/dpu1/dpu_dbg.c | 316 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_dbg.h | 273 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_dbg_util.c | 313 +
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 4 +-
drivers/gpu/drm/msm/msm_drv.c | 6 +-
6 files changed, 912 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_dbg.c
create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_dbg.h
create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_dbg_util.c
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 340682cd0f32..96bd1398edac 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -54,6 +54,8 @@ msm-y := \
disp/dpu1/dpu_core_irq.o \
disp/dpu1/dpu_core_perf.o \
disp/dpu1/dpu_crtc.o \
+ disp/dpu1/dpu_dbg.o \
+ disp/dpu1/dpu_dbg_util.o \
disp/dpu1/dpu_encoder.o \
disp/dpu1/dpu_encoder_phys_cmd.o \
disp/dpu1/dpu_encoder_phys_vid.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_dbg.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_dbg.c
new file mode 100644
index ..6703e1555194
--- /dev/null
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_dbg.c
@@ -0,0 +1,316 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2009-2020, The Linux Foundation. All rights reserved.
+ */
+
+#define pr_fmt(fmt)"[drm:%s:%d] " fmt, __func__, __LINE__
+
+#include "dpu_dbg.h"
+#include "dpu_hw_catalog.h"
+
+/* global dpu debug base structure */
+static struct dpu_dbg_base dpu_dbg;
+
+
+#ifdef CONFIG_DEV_COREDUMP
+static ssize_t dpu_devcoredump_read(char *buffer, loff_t offset,
+ size_t count, void *data, size_t datalen)
+{
+ struct drm_print_iterator iter;
+ struct drm_printer p;
+
+ iter.data = buffer;
+ iter.offset = 0;
+ iter.start = offset;
+ iter.remain = count;
+
+ p = drm_coredump_printer();
+
+ drm_printf(, "---\n");
+
+ drm_printf(, "module: " KBUILD_MODNAME "\n");
+ drm_printf(, "dpu devcoredump\n");
+ drm_printf(, "timestamp %lld\n", ktime_to_ns(dpu_dbg.timestamp));
+
+ dpu_dbg.dpu_dbg_printer =
+ dpu_dbg.enable_reg_dump = DPU_DBG_DUMP_IN_COREDUMP;
+
+ drm_printf(, "===dpu regs\n");
+
+ _dpu_dump_array(_dbg, dpu_dbg.req_dump_blks,
+ ARRAY_SIZE(dpu_dbg.req_dump_blks),
+ dpu_dbg.work_panic, "evtlog_workitem",
+ dpu_dbg.dump_all);
+
+ drm_printf(, "===dpu drm state\n");
+
+ if (dpu_dbg.atomic_state)
+ drm_atomic_print_state(dpu_dbg.atomic_state,
+ );
+
+ return count - iter.remain;
+}
+
+static void dpu_devcoredump_free(void *data)
+{
+ if (dpu_dbg.atomic_state) {
+ drm_atomic_state_put(dpu_dbg.atomic_state);
+ dpu_dbg.atomic_state = NULL;
+ }
+ dpu_dbg.coredump_pending = false;
+}
+
+static void dpu_devcoredump_capture_state(void)
+{
+ struct drm_device *ddev;
+ struct drm_modeset_acquire_ctx ctx;
+
+ dpu_dbg.timestamp = ktime_get();
+
+ ddev = dpu_dbg.drm_dev;
+
+ drm_modeset_acquire_init(, 0);
+
+ while (drm_modeset_lock_all_ctx(ddev, ) != 0)
+ drm_modeset_backoff();
+
+ dpu_dbg.atomic_state = drm_atomic_helper_duplicate_state(ddev,
+ );
+ drm_modeset_drop_locks();
+ drm_modeset_acquire_fini();
+}
+#else
+static void dpu_devcoredump_capture_state(void)
+{
+}
+#endif /* CONFIG_DEV_COREDUMP */
+
+/**
+ * _dpu_dump_work - deferred dump work function
+ * @work: work structure
+ */
+static void _dpu_dump_work(struct kthread_work *work)
+{
+ /* reset the enable_reg_dump to default before every dump */
+ dpu_dbg.enable_reg_dump = DEFAULT_REGDUMP;
+
+ _dpu_dump_array(_dbg, dpu_dbg.req_dump_blks,
+ ARRAY_SIZE(dpu_dbg.req_dump_blks),
+ dpu_dbg.work_panic, "evtlog_workitem",
+ dpu_dbg.dump_all);
+
+ dpu_devcoredump_capture_state();
+
+#ifdef CONFIG_DEV_COREDUMP
+ if (dpu_dbg.enable_reg_dump & DPU_DBG_DUMP_IN_MEM) {
+ dev_coredumpm(dpu_dbg.dev, THIS_MODULE, _dbg, 0, GFP_KERNEL,
+ dpu_devcoredump_read, dpu_devcoredump_free);
+ dpu_dbg.coredump_pending = true;
+ }
+#endif
+}
+
+void dpu_dbg_dump(enum dpu_dbg_dump_context dump_mode, const char *name, ...)
+{
+ int i, index = 0;
+ bool do_panic = false;
+ bool dump_all = false;
+ va_list args;
+ char *blk_name = NULL;
+ struct dpu_dbg_reg_base *blk_base = NULL;
+ struct dpu_dbg_reg_base
[PATCH 3/4] drm/msm: register the base address with dpu_dbg module
Register the base address of various dpu sub-modules with the
dpu_dbg module so that it can be dumped out during error scenarios.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_dbg.c | 4 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c| 6 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c | 7 +++--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 5 +++-
.../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 6 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 8 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c| 7 -
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 12 +++--
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 4 ++-
drivers/gpu/drm/msm/dp/dp_catalog.c | 12 +
drivers/gpu/drm/msm/dp/dp_catalog.h | 4 +++
drivers/gpu/drm/msm/dp/dp_display.c | 2 ++
drivers/gpu/drm/msm/dsi/dsi_host.c| 10 ++-
drivers/gpu/drm/msm/msm_drv.c | 26 ++-
drivers/gpu/drm/msm/msm_drv.h | 3 ++-
15 files changed, 101 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_dbg.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_dbg.c
index 6703e1555194..62f49e60a4ca 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_dbg.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_dbg.c
@@ -263,7 +263,7 @@ int dpu_dbg_reg_register_base(const char *name, void
__iomem *base,
/* Initialize list to make sure check for null list will be valid */
INIT_LIST_HEAD(_base->sub_range_list);
- pr_debug("%s base: %pK max_offset 0x%zX\n", reg_base->name,
+ pr_info("%s base: %pK max_offset 0x%zX\n", reg_base->name,
reg_base->base, reg_base->max_offset);
list_add(_base->reg_base_head, _base->reg_base_list);
@@ -310,7 +310,7 @@ void dpu_dbg_reg_register_dump_range(const char *base_name,
range->xin_id = xin_id;
list_add_tail(>head, _base->sub_range_list);
- pr_debug("base %s, range %s, start 0x%X, end 0x%X\n",
+ pr_info("base_name %s, range_name %s, start 0x%X, end 0x%X\n",
base_name, range->range_name,
range->offset.start, range->offset.end);
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index 758c355b4fd8..3a827ea96723 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -1,5 +1,5 @@
// SPDX-License-Identifier: GPL-2.0-only
-/* Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
+/* Copyright (c) 2015-2018, 2020 The Linux Foundation. All rights reserved.
*/
#include
@@ -7,6 +7,7 @@
#include "dpu_hw_ctl.h"
#include "dpu_kms.h"
#include "dpu_trace.h"
+#include "dpu_dbg.h"
#define CTL_LAYER(lm) \
(((lm) == LM_5) ? (0x024) : (((lm) - LM_0) * 0x004))
@@ -588,6 +589,9 @@ struct dpu_hw_ctl *dpu_hw_ctl_init(enum dpu_ctl idx,
dpu_hw_blk_init(>base, DPU_HW_BLK_CTL, idx, _hw_ops);
+ dpu_dbg_reg_register_dump_range(DPU_DBG_NAME, cfg->name, c->hw.blk_off,
+ c->hw.blk_off + c->hw.length, c->hw.xin_id);
+
return c;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
index a7a24539921f..ee9ae02f5e7f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
@@ -1,5 +1,5 @@
// SPDX-License-Identifier: GPL-2.0-only
-/* Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
+/* Copyright (c) 2015-2018, 2020 The Linux Foundation. All rights reserved.
*/
#include "dpu_hwio.h"
@@ -7,7 +7,7 @@
#include "dpu_hw_lm.h"
#include "dpu_hw_dspp.h"
#include "dpu_kms.h"
-
+#include "dpu_dbg.h"
/* DSPP_PCC */
#define PCC_EN BIT(0)
@@ -115,6 +115,9 @@ struct dpu_hw_dspp *dpu_hw_dspp_init(enum dpu_dspp idx,
dpu_hw_blk_init(>base, DPU_HW_BLK_DSPP, idx, _hw_ops);
+ dpu_dbg_reg_register_dump_range(DPU_DBG_NAME, cfg->name, c->hw.blk_off,
+ c->hw.blk_off + c->hw.length, c->hw.xin_id);
+
return c;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index 6f0f54588124..d8198d4d42bc 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -1,11 +1,12 @@
// SPDX-License-Identifier: GPL-2.0-only
-/* Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
+/* Copyright (c) 2015-2020, The Linux Foundation. All rights reserved.
*/
#include "dpu_hwio.h"
#include "dpu_hw_catalog.h"
#include "dpu_hw_intf.h"
#include "dpu_kms.h"
+#include "dpu_dbg.h"
#define INTF_TIMING_ENGINE_EN 0x000
#define INTF_CONFIG 0x004
@@ -319,6 +320,8 @@ struct dpu_hw_intf *dpu_hw_intf_init(enum dpu_intf idx,
dpu_hw_blk_init(>base, DPU_HW_BLK_INTF, idx, _hw_ops);
+
[PATCH 0/4] Add devcoredump support for DPU
This series adds support to use devcoredump for DPU driver. It introduces the dpu_dbg module which assists in the capturing of register dumps during error scenarios. When a display related error happens, the dpu_dbg module captures all the relevant register dumps along with the snapshot of the drm atomic state and triggers a devcoredump. Abhinav Kumar (4): drm: allow drm_atomic_print_state() to accept any drm_printer disp/msm/dpu: add support to dump dpu registers drm/msm: register the base address with dpu_dbg module drm/msm/dpu: add dpu_dbg points across dpu driver drivers/gpu/drm/drm_atomic.c | 17 +- drivers/gpu/drm/drm_atomic_uapi.c | 4 +- drivers/gpu/drm/drm_crtc_internal.h | 4 +- drivers/gpu/drm/msm/Makefile | 2 + drivers/gpu/drm/msm/disp/dpu1/dpu_dbg.c | 316 ++ drivers/gpu/drm/msm/disp/dpu1/dpu_dbg.h | 273 +++ drivers/gpu/drm/msm/disp/dpu1/dpu_dbg_util.c | 313 + drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 12 +- .../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 5 +- .../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 5 +- .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 4 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c| 6 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c | 7 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 5 +- .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 6 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 8 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c| 7 +- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 12 +- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 4 +- drivers/gpu/drm/msm/dp/dp_catalog.c | 12 + drivers/gpu/drm/msm/dp/dp_catalog.h | 4 + drivers/gpu/drm/msm/dp/dp_display.c | 2 + drivers/gpu/drm/msm/dsi/dsi_host.c| 10 +- drivers/gpu/drm/msm/msm_drv.c | 30 +- drivers/gpu/drm/msm/msm_drv.h | 3 +- 25 files changed, 1045 insertions(+), 26 deletions(-) create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_dbg.c create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_dbg.h create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_dbg_util.c -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/msm/dpu: add dpu_dbg points across dpu driver
Add dpu_dbg points across dpu driver to trigger dumps when critical
errors are hit.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 12 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 5 +++--
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 5 -
3 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index f7f5c258b553..a2ee1af73c9f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
- * Copyright (c) 2014-2018, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2014-2018, 2020 The Linux Foundation. All rights reserved.
* Copyright (C) 2013 Red Hat
* Author: Rob Clark
*/
@@ -26,6 +26,7 @@
#include "dpu_crtc.h"
#include "dpu_trace.h"
#include "dpu_core_irq.h"
+#include "dpu_dbg.h"
#define DPU_DEBUG_ENC(e, fmt, ...) DPU_DEBUG("enc%d " fmt,\
(e) ? (e)->base.base.id : -1, ##__VA_ARGS__)
@@ -1313,6 +1314,11 @@ static void dpu_encoder_underrun_callback(struct
drm_encoder *drm_enc,
DPU_ATRACE_BEGIN("encoder_underrun_callback");
atomic_inc(_enc->underrun_cnt);
+
+ /* trigger dump only on the first underrun */
+ if (atomic_read(_enc->underrun_cnt) == 1)
+ DPU_DBG_DUMP("all");
+
trace_dpu_enc_underrun_cb(DRMID(drm_enc),
atomic_read(_enc->underrun_cnt));
DPU_ATRACE_END("encoder_underrun_callback");
@@ -1553,8 +1559,10 @@ static void dpu_encoder_helper_hw_reset(struct
dpu_encoder_phys *phys_enc)
ctl->idx);
rc = ctl->ops.reset(ctl);
- if (rc)
+ if (rc) {
DPU_ERROR_ENC(dpu_enc, "ctl %d reset failure\n", ctl->idx);
+ DPU_DBG_DUMP("all");
+ }
phys_enc->enable_state = DPU_ENC_ENABLED;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index 8493d68ad841..58f79557b560 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
- * Copyright (c) 2015-2018 The Linux Foundation. All rights reserved.
+ * Copyright (c) 2015-2018, 2020 The Linux Foundation. All rights reserved.
*/
#define pr_fmt(fmt)"[drm:%s:%d] " fmt, __func__, __LINE__
@@ -9,6 +9,7 @@
#include "dpu_core_irq.h"
#include "dpu_formats.h"
#include "dpu_trace.h"
+#include "dpu_dbg.h"
#define DPU_DEBUG_CMDENC(e, fmt, ...) DPU_DEBUG("enc%d intf%d " fmt, \
(e) && (e)->base.parent ? \
@@ -213,7 +214,7 @@ static int _dpu_encoder_phys_cmd_handle_ppdone_timeout(
phys_enc->hw_ctl->idx - CTL_0,
cmd_enc->pp_timeout_report_cnt,
atomic_read(_enc->pending_kickoff_cnt));
-
+ DPU_DBG_DUMP("all");
dpu_encoder_helper_unregister_irq(phys_enc, INTR_IDX_RDPTR);
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index 805e059b50b7..46c5320150fa 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -1,5 +1,5 @@
// SPDX-License-Identifier: GPL-2.0-only
-/* Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
+/* Copyright (c) 2015-2018, 2020 The Linux Foundation. All rights reserved.
*/
#define pr_fmt(fmt)"[drm:%s:%d] " fmt, __func__, __LINE__
@@ -8,6 +8,7 @@
#include "dpu_core_irq.h"
#include "dpu_formats.h"
#include "dpu_trace.h"
+#include "dpu_dbg.h"
#define DPU_DEBUG_VIDENC(e, fmt, ...) DPU_DEBUG("enc%d intf%d " fmt, \
(e) && (e)->parent ? \
@@ -467,6 +468,7 @@ static void dpu_encoder_phys_vid_enable(struct
dpu_encoder_phys *phys_enc)
"update pending flush ctl %d flush_mask 0%x intf_mask 0x%x\n",
ctl->idx - CTL_0, flush_mask, intf_flush_mask);
+ atomic_set(_enc->underrun_cnt, 0);
/* ctl_flush & timing engine enable will be triggered by framework */
if (phys_enc->enable_state == DPU_ENC_DISABLED)
@@ -549,6 +551,7 @@ static void dpu_encoder_phys_vid_prepare_for_kickoff(
if (rc) {
DPU_ERROR_VIDENC(phys_enc, "ctl %d reset failure: %d\n",
ctl->idx, rc);
+ DPU_DBG_DUMP("all");
dpu_encoder_helper_unregister_irq(phys_enc, INTR_IDX_VSYNC);
}
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
Re: [PATCH v2 0/3] drm/panel: mantix panel reset fixes
Hi Guido.
On Tue, Oct 20, 2020 at 01:57:11PM +0200, Guido Günther wrote:
> Hi Daniel, Sam,
> On Mon, Oct 19, 2020 at 05:44:37PM +0200, Daniel Vetter wrote:
> > On Sat, Oct 17, 2020 at 12:47:36PM +0200, Sam Ravnborg wrote:
> > > Hi Guido.
> > >
> > > On Sat, Oct 17, 2020 at 11:13:07AM +0200, Guido Günther wrote:
> > > > Hi Sam,
> > > > On Fri, Oct 16, 2020 at 04:29:16PM +0200, Sam Ravnborg wrote:
> > > > > Hi Guido.
> > > > > On Tue, Oct 13, 2020 at 12:32:45PM +0200, Guido Günther wrote:
> > > > [..snip..]
> > > > > >
> > > > > > Changes from v1:
> > > > > > - As per review comments by Fabio Estevam
> > > > > >
> > > > > > https://lore.kernel.org/dri-devel/CAOMZO5B5ECcConvKej=rcaf8wvoxgq7nuzkj-ad0asaozuq...@mail.gmail.com/
> > > > > >- Fix typo in commit messages
> > > > > > - As per review comments by Rob Herring
> > > > > >https://lore.kernel.org/dri-devel/20200929174624.GA832332@bogus/
> > > > > >- Don't use an array of reset lines
> > > > > >
> > > > > > Guido Günther (3):
> > > > > > drm/panel: mantix: Don't dereference NULL mode
> > > > > > drm/panel: mantix: Fix panel reset
> > > > > > dt-binding: display: Require two resets on mantix panel
> > > > >
> > > > > All applied to drm-misc-next and pushed out.
> > > > > And then I remembered you had commit right - sigh.
> > > >
> > > > Thanks! Is there any special care needed to get that into 5.10? The
> > > > driver landed there in 72967d5616d3f0c714f8eb6c4e258179a9031c45.
> > >
> > > As the patches was applied to drm-misc-next the easiet path would
> > > be to cherry-pick them and apply to drm-misc-fixes.
> > > dim has cherry-pick support - try to use it rahter than doing it by
> > > hand.
> >
> > drm-misc-next-fixes while we're between freeze and merge window end:
> >
> > https://drm.pages.freedesktop.org/maintainer-tools/committer-drm-misc.html#where-do-i-apply-my-patch
>
> Great. Thanks for the pointer, that works. Now i get:
>
> $ ../maintainer-tools/dim push --dry-run
> dim: 3532f0117258 ("dt-binding: display: Require two resets on mantix
> panel"): mandatory review missing.
> dim: c90f95ad6d05 ("drm/panel: mantix: Fix panel reset"): mandatory review
> missing.
> dim: 8b557f793e69 ("drm/panel: mantix: Don't dereference NULL mode"):
> mandatory review missing.
> dim: ERROR: issues in commits detected, aborting
>
> and in fact there's only Signed-off-by's on it:
>
> Fixes: 72967d5616d3 ("drm/panel: Add panel driver for the Mantix
> MLAF057WE51-X DSI panel")
> Signed-off-by: Guido Günther
> Signed-off-by: Sam Ravnborg
> Link:
> https://patchwork.freedesktop.org/patch/msgid/ba71a8ab010d263a8058dd4f711e3bcd95877bf2.1602584953.git@sigxcpu.org
>
> Sam, I assume your Signed-off-by's should have been Reviewed-by ?
> O.k. to fix that up in the commit message before pushing to
> drm-misc-next?
Fine to add my r-b.
For patches I push I always read the patch - but seldom claim that I
review them. It seems a bit implicit I think - but maybe this is just
bad practice on my side.
Then I also avoid the endless discussion with myself it what I did
warrant an a-b or r-b.
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu: remove unneeded break
Applied. Thanks!
Alex
On Mon, Oct 19, 2020 at 11:08 AM Harry Wentland wrote:
>
> On 2020-10-19 10:55 a.m., Christian König wrote:
> > Am 19.10.20 um 16:43 schrieb t...@redhat.com:
> >> From: Tom Rix
> >>
> >> A break is not needed if it is preceded by a return or break
> >>
> >> Signed-off-by: Tom Rix
> >
> > Acked-by: Christian König
>
> Reviewed-by: Harry Wentland
>
> Harry
>
> >
> >> ---
> >> drivers/gpu/drm/amd/display/dc/dce/dce_transform.c | 1 -
> >> drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c | 7 ---
> >> drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c | 7 ---
> >> drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c | 7 ---
> >> drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c | 7 ---
> >> drivers/gpu/drm/amd/display/dc/dce60/dce60_resource.c | 7 ---
> >> drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c | 7 ---
> >> 7 files changed, 43 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c
> >> b/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c
> >> index 2a32b66959ba..130a0a0c8332 100644
> >> --- a/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c
> >> +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c
> >> @@ -1330,7 +1330,6 @@ static bool configure_graphics_mode(
> >> REG_SET(OUTPUT_CSC_CONTROL, 0,
> >> OUTPUT_CSC_GRPH_MODE, 0);
> >> break;
> >> -break;
> >> case COLOR_SPACE_SRGB_LIMITED:
> >> /* TV RGB */
> >> REG_SET(OUTPUT_CSC_CONTROL, 0,
> >> diff --git a/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c
> >> b/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c
> >> index d741787f75dc..42c7d157da32 100644
> >> --- a/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c
> >> +++ b/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c
> >> @@ -418,25 +418,18 @@ static int map_transmitter_id_to_phy_instance(
> >> switch (transmitter) {
> >> case TRANSMITTER_UNIPHY_A:
> >> return 0;
> >> -break;
> >> case TRANSMITTER_UNIPHY_B:
> >> return 1;
> >> -break;
> >> case TRANSMITTER_UNIPHY_C:
> >> return 2;
> >> -break;
> >> case TRANSMITTER_UNIPHY_D:
> >> return 3;
> >> -break;
> >> case TRANSMITTER_UNIPHY_E:
> >> return 4;
> >> -break;
> >> case TRANSMITTER_UNIPHY_F:
> >> return 5;
> >> -break;
> >> case TRANSMITTER_UNIPHY_G:
> >> return 6;
> >> -break;
> >> default:
> >> ASSERT(0);
> >> return 0;
> >> diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
> >> b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
> >> index 2bbfa2e176a9..382581c4a674 100644
> >> --- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
> >> +++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
> >> @@ -471,25 +471,18 @@ static int map_transmitter_id_to_phy_instance(
> >> switch (transmitter) {
> >> case TRANSMITTER_UNIPHY_A:
> >> return 0;
> >> -break;
> >> case TRANSMITTER_UNIPHY_B:
> >> return 1;
> >> -break;
> >> case TRANSMITTER_UNIPHY_C:
> >> return 2;
> >> -break;
> >> case TRANSMITTER_UNIPHY_D:
> >> return 3;
> >> -break;
> >> case TRANSMITTER_UNIPHY_E:
> >> return 4;
> >> -break;
> >> case TRANSMITTER_UNIPHY_F:
> >> return 5;
> >> -break;
> >> case TRANSMITTER_UNIPHY_G:
> >> return 6;
> >> -break;
> >> default:
> >> ASSERT(0);
> >> return 0;
> >> diff --git a/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
> >> b/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
> >> index b622b4b1dac3..7b4b2304bbff 100644
> >> --- a/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
> >> +++ b/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
> >> @@ -446,25 +446,18 @@ static int map_transmitter_id_to_phy_instance(
> >> switch (transmitter) {
> >> case TRANSMITTER_UNIPHY_A:
> >> return 0;
> >> -break;
> >> case TRANSMITTER_UNIPHY_B:
> >> return 1;
> >> -break;
> >> case TRANSMITTER_UNIPHY_C:
> >> return 2;
> >> -break;
> >> case TRANSMITTER_UNIPHY_D:
> >> return 3;
> >> -break;
> >> case TRANSMITTER_UNIPHY_E:
> >> return 4;
> >> -break;
> >> case TRANSMITTER_UNIPHY_F:
> >> return 5;
> >> -break;
> >> case TRANSMITTER_UNIPHY_G:
> >> return 6;
> >> -break;
> >> default:
> >> ASSERT(0);
> >> return 0;
> >> diff --git a/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
> >> b/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
> >> index 16fe7344702f..3d782b7c86cb 100644
> >> ---
[pull] amdgpu, amdkfd drm-fixes-5.10
Hi Dave, Daniel, Fixes for 5.10. The following changes since commit 40b99050455b9a6cb8faf15dcd41888312184720: Merge tag 'drm-intel-next-fixes-2020-10-15' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2020-10-19 09:21:59 +1000) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux tags/amd-drm-fixes-5.10-2020-10-21 for you to fetch changes up to 687e79c0feb4243b141b1e9a20adba3c0ec66f7f: drm/amdgpu: correct the cu and rb info for sienna cichlid (2020-10-21 23:06:23 -0400) amd-drm-fixes-5.10-2020-10-21: amdgpu: - Sienna Cichlid fixes - MST manager resource leak fix - GPU reset fix amdkfd: - Luxmark fix for Navi1x Andrey Grodzovsky (3): drm/amd/display: Revert "drm/amd/display: Fix a list corruption" drm/amd/display: Avoid MST manager resource leak. drm/amd/psp: Fix sysfs: cannot create duplicate filename Evan Quan (1): drm/amdgpu: correct the gpu reset handling for job != NULL case Jay Cornwall (1): drm/amdkfd: Use same SQ prefetch setting as amdgpu John Clements (1): Revert drm/amdgpu: disable sienna chichlid UMC RAS Kenneth Feng (2): drm/amd/pm: fix pp_dpm_fclk drm/amd/pm: remove the average clock value in sysfs Kevin Wang (2): drm/amd/swsmu: add missing feature map for sienna_cichlid drm/amd/swsmu: correct wrong feature bit mapping Likun Gao (5): drm/amdgpu: add function to program pbb mode for sienna cichlid drm/amdgpu: add rlc iram and dram firmware support drm/amdgpu: update golden setting for sienna_cichlid drm/amd/pm: fix pcie information for sienna cichlid drm/amdgpu: correct the cu and rb info for sienna cichlid drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c| 9 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c| 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.h| 4 + drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 10 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h | 11 ++ drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 111 +++-- drivers/gpu/drm/amd/amdgpu/psp_gfx_if.h| 4 +- .../drm/amd/amdkfd/kfd_device_queue_manager_v10.c | 5 +- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8 +- drivers/gpu/drm/amd/pm/inc/smu_types.h | 1 + .../drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c| 22 ++-- drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c | 27 +++-- 13 files changed, 187 insertions(+), 31 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/ttm: remove overlapping memcpy support
From: Dave Airlie
remove the overlapping memcp support as it's never used.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 19 +++
1 file changed, 3 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 0a5694ef1e07..ecb54415d1ca 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -180,9 +180,6 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
void *new_iomap;
int ret;
unsigned long i;
- unsigned long page;
- unsigned long add = 0;
- int dir;
ret = ttm_bo_wait_ctx(bo, ctx);
if (ret)
@@ -220,27 +217,17 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
goto out1;
}
- add = 0;
- dir = 1;
-
- if ((old_mem->mem_type == new_mem->mem_type) &&
- (new_mem->start < old_mem->start + old_mem->size)) {
- dir = -1;
- add = new_mem->num_pages - 1;
- }
-
for (i = 0; i < new_mem->num_pages; ++i) {
- page = i * dir + add;
if (old_iomap == NULL) {
pgprot_t prot = ttm_io_prot(bo, old_mem, PAGE_KERNEL);
- ret = ttm_copy_ttm_io_page(ttm, new_iomap, page,
+ ret = ttm_copy_ttm_io_page(ttm, new_iomap, i,
prot);
} else if (new_iomap == NULL) {
pgprot_t prot = ttm_io_prot(bo, new_mem, PAGE_KERNEL);
- ret = ttm_copy_io_ttm_page(ttm, old_iomap, page,
+ ret = ttm_copy_io_ttm_page(ttm, old_iomap, i,
prot);
} else {
- ret = ttm_copy_io_page(new_iomap, old_iomap, page);
+ ret = ttm_copy_io_page(new_iomap, old_iomap, i);
}
if (ret)
goto out1;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 7/8] drm/mediatek: add DDP support for MT8167
Hi, Fabien:
Fabien Parent 於 2020年10月21日 週三 上午1:43寫道：
>
> Add DDP support for MT8167 SoC.
>
> Signed-off-by: Fabien Parent
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 50 ++
> 1 file changed, 50 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 014c1bbe1df2..bb62fdcf3d71 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -25,6 +25,19 @@
>
> #define INT_MUTEX BIT(1)
>
> +#define MT8167_MUTEX_MOD_DISP_PWM 1
> +#define MT8167_MUTEX_MOD_DISP_OVL0 6
> +#define MT8167_MUTEX_MOD_DISP_OVL1 7
> +#define MT8167_MUTEX_MOD_DISP_RDMA08
> +#define MT8167_MUTEX_MOD_DISP_RDMA19
> +#define MT8167_MUTEX_MOD_DISP_WDMA010
> +#define MT8167_MUTEX_MOD_DISP_CCORR11
> +#define MT8167_MUTEX_MOD_DISP_COLOR12
> +#define MT8167_MUTEX_MOD_DISP_AAL 13
> +#define MT8167_MUTEX_MOD_DISP_GAMMA14
> +#define MT8167_MUTEX_MOD_DISP_DITHER 15
> +#define MT8167_MUTEX_MOD_DISP_UFOE 16
> +
> #define MT8173_MUTEX_MOD_DISP_OVL0 11
> #define MT8173_MUTEX_MOD_DISP_OVL1 12
> #define MT8173_MUTEX_MOD_DISP_RDMA013
> @@ -73,6 +86,8 @@
> #define MUTEX_SOF_DPI1 4
> #define MUTEX_SOF_DSI2 5
> #define MUTEX_SOF_DSI3 6
> +#define MT8167_MUTEX_SOF_DPI0 2
> +#define MT8167_MUTEX_SOF_DPI1 3
>
>
> struct mtk_disp_mutex {
> @@ -135,6 +150,21 @@ static const unsigned int
> mt2712_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_WDMA1] = MT2712_MUTEX_MOD_DISP_WDMA1,
> };
>
> +static const unsigned int mt8167_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> + [DDP_COMPONENT_AAL0] = MT8167_MUTEX_MOD_DISP_AAL,
> + [DDP_COMPONENT_CCORR] = MT8167_MUTEX_MOD_DISP_CCORR,
> + [DDP_COMPONENT_COLOR0] = MT8167_MUTEX_MOD_DISP_COLOR,
> + [DDP_COMPONENT_DITHER] = MT8167_MUTEX_MOD_DISP_DITHER,
> + [DDP_COMPONENT_GAMMA] = MT8167_MUTEX_MOD_DISP_GAMMA,
> + [DDP_COMPONENT_OVL0] = MT8167_MUTEX_MOD_DISP_OVL0,
> + [DDP_COMPONENT_OVL1] = MT8167_MUTEX_MOD_DISP_OVL1,
> + [DDP_COMPONENT_PWM0] = MT8167_MUTEX_MOD_DISP_PWM,
> + [DDP_COMPONENT_RDMA0] = MT8167_MUTEX_MOD_DISP_RDMA0,
> + [DDP_COMPONENT_RDMA1] = MT8167_MUTEX_MOD_DISP_RDMA1,
> + [DDP_COMPONENT_UFOE] = MT8167_MUTEX_MOD_DISP_UFOE,
> + [DDP_COMPONENT_WDMA0] = MT8167_MUTEX_MOD_DISP_WDMA0,
> +};
> +
> static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_AAL0] = MT8173_MUTEX_MOD_DISP_AAL,
> [DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
> @@ -163,6 +193,16 @@ static const unsigned int
> mt2712_mutex_sof[DDP_MUTEX_SOF_DSI3 + 1] = {
> [DDP_MUTEX_SOF_DSI3] = MUTEX_SOF_DSI3,
> };
>
> +static const unsigned int mt8167_mutex_sof[DDP_MUTEX_SOF_DSI3 + 1] = {
> + [DDP_MUTEX_SOF_SINGLE_MODE] = MUTEX_SOF_SINGLE_MODE,
> + [DDP_MUTEX_SOF_DSI0] = MUTEX_SOF_DSI0,
> + [DDP_MUTEX_SOF_DSI1] = MUTEX_SOF_DSI1,
MUTEX_SOF_DSI1 = MT8167_MUTEX_SOF_DPI0 = 2, this is conflict. If
MT8167 has no dsi1, just drop setting for dsi1. Ditto for other
non-exist sof.
Regards,
Chun-Kuang.
> + [DDP_MUTEX_SOF_DPI0] = MT8167_MUTEX_SOF_DPI0,
> + [DDP_MUTEX_SOF_DPI1] = MT8167_MUTEX_SOF_DPI1,
> + [DDP_MUTEX_SOF_DSI2] = MUTEX_SOF_DSI2,
> + [DDP_MUTEX_SOF_DSI3] = MUTEX_SOF_DSI3,
> +};
> +
> static const struct mtk_ddp_data mt2701_ddp_driver_data = {
> .mutex_mod = mt2701_mutex_mod,
> .mutex_sof = mt2712_mutex_sof,
> @@ -177,6 +217,14 @@ static const struct mtk_ddp_data mt2712_ddp_driver_data
> = {
> .mutex_sof_reg = MT2701_DISP_MUTEX0_SOF0,
> };
>
> +static const struct mtk_ddp_data mt8167_ddp_driver_data = {
> + .mutex_mod = mt8167_mutex_mod,
> + .mutex_sof = mt8167_mutex_sof,
> + .mutex_mod_reg = MT2701_DISP_MUTEX0_MOD0,
> + .mutex_sof_reg = MT2701_DISP_MUTEX0_SOF0,
> + .no_clk = true,
> +};
> +
> static const struct mtk_ddp_data mt8173_ddp_driver_data = {
> .mutex_mod = mt8173_mutex_mod,
> .mutex_sof = mt2712_mutex_sof,
> @@ -400,6 +448,8 @@ static const struct of_device_id ddp_driver_dt_match[] = {
> .data = _ddp_driver_data},
> { .compatible = "mediatek,mt2712-disp-mutex",
> .data = _ddp_driver_data},
> + { .compatible = "mediatek,mt8167-disp-mutex",
> + .data = _ddp_driver_data},
> { .compatible = "mediatek,mt8173-disp-mutex",
> .data = _ddp_driver_data},
> {},
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/8] drm/mediatek: add disp-color MT8167 support
Hi, Fabien:
Fabien Parent 於 2020年10月21日 週三 上午1:43寫道：
>
> Add support for disp-color on MT8167 SoC.
Reviewed-by: Chun-Kuang Hu
>
> Signed-off-by: Fabien Parent
> ---
> drivers/gpu/drm/mediatek/mtk_disp_color.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_color.c
> b/drivers/gpu/drm/mediatek/mtk_disp_color.c
> index 3ae9c810845b..a1227cefbf31 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_color.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_color.c
> @@ -16,6 +16,7 @@
>
> #define DISP_COLOR_CFG_MAIN0x0400
> #define DISP_COLOR_START_MT27010x0f00
> +#define DISP_COLOR_START_MT81670x0400
> #define DISP_COLOR_START_MT81730x0c00
> #define DISP_COLOR_START(comp) ((comp)->data->color_offset)
> #define DISP_COLOR_WIDTH(comp) (DISP_COLOR_START(comp) +
> 0x50)
> @@ -148,6 +149,10 @@ static const struct mtk_disp_color_data
> mt2701_color_driver_data = {
> .color_offset = DISP_COLOR_START_MT2701,
> };
>
> +static const struct mtk_disp_color_data mt8167_color_driver_data = {
> + .color_offset = DISP_COLOR_START_MT8167,
> +};
> +
> static const struct mtk_disp_color_data mt8173_color_driver_data = {
> .color_offset = DISP_COLOR_START_MT8173,
> };
> @@ -155,6 +160,8 @@ static const struct mtk_disp_color_data
> mt8173_color_driver_data = {
> static const struct of_device_id mtk_disp_color_driver_dt_match[] = {
> { .compatible = "mediatek,mt2701-disp-color",
> .data = _color_driver_data},
> + { .compatible = "mediatek,mt8167-disp-color",
> + .data = _color_driver_data},
> { .compatible = "mediatek,mt8173-disp-color",
> .data = _color_driver_data},
> {},
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8] dt-bindings: display: mediatek: disp: add documentation for MT8167 SoC
Hi, Fabien: Fabien Parent 於 2020年10月21日 週三 上午1:43寫道： > > Add binding documentation for the MT8167 SoC > Reviewed-by: Chun-Kuang Hu > Signed-off-by: Fabien Parent > --- > .../devicetree/bindings/display/mediatek/mediatek,disp.txt| 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt > b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt > index 121220745d46..33977e15bebd 100644 > --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt > @@ -43,7 +43,7 @@ Required properties (all function blocks): > "mediatek,-dpi" - DPI controller, see > mediatek,dpi.txt > "mediatek,-disp-mutex"- display mutex > "mediatek,-disp-od" - overdrive > - the supported chips are mt2701, mt7623, mt2712 and mt8173. > + the supported chips are mt2701, mt7623, mt2712, mt8167 and mt8173. > - reg: Physical base address and length of the function block register space > - interrupts: The interrupt signal from the function block (required, except > for >merge and split function blocks). > @@ -59,7 +59,7 @@ Required properties (DMA function blocks): > "mediatek,-disp-ovl" > "mediatek,-disp-rdma" > "mediatek,-disp-wdma" > - the supported chips are mt2701 and mt8173. > + the supported chips are mt2701, mt8167 and mt8173. > - larb: Should contain a phandle pointing to the local arbiter device as > defined >in > Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt > - iommus: Should point to the respective IOMMU block with master port as > -- > 2.28.0 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drivers/video: Fix -Wstringop-truncation in hdmi.c
Hi Thomas,
Thank you for the patch.
On Wed, Oct 21, 2020 at 02:12:41PM +0200, Thomas Zimmermann wrote:
> Trying to copy into the string fields with strncpy() gives a warning from
> gcc. Both fields are part of a packed HDMI header and do not require a
> terminating \0 character.
>
> ../drivers/video/hdmi.c: In function 'hdmi_spd_infoframe_init':
> ../drivers/video/hdmi.c:230:2: warning: 'strncpy' specified bound 8 equals
> destination size [-Wstringop-truncation]
> 230 | strncpy(frame->vendor, vendor, sizeof(frame->vendor));
> | ^
> ../drivers/video/hdmi.c:231:2: warning: 'strncpy' specified bound 16 equals
> destination size [-Wstringop-truncation]
> 231 | strncpy(frame->product, product, sizeof(frame->product));
> | ^~~~
>
> Just use memcpy() instead.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/video/hdmi.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index b7a1d6fae90d..1e4cb63d0d11 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -221,14 +221,18 @@ EXPORT_SYMBOL(hdmi_avi_infoframe_pack);
> int hdmi_spd_infoframe_init(struct hdmi_spd_infoframe *frame,
> const char *vendor, const char *product)
> {
> + size_t len;
> +
> memset(frame, 0, sizeof(*frame));
>
> frame->type = HDMI_INFOFRAME_TYPE_SPD;
> frame->version = 1;
> frame->length = HDMI_SPD_INFOFRAME_SIZE;
>
> - strncpy(frame->vendor, vendor, sizeof(frame->vendor));
> - strncpy(frame->product, product, sizeof(frame->product));
> + len = strlen(vendor);
> + memcpy(frame->vendor, vendor, min(len, sizeof(frame->vendor)));
> + len = strlen(product);
> + memcpy(frame->product, product, min(len, sizeof(frame->product)));
As this seems to be a legitimate use of strncpy(), isn't there a way to
silence the warning without requiring this additional runtime complexity
?
>
> return 0;
> }
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/3] drm/panel: mantix panel reset fixes
Hi Daniel, Sam,
On Mon, Oct 19, 2020 at 05:44:37PM +0200, Daniel Vetter wrote:
> On Sat, Oct 17, 2020 at 12:47:36PM +0200, Sam Ravnborg wrote:
> > Hi Guido.
> >
> > On Sat, Oct 17, 2020 at 11:13:07AM +0200, Guido Günther wrote:
> > > Hi Sam,
> > > On Fri, Oct 16, 2020 at 04:29:16PM +0200, Sam Ravnborg wrote:
> > > > Hi Guido.
> > > > On Tue, Oct 13, 2020 at 12:32:45PM +0200, Guido Günther wrote:
> > > [..snip..]
> > > > >
> > > > > Changes from v1:
> > > > > - As per review comments by Fabio Estevam
> > > > >
> > > > > https://lore.kernel.org/dri-devel/CAOMZO5B5ECcConvKej=rcaf8wvoxgq7nuzkj-ad0asaozuq...@mail.gmail.com/
> > > > >- Fix typo in commit messages
> > > > > - As per review comments by Rob Herring
> > > > >https://lore.kernel.org/dri-devel/20200929174624.GA832332@bogus/
> > > > >- Don't use an array of reset lines
> > > > >
> > > > > Guido Günther (3):
> > > > > drm/panel: mantix: Don't dereference NULL mode
> > > > > drm/panel: mantix: Fix panel reset
> > > > > dt-binding: display: Require two resets on mantix panel
> > > >
> > > > All applied to drm-misc-next and pushed out.
> > > > And then I remembered you had commit right - sigh.
> > >
> > > Thanks! Is there any special care needed to get that into 5.10? The
> > > driver landed there in 72967d5616d3f0c714f8eb6c4e258179a9031c45.
> >
> > As the patches was applied to drm-misc-next the easiet path would
> > be to cherry-pick them and apply to drm-misc-fixes.
> > dim has cherry-pick support - try to use it rahter than doing it by
> > hand.
>
> drm-misc-next-fixes while we're between freeze and merge window end:
>
> https://drm.pages.freedesktop.org/maintainer-tools/committer-drm-misc.html#where-do-i-apply-my-patch
Great. Thanks for the pointer, that works. Now i get:
$ ../maintainer-tools/dim push --dry-run
dim: 3532f0117258 ("dt-binding: display: Require two resets on mantix
panel"): mandatory review missing.
dim: c90f95ad6d05 ("drm/panel: mantix: Fix panel reset"): mandatory review
missing.
dim: 8b557f793e69 ("drm/panel: mantix: Don't dereference NULL mode"):
mandatory review missing.
dim: ERROR: issues in commits detected, aborting
and in fact there's only Signed-off-by's on it:
Fixes: 72967d5616d3 ("drm/panel: Add panel driver for the Mantix
MLAF057WE51-X DSI panel")
Signed-off-by: Guido Günther
Signed-off-by: Sam Ravnborg
Link:
https://patchwork.freedesktop.org/patch/msgid/ba71a8ab010d263a8058dd4f711e3bcd95877bf2.1602584953.git@sigxcpu.org
Sam, I assume your Signed-off-by's should have been Reviewed-by ?
O.k. to fix that up in the commit message before pushing to
drm-misc-next?
Cheers,
-- Guido
>
> Cheers, Daniel
>
> >
>
> > When you apply to drm-misc-fixes include a Fixes: tag so the tooling
> > will pick the patches automagically.
> >
> > In hindsight the patches should have carried a Fixes: tag from a start
> > and should have been applied to drm-misc-fixes from a start too.
> >
> > I have done something like above once or twice but anyway reach out if
> > you have questions. Or ask at #dri-devel.
> >
> > Sam
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm: Store USB device in struct drm_device
On Wed, Oct 21, 2020 at 10:01:29PM +0200, Daniel Vetter wrote: > On Wed, Oct 21, 2020 at 03:07:29PM +0200, Thomas Zimmermann wrote: > > The drivers gm12u320 and udl operate on USB devices. They leave the > > PCI device in struct drm_device empty and store the USB device in their > > own driver structure. > > > > Fix this special case and save a few bytes by putting the USB device > > into an anonymous union with the PCI data. It's expected that DRM > > core and helpers only touch the PCI-device field for actual PCI devices. > > Uh no. > > If you're really concerned about the 8 bytes wasted, use drm_device->dev > instead, and upcast it to the usb device. I think some drivers do this > already (at least on the platform side iirc). > > But we had this entire drm_bus midlayer stuff already, and it took forever > to sunset it. I don't want to go back, and saving 8 bytes in a giantic > structure isn't worth that risk imo. Typing this I realized that we could even move the pdev pointer to the legacy chunk of drm_device. Instead of checking for drm_device->pdev we could instead check for dev_is_pci(drm_device->dev) in the 1-2 core code places. But it's a pile of churn to roll that out to drivers, and I'm not sure the 8 bytes saved is even close to paying for that huge effort. -Daniel > > Thomas Zimmermann (3): > > drm: Add reference to USB device to struct drm_device > > drm/tiny/gm12u320: Store USB device in struct drm_device.udev > > drm/udl: Store USB device in struct drm_device.udev > > > > drivers/gpu/drm/tiny/gm12u320.c | 52 + > > drivers/gpu/drm/udl/udl_connector.c | 8 ++--- > > drivers/gpu/drm/udl/udl_drv.c | 2 +- > > drivers/gpu/drm/udl/udl_drv.h | 1 - > > drivers/gpu/drm/udl/udl_main.c | 15 + > > include/drm/drm_device.h| 21 > > 6 files changed, 52 insertions(+), 47 deletions(-) > > > > -- > > 2.28.0 > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm: Store USB device in struct drm_device
On Wed, Oct 21, 2020 at 03:07:29PM +0200, Thomas Zimmermann wrote: > The drivers gm12u320 and udl operate on USB devices. They leave the > PCI device in struct drm_device empty and store the USB device in their > own driver structure. > > Fix this special case and save a few bytes by putting the USB device > into an anonymous union with the PCI data. It's expected that DRM > core and helpers only touch the PCI-device field for actual PCI devices. Uh no. If you're really concerned about the 8 bytes wasted, use drm_device->dev instead, and upcast it to the usb device. I think some drivers do this already (at least on the platform side iirc). But we had this entire drm_bus midlayer stuff already, and it took forever to sunset it. I don't want to go back, and saving 8 bytes in a giantic structure isn't worth that risk imo. -Daniel > > Thomas Zimmermann (3): > drm: Add reference to USB device to struct drm_device > drm/tiny/gm12u320: Store USB device in struct drm_device.udev > drm/udl: Store USB device in struct drm_device.udev > > drivers/gpu/drm/tiny/gm12u320.c | 52 + > drivers/gpu/drm/udl/udl_connector.c | 8 ++--- > drivers/gpu/drm/udl/udl_drv.c | 2 +- > drivers/gpu/drm/udl/udl_drv.h | 1 - > drivers/gpu/drm/udl/udl_main.c | 15 + > include/drm/drm_device.h| 21 > 6 files changed, 52 insertions(+), 47 deletions(-) > > -- > 2.28.0 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 14/16] resource: Move devmem revoke code to resource framework
On Wed, Oct 21, 2020 at 8:59 PM Dan Williams wrote:
>
> On Wed, Oct 21, 2020 at 1:57 AM Daniel Vetter wrote:
> >
> > We want all iomem mmaps to consistently revoke ptes when the kernel
> > takes over and CONFIG_IO_STRICT_DEVMEM is enabled. This includes the
> > pci bar mmaps available through procfs and sysfs, which currently do
> > not revoke mappings.
> >
> > To prepare for this, move the code from the /dev/kmem driver to
> > kernel/resource.c.
> >
> > Reviewed-by: Greg Kroah-Hartman
> > Signed-off-by: Daniel Vetter
> > Cc: Jason Gunthorpe
> > Cc: Kees Cook
> > Cc: Dan Williams
> > Cc: Andrew Morton
> > Cc: John Hubbard
> > Cc: Jérôme Glisse
> > Cc: Jan Kara
> > Cc: Dan Williams
> > Cc: linux...@kvack.org
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-samsung-...@vger.kernel.org
> > Cc: linux-me...@vger.kernel.org
> > Cc: Arnd Bergmann
> > Cc: Greg Kroah-Hartman
> > Cc: Daniel Vetter
> > Cc: David Hildenbrand
> > Cc: "Rafael J. Wysocki"
> > Signed-off-by: Daniel Vetter
> > --
> > v3:
> > - add barrier for consistency and document why we don't have to check
> > for NULL (Jason)
> > ---
> > drivers/char/mem.c | 85 +-
> > include/linux/ioport.h | 6 +--
> > kernel/resource.c | 101 -
> > 3 files changed, 102 insertions(+), 90 deletions(-)
> >
> > diff --git a/drivers/char/mem.c b/drivers/char/mem.c
> > index 5502f56f3655..53338aad8d28 100644
> > --- a/drivers/char/mem.c
> > +++ b/drivers/char/mem.c
> > @@ -31,9 +31,6 @@
> > #include
> > #include
> > #include
> > -#include
> > -#include
> > -#include
> >
> > #ifdef CONFIG_IA64
> > # include
> > @@ -809,42 +806,6 @@ static loff_t memory_lseek(struct file *file, loff_t
> > offset, int orig)
> > return ret;
> > }
> >
> > -static struct inode *devmem_inode;
> > -
> > -#ifdef CONFIG_IO_STRICT_DEVMEM
> > -void revoke_devmem(struct resource *res)
> > -{
> > - /* pairs with smp_store_release() in devmem_init_inode() */
> > - struct inode *inode = smp_load_acquire(_inode);
> > -
> > - /*
> > -* Check that the initialization has completed. Losing the race
> > -* is ok because it means drivers are claiming resources before
> > -* the fs_initcall level of init and prevent /dev/mem from
> > -* establishing mappings.
> > -*/
> > - if (!inode)
> > - return;
> > -
> > - /*
> > -* The expectation is that the driver has successfully marked
> > -* the resource busy by this point, so devmem_is_allowed()
> > -* should start returning false, however for performance this
> > -* does not iterate the entire resource range.
> > -*/
> > - if (devmem_is_allowed(PHYS_PFN(res->start)) &&
> > - devmem_is_allowed(PHYS_PFN(res->end))) {
> > - /*
> > -* *cringe* iomem=relaxed says "go ahead, what's the
> > -* worst that can happen?"
> > -*/
> > - return;
> > - }
> > -
> > - unmap_mapping_range(inode->i_mapping, res->start,
> > resource_size(res), 1);
> > -}
> > -#endif
> > -
> > static int open_port(struct inode *inode, struct file *filp)
> > {
> > int rc;
> > @@ -864,7 +825,7 @@ static int open_port(struct inode *inode, struct file
> > *filp)
> > * revocations when drivers want to take over a /dev/mem mapped
> > * range.
> > */
> > - filp->f_mapping = inode->i_mapping;
> > + filp->f_mapping = iomem_get_mapping();
> >
> > return 0;
> > }
> > @@ -995,48 +956,6 @@ static char *mem_devnode(struct device *dev, umode_t
> > *mode)
> >
> > static struct class *mem_class;
> >
> > -static int devmem_fs_init_fs_context(struct fs_context *fc)
> > -{
> > - return init_pseudo(fc, DEVMEM_MAGIC) ? 0 : -ENOMEM;
> > -}
> > -
> > -static struct file_system_type devmem_fs_type = {
> > - .name = "devmem",
> > - .owner = THIS_MODULE,
> > - .init_fs_context = devmem_fs_init_fs_context,
> > - .kill_sb= kill_anon_super,
> > -};
> > -
> > -static int devmem_init_inode(void)
> > -{
> > - static struct vfsmount *devmem_vfs_mount;
> > - static int devmem_fs_cnt;
> > - struct inode *inode;
> > - int rc;
> > -
> > - rc = simple_pin_fs(_fs_type, _vfs_mount,
> > _fs_cnt);
> > - if (rc < 0) {
> > - pr_err("Cannot mount /dev/mem pseudo filesystem: %d\n", rc);
> > - return rc;
> > - }
> > -
> > - inode = alloc_anon_inode(devmem_vfs_mount->mnt_sb);
> > - if (IS_ERR(inode)) {
> > - rc = PTR_ERR(inode);
> > - pr_err("Cannot allocate inode for /dev/mem: %d\n", rc);
> > - simple_release_fs(_vfs_mount, _fs_cnt);
> > - return rc;
> > - }
> > -
> > - /*
> > -* Publish /dev/mem initialized.
> > -
Re: [PATCH v3 12/16] PCI: Obey iomem restrictions for procfs mmap
On Wed, Oct 21, 2020 at 6:37 PM Jason Gunthorpe wrote: > > On Wed, Oct 21, 2020 at 05:54:54PM +0200, Daniel Vetter wrote: > > > The trouble is that io_remap_pfn adjust vma->pgoff, so we'd need to > > split that. So ideally ->mmap would never set up any ptes. > > /dev/mem makes pgoff == pfn so it doesn't get changed by remap. > > pgoff doesn't get touched for MAP_SHARED either, so there are other > users that could work like this - eg anyone mmaping IO memory is > probably OK. I was more generally thinking for io_remap_pfn_users because of the mkwrite use-case we might have in fbdev emulation in drm. > > I guess one option would be if remap_pfn_range would steal the > > vma->vm_ops pointer for itself, then it could set up the correct > > ->install_ptes hook. But there's tons of callers for that, so not sure > > that's a bright idea. > > The caller has to check that the mapping is still live, and I think > hold a lock across the remap? Auto-defering it doesn't seem feasible. Right auto-defering reopens the race, so making this work automatically is a bit much. I guess just splitting this into a setup/install part and then doing the install of all the ptes at first fault should be good enough. We don't really need a new install_pages for that, just an io_remap_pfn_range that's split in two parts. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 14/16] resource: Move devmem revoke code to resource framework
On Wed, Oct 21, 2020 at 1:57 AM Daniel Vetter wrote:
>
> We want all iomem mmaps to consistently revoke ptes when the kernel
> takes over and CONFIG_IO_STRICT_DEVMEM is enabled. This includes the
> pci bar mmaps available through procfs and sysfs, which currently do
> not revoke mappings.
>
> To prepare for this, move the code from the /dev/kmem driver to
> kernel/resource.c.
>
> Reviewed-by: Greg Kroah-Hartman
> Signed-off-by: Daniel Vetter
> Cc: Jason Gunthorpe
> Cc: Kees Cook
> Cc: Dan Williams
> Cc: Andrew Morton
> Cc: John Hubbard
> Cc: Jérôme Glisse
> Cc: Jan Kara
> Cc: Dan Williams
> Cc: linux...@kvack.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-me...@vger.kernel.org
> Cc: Arnd Bergmann
> Cc: Greg Kroah-Hartman
> Cc: Daniel Vetter
> Cc: David Hildenbrand
> Cc: "Rafael J. Wysocki"
> Signed-off-by: Daniel Vetter
> --
> v3:
> - add barrier for consistency and document why we don't have to check
> for NULL (Jason)
> ---
> drivers/char/mem.c | 85 +-
> include/linux/ioport.h | 6 +--
> kernel/resource.c | 101 -
> 3 files changed, 102 insertions(+), 90 deletions(-)
>
> diff --git a/drivers/char/mem.c b/drivers/char/mem.c
> index 5502f56f3655..53338aad8d28 100644
> --- a/drivers/char/mem.c
> +++ b/drivers/char/mem.c
> @@ -31,9 +31,6 @@
> #include
> #include
> #include
> -#include
> -#include
> -#include
>
> #ifdef CONFIG_IA64
> # include
> @@ -809,42 +806,6 @@ static loff_t memory_lseek(struct file *file, loff_t
> offset, int orig)
> return ret;
> }
>
> -static struct inode *devmem_inode;
> -
> -#ifdef CONFIG_IO_STRICT_DEVMEM
> -void revoke_devmem(struct resource *res)
> -{
> - /* pairs with smp_store_release() in devmem_init_inode() */
> - struct inode *inode = smp_load_acquire(_inode);
> -
> - /*
> -* Check that the initialization has completed. Losing the race
> -* is ok because it means drivers are claiming resources before
> -* the fs_initcall level of init and prevent /dev/mem from
> -* establishing mappings.
> -*/
> - if (!inode)
> - return;
> -
> - /*
> -* The expectation is that the driver has successfully marked
> -* the resource busy by this point, so devmem_is_allowed()
> -* should start returning false, however for performance this
> -* does not iterate the entire resource range.
> -*/
> - if (devmem_is_allowed(PHYS_PFN(res->start)) &&
> - devmem_is_allowed(PHYS_PFN(res->end))) {
> - /*
> -* *cringe* iomem=relaxed says "go ahead, what's the
> -* worst that can happen?"
> -*/
> - return;
> - }
> -
> - unmap_mapping_range(inode->i_mapping, res->start, resource_size(res),
> 1);
> -}
> -#endif
> -
> static int open_port(struct inode *inode, struct file *filp)
> {
> int rc;
> @@ -864,7 +825,7 @@ static int open_port(struct inode *inode, struct file
> *filp)
> * revocations when drivers want to take over a /dev/mem mapped
> * range.
> */
> - filp->f_mapping = inode->i_mapping;
> + filp->f_mapping = iomem_get_mapping();
>
> return 0;
> }
> @@ -995,48 +956,6 @@ static char *mem_devnode(struct device *dev, umode_t
> *mode)
>
> static struct class *mem_class;
>
> -static int devmem_fs_init_fs_context(struct fs_context *fc)
> -{
> - return init_pseudo(fc, DEVMEM_MAGIC) ? 0 : -ENOMEM;
> -}
> -
> -static struct file_system_type devmem_fs_type = {
> - .name = "devmem",
> - .owner = THIS_MODULE,
> - .init_fs_context = devmem_fs_init_fs_context,
> - .kill_sb= kill_anon_super,
> -};
> -
> -static int devmem_init_inode(void)
> -{
> - static struct vfsmount *devmem_vfs_mount;
> - static int devmem_fs_cnt;
> - struct inode *inode;
> - int rc;
> -
> - rc = simple_pin_fs(_fs_type, _vfs_mount,
> _fs_cnt);
> - if (rc < 0) {
> - pr_err("Cannot mount /dev/mem pseudo filesystem: %d\n", rc);
> - return rc;
> - }
> -
> - inode = alloc_anon_inode(devmem_vfs_mount->mnt_sb);
> - if (IS_ERR(inode)) {
> - rc = PTR_ERR(inode);
> - pr_err("Cannot allocate inode for /dev/mem: %d\n", rc);
> - simple_release_fs(_vfs_mount, _fs_cnt);
> - return rc;
> - }
> -
> - /*
> -* Publish /dev/mem initialized.
> -* Pairs with smp_load_acquire() in revoke_devmem().
> -*/
> - smp_store_release(_inode, inode);
> -
> - return 0;
> -}
> -
> static int __init chr_dev_init(void)
> {
> int minor;
> @@ -1058,8 +977,6 @@ static int __init chr_dev_init(void)
> */
> if ((minor == DEVPORT_MINOR) &&
Re: amdgpu: Manual Card Configuration Change
On Mon, Oct 19, 2020 at 8:53 PM Josh Fuhs wrote: > > Thanks. I tried 5.9.1 and I think there's still a problem, or at least > something different. > > Using the same configuration script, I noticed that my cards are running a > lot hotter. For example, here's total power consumption of a two-card system > with two different kernels: > > 5.8.14: 460W > 5.9.1: 560+W > > Memory and system clocks are initially set the same on all cards in all cases. Can you bisect? Alex > > Josh > > > ‐‐‐ Original Message ‐‐‐ > On Monday, October 19, 2020 2:22 PM, Alex Deucher > wrote: > > > On Sun, Oct 18, 2020 at 4:32 PM Josh Fuhs joshua.f...@pm.me wrote: > > > > > Hello all, > > > Regarding amdgpu, I've been using some Radeon 5700XTs for compute work > > > with kernels through 5.8.14. I recently tried kernel 5.9.0, and found > > > that the following is no longer allowed: > > > echo "m 1 200" | sudo tee /sys/class/drm/card0/device/pp_od_clk_voltage > > > Is this an expected change? If so, where should I look for documentation > > > regarding how to manually configure these cards with this kernel. Note, > > > I've had this working with 5.8 kernels for months. > > > > It was a bug. Fixed in 5.9.1. > > > > Alex > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/6] drm: amdgpu: kernel-doc: update some adev parameters
Applied. Thanks! Alex On Wed, Oct 21, 2020 at 8:17 AM Mauro Carvalho Chehab wrote: > > Running "make htmldocs: produce lots of warnings on those files: > ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:177: warning: Excess > function parameter 'man' description in 'amdgpu_vram_mgr_init' > ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:177: warning: Excess > function parameter 'p_size' description in 'amdgpu_vram_mgr_init' > ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:211: warning: Excess > function parameter 'man' description in 'amdgpu_vram_mgr_fini' > ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:177: warning: Excess > function parameter 'man' description in 'amdgpu_vram_mgr_init' > ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:177: warning: Excess > function parameter 'p_size' description in 'amdgpu_vram_mgr_init' > ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:211: warning: Excess > function parameter 'man' description in 'amdgpu_vram_mgr_fini' > ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:177: warning: Excess > function parameter 'man' description in 'amdgpu_vram_mgr_init' > ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:177: warning: Excess > function parameter 'p_size' description in 'amdgpu_vram_mgr_init' > ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:211: warning: Excess > function parameter 'man' description in 'amdgpu_vram_mgr_fini' > ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:177: warning: Excess > function parameter 'man' description in 'amdgpu_vram_mgr_init' > ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:177: warning: Excess > function parameter 'p_size' description in 'amdgpu_vram_mgr_init' > ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:211: warning: Excess > function parameter 'man' description in 'amdgpu_vram_mgr_fini' > ./drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c:90: warning: Excess > function parameter 'man' description in 'amdgpu_gtt_mgr_init' > ./drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c:90: warning: Excess > function parameter 'p_size' description in 'amdgpu_gtt_mgr_init' > ./drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c:134: warning: Excess > function parameter 'man' description in 'amdgpu_gtt_mgr_fini' > ./drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c:90: warning: Excess > function parameter 'man' description in 'amdgpu_gtt_mgr_init' > ./drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c:90: warning: Excess > function parameter 'p_size' description in 'amdgpu_gtt_mgr_init' > ./drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c:134: warning: Excess > function parameter 'man' description in 'amdgpu_gtt_mgr_fini' > ./drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:675: warning: Excess > function parameter 'dev' description in 'amdgpu_device_asic_init' > ./drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:675: warning: Excess > function parameter 'dev' description in 'amdgpu_device_asic_init' > ./drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:675: warning: Excess > function parameter 'dev' description in 'amdgpu_device_asic_init' > ./drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:675: warning: Excess > function parameter 'dev' description in 'amdgpu_device_asic_init' > > They're related to the repacement of some parameters by adev, > and due to a few renamed parameters. > > While here, uniform the name of the parameter for it to be > the same on all functions using a pointer to struct amdgpu_device. > > Update the kernel-doc documentation accordingly. > > Signed-off-by: Mauro Carvalho Chehab > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 28 ++-- > drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 6 ++--- > drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 7 +++-- > 3 files changed, 20 insertions(+), 21 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c > index e8b41756c9f9..f8785bdec79c 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c > @@ -705,7 +705,7 @@ void amdgpu_device_indirect_wreg64(struct amdgpu_device > *adev, > /** > * amdgpu_invalid_rreg - dummy reg read function > * > - * @adev: amdgpu device pointer > + * @adev: amdgpu_device pointer > * @reg: offset of register > * > * Dummy register read function. Used for register blocks > @@ -722,7 +722,7 @@ static uint32_t amdgpu_invalid_rreg(struct amdgpu_device > *adev, uint32_t reg) > /** > * amdgpu_invalid_wreg - dummy reg write function > * > - * @adev: amdgpu device pointer > + * @adev: amdgpu_device pointer > * @reg: offset of register > * @v: value to write to the register > * > @@ -739,7 +739,7 @@ static void amdgpu_invalid_wreg(struct amdgpu_device > *adev, uint32_t reg, uint32 > /** > * amdgpu_invalid_rreg64 - dummy 64 bit reg read function > * > - * @adev:
Re: [Outreachy kernel][PATCH] gpu: amd: Return boolean types instead of integer values
Applied. Thanks! Alex On Wed, Oct 21, 2020 at 2:29 PM Sumera Priyadarsini wrote: > > Return statements for functions returning bool should use truth > and false instead of 1 and 0 respectively. > > Modify cik_event_interrupt.c to return false instead of 0. > > Issue found with Coccinelle. > > Signed-off-by: Sumera Priyadarsini > --- > drivers/gpu/drm/amd/amdkfd/cik_event_interrupt.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdkfd/cik_event_interrupt.c > b/drivers/gpu/drm/amd/amdkfd/cik_event_interrupt.c > index 24b471734117..8e64c01565ac 100644 > --- a/drivers/gpu/drm/amd/amdkfd/cik_event_interrupt.c > +++ b/drivers/gpu/drm/amd/amdkfd/cik_event_interrupt.c > @@ -66,12 +66,12 @@ static bool cik_event_interrupt_isr(struct kfd_dev *dev, > vmid = (ihre->ring_id & 0xff00) >> 8; > if (vmid < dev->vm_info.first_vmid_kfd || > vmid > dev->vm_info.last_vmid_kfd) > - return 0; > + return false; > > /* If there is no valid PASID, it's likely a firmware bug */ > pasid = (ihre->ring_id & 0x) >> 16; > if (WARN_ONCE(pasid == 0, "FW bug: No PASID in KFD interrupt")) > - return 0; > + return false; > > /* Interrupt types we care about: various signals and faults. > * They will be forwarded to a work queue (see below). > -- > 2.25.1 > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 13/16] /dev/mem: Only set filp->f_mapping
On Wed, Oct 21, 2020 at 1:57 AM Daniel Vetter wrote: > > When we care about pagecache maintenance, we need to make sure that > both f_mapping and i_mapping point at the right mapping. > > But for iomem mappings we only care about the virtual/pte side of > things, so f_mapping is enough. Also setting inode->i_mapping was > confusing me as a driver maintainer, since in e.g. drivers/gpu we > don't do that. Per Dan this seems to be copypasta from places which do > care about pagecache consistency, but not needed. Hence remove it for > slightly less confusion. > > Signed-off-by: Daniel Vetter > Cc: Jason Gunthorpe > Cc: Kees Cook > Cc: Dan Williams > Cc: Andrew Morton > Cc: John Hubbard > Cc: Jérôme Glisse > Cc: Jan Kara > Cc: Dan Williams Reviewed-by: Dan Williams ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: add client cap to expose low power modes
On Wed, 21 Oct 2020 at 17:34, Daniel Vetter wrote: > On Wed, Oct 21, 2020 at 05:11:00PM +0100, Daniel Stone wrote: > > It makes sense to me: some modes are annotated with a 'low-power' > > flag, tucked away behind a client cap which makes clients opt in, and > > they can switch into the low-power mode (letting the display/panel > > save a lot of power) _if_ they only have at most 15% of pixels lit up. > > > > My worry is about the 15% though ... what happens when hardware allows > > up to 20%, or only allows 10%? > > Yeah exactly, that's what I'm worried about too, these kind of details. > Opt-in flag for special modes, no problem, but we need to make sure we > agree on what flavour of special exactly they are. > > > If we can reuse the same modelines, then rather than create new > > modelines just for low-power modes, I'd rather create a client CRTC > > property specifying the number/percentages of pixels on the CRTC which > > are lit non-zero. That would give us more wriggle room to change the > > semantics, as well as redefine 'low power' in terms of > > monochrome/scaled/non-bright/etc modes. But it does make the > > switching-between-clients problem even worse than it already is. > > Yeah, that would make sense too. Or maybe even add read-only hint that > says "if you're below 15% non-black we can do low power for your, please > be nice". If the hardware can actually do that autonomously then great, but I'm guessing the reason we're talking about separate opt-in modes here is that it can't. Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/8] drm/mediatek: dsi: add pdata variable to start clk in HS mode
Hi, Fabien:
Fabien Parent 於 2020年10月21日 週三 上午1:43寫道：
>
> On MT8167, DSI seems to work fine only if we start the clk in HS mode.
> If we don't start the clk in HS but try to switch later to HS, the
> display does not work.
>
> This commit adds a platform data variable to be used to start the
> DSI clk in HS mode at power on.
This patch looks like a hack patch. If you cowork with Mediatek,
please find out the correct solution or give a reasonable explanation.
If you could not get help from Mediatek, I would wait for comment on
this patch.
Regards,
Chun-Kuang.
>
> Signed-off-by: Fabien Parent
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 4a188a942c38..461643c05689 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -175,6 +175,7 @@ struct mtk_dsi_driver_data {
> const u32 reg_cmdq_off;
> bool has_shadow_ctl;
> bool has_size_ctl;
> + bool use_hs_on_power_on;
> };
>
> struct mtk_dsi {
> @@ -671,7 +672,7 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
>
> mtk_dsi_clk_ulp_mode_leave(dsi);
> mtk_dsi_lane0_ulp_mode_leave(dsi);
> - mtk_dsi_clk_hs_mode(dsi, 0);
> + mtk_dsi_clk_hs_mode(dsi, !!dsi->driver_data->use_hs_on_power_on);
>
> return 0;
> err_disable_engine_clk:
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/8] dt-bindings: display: mediatek: dsi: add documentation for MT8167 SoC
Hi, Fabien:
Fabien Parent 於 2020年10月21日 週三 上午1:43寫道：
>
> Add binding documentation for the MT8167 SoC. The SoC needs
> an additional clock compared to the already supported SoC: mipi26m.
>
> Signed-off-by: Fabien Parent
> ---
> .../devicetree/bindings/display/mediatek/mediatek,dsi.txt | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> index f06f24d405a5..10ae6be7225e 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> @@ -7,12 +7,13 @@ channel output.
>
> Required properties:
> - compatible: "mediatek,-dsi"
> -- the supported chips are mt2701, mt7623, mt8173 and mt8183.
> +- the supported chips are mt2701, mt7623, mt8167, mt8173 and mt8183.
> - reg: Physical base address and length of the controller's registers
> - interrupts: The interrupt signal from the function block.
> - clocks: device clocks
>See Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
> -- clock-names: must contain "engine", "digital", and "hs"
> +- clock-names: must contain "engine", "digital", "hs"
> + Can optionnally also contain "mipi26m"
It seems that mipi26m is the clock of mipi-tx. In mt8173.dtsi [1],
mipi-tx's clock is 26m.
mipi_tx0: mipi-dphy@10215000 {
compatible = "mediatek,mt8173-mipi-tx";
reg = <0 0x10215000 0 0x1000>;
clocks = <>;
clock-output-names = "mipi_tx0_pll";
#clock-cells = <0>;
#phy-cells = <0>;
status = "disabled";
};
If this is the clock of mipi-tx, it should be controlled by mipi-tx driver.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/mediatek/mt8173.dtsi?h=v5.9
Regards,
Chun-Kuang.
> - phys: phandle link to the MIPI D-PHY controller.
> - phy-names: must contain "dphy"
> - port: Output port node with endpoint definitions as described in
> @@ -26,7 +27,7 @@ The MIPI TX configuration module controls the MIPI D-PHY.
>
> Required properties:
> - compatible: "mediatek,-mipi-tx"
> -- the supported chips are mt2701, 7623, mt8173 and mt8183.
> +- the supported chips are mt2701, 7623, mt8167, mt8173 and mt8183.
> - reg: Physical base address and length of the controller's registers
> - clocks: PLL reference clock
> - clock-output-names: name of the output clock line to the DSI encoder
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 3/8] drm/msm: Unconditionally call dev_pm_opp_of_remove_table()
On Wed, Oct 21, 2020 at 12:24 AM Viresh Kumar wrote: > > On 05-10-20, 11:56, Viresh Kumar wrote: > > On 28-08-20, 11:37, Viresh Kumar wrote: > > > dev_pm_opp_of_remove_table() doesn't report any errors when it fails to > > > find the OPP table with error -ENODEV (i.e. OPP table not present for > > > the device). And we can call dev_pm_opp_of_remove_table() > > > unconditionally here. > > > > > > While at it, also create a label to put clkname. > > > > > > Signed-off-by: Viresh Kumar > > > > Can someone please apply this and the other drm patch (2/8) ? > > Rob/Rajendra, can someone please have a look at these patches ? Oh, sorry I missed that, could someone re-send it and CC freedr...@lists.freedesktop.org so it shows up in patchworks.. that is more reliable counting on me to not overlook something in my mail BR, -R ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 12/24] drm/dp: fix a kernel-doc issue at drm_edid.c
Ah, good point. It looks like you've already added the drm-misc-next and drm
maintainers to here so as long as they're aware that should be fine
On Wed, 2020-10-21 at 12:11 +0200, Mauro Carvalho Chehab wrote:
> Hi Lyude,
>
> Em Tue, 13 Oct 2020 15:49:11 -0400
> Lyude Paul escreveu:
>
> > wait, I think there's some confusion here. these patches have already been
> > pushed
>
> As the patch adding the warning was merged upstream at the 5.10 merge
> window, the fixup one should also be added there, instead of waiting
> until 5.11 ;-)
>
> So, if OK for you, I'll send this upstream via my tree by the end of
> the merge window, as our goal is that 5.10 won't have doc warnings.
>
> Regards,
> Mauro
> >
> > On Tue, 2020-10-13 at 14:14 +0200, Mauro Carvalho Chehab wrote:
> > > The name of the argument is different, causing those warnings:
> > >
> > > ./drivers/gpu/drm/drm_edid.c:3754: warning: Function parameter or
> > > member
> > > 'video_code' not described in 'drm_display_mode_from_cea_vic'
> > > ./drivers/gpu/drm/drm_edid.c:3754: warning: Excess function parameter
> > > 'vic' description in 'drm_display_mode_from_cea_vic'
> > >
> > > Fixes: 7af655bce275 ("drm/dp: Add drm_dp_downstream_mode()")
> > > Signed-off-by: Mauro Carvalho Chehab
> > > ---
> > > drivers/gpu/drm/drm_edid.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > index a82f37d44258..631125b46e04 100644
> > > --- a/drivers/gpu/drm/drm_edid.c
> > > +++ b/drivers/gpu/drm/drm_edid.c
> > > @@ -3741,7 +3741,7 @@ drm_add_cmdb_modes(struct drm_connector
> > > *connector, u8
> > > svd)
> > > /**
> > > * drm_display_mode_from_cea_vic() - return a mode for CEA VIC
> > > * @dev: DRM device
> > > - * @vic: CEA VIC of the mode
> > > + * @video_code: CEA VIC of the mode
> > > *
> > > * Creates a new mode matching the specified CEA VIC.
> > > *
>
>
> Thanks,
> Mauro
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: add client cap to expose low power modes
On Wed, Oct 21, 2020 at 05:11:00PM +0100, Daniel Stone wrote: > On Wed, 21 Oct 2020 at 16:58, Daniel Vetter wrote: > > On Wed, Oct 21, 2020 at 4:59 PM Ken Huang wrote: > > > It's useful in Android and other embedded devices to implement Always On > > > Display (ex. showing clock faces with less than 15% OPR on screen). > > > > > > OPR (On Pixel Ratio) is the percentage of luminance amount over the > > > display area. > > > It's derived by gray levels of display image pattern and the backlight > > > (or OLED) driving force (or current). > > > ex: OPR=100% means a full white pattern with maximum backlight (or OLED) > > > brightness, while full black would be OPR=0%. > > > > > > In userspace, when the client initializes, we can set capability via > > > drmSetClientCap() to ask the display driver to expose the drm modes with > > > DRM_MODE_FLAG_LOW_POWER flag. > > > Userspace can check DRM_MODE_FLAG_LOW_POWER flag to know which modes can > > > be used to consume the least amount of power during Always On Display. > > > Ignoring modes with this flag set during normal operating mode. > > > > Hm I'm not really sure what this changes ... I think we need the > > entire pile of patches: Userspace, driver, drm core, anything else. > > Just adding this flag doesn't make much sense really, since I have no > > idea what the semantics are. Even after you've explained the use-case. > > It makes sense to me: some modes are annotated with a 'low-power' > flag, tucked away behind a client cap which makes clients opt in, and > they can switch into the low-power mode (letting the display/panel > save a lot of power) _if_ they only have at most 15% of pixels lit up. > > My worry is about the 15% though ... what happens when hardware allows > up to 20%, or only allows 10%? Yeah exactly, that's what I'm worried about too, these kind of details. Opt-in flag for special modes, no problem, but we need to make sure we agree on what flavour of special exactly they are. > If we can reuse the same modelines, then rather than create new > modelines just for low-power modes, I'd rather create a client CRTC > property specifying the number/percentages of pixels on the CRTC which > are lit non-zero. That would give us more wriggle room to change the > semantics, as well as redefine 'low power' in terms of > monochrome/scaled/non-bright/etc modes. But it does make the > switching-between-clients problem even worse than it already is. Yeah, that would make sense too. Or maybe even add read-only hint that says "if you're below 15% non-black we can do low power for your, please be nice". -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/doc: Document legacy_cursor_update better
It's the horror and shouldn't be used. Realized we're not clear on
this in a discussion with Rob about what msm is doing to better
support async commits.
v2: Refine existing todo item to include this (Thomas)
Cc: Sean Paul
Cc: Rob Clark
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
---
Documentation/gpu/todo.rst | 4
include/drm/drm_atomic.h | 12 +++-
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 700637e25ecd..6b224ef14455 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -105,6 +105,10 @@ converted over to the new infrastructure.
One issue with the helpers is that they require that drivers handle completion
events for atomic commits correctly. But fixing these bugs is good anyway.
+Somewhat related is the legacy_cursor_update hack, which should be replaced
with
+the new atomic_async_check/commit functionality in the helpers in drivers that
+still look at that flag.
+
Contact: Daniel Vetter, respective driver maintainers
Level: Advanced
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index d07c851d255b..413fd0ca56a8 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -308,7 +308,6 @@ struct __drm_private_objs_state {
* struct drm_atomic_state - the global state object for atomic updates
* @ref: count of all references to this state (will not be freed until zero)
* @dev: parent DRM device
- * @legacy_cursor_update: hint to enforce legacy cursor IOCTL semantics
* @async_update: hint for asynchronous plane update
* @planes: pointer to array of structures with per-plane data
* @crtcs: pointer to array of CRTC pointers
@@ -336,6 +335,17 @@ struct drm_atomic_state {
* drm_atomic_crtc_needs_modeset().
*/
bool allow_modeset : 1;
+ /**
+* @legacy_cursor_update:
+*
+* Hint to enforce legacy cursor IOCTL semantics.
+*
+* WARNING: This is thoroughly broken and pretty much impossible to
+* implement correctly. Drivers must ignore this and should instead
+* implement _plane_helper_funcs.atomic_async_check and
+* _plane_helper_funcs.atomic_async_commit hooks. New users of this
+* flag are not allowed.
+*/
bool legacy_cursor_update : 1;
bool async_update : 1;
/**
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/vc4: Drop legacy_cursor_update override
With the removal of helper support it doesn't do anything anymore. Also, we already have async plane update code in vc4. Signed-off-by: Daniel Vetter Cc: Eric Anholt Cc: Maxime Ripard --- drivers/gpu/drm/vc4/vc4_kms.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c index 149825ff5df8..bf0da77ab2e6 100644 --- a/drivers/gpu/drm/vc4/vc4_kms.c +++ b/drivers/gpu/drm/vc4/vc4_kms.c @@ -353,12 +353,6 @@ static int vc4_atomic_commit(struct drm_device *dev, return 0; } - /* We know for sure we don't want an async update here. Set -* state->legacy_cursor_update to false to prevent -* drm_atomic_helper_setup_commit() from auto-completing -* commit->flip_done. -*/ - state->legacy_cursor_update = false; ret = drm_atomic_helper_setup_commit(state, nonblock); if (ret) return ret; -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/atomic-helpers: remove legacy_cursor_update hacks
The stuff never really worked, and leads to lots of fun because it
out-of-order frees atomic states. Which upsets KASAN, among other
things.
For async updates we now have a more solid solution with the
->atomic_async_check and ->atomic_async_commit hooks. Support for that
for msm and vc4 landed. nouveau and i915 have their own commit
routines, doing something similar.
For everyone else it's probably better to remove the use-after-free
bug, and encourage folks to use the async support instead. The
affected drivers which register a legacy cursor plane and don't either
use the new async stuff or their own commit routine are: amdgpu,
atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx.
Inspired by an amdgpu bug report.
v2: Drop RFC, I think with amdgpu converted over to use
atomic_async_check/commit done in
commit 674e78acae0dfb4beb56132e41cbae5b60f7d662
Author: Nicholas Kazlauskas
Date: Wed Dec 5 14:59:07 2018 -0500
drm/amd/display: Add fast path for cursor plane updates
we don't have any driver anymore where we have userspace expecting
solid legacy cursor support _and_ they are using the atomic helpers in
their fully glory. So we can retire this.
References: https://bugzilla.kernel.org/show_bug.cgi?id=199425
Cc: mikita.lip...@amd.com
Cc: Michel Dänzer
Cc: harry.wentl...@amd.com
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index a7bcb4b4586c..549a31e6042c 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1481,13 +1481,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device
*dev,
int i, ret;
unsigned crtc_mask = 0;
-/*
- * Legacy cursor ioctls are completely unsynced, and userspace
- * relies on that (by doing tons of cursor updates).
- */
- if (old_state->legacy_cursor_update)
- return;
-
for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state,
new_crtc_state, i) {
if (!new_crtc_state->active)
continue;
@@ -2106,12 +2099,6 @@ int drm_atomic_helper_setup_commit(struct
drm_atomic_state *state,
continue;
}
- /* Legacy cursor updates are fully unsynced. */
- if (state->legacy_cursor_update) {
- complete_all(>flip_done);
- continue;
- }
-
if (!new_crtc_state->event) {
commit->event = kzalloc(sizeof(*commit->event),
GFP_KERNEL);
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v2 09/15] misc/mei/hdcp: Fix AUTH_STREAM_REQ cmd buffer len
> > On Tue, 20 Oct 2020, Anshuman Gupta wrote: > > Fix the size of WIRED_REPEATER_AUTH_STREAM_REQ cmd buffer size. > > It is based upon the actual number of MST streams and size of > > wired_cmd_repeater_auth_stream_req_in. > > Excluding the size of hdcp_cmd_header. > > > > Cc: Tomas Winkler > > Cc: Ramalingam C > > Signed-off-by: Anshuman Gupta > > Tomas, ack to merge this via drm-intel? I have no problem with merging it via drm-intel, just see a little nitpick bellow: > Thanks, > Jani. > > > --- > > drivers/misc/mei/hdcp/mei_hdcp.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c > > b/drivers/misc/mei/hdcp/mei_hdcp.c > > index 9ae9669e46ea..b10d266fb60a 100644 > > --- a/drivers/misc/mei/hdcp/mei_hdcp.c > > +++ b// > > @@ -569,8 +569,7 @@ static int mei_hdcp_verify_mprime(struct device > *dev, > > verify_mprime_in->header.api_version = HDCP_API_VERSION; > > verify_mprime_in->header.command_id = > WIRED_REPEATER_AUTH_STREAM_REQ; > > verify_mprime_in->header.status = ME_HDCP_STATUS_SUCCESS; > > - verify_mprime_in->header.buffer_len = > > - > WIRED_CMD_BUF_LEN_REPEATER_AUTH_STREAM_REQ_MIN_IN; > > + verify_mprime_in->header.buffer_len = cmd_size - sizeof(struct > > +hdcp_cmd_header); I believe the following annotation would be preferable: cmd_size - sizeof(verify_mprime_in->header) > > > > verify_mprime_in->port.integrated_port_type = data->port_type; > > verify_mprime_in->port.physical_port = (u8)data->fw_ddi; > > -- > Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: add client cap to expose low power modes
On Wed, 21 Oct 2020 at 16:58, Daniel Vetter wrote: > On Wed, Oct 21, 2020 at 4:59 PM Ken Huang wrote: > > It's useful in Android and other embedded devices to implement Always On > > Display (ex. showing clock faces with less than 15% OPR on screen). > > > > OPR (On Pixel Ratio) is the percentage of luminance amount over the display > > area. > > It's derived by gray levels of display image pattern and the backlight (or > > OLED) driving force (or current). > > ex: OPR=100% means a full white pattern with maximum backlight (or OLED) > > brightness, while full black would be OPR=0%. > > > > In userspace, when the client initializes, we can set capability via > > drmSetClientCap() to ask the display driver to expose the drm modes with > > DRM_MODE_FLAG_LOW_POWER flag. > > Userspace can check DRM_MODE_FLAG_LOW_POWER flag to know which modes can be > > used to consume the least amount of power during Always On Display. > > Ignoring modes with this flag set during normal operating mode. > > Hm I'm not really sure what this changes ... I think we need the > entire pile of patches: Userspace, driver, drm core, anything else. > Just adding this flag doesn't make much sense really, since I have no > idea what the semantics are. Even after you've explained the use-case. It makes sense to me: some modes are annotated with a 'low-power' flag, tucked away behind a client cap which makes clients opt in, and they can switch into the low-power mode (letting the display/panel save a lot of power) _if_ they only have at most 15% of pixels lit up. My worry is about the 15% though ... what happens when hardware allows up to 20%, or only allows 10%? If we can reuse the same modelines, then rather than create new modelines just for low-power modes, I'd rather create a client CRTC property specifying the number/percentages of pixels on the CRTC which are lit non-zero. That would give us more wriggle room to change the semantics, as well as redefine 'low power' in terms of monochrome/scaled/non-bright/etc modes. But it does make the switching-between-clients problem even worse than it already is. Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Give irq_by_busid drm_legacy_ prefix
On Thu, Oct 08, 2020 at 10:38:05AM -0400, Alex Deucher wrote:
> On Thu, Oct 8, 2020 at 10:29 AM Daniel Vetter wrote:
> >
> > It's the only ioctl handler purely for legacy drivers that didn't have
> > this yet.
> >
> > Signed-off-by: Daniel Vetter
>
> Reviewed-by: Alex Deucher
Thanks for reviewing, patch applied.
-Daniel
>
> > ---
> > drivers/gpu/drm/drm_internal.h | 8
> > drivers/gpu/drm/drm_ioctl.c| 2 +-
> > drivers/gpu/drm/drm_pci.c | 6 +++---
> > 3 files changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
> > index b65865c630b0..2bdac3557765 100644
> > --- a/drivers/gpu/drm/drm_internal.h
> > +++ b/drivers/gpu/drm/drm_internal.h
> > @@ -53,15 +53,15 @@ void drm_lastclose(struct drm_device *dev);
> > #ifdef CONFIG_PCI
> >
> > /* drm_pci.c */
> > -int drm_irq_by_busid(struct drm_device *dev, void *data,
> > -struct drm_file *file_priv);
> > +int drm_legacy_irq_by_busid(struct drm_device *dev, void *data,
> > + struct drm_file *file_priv);
> > void drm_pci_agp_destroy(struct drm_device *dev);
> > int drm_pci_set_busid(struct drm_device *dev, struct drm_master *master);
> >
> > #else
> >
> > -static inline int drm_irq_by_busid(struct drm_device *dev, void *data,
> > - struct drm_file *file_priv)
> > +static inline int drm_legacy_irq_by_busid(struct drm_device *dev, void
> > *data,
> > + struct drm_file *file_priv)
> > {
> > return -EINVAL;
> > }
> > diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> > index 87a44492957e..6def1621e32a 100644
> > --- a/drivers/gpu/drm/drm_ioctl.c
> > +++ b/drivers/gpu/drm/drm_ioctl.c
> > @@ -578,7 +578,7 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
> > DRM_IOCTL_DEF(DRM_IOCTL_VERSION, drm_version, DRM_RENDER_ALLOW),
> > DRM_IOCTL_DEF(DRM_IOCTL_GET_UNIQUE, drm_getunique, 0),
> > DRM_IOCTL_DEF(DRM_IOCTL_GET_MAGIC, drm_getmagic, 0),
> > - DRM_IOCTL_DEF(DRM_IOCTL_IRQ_BUSID, drm_irq_by_busid,
> > DRM_MASTER|DRM_ROOT_ONLY),
> > + DRM_IOCTL_DEF(DRM_IOCTL_IRQ_BUSID, drm_legacy_irq_by_busid,
> > DRM_MASTER|DRM_ROOT_ONLY),
> >
> > DRM_LEGACY_IOCTL_DEF(DRM_IOCTL_GET_MAP, drm_legacy_getmap_ioctl, 0),
> >
> > diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
> > index c250fb5a88ca..6dba4b8ce4fe 100644
> > --- a/drivers/gpu/drm/drm_pci.c
> > +++ b/drivers/gpu/drm/drm_pci.c
> > @@ -139,7 +139,7 @@ static int drm_pci_irq_by_busid(struct drm_device *dev,
> > struct drm_irq_busid *p)
> > }
> >
> > /**
> > - * drm_irq_by_busid - Get interrupt from bus ID
> > + * drm_legacy_irq_by_busid - Get interrupt from bus ID
> > * @dev: DRM device
> > * @data: IOCTL parameter pointing to a drm_irq_busid structure
> > * @file_priv: DRM file private.
> > @@ -150,8 +150,8 @@ static int drm_pci_irq_by_busid(struct drm_device *dev,
> > struct drm_irq_busid *p)
> > *
> > * Return: 0 on success or a negative error code on failure.
> > */
> > -int drm_irq_by_busid(struct drm_device *dev, void *data,
> > -struct drm_file *file_priv)
> > +int drm_legacy_irq_by_busid(struct drm_device *dev, void *data,
> > + struct drm_file *file_priv)
> > {
> > struct drm_irq_busid *p = data;
> >
> > --
> > 2.28.0
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: add client cap to expose low power modes
On Wed, Oct 21, 2020 at 4:59 PM Ken Huang wrote: > > Hi All, > > It's useful in Android and other embedded devices to implement Always On > Display (ex. showing clock faces with less than 15% OPR on screen). > > OPR (On Pixel Ratio) is the percentage of luminance amount over the display > area. > It's derived by gray levels of display image pattern and the backlight (or > OLED) driving force (or current). > ex: OPR=100% means a full white pattern with maximum backlight (or OLED) > brightness, while full black would be OPR=0%. > > In userspace, when the client initializes, we can set capability via > drmSetClientCap() to ask the display driver to expose the drm modes with > DRM_MODE_FLAG_LOW_POWER flag. > Userspace can check DRM_MODE_FLAG_LOW_POWER flag to know which modes can be > used to consume the least amount of power during Always On Display. > Ignoring modes with this flag set during normal operating mode. Hm I'm not really sure what this changes ... I think we need the entire pile of patches: Userspace, driver, drm core, anything else. Just adding this flag doesn't make much sense really, since I have no idea what the semantics are. Even after you've explained the use-case. Also for new kms uapi we need an igt testcase to exercise this and make sure it works. -Daniel > > Thanks, > Ken > > Daniel Vetter 於 2020年10月21日 週三 下午4:34寫道： >> >> On Wed, Oct 21, 2020 at 07:40:48AM +, Simon Ser wrote: >> > On Wednesday, October 21, 2020 8:54 AM, Ken Huang >> > wrote: >> > >> > > From: Adrian Salido sali...@google.com >> > > >> > > Some displays may support Low Power modes, however, these modes may >> > > require special handling as they would usually require lower OPR >> > > content on framebuffers. >> > >> > I'm not familiar with OPR. Can you explain what it is and what it means >> > for user-space? >> >> Also since this is new uapi, I guess best explanation would include the >> userspace code that makes sensible use of this. >> -Daniel >> -- >> Daniel Vetter >> Software Engineer, Intel Corporation >> http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 12/16] PCI: Obey iomem restrictions for procfs mmap
On Wed, Oct 21, 2020 at 5:13 PM Jason Gunthorpe wrote: > > On Wed, Oct 21, 2020 at 04:42:11PM +0200, Daniel Vetter wrote: > > > Uh yes. In drivers/gpu this isn't a problem because we only install > > ptes from the vm_ops->fault handler. So no races. And I don't think > > you can fix this otherwise through holding locks: mmap_sem we can't > > hold because before vma_link we don't even know which mm_struct is > > involved, so can't solve the race. Plus this would be worse that > > mm_take_all_locks used by mmu notifier. And the address_space > > i_mmap_lock is also no good since it's not held during the ->mmap > > callback, when we write the ptes. And the resource locks is even less > > useful, since we're not going to hold that at vma_link() time for > > sure. > > > > Hence delaying the pte writes after the vma_link, which means ->fault > > time, looks like the only way to close this gap. > > > Trouble is I have no idea how to do this cleanly ... > > How about add a vm_ops callback 'install_pages'/'prefault_pages' ? > > Call it after vm_link() - basically just move the remap_pfn, under > some other lock, into there. Yeah, I think that would be useful. This might also be useful for something entirely different: For legacy fbdev emulation on top of drm kernel modesetting drivers we need to track dirty pages of VM_IO mmaps. Right now that's a gross hack, and essentially we just pay the price for entirely separate storage and an additional memcpy when this is needed to emulate fbdev mmap on top of drm. But if we have install_ptes callback or similar we could just wrap the native vm_ops and add a mkwrite callback on top for that dirty tracking. For that the hook would need to be after vm_set_page_prot so that we write-protect the ptes by default, since that's where we compute vma_wants_writenotify(). That's also after vma_link, so one hook for two use-cases. The trouble is that io_remap_pfn adjust vma->pgoff, so we'd need to split that. So ideally ->mmap would never set up any ptes. I guess one option would be if remap_pfn_range would steal the vma->vm_ops pointer for itself, then it could set up the correct ->install_ptes hook. But there's tons of callers for that, so not sure that's a bright idea. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm: bridge: Propagate the bus flags from bridge->timings
On 16/10/2020 13:39, Nikhil Devshatwar wrote: > When the next bridge does not specify any bus flags, use the > bridge->timings->input_bus_flags as fallback when propagating > bus flags from next bridge to current bridge. > > Signed-off-by: Nikhil Devshatwar > --- > drivers/gpu/drm/drm_bridge.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c > index 64f0effb52ac..8353723323ab 100644 > --- a/drivers/gpu/drm/drm_bridge.c > +++ b/drivers/gpu/drm/drm_bridge.c > @@ -975,6 +975,13 @@ drm_atomic_bridge_propagate_bus_flags(struct drm_bridge > *bridge, >* duplicate the "dummy propagation" logic. >*/ > bridge_state->input_bus_cfg.flags = output_flags; > + > + /* > + * Use the bridge->timings->input_bus_flags as fallback if the next > bridge > + * does not specify the flags > + */ > + if (!bridge_state->input_bus_cfg.flags) > + bridge_state->input_bus_cfg.flags = > bridge->timings->input_bus_flags; According to docs, timings can be NULL. And, hmm... It's too easy to get confused with these, but... If the bridge defines timings, and timings->input_bus_flags != 0, should we always pick that, even if we got something via output_flags? Logic being, if this bridge defines timings->input_bus_flags, it probably wants that to be used regardless whether we got something from the next bridge. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: document that user-space should avoid parsing EDIDs
On 2020-10-21 10:35 a.m., Ville Syrjälä wrote:
On Tue, Oct 20, 2020 at 09:46:30PM -0400, Vitaly Prosyak wrote:
On 2020-10-20 11:04 a.m., Ville Syrjälä wrote:
On Mon, Oct 19, 2020 at 11:08:27PM -0400, Vitaly Prosyak wrote:
On 2020-10-19 3:49 a.m., Pekka Paalanen wrote:
On Fri, 16 Oct 2020 16:50:16 +0300
Ville Syrjälä wrote:
On Mon, Oct 12, 2020 at 10:11:01AM +0300, Pekka Paalanen wrote:
On Fri, 9 Oct 2020 17:20:18 +0300
Ville Syrjälä wrote:
There is a slight snag on some Intel platforms that the gamma LUT
is sitting after the CSC unit, and currently we use the CSC for
the range compression.
Thanks a lot for letting us to know about this!
AMD display pipe has always at the end CSC matrix where we apply appropriate
range conversion if necessary.
On glk in particular I*think* we currently just do the wrong
thing do the range compression before gamma. The same probably
applies to hsw+ when both gamma and degamma are used at the same
time. But that is clearly buggy, and we should fix it to either:
a) return an error, which isn't super awesome since then you
can't do gamma+limited range at the same time on glk, nor
gamma+degamma+limited range on hsw+.
b) for the glk case we could use the hw degamma LUT for the
gamma, which isn't great becasue the hw gamma and degamma
LUTs are quite different beasts, and so the hw degamma LUT
might not be able to do exactly what we need.
Do you mean that hw de-gamma LUT build on ROM ( it is not programmable, just
select the proper bit)?
No. The hw degamma LUT is a 1x33 linearly interpolated
non-decreasing curve. So can't do directcolor type stuff,
and each RGB channel must have the same gamma.
The hw gamma LUT on the other hand can operate in multiple
different modes, from which we currently choose the
3x1024 non-interpoated mode. Which can do all those
things the degamma LUT can't do.
On hsw+ we do
use this trick already to get the gamma+limited range right,
but on these platforms the hw gamma and degamma LUTs have
identical capabilities.
c) do the range compression with the hw gamma LUT instead, which
of course means we have to combine the user gamma and range
compression into the same gamma LUT.
Nice w/a and in amdgpu we are using also curve concatenations into re gamma LUT.
The number of concatenations could be as many as need it and we may take
advantage of this in user mode. Does this sounds preliminarily good?
Wouldn't the following sentence be interesting for you if the user mode
generates 1D LUT points using X axis exponential distribution to avoid
unnecessary interpolation in kernel? It may be especially important if curve
concatenation is expected?
Yeah, I think we want a new uapi for gamma stuff that will allow
userspace to properly calculate things up front for different kinds
of hw implementations, without the kernel having to interpolate/decimate.
We've had some discussions/proposals on the list.
So I think c) is what it should be. Would just need to find the time
to implement it, and figure out how to not totally mess up our
driver's hw state checker. Hmm, except this won't help at all
with YCbCr output since we need to apply gamma before the
RGB->YCbCr conversion (which uses the same CSC again). Argh.
So YCbCr output would still need option b).
Thankfully icl+ fixed all this by adding a dedicated output CSC
unit which sits after the gamma LUT in the pipeline. And pre-hsw
is almost fine as well since the hw has a dedicated fixed function
thing for the range compression. So the only snag on pre-hsw
is the YCbCr+degamma+gamma case.
Where is the display engine scaler is located on Intel platforms?
AMD old ASIC's have a display scaler after display color pipeline ,so the whole
color processing can be a bit mess up unless integer scaling is in use.
The new ASIC's ( ~5 years already) have scaler before color pipeline.
We have a somewhat similar situation.
On older hw the scaler tap point is at the end of the pipe, so
between the gamma LUT and dithering.
On icl+ I think we have two tap points; one between degamma
LUT and the first pipe CSC, and a second one between the output
CSC and dithering. The spec calls these non-linear and linear tap
points. The scaler also gained another linear vs. non-linear
control knob which affects the precision at which it can operate
in some form. There's also some other interaction between this and
another knob ("HDR" mode) which controls the precision of blending
in the pipe. I haven't yet thought how we should configure all this
to the best effect. For the moment we leave these scaler settings
to their defaults, which means using the non-linear tap point and
non-linear precision setting. The blending precision we adjust
dynamically depending on which planes are enabled. Only a subset
of the planes (so called HDR planes) can be enabled when using the
high precision blending mode.
On icl+ plane scaling also has the two different tap
Re: [PATCH v3 12/16] PCI: Obey iomem restrictions for procfs mmap
On Wed, Oct 21, 2020 at 2:50 PM Jason Gunthorpe wrote:
>
> On Wed, Oct 21, 2020 at 10:56:51AM +0200, Daniel Vetter wrote:
> > There's three ways to access PCI BARs from userspace: /dev/mem, sysfs
> > files, and the old proc interface. Two check against
> > iomem_is_exclusive, proc never did. And with CONFIG_IO_STRICT_DEVMEM,
> > this starts to matter, since we don't want random userspace having
> > access to PCI BARs while a driver is loaded and using it.
> >
> > Fix this by adding the same iomem_is_exclusive() check we already have
> > on the sysfs side in pci_mmap_resource().
> >
> > References: 90a545e98126 ("restrict /dev/mem to idle io memory ranges")
> > Signed-off-by: Daniel Vetter
> > Cc: Jason Gunthorpe
> > Cc: Kees Cook
> > Cc: Dan Williams
> > Cc: Andrew Morton
> > Cc: John Hubbard
> > Cc: Jérôme Glisse
> > Cc: Jan Kara
> > Cc: Dan Williams
> > Cc: linux...@kvack.org
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-samsung-...@vger.kernel.org
> > Cc: linux-me...@vger.kernel.org
> > Cc: Bjorn Helgaas
> > Cc: linux-...@vger.kernel.org
> > Signed-off-by: Daniel Vetter
>
> Maybe not for fixing in this series, but this access to
> IORESOURCE_BUSY doesn't have any locking.
>
> The write side holds the resource_lock at least..
>
> > ret = pci_mmap_page_range(dev, i, vma,
> > fpriv->mmap_state, write_combine);
>
> At this point the vma isn't linked into the address space, so doesn't
> this happen?
>
> CPU 0 CPU1
> mmap_region()
>vma = vm_area_alloc
>proc_bus_pci_mmap
> iomem_is_exclusive
> pci_mmap_page_range
> revoke_devmem
> unmap_mapping_range()
> // vma is not linked to the address space here,
> // unmap doesn't find it
> vma_link()
> !!! The VMA gets mapped with the revoked PTEs
>
> I couldn't find anything that prevents it at least, no mmap_sem on the
> unmap side, just the i_mmap_lock
>
> Not seeing how address space and pre-populating during mmap work
> together? Did I miss locking someplace?
>
> Not something to be fixed for this series, this is clearly an
> improvement, but seems like another problem to tackle?
Uh yes. In drivers/gpu this isn't a problem because we only install
ptes from the vm_ops->fault handler. So no races. And I don't think
you can fix this otherwise through holding locks: mmap_sem we can't
hold because before vma_link we don't even know which mm_struct is
involved, so can't solve the race. Plus this would be worse that
mm_take_all_locks used by mmu notifier. And the address_space
i_mmap_lock is also no good since it's not held during the ->mmap
callback, when we write the ptes. And the resource locks is even less
useful, since we're not going to hold that at vma_link() time for
sure.
Hence delaying the pte writes after the vma_link, which means ->fault
time, looks like the only way to close this gap.
Trouble is I have no idea how to do this cleanly ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: document that user-space should avoid parsing EDIDs
On Tue, Oct 20, 2020 at 09:46:30PM -0400, Vitaly Prosyak wrote:
>
> On 2020-10-20 11:04 a.m., Ville Syrjälä wrote:
> > On Mon, Oct 19, 2020 at 11:08:27PM -0400, Vitaly Prosyak wrote:
> >> On 2020-10-19 3:49 a.m., Pekka Paalanen wrote:
> >>> On Fri, 16 Oct 2020 16:50:16 +0300
> >>> Ville Syrjälä wrote:
> >>>
> On Mon, Oct 12, 2020 at 10:11:01AM +0300, Pekka Paalanen wrote:
> > On Fri, 9 Oct 2020 17:20:18 +0300
> > Ville Syrjälä wrote:
> >
> There is a slight snag on some Intel platforms that the gamma LUT
> is sitting after the CSC unit, and currently we use the CSC for
> the range compression.
> >> Thanks a lot for letting us to know about this!
> >> AMD display pipe has always at the end CSC matrix where we apply
> >> appropriate range conversion if necessary.
> >>
> On glk in particular I*think* we currently just do the wrong
> thing do the range compression before gamma. The same probably
> applies to hsw+ when both gamma and degamma are used at the same
> time. But that is clearly buggy, and we should fix it to either:
> a) return an error, which isn't super awesome since then you
> can't do gamma+limited range at the same time on glk, nor
> gamma+degamma+limited range on hsw+.
> b) for the glk case we could use the hw degamma LUT for the
> gamma, which isn't great becasue the hw gamma and degamma
> LUTs are quite different beasts, and so the hw degamma LUT
> might not be able to do exactly what we need.
> >> Do you mean that hw de-gamma LUT build on ROM ( it is not programmable,
> >> just select the proper bit)?
> > No. The hw degamma LUT is a 1x33 linearly interpolated
> > non-decreasing curve. So can't do directcolor type stuff,
> > and each RGB channel must have the same gamma.
> >
> > The hw gamma LUT on the other hand can operate in multiple
> > different modes, from which we currently choose the
> > 3x1024 non-interpoated mode. Which can do all those
> > things the degamma LUT can't do.
> >
> On hsw+ we do
> use this trick already to get the gamma+limited range right,
> but on these platforms the hw gamma and degamma LUTs have
> identical capabilities.
> c) do the range compression with the hw gamma LUT instead, which
> of course means we have to combine the user gamma and range
> compression into the same gamma LUT.
> >> Nice w/a and in amdgpu we are using also curve concatenations into re
> >> gamma LUT.
> >>
> >> The number of concatenations could be as many as need it and we may take
> >> advantage of this in user mode. Does this sounds preliminarily good?
> >>
> >> Wouldn't the following sentence be interesting for you if the user mode
> >> generates 1D LUT points using X axis exponential distribution to avoid
> >> unnecessary interpolation in kernel? It may be especially important if
> >> curve concatenation is expected?
> > Yeah, I think we want a new uapi for gamma stuff that will allow
> > userspace to properly calculate things up front for different kinds
> > of hw implementations, without the kernel having to interpolate/decimate.
> > We've had some discussions/proposals on the list.
> >
> So I think c) is what it should be. Would just need to find the time
> to implement it, and figure out how to not totally mess up our
> driver's hw state checker. Hmm, except this won't help at all
> with YCbCr output since we need to apply gamma before the
> RGB->YCbCr conversion (which uses the same CSC again). Argh.
> So YCbCr output would still need option b).
>
> Thankfully icl+ fixed all this by adding a dedicated output CSC
> unit which sits after the gamma LUT in the pipeline. And pre-hsw
> is almost fine as well since the hw has a dedicated fixed function
> thing for the range compression. So the only snag on pre-hsw
> is the YCbCr+degamma+gamma case.
> >> Where is the display engine scaler is located on Intel platforms?
> >> AMD old ASIC's have a display scaler after display color pipeline ,so the
> >> whole color processing can be a bit mess up unless integer scaling is in
> >> use.
> >>
> >> The new ASIC's ( ~5 years already) have scaler before color pipeline.
> > We have a somewhat similar situation.
> >
> > On older hw the scaler tap point is at the end of the pipe, so
> > between the gamma LUT and dithering.
> >
> > On icl+ I think we have two tap points; one between degamma
> > LUT and the first pipe CSC, and a second one between the output
> > CSC and dithering. The spec calls these non-linear and linear tap
> > points. The scaler also gained another linear vs. non-linear
> > control knob which affects the precision at which it can operate
> > in some form. There's also some other interaction between this and
> > another knob ("HDR" mode) which controls the precision of blending
> > in the pipe. I haven't yet thought how we should configure
Re: [PATCH v3 08/16] s390/pci: Remove races against pte updates
On Wed, Oct 21, 2020 at 11:38 AM Niklas Schnelle wrote:
>
>
>
> On 10/21/20 10:56 AM, Daniel Vetter wrote:
> > Way back it was a reasonable assumptions that iomem mappings never
> > change the pfn range they point at. But this has changed:
> >
> > - gpu drivers dynamically manage their memory nowadays, invalidating
> > ptes with unmap_mapping_range when buffers get moved
> >
> > - contiguous dma allocations have moved from dedicated carvetouts to
> > cma regions. This means if we miss the unmap the pfn might contain
> > pagecache or anon memory (well anything allocated with GFP_MOVEABLE)
> >
> > - even /dev/mem now invalidates mappings when the kernel requests that
> > iomem region when CONFIG_IO_STRICT_DEVMEM is set, see commit
> > 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims the
> > region")
> >
> > Accessing pfns obtained from ptes without holding all the locks is
> > therefore no longer a good idea. Fix this.
> >
> > Since zpci_memcpy_from|toio seems to not do anything nefarious with
> > locks we just need to open code get_pfn and follow_pfn and make sure
> > we drop the locks only after we're done. The write function also needs
> > the copy_from_user move, since we can't take userspace faults while
> > holding the mmap sem.
> >
> > v2: Move VM_IO | VM_PFNMAP checks around so they keep returning EINVAL
> > like before (Gerard)
> >
> > v3: Polish commit message (Niklas)
> >
> > Reviewed-by: Gerald Schaefer
> > Signed-off-by: Daniel Vetter
> > Cc: Jason Gunthorpe
> > Cc: Dan Williams
> > Cc: Kees Cook
> > Cc: Andrew Morton
> > Cc: John Hubbard
> > Cc: Jérôme Glisse
> > Cc: Jan Kara
> > Cc: linux...@kvack.org
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-samsung-...@vger.kernel.org
> > Cc: linux-me...@vger.kernel.org
> > Cc: Niklas Schnelle
> > Cc: Gerald Schaefer
> > Cc: linux-s...@vger.kernel.org
> > Cc: Niklas Schnelle
> > Signed-off-by: Daniel Vetter
>
> This should be ".ch", but since this is clearly a typo and you also send from
> @ffwll.ch,
> I took the liberty and fixed it for this commit and applied your patch to our
> internal
> branch, Heiko or Vasily will then pick it up for the s390 tree.
Uh yes, and I've copypasted this to all patches :-/
Thanks for picking this up, I'll drop it here from my series.
Cheers, Daniel
>
> Thanks!
>
> > ---
> > arch/s390/pci/pci_mmio.c | 98 +++-
> > 1 file changed, 57 insertions(+), 41 deletions(-)
> >
> > diff --git a/arch/s390/pci/pci_mmio.c b/arch/s390/pci/pci_mmio.c
> > index 401cf670a243..1a6adbc68ee8 100644
> > --- a/arch/s390/pci/pci_mmio.c
> > +++ b/arch/s390/pci/pci_mmio.c
> > @@ -119,33 +119,15 @@ static inline int __memcpy_toio_inuser(void __iomem
> > *dst,
> > return rc;
> > }
> >
> > -static long get_pfn(unsigned long user_addr, unsigned long access,
> > - unsigned long *pfn)
> > -{
> > - struct vm_area_struct *vma;
> > - long ret;
> > -
> > - mmap_read_lock(current->mm);
> > - ret = -EINVAL;
> > - vma = find_vma(current->mm, user_addr);
> > - if (!vma)
> > - goto out;
> > - ret = -EACCES;
> > - if (!(vma->vm_flags & access))
> > - goto out;
> > - ret = follow_pfn(vma, user_addr, pfn);
> > -out:
> > - mmap_read_unlock(current->mm);
> > - return ret;
> > -}
> > -
> > SYSCALL_DEFINE3(s390_pci_mmio_write, unsigned long, mmio_addr,
> > const void __user *, user_buffer, size_t, length)
> > {
> > u8 local_buf[64];
> > void __iomem *io_addr;
> > void *buf;
> > - unsigned long pfn;
> > + struct vm_area_struct *vma;
> > + pte_t *ptep;
> > + spinlock_t *ptl;
> > long ret;
> >
> > if (!zpci_is_enabled())
> > @@ -158,7 +140,7 @@ SYSCALL_DEFINE3(s390_pci_mmio_write, unsigned long,
> > mmio_addr,
> >* We only support write access to MIO capable devices if we are on
> >* a MIO enabled system. Otherwise we would have to check for every
> >* address if it is a special ZPCI_ADDR and would have to do
> > - * a get_pfn() which we don't need for MIO capable devices. Currently
> > + * a pfn lookup which we don't need for MIO capable devices.
> > Currently
> >* ISM devices are the only devices without MIO support and there is
> > no
> >* known need for accessing these from userspace.
> >*/
> > @@ -176,21 +158,37 @@ SYSCALL_DEFINE3(s390_pci_mmio_write, unsigned long,
> > mmio_addr,
> > } else
> > buf = local_buf;
> >
> > - ret = get_pfn(mmio_addr, VM_WRITE, );
> > + ret = -EFAULT;
> > + if (copy_from_user(buf, user_buffer, length))
> > + goto out_free;
> > +
> > + mmap_read_lock(current->mm);
> > + ret = -EINVAL;
> > + vma = find_vma(current->mm, mmio_addr);
> > + if (!vma)
> > + goto out_unlock_mmap;
> > + if (!(vma->vm_flags & (VM_IO |
[PATCH 3/3] drm/udl: Store USB device in struct drm_device.udev
Drop the driver's udev field in favor of the one in struct drm_device. No
functional changes made.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/udl/udl_connector.c | 8
drivers/gpu/drm/udl/udl_drv.c | 2 +-
drivers/gpu/drm/udl/udl_drv.h | 1 -
drivers/gpu/drm/udl/udl_main.c | 15 ---
4 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_connector.c
b/drivers/gpu/drm/udl/udl_connector.c
index cdc1c42e1669..b86e75d76c5a 100644
--- a/drivers/gpu/drm/udl/udl_connector.c
+++ b/drivers/gpu/drm/udl/udl_connector.c
@@ -20,6 +20,7 @@ static int udl_get_edid_block(void *data, u8 *buf, unsigned
int block,
int ret, i;
u8 *read_buff;
struct udl_device *udl = data;
+ struct usb_device *udev = udl->drm.udev;
read_buff = kmalloc(2, GFP_KERNEL);
if (!read_buff)
@@ -27,10 +28,9 @@ static int udl_get_edid_block(void *data, u8 *buf, unsigned
int block,
for (i = 0; i < len; i++) {
int bval = (i + block * EDID_LENGTH) << 8;
- ret = usb_control_msg(udl->udev,
- usb_rcvctrlpipe(udl->udev, 0),
- (0x02), (0x80 | (0x02 << 5)), bval,
- 0xA1, read_buff, 2, HZ);
+ ret = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
+ 0x02, (0x80 | (0x02 << 5)), bval,
+ 0xA1, read_buff, 2, HZ);
if (ret < 1) {
DRM_ERROR("Read EDID byte %d failed err %x\n", i, ret);
kfree(read_buff);
diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
index 96d4317a2c1b..0aca9a3221ab 100644
--- a/drivers/gpu/drm/udl/udl_drv.c
+++ b/drivers/gpu/drm/udl/udl_drv.c
@@ -62,7 +62,7 @@ static struct udl_device *udl_driver_create(struct
usb_interface *interface)
if (IS_ERR(udl))
return udl;
- udl->udev = udev;
+ udl->drm.udev = udev;
r = udl_init(udl);
if (r)
diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
index b1461f30780b..889bfa21deb0 100644
--- a/drivers/gpu/drm/udl/udl_drv.h
+++ b/drivers/gpu/drm/udl/udl_drv.h
@@ -50,7 +50,6 @@ struct urb_list {
struct udl_device {
struct drm_device drm;
struct device *dev;
- struct usb_device *udev;
struct drm_simple_display_pipe display_pipe;
diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index f5d27f2a5654..f2ef5b169523 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -98,19 +98,19 @@ static int udl_parse_vendor_descriptor(struct drm_device
*dev,
*/
static int udl_select_std_channel(struct udl_device *udl)
{
- int ret;
static const u8 set_def_chn[] = {0x57, 0xCD, 0xDC, 0xA7,
0x1C, 0x88, 0x5E, 0x15,
0x60, 0xFE, 0xC6, 0x97,
0x16, 0x3D, 0x47, 0xF2};
+ struct usb_device *udev = udl->drm.udev;
void *sendbuf;
+ int ret;
sendbuf = kmemdup(set_def_chn, sizeof(set_def_chn), GFP_KERNEL);
if (!sendbuf)
return -ENOMEM;
- ret = usb_control_msg(udl->udev,
- usb_sndctrlpipe(udl->udev, 0),
+ ret = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
NR_USB_REQUEST_CHANNEL,
(USB_DIR_OUT | USB_TYPE_VENDOR), 0, 0,
sendbuf, sizeof(set_def_chn),
@@ -198,6 +198,7 @@ static void udl_free_urb_list(struct drm_device *dev)
static int udl_alloc_urb_list(struct drm_device *dev, int count, size_t size)
{
struct udl_device *udl = to_udl(dev);
+ struct usb_device *udev = udl->drm.udev;
struct urb *urb;
struct urb_node *unode;
char *buf;
@@ -229,7 +230,7 @@ static int udl_alloc_urb_list(struct drm_device *dev, int
count, size_t size)
}
unode->urb = urb;
- buf = usb_alloc_coherent(udl->udev, size, GFP_KERNEL,
+ buf = usb_alloc_coherent(udev, size, GFP_KERNEL,
>transfer_dma);
if (!buf) {
kfree(unode);
@@ -243,8 +244,8 @@ static int udl_alloc_urb_list(struct drm_device *dev, int
count, size_t size)
}
/* urb->transfer_buffer_length set to actual before submit */
- usb_fill_bulk_urb(urb, udl->udev, usb_sndbulkpipe(udl->udev, 1),
- buf, size, udl_urb_completion, unode);
+ usb_fill_bulk_urb(urb, udev, usb_sndbulkpipe(udev, 1),
+ buf, size, udl_urb_completion, unode);
urb->transfer_flags |=
[PATCH 2/3] drm/tiny/gm12u320: Store USB device in struct drm_device.udev
Drop the driver's udev field in favor of the one in struct drm_device. No
functional changes made.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/gm12u320.c | 52 +++--
1 file changed, 24 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/tiny/gm12u320.c b/drivers/gpu/drm/tiny/gm12u320.c
index cc397671f689..7d98906b3d59 100644
--- a/drivers/gpu/drm/tiny/gm12u320.c
+++ b/drivers/gpu/drm/tiny/gm12u320.c
@@ -45,7 +45,7 @@ MODULE_PARM_DESC(eco_mode, "Turn on Eco mode (less bright,
more silent)");
#define GM12U320_BLOCK_COUNT 20
#define GM12U320_ERR(fmt, ...) \
- DRM_DEV_ERROR(>udev->dev, fmt, ##__VA_ARGS__)
+ DRM_DEV_ERROR(>dev.udev->dev, fmt, ##__VA_ARGS__)
#define MISC_RCV_EPT 1
#define DATA_RCV_EPT 2
@@ -85,7 +85,6 @@ struct gm12u320_device {
struct drm_devicedev;
struct drm_simple_display_pipe pipe;
struct drm_connector conn;
- struct usb_device *udev;
unsigned char *cmd_buf;
unsigned char *data_buf[GM12U320_BLOCK_COUNT];
struct {
@@ -191,6 +190,7 @@ static int gm12u320_misc_request(struct gm12u320_device
*gm12u320,
u8 req_a, u8 req_b,
u8 arg_a, u8 arg_b, u8 arg_c, u8 arg_d)
{
+ struct usb_device *udev = gm12u320->dev.udev;
int ret, len;
memcpy(gm12u320->cmd_buf, _misc, CMD_SIZE);
@@ -202,8 +202,7 @@ static int gm12u320_misc_request(struct gm12u320_device
*gm12u320,
gm12u320->cmd_buf[25] = arg_d;
/* Send request */
- ret = usb_bulk_msg(gm12u320->udev,
- usb_sndbulkpipe(gm12u320->udev, MISC_SND_EPT),
+ ret = usb_bulk_msg(udev, usb_sndbulkpipe(udev, MISC_SND_EPT),
gm12u320->cmd_buf, CMD_SIZE, , CMD_TIMEOUT);
if (ret || len != CMD_SIZE) {
GM12U320_ERR("Misc. req. error %d\n", ret);
@@ -211,8 +210,7 @@ static int gm12u320_misc_request(struct gm12u320_device
*gm12u320,
}
/* Read value */
- ret = usb_bulk_msg(gm12u320->udev,
- usb_rcvbulkpipe(gm12u320->udev, MISC_RCV_EPT),
+ ret = usb_bulk_msg(udev, usb_rcvbulkpipe(udev, MISC_RCV_EPT),
gm12u320->cmd_buf, MISC_VALUE_SIZE, ,
DATA_TIMEOUT);
if (ret || len != MISC_VALUE_SIZE) {
@@ -222,8 +220,7 @@ static int gm12u320_misc_request(struct gm12u320_device
*gm12u320,
/* cmd_buf[0] now contains the read value, which we don't use */
/* Read status */
- ret = usb_bulk_msg(gm12u320->udev,
- usb_rcvbulkpipe(gm12u320->udev, MISC_RCV_EPT),
+ ret = usb_bulk_msg(udev, usb_rcvbulkpipe(udev, MISC_RCV_EPT),
gm12u320->cmd_buf, READ_STATUS_SIZE, ,
CMD_TIMEOUT);
if (ret || len != READ_STATUS_SIZE) {
@@ -331,6 +328,7 @@ static void gm12u320_fb_update_work(struct work_struct
*work)
struct gm12u320_device *gm12u320 =
container_of(to_delayed_work(work), struct gm12u320_device,
fb_update.work);
+ struct usb_device *udev = gm12u320->dev.udev;
int block, block_size, len;
int ret = 0;
@@ -350,43 +348,41 @@ static void gm12u320_fb_update_work(struct work_struct
*work)
gm12u320->cmd_buf[21] =
block | (gm12u320->fb_update.frame << 7);
- ret = usb_bulk_msg(gm12u320->udev,
- usb_sndbulkpipe(gm12u320->udev, DATA_SND_EPT),
- gm12u320->cmd_buf, CMD_SIZE, ,
- CMD_TIMEOUT);
+ ret = usb_bulk_msg(udev,
+ usb_sndbulkpipe(udev, DATA_SND_EPT),
+ gm12u320->cmd_buf, CMD_SIZE, ,
+ CMD_TIMEOUT);
if (ret || len != CMD_SIZE)
goto err;
/* Send data block to device */
- ret = usb_bulk_msg(gm12u320->udev,
- usb_sndbulkpipe(gm12u320->udev, DATA_SND_EPT),
- gm12u320->data_buf[block], block_size,
- , DATA_TIMEOUT);
+ ret = usb_bulk_msg(udev,
+ usb_sndbulkpipe(udev, DATA_SND_EPT),
+ gm12u320->data_buf[block], block_size,
+ , DATA_TIMEOUT);
if (ret || len != block_size)
goto err;
/* Read status */
- ret = usb_bulk_msg(gm12u320->udev,
- usb_rcvbulkpipe(gm12u320->udev, DATA_RCV_EPT),
- gm12u320->cmd_buf, READ_STATUS_SIZE, ,
- CMD_TIMEOUT);
+
[PATCH 1/3] drm: Add reference to USB device to struct drm_device
We have DRM drivers that operate on USB devices. So far they had
to store a pointer to the USB device structure. Move the reference
into struct drm_device. Putting the USB device into a union with
the PCI data saves a few bytes. Both should mutually exclusive.
Signed-off-by: Thomas Zimmermann
---
include/drm/drm_device.h | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
index f4f68e7a9149..9871fcabd720 100644
--- a/include/drm/drm_device.h
+++ b/include/drm/drm_device.h
@@ -25,6 +25,7 @@ struct inode;
struct pci_dev;
struct pci_controller;
+struct usb_device;
/**
* enum drm_switch_power - power state of drm device
@@ -283,16 +284,24 @@ struct drm_device {
*/
spinlock_t event_lock;
- /** @agp: AGP data */
- struct drm_agp_head *agp;
+ union {
+ struct {
+ /** @agp: AGP data */
+ struct drm_agp_head *agp;
- /** @pdev: PCI device structure */
- struct pci_dev *pdev;
+ /** @pdev: PCI device structure */
+ struct pci_dev *pdev;
#ifdef __alpha__
- /** @hose: PCI hose, only used on ALPHA platforms. */
- struct pci_controller *hose;
+ /** @hose: PCI hose, only used on ALPHA platforms. */
+ struct pci_controller *hose;
#endif
+ };
+
+ /** @udev: USB device structure */
+ struct usb_device *udev;
+ };
+
/** @num_crtcs: Number of CRTCs on this device */
unsigned int num_crtcs;
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] drm: Store USB device in struct drm_device
The drivers gm12u320 and udl operate on USB devices. They leave the PCI device in struct drm_device empty and store the USB device in their own driver structure. Fix this special case and save a few bytes by putting the USB device into an anonymous union with the PCI data. It's expected that DRM core and helpers only touch the PCI-device field for actual PCI devices. Thomas Zimmermann (3): drm: Add reference to USB device to struct drm_device drm/tiny/gm12u320: Store USB device in struct drm_device.udev drm/udl: Store USB device in struct drm_device.udev drivers/gpu/drm/tiny/gm12u320.c | 52 + drivers/gpu/drm/udl/udl_connector.c | 8 ++--- drivers/gpu/drm/udl/udl_drv.c | 2 +- drivers/gpu/drm/udl/udl_drv.h | 1 - drivers/gpu/drm/udl/udl_main.c | 15 + include/drm/drm_device.h| 21 6 files changed, 52 insertions(+), 47 deletions(-) -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 203339] AMDGPU: virtual_display disables physical outputs
https://bugzilla.kernel.org/show_bug.cgi?id=203339 --- Comment #5 from Alex Deucher (alexdeuc...@gmail.com) --- (In reply to vita.am...@gmail.com from comment #4) > But what if i need virtual display in order to use it as a second monitor > via vnc? There is no way... Patches welcomed. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/6] Documentation build fixes against upstream
As we're close to the end of the merge window for Kernel 5.10, this series contain the patches from the past two documentation fix series I sent during the merge window and that required more work. It is based on the top of upstream. The full series with the patches that either didn't generate any reply or have been acked is on this branch: https://git.linuxtv.org/mchehab/experimental.git/log/?h=docs_for_v5.10 There are a couple of warnings that aren't addressed here, because they don't show at linux-next. I'm keeping a second patch series against next-20201021 fixing additional warnings caused by patches pending merges. I'll be posting those in separate. Regards, Mauro Mauro Carvalho Chehab (6): drm: amdgpu: kernel-doc: update some adev parameters docs: lockdep-design: fix some warning issues locking/refcount: move kernel-doc markups to the proper place IB/srpt: docs: add a description for cq_size member kunit: test: fix remaining kernel-doc warnings docs: fs: api-summary.rst: get rid of kernel-doc include Documentation/filesystems/api-summary.rst| 3 - Documentation/locking/lockdep-design.rst | 51 +++--- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 28 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 7 +- drivers/infiniband/ulp/srpt/ib_srpt.h| 1 + include/kunit/test.h | 16 +- include/linux/refcount.h | 158 +-- 8 files changed, 139 insertions(+), 131 deletions(-) -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/6] drm: amdgpu: kernel-doc: update some adev parameters
Running "make htmldocs: produce lots of warnings on those files: ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:177: warning: Excess function parameter 'man' description in 'amdgpu_vram_mgr_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:177: warning: Excess function parameter 'p_size' description in 'amdgpu_vram_mgr_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:211: warning: Excess function parameter 'man' description in 'amdgpu_vram_mgr_fini' ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:177: warning: Excess function parameter 'man' description in 'amdgpu_vram_mgr_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:177: warning: Excess function parameter 'p_size' description in 'amdgpu_vram_mgr_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:211: warning: Excess function parameter 'man' description in 'amdgpu_vram_mgr_fini' ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:177: warning: Excess function parameter 'man' description in 'amdgpu_vram_mgr_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:177: warning: Excess function parameter 'p_size' description in 'amdgpu_vram_mgr_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:211: warning: Excess function parameter 'man' description in 'amdgpu_vram_mgr_fini' ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:177: warning: Excess function parameter 'man' description in 'amdgpu_vram_mgr_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:177: warning: Excess function parameter 'p_size' description in 'amdgpu_vram_mgr_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:211: warning: Excess function parameter 'man' description in 'amdgpu_vram_mgr_fini' ./drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c:90: warning: Excess function parameter 'man' description in 'amdgpu_gtt_mgr_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c:90: warning: Excess function parameter 'p_size' description in 'amdgpu_gtt_mgr_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c:134: warning: Excess function parameter 'man' description in 'amdgpu_gtt_mgr_fini' ./drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c:90: warning: Excess function parameter 'man' description in 'amdgpu_gtt_mgr_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c:90: warning: Excess function parameter 'p_size' description in 'amdgpu_gtt_mgr_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c:134: warning: Excess function parameter 'man' description in 'amdgpu_gtt_mgr_fini' ./drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:675: warning: Excess function parameter 'dev' description in 'amdgpu_device_asic_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:675: warning: Excess function parameter 'dev' description in 'amdgpu_device_asic_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:675: warning: Excess function parameter 'dev' description in 'amdgpu_device_asic_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:675: warning: Excess function parameter 'dev' description in 'amdgpu_device_asic_init' They're related to the repacement of some parameters by adev, and due to a few renamed parameters. While here, uniform the name of the parameter for it to be the same on all functions using a pointer to struct amdgpu_device. Update the kernel-doc documentation accordingly. Signed-off-by: Mauro Carvalho Chehab --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 28 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 6 ++--- drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 7 +++-- 3 files changed, 20 insertions(+), 21 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index e8b41756c9f9..f8785bdec79c 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -705,7 +705,7 @@ void amdgpu_device_indirect_wreg64(struct amdgpu_device *adev, /** * amdgpu_invalid_rreg - dummy reg read function * - * @adev: amdgpu device pointer + * @adev: amdgpu_device pointer * @reg: offset of register * * Dummy register read function. Used for register blocks @@ -722,7 +722,7 @@ static uint32_t amdgpu_invalid_rreg(struct amdgpu_device *adev, uint32_t reg) /** * amdgpu_invalid_wreg - dummy reg write function * - * @adev: amdgpu device pointer + * @adev: amdgpu_device pointer * @reg: offset of register * @v: value to write to the register * @@ -739,7 +739,7 @@ static void amdgpu_invalid_wreg(struct amdgpu_device *adev, uint32_t reg, uint32 /** * amdgpu_invalid_rreg64 - dummy 64 bit reg read function * - * @adev: amdgpu device pointer + * @adev: amdgpu_device pointer * @reg: offset of register * * Dummy register read function. Used for register blocks @@ -756,7 +756,7 @@ static uint64_t amdgpu_invalid_rreg64(struct amdgpu_device *adev, uint32_t reg) /** *
[PATCH] video/fbdev/core: Mark debug-only variable as __maybe_unused
Compiling fbcon.c gives
../drivers/video/fbdev/core/fbcon.c: In function 'fbcon_exit':
../drivers/video/fbdev/core/fbcon.c:3358:7: warning: variable 'pending' set but
not used [-Wunused-but-set-variable]
3358 | int pending = 0;
| ^~~
The variable pending is only used for fbcon debugging. It's unused
otherwise. Mark it accordingly.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/core/fbcon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index d03f62369734..aca1512b6e86 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -3355,7 +3355,7 @@ static void fbcon_exit(void)
#endif
for_each_registered_fb(i) {
- int pending = 0;
+ int __maybe_unused pending = 0;
mapped = 0;
info = registered_fb[i];
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drivers/video: Fix -Wstringop-truncation in hdmi.c
Trying to copy into the string fields with strncpy() gives a warning from
gcc. Both fields are part of a packed HDMI header and do not require a
terminating \0 character.
../drivers/video/hdmi.c: In function 'hdmi_spd_infoframe_init':
../drivers/video/hdmi.c:230:2: warning: 'strncpy' specified bound 8 equals
destination size [-Wstringop-truncation]
230 | strncpy(frame->vendor, vendor, sizeof(frame->vendor));
| ^
../drivers/video/hdmi.c:231:2: warning: 'strncpy' specified bound 16 equals
destination size [-Wstringop-truncation]
231 | strncpy(frame->product, product, sizeof(frame->product));
| ^~~~
Just use memcpy() instead.
Signed-off-by: Thomas Zimmermann
---
drivers/video/hdmi.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index b7a1d6fae90d..1e4cb63d0d11 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -221,14 +221,18 @@ EXPORT_SYMBOL(hdmi_avi_infoframe_pack);
int hdmi_spd_infoframe_init(struct hdmi_spd_infoframe *frame,
const char *vendor, const char *product)
{
+ size_t len;
+
memset(frame, 0, sizeof(*frame));
frame->type = HDMI_INFOFRAME_TYPE_SPD;
frame->version = 1;
frame->length = HDMI_SPD_INFOFRAME_SIZE;
- strncpy(frame->vendor, vendor, sizeof(frame->vendor));
- strncpy(frame->product, product, sizeof(frame->product));
+ len = strlen(vendor);
+ memcpy(frame->vendor, vendor, min(len, sizeof(frame->vendor)));
+ len = strlen(product);
+ memcpy(frame->product, product, min(len, sizeof(frame->product)));
return 0;
}
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm/tidss: Move to newer connector model
On 16/10/2020 13:39, Nikhil Devshatwar wrote:
> To be able to support connector operations across multiple
> bridges, it is recommended that the connector should be
> created by the SoC driver instead of the bridges.
>
> Modify the tidss modesetting initialization sequence to
> create the connector and attach bridges with flag
> DRM_BRIDGE_ATTACH_NO_CONNECTOR
>
> Signed-off-by: Nikhil Devshatwar
> ---
> drivers/gpu/drm/tidss/tidss_drv.h | 3 +++
> drivers/gpu/drm/tidss/tidss_kms.c | 15 ++-
> 2 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/tidss/tidss_drv.h
> b/drivers/gpu/drm/tidss/tidss_drv.h
> index 7de4bba52e6f..cfbf85a4d92b 100644
> --- a/drivers/gpu/drm/tidss/tidss_drv.h
> +++ b/drivers/gpu/drm/tidss/tidss_drv.h
> @@ -27,6 +27,9 @@ struct tidss_device {
> unsigned int num_planes;
> struct drm_plane *planes[TIDSS_MAX_PLANES];
>
> + unsigned int num_connectors;
> + struct drm_connector *connectors[TIDSS_MAX_PORTS];
> +
> spinlock_t wait_lock; /* protects the irq masks */
> dispc_irq_t irq_mask; /* enabled irqs in addition to wait_list */
> };
> diff --git a/drivers/gpu/drm/tidss/tidss_kms.c
> b/drivers/gpu/drm/tidss/tidss_kms.c
> index 09485c7f0d6f..51c24b4a6a21 100644
> --- a/drivers/gpu/drm/tidss/tidss_kms.c
> +++ b/drivers/gpu/drm/tidss/tidss_kms.c
> @@ -7,6 +7,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -192,6 +193,7 @@ static int tidss_dispc_modeset_init(struct tidss_device
> *tidss)
> for (i = 0; i < num_pipes; ++i) {
> struct tidss_plane *tplane;
> struct tidss_crtc *tcrtc;
> + struct drm_connector *connector;
> struct drm_encoder *enc;
> u32 hw_plane_id = feat->vid_order[tidss->num_planes];
> int ret;
> @@ -222,11 +224,22 @@ static int tidss_dispc_modeset_init(struct tidss_device
> *tidss)
> return PTR_ERR(enc);
> }
>
> - ret = drm_bridge_attach(enc, pipes[i].bridge, NULL, 0);
> + ret = drm_bridge_attach(enc, pipes[i].bridge, NULL,
> + DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> if (ret) {
> dev_err(tidss->dev, "bridge attach failed: %d\n", ret);
> return ret;
> }
> +
> + connector = drm_bridge_connector_init(>ddev, enc);
> + if (IS_ERR(connector)) {
> + dev_err(tidss->dev, "bridge_connector create failed\n");
> + return PTR_ERR(connector);
> + }
> +
> + tidss->connectors[tidss->num_connectors++] = connector;
> +
> + drm_connector_attach_encoder(connector, enc);
This call may return an error.
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/ttm: avoid multihop moves in drivers.
Am 21.10.20 um 10:33 schrieb Daniel Vetter:
On Wed, Oct 21, 2020 at 02:40:31PM +1000, Dave Airlie wrote:
From: Dave Airlie
Currently drivers get called to move a buffer, but if they have to
move it temporarily through another space (SYSTEM->VRAM via TT)
then they can end up with a lot of ttm->driver->ttm call stacks,
if the temprorary space moves requires eviction.
Instead of letting the driver do all the placement/space for the
temporary, allow it to report back (-EMULTIHOP) a placement (hop)
to the move code, which will then do the temporary move, and the
correct placement move afterwards.
This removes a lot of code from drivers, at the expense of
adding some midlayering. I've some further ideas on how to turn
it inside out, but I think this is a good solution to the call
stack problems.
Signed-off-by: Dave Airlie
So at first I freaked out about this a bit on irc, as in "this is horrible
midlayer madness". But it does look a lot cleaner, it's definitely a step
in the right direction, and I guess for most drivers it's going to be good
enough. Maybe there's going to be drivers which want to have even better
control over where buffers are placed, who's victimized, and what
intermediate steps to take. But doing that demidlayering can be done when
there's a need, I think all the building blocks with the in-flight
untangling are there now.
So I guess I like this now after the initial shock passed :-)
Essentially this is a really big de-midlayering :)
See previously the call chain was like this:
driver->ttm->driver->ttm->driver->ttm->driver
For each multi hop we played ping/pong once between driver and ttm :)
Now we at least only have driver->ttm->driver. Which is not ideal
either, but still a lot better than before.
Christian.
-Daniel
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 139 +++--
drivers/gpu/drm/drm_gem_vram_helper.c | 3 +-
drivers/gpu/drm/nouveau/nouveau_bo.c | 115 +++--
drivers/gpu/drm/qxl/qxl_ttm.c | 3 +-
drivers/gpu/drm/radeon/radeon_ttm.c| 122 +++---
drivers/gpu/drm/ttm/ttm_bo.c | 62 +++--
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 3 +-
include/drm/ttm/ttm_bo_driver.h| 5 +-
8 files changed, 108 insertions(+), 344 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 62f9194b1dd1..0fd4f270d794 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -515,119 +515,6 @@ static int amdgpu_move_blit(struct ttm_buffer_object *bo,
return r;
}
-/**
- * amdgpu_move_vram_ram - Copy VRAM buffer to RAM buffer
- *
- * Called by amdgpu_bo_move().
- */
-static int amdgpu_move_vram_ram(struct ttm_buffer_object *bo, bool evict,
- struct ttm_operation_ctx *ctx,
- struct ttm_resource *new_mem)
-{
- struct ttm_resource *old_mem = >mem;
- struct ttm_resource tmp_mem;
- struct ttm_place placements;
- struct ttm_placement placement;
- int r;
-
- /* create space/pages for new_mem in GTT space */
- tmp_mem = *new_mem;
- tmp_mem.mm_node = NULL;
- placement.num_placement = 1;
- placement.placement =
- placement.num_busy_placement = 1;
- placement.busy_placement =
- placements.fpfn = 0;
- placements.lpfn = 0;
- placements.mem_type = TTM_PL_TT;
- placements.flags = 0;
- r = ttm_bo_mem_space(bo, , _mem, ctx);
- if (unlikely(r)) {
- pr_err("Failed to find GTT space for blit from VRAM\n");
- return r;
- }
-
- r = ttm_tt_populate(bo->bdev, bo->ttm, ctx);
- if (unlikely(r))
- goto out_cleanup;
-
- /* Bind the memory to the GTT space */
- r = amdgpu_ttm_backend_bind(bo->bdev, bo->ttm, _mem);
- if (unlikely(r)) {
- goto out_cleanup;
- }
-
- /* blit VRAM to GTT */
- r = amdgpu_move_blit(bo, evict, _mem, old_mem);
- if (unlikely(r)) {
- goto out_cleanup;
- }
-
- r = ttm_bo_wait_ctx(bo, ctx);
- if (unlikely(r))
- goto out_cleanup;
-
- amdgpu_ttm_backend_unbind(bo->bdev, bo->ttm);
- ttm_resource_free(bo, >mem);
- ttm_bo_assign_mem(bo, new_mem);
-out_cleanup:
- ttm_resource_free(bo, _mem);
- return r;
-}
-
-/**
- * amdgpu_move_ram_vram - Copy buffer from RAM to VRAM
- *
- * Called by amdgpu_bo_move().
- */
-static int amdgpu_move_ram_vram(struct ttm_buffer_object *bo, bool evict,
- struct ttm_operation_ctx *ctx,
- struct ttm_resource *new_mem)
-{
- struct ttm_resource *old_mem = >mem;
- struct ttm_resource tmp_mem;
- struct ttm_placement placement;
- struct ttm_place placements;
- int r;
-
- /* make space
Re: [PATCH v2 12/24] drm/dp: fix a kernel-doc issue at drm_edid.c
Hi Lyude,
Em Tue, 13 Oct 2020 15:49:11 -0400
Lyude Paul escreveu:
> wait, I think there's some confusion here. these patches have already been
> pushed
As the patch adding the warning was merged upstream at the 5.10 merge
window, the fixup one should also be added there, instead of waiting
until 5.11 ;-)
So, if OK for you, I'll send this upstream via my tree by the end of
the merge window, as our goal is that 5.10 won't have doc warnings.
Regards,
Mauro
>
>
> On Tue, 2020-10-13 at 14:14 +0200, Mauro Carvalho Chehab wrote:
> > The name of the argument is different, causing those warnings:
> >
> > ./drivers/gpu/drm/drm_edid.c:3754: warning: Function parameter or member
> > 'video_code' not described in 'drm_display_mode_from_cea_vic'
> > ./drivers/gpu/drm/drm_edid.c:3754: warning: Excess function parameter
> > 'vic' description in 'drm_display_mode_from_cea_vic'
> >
> > Fixes: 7af655bce275 ("drm/dp: Add drm_dp_downstream_mode()")
> > Signed-off-by: Mauro Carvalho Chehab
> > ---
> > drivers/gpu/drm/drm_edid.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index a82f37d44258..631125b46e04 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -3741,7 +3741,7 @@ drm_add_cmdb_modes(struct drm_connector *connector, u8
> > svd)
> > /**
> > * drm_display_mode_from_cea_vic() - return a mode for CEA VIC
> > * @dev: DRM device
> > - * @vic: CEA VIC of the mode
> > + * @video_code: CEA VIC of the mode
> > *
> > * Creates a new mode matching the specified CEA VIC.
> > *
Thanks,
Mauro
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/ttm: ttm_bo_mem_placement doesn't need ctx parameter.
Am 21.10.20 um 06:40 schrieb Dave Airlie:
From: Dave Airlie
Removed unused parameter.
Signed-off-by: Dave Airlie
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index e2afab3d97ee..5b411252a857 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -830,7 +830,6 @@ static int ttm_bo_mem_force_space(struct ttm_buffer_object
*bo,
* @bo: BO to find memory for
* @place: where to search
* @mem: the memory object to fill in
- * @ctx: operation context
*
* Check if placement is compatible and fill in mem structure.
* Returns -EBUSY if placement won't work or negative error code.
@@ -838,8 +837,7 @@ static int ttm_bo_mem_force_space(struct ttm_buffer_object
*bo,
*/
static int ttm_bo_mem_placement(struct ttm_buffer_object *bo,
const struct ttm_place *place,
- struct ttm_resource *mem,
- struct ttm_operation_ctx *ctx)
+ struct ttm_resource *mem)
{
struct ttm_bo_device *bdev = bo->bdev;
struct ttm_resource_manager *man;
@@ -884,7 +882,7 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
const struct ttm_place *place = >placement[i];
struct ttm_resource_manager *man;
- ret = ttm_bo_mem_placement(bo, place, mem, ctx);
+ ret = ttm_bo_mem_placement(bo, place, mem);
if (ret)
continue;
@@ -910,7 +908,7 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
for (i = 0; i < placement->num_busy_placement; ++i) {
const struct ttm_place *place = >busy_placement[i];
- ret = ttm_bo_mem_placement(bo, place, mem, ctx);
+ ret = ttm_bo_mem_placement(bo, place, mem);
if (ret)
continue;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/ttm: replace last move_notify with delete_mem_notify
Am 21.10.20 um 06:40 schrieb Dave Airlie:
From: Dave Airlie
The move notify callback is only used in one place, this should
be removed in the future, but for now just rename it to the use
case which is to notify the driver that the GPU memory is to be
deleted.
Probably the right thing to do is to call the move callback with
move(from, NULL) in this case as well.
And then driver can call the necessary function to throw away the
backing store pipelined.
Drivers can be cleaned up after this separately.
Signed-off-by: Dave Airlie
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 8 +++-
drivers/gpu/drm/drm_gem_vram_helper.c | 8 +++-
drivers/gpu/drm/nouveau/nouveau_bo.c | 8 +++-
drivers/gpu/drm/qxl/qxl_ttm.c | 7 ++-
drivers/gpu/drm/radeon/radeon_ttm.c| 8 +++-
drivers/gpu/drm/ttm/ttm_bo.c | 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 8 +++-
include/drm/ttm/ttm_bo_driver.h| 10 ++
8 files changed, 41 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 87e10a212b8a..62f9194b1dd1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1730,6 +1730,12 @@ static int amdgpu_ttm_access_memory(struct
ttm_buffer_object *bo,
return ret;
}
+static void
+amdgpu_bo_delete_mem_notify(struct ttm_buffer_object *bo)
+{
+ amdgpu_bo_move_notify(bo, false, NULL);
+}
+
static struct ttm_bo_driver amdgpu_bo_driver = {
.ttm_tt_create = _ttm_tt_create,
.ttm_tt_populate = _ttm_tt_populate,
@@ -1739,7 +1745,7 @@ static struct ttm_bo_driver amdgpu_bo_driver = {
.evict_flags = _evict_flags,
.move = _bo_move,
.verify_access = _verify_access,
- .move_notify = _bo_move_notify,
+ .delete_mem_notify = _bo_delete_mem_notify,
.release_notify = _bo_release_notify,
.io_mem_reserve = _ttm_io_mem_reserve,
.io_mem_pfn = amdgpu_ttm_io_mem_pfn,
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 19087b22bdbb..9da823eb0edd 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -949,9 +949,7 @@ static void bo_driver_evict_flags(struct ttm_buffer_object
*bo,
drm_gem_vram_bo_driver_evict_flags(gbo, placement);
}
-static void bo_driver_move_notify(struct ttm_buffer_object *bo,
- bool evict,
- struct ttm_resource *new_mem)
+static void bo_driver_delete_mem_notify(struct ttm_buffer_object *bo)
{
struct drm_gem_vram_object *gbo;
@@ -961,7 +959,7 @@ static void bo_driver_move_notify(struct ttm_buffer_object *bo,
gbo = drm_gem_vram_of_bo(bo);
- drm_gem_vram_bo_driver_move_notify(gbo, evict, new_mem);
+ drm_gem_vram_bo_driver_move_notify(gbo, false, NULL);
}
static int bo_driver_move(struct ttm_buffer_object *bo,
@@ -1002,7 +1000,7 @@ static struct ttm_bo_driver bo_driver = {
.eviction_valuable = ttm_bo_eviction_valuable,
.evict_flags = bo_driver_evict_flags,
.move = bo_driver_move,
- .move_notify = bo_driver_move_notify,
+ .delete_mem_notify = bo_driver_delete_mem_notify,
.io_mem_reserve = bo_driver_io_mem_reserve,
};
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 70b6f3b1ae85..acff82afe260 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1401,6 +1401,12 @@ nouveau_bo_fence(struct nouveau_bo *nvbo, struct
nouveau_fence *fence, bool excl
dma_resv_add_shared_fence(resv, >base);
}
+static void
+nouveau_bo_delete_mem_notify(struct ttm_buffer_object *bo)
+{
+ nouveau_bo_move_ntfy(bo, false, NULL);
+}
+
struct ttm_bo_driver nouveau_bo_driver = {
.ttm_tt_create = _ttm_tt_create,
.ttm_tt_populate = _ttm_tt_populate,
@@ -1408,7 +1414,7 @@ struct ttm_bo_driver nouveau_bo_driver = {
.ttm_tt_destroy = _ttm_tt_destroy,
.eviction_valuable = ttm_bo_eviction_valuable,
.evict_flags = nouveau_bo_evict_flags,
- .move_notify = nouveau_bo_move_ntfy,
+ .delete_mem_notify = nouveau_bo_delete_mem_notify,
.move = nouveau_bo_move,
.verify_access = nouveau_bo_verify_access,
.io_mem_reserve = _ttm_io_mem_reserve,
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index 1cc3c14bc684..b52a4563b47b 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -166,6 +166,11 @@ static int qxl_bo_move(struct ttm_buffer_object *bo, bool
evict,
return ret;
}
+static void qxl_bo_delete_mem_notify(struct ttm_buffer_object *bo)
+{
+ qxl_bo_move_notify(bo, false, NULL);
+}
+
static struct
Re: [PATCH v7 0/4] Introduce drm scaling filter property
On Tue, 20 Oct 2020, Pankaj Bharadiya wrote: > Kodi patches are reviewed and accepted for merge now. > > Here is the userspace patch series link: > https://github.com/xbmc/xbmc/pull/18567 > > Background on Integer scaling: > > Integer scaling (IS) is a nearest-neighbor upscaling technique that > simply scales up the existing pixels by an integer (i.e., whole > number) multiplier. Nearest-neighbor (NN) interpolation works by > filling in the missing color values in the upscaled image with that of > the coordinate-mapped nearest source pixel value. > > Both IS and NN preserve the clarity of the original image. In > contrast, traditional upscaling algorithms, such as bilinear or > bicubic interpolation, result in blurry upscaled images because they > employ interpolation techniques that smooth out the transition from > one pixel to another. Therefore, integer scaling is particularly > useful for pixel art games that rely on sharp, blocky images to > deliver their distinctive look. > > Many gaming communities have been asking for integer-mode scaling > support, some links and background: > > https://software.intel.com/en-us/articles/integer-scaling-support-on-intel-graphics > http://tanalin.com/en/articles/lossless-scaling/ > https://community.amd.com/thread/209107 > https://www.nvidia.com/en-us/geforce/forums/game-ready-drivers/13/1002/feature-request-nonblurry-upscaling-at-integer-rat/ Thanks for the patches and review, pushed to dinq with Daniel's IRC ack to merge via drm-intel. BR, Jani. > > changes since v6: > * Move property doc to existing "Standard CRTC Properties" and > "Plane Composition Properties" doc comments (Simon) > * Drop 0002 patch > > Pankaj Bharadiya (4): > drm: Introduce plane and CRTC scaling filter properties > drm/i915: Introduce scaling filter related registers and bit fields > drm/i915/display: Add Nearest-neighbor based integer scaling support > drm/i915: Enable scaling filter for plane and CRTC > > drivers/gpu/drm/drm_atomic_uapi.c | 8 ++ > drivers/gpu/drm/drm_blend.c | 13 ++ > drivers/gpu/drm/drm_crtc.c| 40 ++ > drivers/gpu/drm/drm_crtc_internal.h | 3 + > drivers/gpu/drm/drm_plane.c | 73 +++ > .../gpu/drm/i915/display/intel_atomic_plane.c | 1 + > drivers/gpu/drm/i915/display/intel_display.c | 117 +- > drivers/gpu/drm/i915/display/intel_display.h | 4 + > .../drm/i915/display/intel_display_types.h| 2 + > drivers/gpu/drm/i915/display/intel_sprite.c | 15 ++- > drivers/gpu/drm/i915/i915_reg.h | 22 > include/drm/drm_crtc.h| 16 +++ > include/drm/drm_plane.h | 21 > 13 files changed, 331 insertions(+), 4 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/drm_vblank: use drm_warn_once() to warn undefined mode timing
On Mon, Oct 19, 2020 at 05:48:29PM +0200, Daniel Vetter wrote:
> On Fri, Oct 16, 2020 at 07:46:41PM +0800, Shawn Guo wrote:
> > Indeed! Adding drm_crtc_vblank_reset() into driver crtc reset hook
> > removes the WARNING for me. Really appreciate your comments, Daniel!
>
> This should work automatically if you're using the atomic state helpers.
> Please try to unify as much as possible, so you're not missing any future
> bugfixes in this area. Although I thought I've completely reviewed all
> drivers to fix as many as possible for this bug. Are you on some older
> kernel that didn't have this? Maybe good idea to submit the bugfix in
> upstream to stable, if that's the case.
Yes, I'm running a 4.19 stable kernel with msm/mdp5 device. The bug was
addressed (unintentionally?) by one patch that is part of the series
adding Nexus 5 display support. And later on, you commit 51f644b40b4b
("drm/atomic-helper: reset vblank on crtc reset") switches the driver to
use atomic state helper.
Shawn
[1] https://lore.kernel.org/patchwork/patch/1082564/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 203339] AMDGPU: virtual_display disables physical outputs
https://bugzilla.kernel.org/show_bug.cgi?id=203339 vita.am...@gmail.com (vita.am...@gmail.com) changed: What|Removed |Added CC||vita.am...@gmail.com --- Comment #4 from vita.am...@gmail.com (vita.am...@gmail.com) --- But what if i need virtual display in order to use it as a second monitor via vnc? There is no way... -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 16/16] PCI: Revoke mappings like devmem
Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims
the region") /dev/kmem zaps ptes when the kernel requests exclusive
acccess to an iomem region. And with CONFIG_IO_STRICT_DEVMEM, this is
the default for all driver uses.
Except there's two more ways to access PCI BARs: sysfs and proc mmap
support. Let's plug that hole.
For revoke_devmem() to work we need to link our vma into the same
address_space, with consistent vma->vm_pgoff. ->pgoff is already
adjusted, because that's how (io_)remap_pfn_range works, but for the
mapping we need to adjust vma->vm_file->f_mapping. The cleanest way is
to adjust this at at ->open time:
- for sysfs this is easy, now that binary attributes support this. We
just set bin_attr->mapping when mmap is supported
- for procfs it's a bit more tricky, since procfs pci access has only
one file per device, and access to a specific resources first needs
to be set up with some ioctl calls. But mmap is only supported for
the same resources as sysfs exposes with mmap support, and otherwise
rejected, so we can set the mapping unconditionally at open time
without harm.
A special consideration is for arch_can_pci_mmap_io() - we need to
make sure that the ->f_mapping doesn't alias between ioport and iomem
space. There's only 2 ways in-tree to support mmap of ioports: generic
pci mmap (ARCH_GENERIC_PCI_MMAP_RESOURCE), and sparc as the single
architecture hand-rolling. Both approach support ioport mmap through a
special pfn range and not through magic pte attributes. Aliasing is
therefore not a problem.
The only difference in access checks left is that sysfs PCI mmap does
not check for CAP_RAWIO. I'm not really sure whether that should be
added or not.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: Greg Kroah-Hartman
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Bjorn Helgaas
Cc: linux-...@vger.kernel.org
Signed-off-by: Daniel Vetter
--
v2:
- Totally new approach: Adjust filp->f_mapping at open time. Note that
this now works on all architectures, not just those support
ARCH_GENERIC_PCI_MMAP_RESOURCE
---
drivers/pci/pci-sysfs.c | 4
drivers/pci/proc.c | 1 +
2 files changed, 5 insertions(+)
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 6d78df981d41..cee38fcb4a86 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -928,6 +928,7 @@ void pci_create_legacy_files(struct pci_bus *b)
b->legacy_io->read = pci_read_legacy_io;
b->legacy_io->write = pci_write_legacy_io;
b->legacy_io->mmap = pci_mmap_legacy_io;
+ b->legacy_io->mapping = iomem_get_mapping();
pci_adjust_legacy_attr(b, pci_mmap_io);
error = device_create_bin_file(>dev, b->legacy_io);
if (error)
@@ -940,6 +941,7 @@ void pci_create_legacy_files(struct pci_bus *b)
b->legacy_mem->size = 1024*1024;
b->legacy_mem->attr.mode = 0600;
b->legacy_mem->mmap = pci_mmap_legacy_mem;
+ b->legacy_io->mapping = iomem_get_mapping();
pci_adjust_legacy_attr(b, pci_mmap_mem);
error = device_create_bin_file(>dev, b->legacy_mem);
if (error)
@@ -1155,6 +1157,8 @@ static int pci_create_attr(struct pci_dev *pdev, int num,
int write_combine)
res_attr->mmap = pci_mmap_resource_uc;
}
}
+ if (res_attr->mmap)
+ res_attr->mapping = iomem_get_mapping();
res_attr->attr.name = res_attr_name;
res_attr->attr.mode = 0600;
res_attr->size = pci_resource_len(pdev, num);
diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c
index 3a2f90beb4cb..9bab07302bbf 100644
--- a/drivers/pci/proc.c
+++ b/drivers/pci/proc.c
@@ -298,6 +298,7 @@ static int proc_bus_pci_open(struct inode *inode, struct
file *file)
fpriv->write_combine = 0;
file->private_data = fpriv;
+ file->f_mapping = iomem_get_mapping();
return 0;
}
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 13/16] /dev/mem: Only set filp->f_mapping
When we care about pagecache maintenance, we need to make sure that both f_mapping and i_mapping point at the right mapping. But for iomem mappings we only care about the virtual/pte side of things, so f_mapping is enough. Also setting inode->i_mapping was confusing me as a driver maintainer, since in e.g. drivers/gpu we don't do that. Per Dan this seems to be copypasta from places which do care about pagecache consistency, but not needed. Hence remove it for slightly less confusion. Signed-off-by: Daniel Vetter Cc: Jason Gunthorpe Cc: Kees Cook Cc: Dan Williams Cc: Andrew Morton Cc: John Hubbard Cc: Jérôme Glisse Cc: Jan Kara Cc: Dan Williams Cc: linux...@kvack.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-samsung-...@vger.kernel.org Cc: linux-me...@vger.kernel.org Signed-off-by: Daniel Vetter --- drivers/char/mem.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/char/mem.c b/drivers/char/mem.c index abd4ffdc8cde..5502f56f3655 100644 --- a/drivers/char/mem.c +++ b/drivers/char/mem.c @@ -864,7 +864,6 @@ static int open_port(struct inode *inode, struct file *filp) * revocations when drivers want to take over a /dev/mem mapped * range. */ - inode->i_mapping = devmem_inode->i_mapping; filp->f_mapping = inode->i_mapping; return 0; -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 14/16] resource: Move devmem revoke code to resource framework
We want all iomem mmaps to consistently revoke ptes when the kernel
takes over and CONFIG_IO_STRICT_DEVMEM is enabled. This includes the
pci bar mmaps available through procfs and sysfs, which currently do
not revoke mappings.
To prepare for this, move the code from the /dev/kmem driver to
kernel/resource.c.
Reviewed-by: Greg Kroah-Hartman
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Daniel Vetter
Cc: David Hildenbrand
Cc: "Rafael J. Wysocki"
Signed-off-by: Daniel Vetter
--
v3:
- add barrier for consistency and document why we don't have to check
for NULL (Jason)
---
drivers/char/mem.c | 85 +-
include/linux/ioport.h | 6 +--
kernel/resource.c | 101 -
3 files changed, 102 insertions(+), 90 deletions(-)
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 5502f56f3655..53338aad8d28 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -31,9 +31,6 @@
#include
#include
#include
-#include
-#include
-#include
#ifdef CONFIG_IA64
# include
@@ -809,42 +806,6 @@ static loff_t memory_lseek(struct file *file, loff_t
offset, int orig)
return ret;
}
-static struct inode *devmem_inode;
-
-#ifdef CONFIG_IO_STRICT_DEVMEM
-void revoke_devmem(struct resource *res)
-{
- /* pairs with smp_store_release() in devmem_init_inode() */
- struct inode *inode = smp_load_acquire(_inode);
-
- /*
-* Check that the initialization has completed. Losing the race
-* is ok because it means drivers are claiming resources before
-* the fs_initcall level of init and prevent /dev/mem from
-* establishing mappings.
-*/
- if (!inode)
- return;
-
- /*
-* The expectation is that the driver has successfully marked
-* the resource busy by this point, so devmem_is_allowed()
-* should start returning false, however for performance this
-* does not iterate the entire resource range.
-*/
- if (devmem_is_allowed(PHYS_PFN(res->start)) &&
- devmem_is_allowed(PHYS_PFN(res->end))) {
- /*
-* *cringe* iomem=relaxed says "go ahead, what's the
-* worst that can happen?"
-*/
- return;
- }
-
- unmap_mapping_range(inode->i_mapping, res->start, resource_size(res),
1);
-}
-#endif
-
static int open_port(struct inode *inode, struct file *filp)
{
int rc;
@@ -864,7 +825,7 @@ static int open_port(struct inode *inode, struct file *filp)
* revocations when drivers want to take over a /dev/mem mapped
* range.
*/
- filp->f_mapping = inode->i_mapping;
+ filp->f_mapping = iomem_get_mapping();
return 0;
}
@@ -995,48 +956,6 @@ static char *mem_devnode(struct device *dev, umode_t *mode)
static struct class *mem_class;
-static int devmem_fs_init_fs_context(struct fs_context *fc)
-{
- return init_pseudo(fc, DEVMEM_MAGIC) ? 0 : -ENOMEM;
-}
-
-static struct file_system_type devmem_fs_type = {
- .name = "devmem",
- .owner = THIS_MODULE,
- .init_fs_context = devmem_fs_init_fs_context,
- .kill_sb= kill_anon_super,
-};
-
-static int devmem_init_inode(void)
-{
- static struct vfsmount *devmem_vfs_mount;
- static int devmem_fs_cnt;
- struct inode *inode;
- int rc;
-
- rc = simple_pin_fs(_fs_type, _vfs_mount, _fs_cnt);
- if (rc < 0) {
- pr_err("Cannot mount /dev/mem pseudo filesystem: %d\n", rc);
- return rc;
- }
-
- inode = alloc_anon_inode(devmem_vfs_mount->mnt_sb);
- if (IS_ERR(inode)) {
- rc = PTR_ERR(inode);
- pr_err("Cannot allocate inode for /dev/mem: %d\n", rc);
- simple_release_fs(_vfs_mount, _fs_cnt);
- return rc;
- }
-
- /*
-* Publish /dev/mem initialized.
-* Pairs with smp_load_acquire() in revoke_devmem().
-*/
- smp_store_release(_inode, inode);
-
- return 0;
-}
-
static int __init chr_dev_init(void)
{
int minor;
@@ -1058,8 +977,6 @@ static int __init chr_dev_init(void)
*/
if ((minor == DEVPORT_MINOR) && !arch_has_dev_port())
continue;
- if ((minor == DEVMEM_MINOR) && devmem_init_inode() != 0)
- continue;
device_create(mem_class, NULL, MKDEV(MEM_MAJOR, minor),
NULL, devlist[minor].name);
diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index
[PATCH v3 12/16] PCI: Obey iomem restrictions for procfs mmap
There's three ways to access PCI BARs from userspace: /dev/mem, sysfs
files, and the old proc interface. Two check against
iomem_is_exclusive, proc never did. And with CONFIG_IO_STRICT_DEVMEM,
this starts to matter, since we don't want random userspace having
access to PCI BARs while a driver is loaded and using it.
Fix this by adding the same iomem_is_exclusive() check we already have
on the sysfs side in pci_mmap_resource().
References: 90a545e98126 ("restrict /dev/mem to idle io memory ranges")
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Bjorn Helgaas
Cc: linux-...@vger.kernel.org
Signed-off-by: Daniel Vetter
--
v2: Improve commit message (Bjorn)
---
drivers/pci/proc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c
index d35186b01d98..3a2f90beb4cb 100644
--- a/drivers/pci/proc.c
+++ b/drivers/pci/proc.c
@@ -274,6 +274,11 @@ static int proc_bus_pci_mmap(struct file *file, struct
vm_area_struct *vma)
else
return -EINVAL;
}
+
+ if (dev->resource[i].flags & IORESOURCE_MEM &&
+ iomem_is_exclusive(dev->resource[i].start))
+ return -EINVAL;
+
ret = pci_mmap_page_range(dev, i, vma,
fpriv->mmap_state, write_combine);
if (ret < 0)
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 09/16] mm: Add unsafe_follow_pfn
Way back it was a reasonable assumptions that iomem mappings never
change the pfn range they point at. But this has changed:
- gpu drivers dynamically manage their memory nowadays, invalidating
ptes with unmap_mapping_range when buffers get moved
- contiguous dma allocations have moved from dedicated carvetouts to
cma regions. This means if we miss the unmap the pfn might contain
pagecache or anon memory (well anything allocated with GFP_MOVEABLE)
- even /dev/mem now invalidates mappings when the kernel requests that
iomem region when CONFIG_IO_STRICT_DEVMEM is set, see 3234ac664a87
("/dev/mem: Revoke mappings when a driver claims the region")
Accessing pfns obtained from ptes without holding all the locks is
therefore no longer a good idea.
Unfortunately there's some users where this is not fixable (like v4l
userptr of iomem mappings) or involves a pile of work (vfio type1
iommu). For now annotate these as unsafe and splat appropriately.
This patch adds an unsafe_follow_pfn, which later patches will then
roll out to all appropriate places.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: k...@vger.kernel.org
Signed-off-by: Daniel Vetter
---
include/linux/mm.h | 2 ++
mm/memory.c| 32 +++-
mm/nommu.c | 17 +
security/Kconfig | 13 +
4 files changed, 63 insertions(+), 1 deletion(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 2a16631c1fda..ec8c90928fc9 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1653,6 +1653,8 @@ int follow_pte_pmd(struct mm_struct *mm, unsigned long
address,
pte_t **ptepp, pmd_t **pmdpp, spinlock_t **ptlp);
int follow_pfn(struct vm_area_struct *vma, unsigned long address,
unsigned long *pfn);
+int unsafe_follow_pfn(struct vm_area_struct *vma, unsigned long address,
+ unsigned long *pfn);
int follow_phys(struct vm_area_struct *vma, unsigned long address,
unsigned int flags, unsigned long *prot, resource_size_t *phys);
int generic_access_phys(struct vm_area_struct *vma, unsigned long addr,
diff --git a/mm/memory.c b/mm/memory.c
index fff817608eb4..bcba4e8f1501 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4788,7 +4788,12 @@ EXPORT_SYMBOL(follow_pte_pmd);
* @address: user virtual address
* @pfn: location to store found PFN
*
- * Only IO mappings and raw PFN mappings are allowed.
+ * Only IO mappings and raw PFN mappings are allowed. Note that callers must
+ * ensure coherency with pte updates by using a _notifier to follow
updates.
+ * If this is not feasible, or the access to the @pfn is only very short term,
+ * use follow_pte_pmd() instead and hold the pagetable lock for the duration of
+ * the access instead. Any caller not following these requirements must use
+ * unsafe_follow_pfn() instead.
*
* Return: zero and the pfn at @pfn on success, -ve otherwise.
*/
@@ -4811,6 +4816,31 @@ int follow_pfn(struct vm_area_struct *vma, unsigned long
address,
}
EXPORT_SYMBOL(follow_pfn);
+/**
+ * unsafe_follow_pfn - look up PFN at a user virtual address
+ * @vma: memory mapping
+ * @address: user virtual address
+ * @pfn: location to store found PFN
+ *
+ * Only IO mappings and raw PFN mappings are allowed.
+ *
+ * Returns zero and the pfn at @pfn on success, -ve otherwise.
+ */
+int unsafe_follow_pfn(struct vm_area_struct *vma, unsigned long address,
+ unsigned long *pfn)
+{
+#ifdef CONFIG_STRICT_FOLLOW_PFN
+ pr_info("unsafe follow_pfn usage rejected, see
CONFIG_STRICT_FOLLOW_PFN\n");
+ return -EINVAL;
+#else
+ WARN_ONCE(1, "unsafe follow_pfn usage\n");
+ add_taint(TAINT_USER, LOCKDEP_STILL_OK);
+
+ return follow_pfn(vma, address, pfn);
+#endif
+}
+EXPORT_SYMBOL(unsafe_follow_pfn);
+
#ifdef CONFIG_HAVE_IOREMAP_PROT
int follow_phys(struct vm_area_struct *vma,
unsigned long address, unsigned int flags,
diff --git a/mm/nommu.c b/mm/nommu.c
index 75a327149af1..3db2910f0d64 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -132,6 +132,23 @@ int follow_pfn(struct vm_area_struct *vma, unsigned long
address,
}
EXPORT_SYMBOL(follow_pfn);
+/**
+ * unsafe_follow_pfn - look up PFN at a user virtual address
+ * @vma: memory mapping
+ * @address: user virtual address
+ * @pfn: location to store found PFN
+ *
+ * Only IO mappings and raw PFN mappings are allowed.
+ *
+ * Returns zero and the pfn at @pfn on success, -ve otherwise.
+ */
+int unsafe_follow_pfn(struct vm_area_struct *vma, unsigned long address,
+ unsigned long *pfn)
+{
+ return follow_pfn(vma, address, pfn);
+}
+EXPORT_SYMBOL(unsafe_follow_pfn);
+
LIST_HEAD(vmap_area_list);
void vfree(const void *addr)
diff --git
[PATCH v3 15/16] sysfs: Support zapping of binary attr mmaps
We want to be able to revoke pci mmaps so that the same access rules
applies as for /dev/kmem. Revoke support for devmem was added in
3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims the
region").
The simplest way to achieve this is by having the same filp->f_mapping
for all mappings, so that unmap_mapping_range can find them all, no
matter through which file they've been created. Since this must be set
at open time we need sysfs support for this.
Add an optional mapping parameter bin_attr, which is only consulted
when there's also an mmap callback, since without mmap support
allowing to adjust the ->f_mapping makes no sense.
Reviewed-by: Greg Kroah-Hartman
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Bjorn Helgaas
Cc: linux-...@vger.kernel.org
Cc: Greg Kroah-Hartman
Cc: "Rafael J. Wysocki"
Cc: Christian Brauner
Cc: "David S. Miller"
Cc: Michael Ellerman
Cc: Sourabh Jain
Cc: Daniel Vetter
Cc: Mauro Carvalho Chehab
Cc: Nayna Jain
Signed-off-by: Daniel Vetter
---
fs/sysfs/file.c | 11 +++
include/linux/sysfs.h | 2 ++
2 files changed, 13 insertions(+)
diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
index eb6897ab78e7..9d8ccdb000e3 100644
--- a/fs/sysfs/file.c
+++ b/fs/sysfs/file.c
@@ -169,6 +169,16 @@ static int sysfs_kf_bin_mmap(struct kernfs_open_file *of,
return battr->mmap(of->file, kobj, battr, vma);
}
+static int sysfs_kf_bin_open(struct kernfs_open_file *of)
+{
+ struct bin_attribute *battr = of->kn->priv;
+
+ if (battr->mapping)
+ of->file->f_mapping = battr->mapping;
+
+ return 0;
+}
+
void sysfs_notify(struct kobject *kobj, const char *dir, const char *attr)
{
struct kernfs_node *kn = kobj->sd, *tmp;
@@ -240,6 +250,7 @@ static const struct kernfs_ops sysfs_bin_kfops_mmap = {
.read = sysfs_kf_bin_read,
.write = sysfs_kf_bin_write,
.mmap = sysfs_kf_bin_mmap,
+ .open = sysfs_kf_bin_open,
};
int sysfs_add_file_mode_ns(struct kernfs_node *parent,
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index 34e84122f635..a17a474d1601 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -164,11 +164,13 @@ __ATTRIBUTE_GROUPS(_name)
struct file;
struct vm_area_struct;
+struct address_space;
struct bin_attribute {
struct attributeattr;
size_t size;
void*private;
+ struct address_space*mapping;
ssize_t (*read)(struct file *, struct kobject *, struct bin_attribute *,
char *, loff_t, size_t);
ssize_t (*write)(struct file *, struct kobject *, struct bin_attribute
*,
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 03/16] misc/habana: Stop using frame_vector helpers
All we need are a pages array, pin_user_pages_fast can give us that
directly. Plus this avoids the entire raw pfn side of get_vaddr_frames.
Reviewed-by: John Hubbard
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Oded Gabbay
Cc: Omer Shpigelman
Cc: Ofir Bitton
Cc: Tomer Tayar
Cc: Moti Haimovski
Cc: Daniel Vetter
Cc: Greg Kroah-Hartman
Cc: Pawel Piskorski
Signed-off-by: Daniel Vetter
--
v2: Use unpin_user_pages_dirty_lock (John)
v3: Update kerneldoc (Oded)
---
drivers/misc/habanalabs/Kconfig | 1 -
drivers/misc/habanalabs/common/habanalabs.h | 6 ++-
drivers/misc/habanalabs/common/memory.c | 49 -
3 files changed, 22 insertions(+), 34 deletions(-)
diff --git a/drivers/misc/habanalabs/Kconfig b/drivers/misc/habanalabs/Kconfig
index 8eb5d38c618e..2f04187f7167 100644
--- a/drivers/misc/habanalabs/Kconfig
+++ b/drivers/misc/habanalabs/Kconfig
@@ -6,7 +6,6 @@
config HABANA_AI
tristate "HabanaAI accelerators (habanalabs)"
depends on PCI && HAS_IOMEM
- select FRAME_VECTOR
select DMA_SHARED_BUFFER
select GENERIC_ALLOCATOR
select HWMON
diff --git a/drivers/misc/habanalabs/common/habanalabs.h
b/drivers/misc/habanalabs/common/habanalabs.h
index edbd627b29d2..41af090b3e6a 100644
--- a/drivers/misc/habanalabs/common/habanalabs.h
+++ b/drivers/misc/habanalabs/common/habanalabs.h
@@ -870,7 +870,8 @@ struct hl_ctx_mgr {
* struct hl_userptr - memory mapping chunk information
* @vm_type: type of the VM.
* @job_node: linked-list node for hanging the object on the Job's list.
- * @vec: pointer to the frame vector.
+ * @pages: pointer to struct page array
+ * @npages: size of @pages array
* @sgt: pointer to the scatter-gather table that holds the pages.
* @dir: for DMA unmapping, the direction must be supplied, so save it.
* @debugfs_list: node in debugfs list of command submissions.
@@ -881,7 +882,8 @@ struct hl_ctx_mgr {
struct hl_userptr {
enum vm_type_t vm_type; /* must be first */
struct list_headjob_node;
- struct frame_vector *vec;
+ struct page **pages;
+ unsigned intnpages;
struct sg_table *sgt;
enum dma_data_direction dir;
struct list_headdebugfs_list;
diff --git a/drivers/misc/habanalabs/common/memory.c
b/drivers/misc/habanalabs/common/memory.c
index 5ff4688683fd..327b64479f97 100644
--- a/drivers/misc/habanalabs/common/memory.c
+++ b/drivers/misc/habanalabs/common/memory.c
@@ -1281,45 +1281,41 @@ static int get_user_memory(struct hl_device *hdev, u64
addr, u64 size,
return -EFAULT;
}
- userptr->vec = frame_vector_create(npages);
- if (!userptr->vec) {
+ userptr->pages = kvmalloc_array(npages, sizeof(*userptr->pages),
+ GFP_KERNEL);
+ if (!userptr->pages) {
dev_err(hdev->dev, "Failed to create frame vector\n");
return -ENOMEM;
}
- rc = get_vaddr_frames(start, npages, FOLL_FORCE | FOLL_WRITE,
- userptr->vec);
+ rc = pin_user_pages_fast(start, npages, FOLL_FORCE | FOLL_WRITE,
+userptr->pages);
if (rc != npages) {
dev_err(hdev->dev,
"Failed to map host memory, user ptr probably wrong\n");
if (rc < 0)
- goto destroy_framevec;
+ goto destroy_pages;
+ npages = rc;
rc = -EFAULT;
- goto put_framevec;
- }
-
- if (frame_vector_to_pages(userptr->vec) < 0) {
- dev_err(hdev->dev,
- "Failed to translate frame vector to pages\n");
- rc = -EFAULT;
- goto put_framevec;
+ goto put_pages;
}
+ userptr->npages = npages;
rc = sg_alloc_table_from_pages(userptr->sgt,
- frame_vector_pages(userptr->vec),
- npages, offset, size, GFP_ATOMIC);
+ userptr->pages,
+ npages, offset, size, GFP_ATOMIC);
if (rc < 0) {
dev_err(hdev->dev, "failed to create SG table from pages\n");
- goto put_framevec;
+ goto put_pages;
}
return 0;
-put_framevec:
- put_vaddr_frames(userptr->vec);
-destroy_framevec:
- frame_vector_destroy(userptr->vec);
+put_pages:
+ unpin_user_pages(userptr->pages, npages);
+destroy_pages:
+ kvfree(userptr->pages);
return rc;
}
@@ -1405,8 +1401,6 @@ int
[PATCH v3 07/16] mm: Close race in generic_access_phys
Way back it was a reasonable assumptions that iomem mappings never
change the pfn range they point at. But this has changed:
- gpu drivers dynamically manage their memory nowadays, invalidating
ptes with unmap_mapping_range when buffers get moved
- contiguous dma allocations have moved from dedicated carvetouts to
cma regions. This means if we miss the unmap the pfn might contain
pagecache or anon memory (well anything allocated with GFP_MOVEABLE)
- even /dev/mem now invalidates mappings when the kernel requests that
iomem region when CONFIG_IO_STRICT_DEVMEM is set, see 3234ac664a87
("/dev/mem: Revoke mappings when a driver claims the region")
Accessing pfns obtained from ptes without holding all the locks is
therefore no longer a good idea. Fix this.
Since ioremap might need to manipulate pagetables too we need to drop
the pt lock and have a retry loop if we raced.
While at it, also add kerneldoc and improve the comment for the
vma_ops->access function. It's for accessing, not for moving the
memory from iomem to system memory, as the old comment seemed to
suggest.
References: 28b2ee20c7cb ("access_process_vm device memory infrastructure")
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Dan Williams
Cc: Kees Cook
Cc: Benjamin Herrensmidt
Cc: Dave Airlie
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Signed-off-by: Daniel Vetter
--
v2: Fix inversion in the retry check (John).
---
include/linux/mm.h | 3 ++-
mm/memory.c| 44 ++--
2 files changed, 44 insertions(+), 3 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index acd60fbf1a5a..2a16631c1fda 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -566,7 +566,8 @@ struct vm_operations_struct {
vm_fault_t (*pfn_mkwrite)(struct vm_fault *vmf);
/* called by access_process_vm when get_user_pages() fails, typically
-* for use by special VMAs that can switch between memory and hardware
+* for use by special VMAs. See also generic_access_phys() for a generic
+* implementation useful for any iomem mapping.
*/
int (*access)(struct vm_area_struct *vma, unsigned long addr,
void *buf, int len, int write);
diff --git a/mm/memory.c b/mm/memory.c
index eeae590e526a..fff817608eb4 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4840,28 +4840,68 @@ int follow_phys(struct vm_area_struct *vma,
return ret;
}
+/**
+ * generic_access_phys - generic implementation for iomem mmap access
+ * @vma: the vma to access
+ * @addr: userspace addres, not relative offset within @vma
+ * @buf: buffer to read/write
+ * @len: length of transfer
+ * @write: set to FOLL_WRITE when writing, otherwise reading
+ *
+ * This is a generic implementation for _operations_struct.access for an
+ * iomem mapping. This callback is used by access_process_vm() when the @vma is
+ * not page based.
+ */
int generic_access_phys(struct vm_area_struct *vma, unsigned long addr,
void *buf, int len, int write)
{
resource_size_t phys_addr;
unsigned long prot = 0;
void __iomem *maddr;
+ pte_t *ptep, pte;
+ spinlock_t *ptl;
int offset = addr & (PAGE_SIZE-1);
+ int ret = -EINVAL;
+
+ if (!(vma->vm_flags & (VM_IO | VM_PFNMAP)))
+ return -EINVAL;
+
+retry:
+ if (follow_pte(vma->vm_mm, addr, , ))
+ return -EINVAL;
+ pte = *ptep;
+ pte_unmap_unlock(ptep, ptl);
- if (follow_phys(vma, addr, write, , _addr))
+ prot = pgprot_val(pte_pgprot(pte));
+ phys_addr = (resource_size_t)pte_pfn(pte) << PAGE_SHIFT;
+
+ if ((write & FOLL_WRITE) && !pte_write(pte))
return -EINVAL;
maddr = ioremap_prot(phys_addr, PAGE_ALIGN(len + offset), prot);
if (!maddr)
return -ENOMEM;
+ if (follow_pte(vma->vm_mm, addr, , ))
+ goto out_unmap;
+
+ if (!pte_same(pte, *ptep)) {
+ pte_unmap_unlock(ptep, ptl);
+ iounmap(maddr);
+
+ goto retry;
+ }
+
if (write)
memcpy_toio(maddr + offset, buf, len);
else
memcpy_fromio(buf, maddr + offset, len);
+ ret = len;
+ pte_unmap_unlock(ptep, ptl);
+out_unmap:
iounmap(maddr);
- return len;
+ return ret;
}
EXPORT_SYMBOL_GPL(generic_access_phys);
#endif
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 10/16] media/videbuf1|2: Mark follow_pfn usage as unsafe
The media model assumes that buffers are all preallocated, so that
when a media pipeline is running we never miss a deadline because the
buffers aren't allocated or available.
This means we cannot fix the v4l follow_pfn usage through
mmu_notifier, without breaking how this all works. The only real fix
is to deprecate userptr support for VM_IO | VM_PFNMAP mappings and
tell everyone to cut over to dma-buf memory sharing for zerocopy.
userptr for normal memory will keep working as-is, this only affects
the zerocopy userptr usage enabled in 50ac952d2263 ("[media]
videobuf2-dma-sg: Support io userptr operations on io memory").
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Pawel Osciak
Cc: Marek Szyprowski
Cc: Kyungmin Park
Cc: Tomasz Figa
Cc: Laurent Dufour
Cc: Vlastimil Babka
Cc: Daniel Jordan
Cc: Michel Lespinasse
Signed-off-by: Daniel Vetter
--
v3:
- Reference the commit that enabled the zerocopy userptr use case to
make it abundandtly clear that this patch only affects that, and not
normal memory userptr. The old commit message already explained that
normal memory userptr is unaffected, but I guess that was not clear
enough.
---
drivers/media/common/videobuf2/frame_vector.c | 2 +-
drivers/media/v4l2-core/videobuf-dma-contig.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/common/videobuf2/frame_vector.c
b/drivers/media/common/videobuf2/frame_vector.c
index 6590987c14bd..e630494da65c 100644
--- a/drivers/media/common/videobuf2/frame_vector.c
+++ b/drivers/media/common/videobuf2/frame_vector.c
@@ -69,7 +69,7 @@ int get_vaddr_frames(unsigned long start, unsigned int
nr_frames,
break;
while (ret < nr_frames && start + PAGE_SIZE <= vma->vm_end) {
- err = follow_pfn(vma, start, [ret]);
+ err = unsafe_follow_pfn(vma, start, [ret]);
if (err) {
if (ret == 0)
ret = err;
diff --git a/drivers/media/v4l2-core/videobuf-dma-contig.c
b/drivers/media/v4l2-core/videobuf-dma-contig.c
index 52312ce2ba05..821c4a76ab96 100644
--- a/drivers/media/v4l2-core/videobuf-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf-dma-contig.c
@@ -183,7 +183,7 @@ static int videobuf_dma_contig_user_get(struct
videobuf_dma_contig_memory *mem,
user_address = untagged_baddr;
while (pages_done < (mem->size >> PAGE_SHIFT)) {
- ret = follow_pfn(vma, user_address, _pfn);
+ ret = unsafe_follow_pfn(vma, user_address, _pfn);
if (ret)
break;
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 00/16] follow_pfn and other iomap races
Hi all,
Round 3 of my patch series to clamp down a bunch of races and gaps
around follow_pfn and other access to iomem mmaps. Previous version:
v1:
https://lore.kernel.org/dri-devel/20201007164426.1812530-1-daniel.vet...@ffwll.ch/
v2:
https://lore.kernel.org/dri-devel/20201009075934.3509076-1-daniel.vet...@ffwll.ch
And the discussion that sparked this journey:
https://lore.kernel.org/dri-devel/20201007164426.1812530-1-daniel.vet...@ffwll.ch/
I was waiting for the testing result for habanalabs from Oded, but I guess
Oded was waiting for my v3.
Changes in v3:
- Bunch of polish all over, no functional changes aside from one barrier
in the resource code, for consistency.
- A few more r-b tags.
Changes in v2:
- tons of small polish all over, thanks to all the reviewers who
spotted issues
- I managed to test at least the generic_access_phys and pci mmap revoke
stuff with a few gdb sessions using our i915 debug tools (hence now also
the drm/i915 patch to properly request all the pci bar regions)
- reworked approach for the pci mmap revoke: Infrastructure moved into
kernel/resource.c, address_space mapping is now set up at open time for
everyone (which required some sysfs changes). Does indeed look a lot
cleaner and a lot less invasive than I feared at first.
The big thing I can't test are all the frame_vector changes in habanalbas,
exynos and media. Gerald has given the s390 patch a spin already.
Review, testing, feedback all very much welcome.
Cheers, Daniel
Daniel Vetter (16):
drm/exynos: Stop using frame_vector helpers
drm/exynos: Use FOLL_LONGTERM for g2d cmdlists
misc/habana: Stop using frame_vector helpers
misc/habana: Use FOLL_LONGTERM for userptr
mm/frame-vector: Use FOLL_LONGTERM
media: videobuf2: Move frame_vector into media subsystem
mm: Close race in generic_access_phys
s390/pci: Remove races against pte updates
mm: Add unsafe_follow_pfn
media/videbuf1|2: Mark follow_pfn usage as unsafe
vfio/type1: Mark follow_pfn as unsafe
PCI: Obey iomem restrictions for procfs mmap
/dev/mem: Only set filp->f_mapping
resource: Move devmem revoke code to resource framework
sysfs: Support zapping of binary attr mmaps
PCI: Revoke mappings like devmem
arch/s390/pci/pci_mmio.c | 98 ++---
drivers/char/mem.c| 86 +--
drivers/gpu/drm/exynos/Kconfig| 1 -
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 48 -
drivers/media/common/videobuf2/Kconfig| 1 -
drivers/media/common/videobuf2/Makefile | 1 +
.../media/common/videobuf2}/frame_vector.c| 54 --
drivers/media/platform/omap/Kconfig | 1 -
drivers/media/v4l2-core/videobuf-dma-contig.c | 2 +-
drivers/misc/habanalabs/Kconfig | 1 -
drivers/misc/habanalabs/common/habanalabs.h | 6 +-
drivers/misc/habanalabs/common/memory.c | 50 -
drivers/pci/pci-sysfs.c | 4 +
drivers/pci/proc.c| 6 ++
drivers/vfio/vfio_iommu_type1.c | 4 +-
fs/sysfs/file.c | 11 ++
include/linux/ioport.h| 6 +-
include/linux/mm.h| 47 +---
include/linux/sysfs.h | 2 +
include/media/frame_vector.h | 47
include/media/videobuf2-core.h| 1 +
kernel/resource.c | 101 +-
mm/Kconfig| 3 -
mm/Makefile | 1 -
mm/memory.c | 76 -
mm/nommu.c| 17 +++
security/Kconfig | 13 +++
27 files changed, 403 insertions(+), 285 deletions(-)
rename {mm => drivers/media/common/videobuf2}/frame_vector.c (85%)
create mode 100644 include/media/frame_vector.h
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 05/16] mm/frame-vector: Use FOLL_LONGTERM
This is used by media/videbuf2 for persistent dma mappings, not just
for a single dma operation and then freed again, so needs
FOLL_LONGTERM.
Unfortunately current pup_locked doesn't support FOLL_LONGTERM due to
locking issues. Rework the code to pull the pup path out from the
mmap_sem critical section as suggested by Jason.
By relying entirely on the vma checks in pin_user_pages and follow_pfn
(for vm_flags and vma_is_fsdax) we can also streamline the code a lot.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Pawel Osciak
Cc: Marek Szyprowski
Cc: Kyungmin Park
Cc: Tomasz Figa
Cc: Mauro Carvalho Chehab
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Signed-off-by: Daniel Vetter
--
v2: Streamline the code and further simplify the loop checks (Jason)
---
mm/frame_vector.c | 50 ++-
1 file changed, 15 insertions(+), 35 deletions(-)
diff --git a/mm/frame_vector.c b/mm/frame_vector.c
index 10f82d5643b6..d44779e56313 100644
--- a/mm/frame_vector.c
+++ b/mm/frame_vector.c
@@ -38,7 +38,6 @@ int get_vaddr_frames(unsigned long start, unsigned int
nr_frames,
struct vm_area_struct *vma;
int ret = 0;
int err;
- int locked;
if (nr_frames == 0)
return 0;
@@ -48,40 +47,25 @@ int get_vaddr_frames(unsigned long start, unsigned int
nr_frames,
start = untagged_addr(start);
- mmap_read_lock(mm);
- locked = 1;
- vma = find_vma_intersection(mm, start, start + 1);
- if (!vma) {
- ret = -EFAULT;
- goto out;
- }
-
- /*
-* While get_vaddr_frames() could be used for transient (kernel
-* controlled lifetime) pinning of memory pages all current
-* users establish long term (userspace controlled lifetime)
-* page pinning. Treat get_vaddr_frames() like
-* get_user_pages_longterm() and disallow it for filesystem-dax
-* mappings.
-*/
- if (vma_is_fsdax(vma)) {
- ret = -EOPNOTSUPP;
- goto out;
- }
-
- if (!(vma->vm_flags & (VM_IO | VM_PFNMAP))) {
+ ret = pin_user_pages_fast(start, nr_frames,
+ FOLL_FORCE | FOLL_WRITE | FOLL_LONGTERM,
+ (struct page **)(vec->ptrs));
+ if (ret > 0) {
vec->got_ref = true;
vec->is_pfns = false;
- ret = pin_user_pages_locked(start, nr_frames,
- gup_flags, (struct page **)(vec->ptrs), );
- goto out;
+ goto out_unlocked;
}
+ mmap_read_lock(mm);
vec->got_ref = false;
vec->is_pfns = true;
do {
unsigned long *nums = frame_vector_pfns(vec);
+ vma = find_vma_intersection(mm, start, start + 1);
+ if (!vma)
+ break;
+
while (ret < nr_frames && start + PAGE_SIZE <= vma->vm_end) {
err = follow_pfn(vma, start, [ret]);
if (err) {
@@ -92,17 +76,13 @@ int get_vaddr_frames(unsigned long start, unsigned int
nr_frames,
start += PAGE_SIZE;
ret++;
}
- /*
-* We stop if we have enough pages or if VMA doesn't completely
-* cover the tail page.
-*/
- if (ret >= nr_frames || start < vma->vm_end)
+ /* Bail out if VMA doesn't completely cover the tail page. */
+ if (start < vma->vm_end)
break;
- vma = find_vma_intersection(mm, start, start + 1);
- } while (vma && vma->vm_flags & (VM_IO | VM_PFNMAP));
+ } while (ret < nr_frames);
out:
- if (locked)
- mmap_read_unlock(mm);
+ mmap_read_unlock(mm);
+out_unlocked:
if (!ret)
ret = -EFAULT;
if (ret > 0)
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 11/16] vfio/type1: Mark follow_pfn as unsafe
The code seems to stuff these pfns into iommu pts (or something like
that, I didn't follow), but there's no mmu_notifier to ensure that
access is synchronized with pte updates.
Hence mark these as unsafe. This means that with
CONFIG_STRICT_FOLLOW_PFN, these will be rejected.
Real fix is to wire up an mmu_notifier ... somehow. Probably means any
invalidate is a fatal fault for this vfio device, but then this
shouldn't ever happen if userspace is reasonable.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Alex Williamson
Cc: Cornelia Huck
Cc: k...@vger.kernel.org
Signed-off-by: Daniel Vetter
---
drivers/vfio/vfio_iommu_type1.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 5fbf0c1f7433..a4d53f3d0a35 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -421,7 +421,7 @@ static int follow_fault_pfn(struct vm_area_struct *vma,
struct mm_struct *mm,
{
int ret;
- ret = follow_pfn(vma, vaddr, pfn);
+ ret = unsafe_follow_pfn(vma, vaddr, pfn);
if (ret) {
bool unlocked = false;
@@ -435,7 +435,7 @@ static int follow_fault_pfn(struct vm_area_struct *vma,
struct mm_struct *mm,
if (ret)
return ret;
- ret = follow_pfn(vma, vaddr, pfn);
+ ret = unsafe_follow_pfn(vma, vaddr, pfn);
}
return ret;
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 01/16] drm/exynos: Stop using frame_vector helpers
All we need are a pages array, pin_user_pages_fast can give us that
directly. Plus this avoids the entire raw pfn side of get_vaddr_frames.
Reviewed-by: John Hubbard
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Signed-off-by: Daniel Vetter
--
v2: Use unpin_user_pages_dirty_lock (John)
---
drivers/gpu/drm/exynos/Kconfig | 1 -
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 47 +++--
2 files changed, 20 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 6417f374b923..43257ef3c09d 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -88,7 +88,6 @@ comment "Sub-drivers"
config DRM_EXYNOS_G2D
bool "G2D"
depends on VIDEO_SAMSUNG_S5P_G2D=n || COMPILE_TEST
- select FRAME_VECTOR
help
Choose this option if you want to use Exynos G2D for DRM.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 967a5cdc120e..ecede41af9b9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -205,7 +205,8 @@ struct g2d_cmdlist_userptr {
dma_addr_t dma_addr;
unsigned long userptr;
unsigned long size;
- struct frame_vector *vec;
+ struct page **pages;
+ unsigned intnpages;
struct sg_table *sgt;
atomic_trefcount;
boolin_pool;
@@ -378,7 +379,6 @@ static void g2d_userptr_put_dma_addr(struct g2d_data *g2d,
bool force)
{
struct g2d_cmdlist_userptr *g2d_userptr = obj;
- struct page **pages;
if (!obj)
return;
@@ -398,15 +398,9 @@ static void g2d_userptr_put_dma_addr(struct g2d_data *g2d,
dma_unmap_sgtable(to_dma_dev(g2d->drm_dev), g2d_userptr->sgt,
DMA_BIDIRECTIONAL, 0);
- pages = frame_vector_pages(g2d_userptr->vec);
- if (!IS_ERR(pages)) {
- int i;
-
- for (i = 0; i < frame_vector_count(g2d_userptr->vec); i++)
- set_page_dirty_lock(pages[i]);
- }
- put_vaddr_frames(g2d_userptr->vec);
- frame_vector_destroy(g2d_userptr->vec);
+ unpin_user_pages_dirty_lock(g2d_userptr->pages, g2d_userptr->npages,
+ true);
+ kvfree(g2d_userptr->pages);
if (!g2d_userptr->out_of_list)
list_del_init(_userptr->list);
@@ -474,35 +468,34 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct
g2d_data *g2d,
offset = userptr & ~PAGE_MASK;
end = PAGE_ALIGN(userptr + size);
npages = (end - start) >> PAGE_SHIFT;
- g2d_userptr->vec = frame_vector_create(npages);
- if (!g2d_userptr->vec) {
+ g2d_userptr->pages = kvmalloc_array(npages, sizeof(*g2d_userptr->pages),
+ GFP_KERNEL);
+ if (!g2d_userptr->pages) {
ret = -ENOMEM;
goto err_free;
}
- ret = get_vaddr_frames(start, npages, FOLL_FORCE | FOLL_WRITE,
- g2d_userptr->vec);
+ ret = pin_user_pages_fast(start, npages, FOLL_FORCE | FOLL_WRITE,
+ g2d_userptr->pages);
if (ret != npages) {
DRM_DEV_ERROR(g2d->dev,
"failed to get user pages from userptr.\n");
if (ret < 0)
- goto err_destroy_framevec;
- ret = -EFAULT;
- goto err_put_framevec;
- }
- if (frame_vector_to_pages(g2d_userptr->vec) < 0) {
+ goto err_destroy_pages;
+ npages = ret;
ret = -EFAULT;
- goto err_put_framevec;
+ goto err_unpin_pages;
}
+ g2d_userptr->npages = npages;
sgt = kzalloc(sizeof(*sgt), GFP_KERNEL);
if (!sgt) {
ret = -ENOMEM;
- goto err_put_framevec;
+ goto err_unpin_pages;
}
ret = sg_alloc_table_from_pages(sgt,
- frame_vector_pages(g2d_userptr->vec),
+ g2d_userptr->pages,
npages, offset, size, GFP_KERNEL);
if (ret < 0) {
DRM_DEV_ERROR(g2d->dev, "failed to get sgt from pages.\n");
@@ -538,11 +531,11 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct
g2d_data *g2d,
err_free_sgt:
kfree(sgt);
[PATCH v3 08/16] s390/pci: Remove races against pte updates
Way back it was a reasonable assumptions that iomem mappings never
change the pfn range they point at. But this has changed:
- gpu drivers dynamically manage their memory nowadays, invalidating
ptes with unmap_mapping_range when buffers get moved
- contiguous dma allocations have moved from dedicated carvetouts to
cma regions. This means if we miss the unmap the pfn might contain
pagecache or anon memory (well anything allocated with GFP_MOVEABLE)
- even /dev/mem now invalidates mappings when the kernel requests that
iomem region when CONFIG_IO_STRICT_DEVMEM is set, see commit
3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims the
region")
Accessing pfns obtained from ptes without holding all the locks is
therefore no longer a good idea. Fix this.
Since zpci_memcpy_from|toio seems to not do anything nefarious with
locks we just need to open code get_pfn and follow_pfn and make sure
we drop the locks only after we're done. The write function also needs
the copy_from_user move, since we can't take userspace faults while
holding the mmap sem.
v2: Move VM_IO | VM_PFNMAP checks around so they keep returning EINVAL
like before (Gerard)
v3: Polish commit message (Niklas)
Reviewed-by: Gerald Schaefer
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Dan Williams
Cc: Kees Cook
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Niklas Schnelle
Cc: Gerald Schaefer
Cc: linux-s...@vger.kernel.org
Cc: Niklas Schnelle
Signed-off-by: Daniel Vetter
---
arch/s390/pci/pci_mmio.c | 98 +++-
1 file changed, 57 insertions(+), 41 deletions(-)
diff --git a/arch/s390/pci/pci_mmio.c b/arch/s390/pci/pci_mmio.c
index 401cf670a243..1a6adbc68ee8 100644
--- a/arch/s390/pci/pci_mmio.c
+++ b/arch/s390/pci/pci_mmio.c
@@ -119,33 +119,15 @@ static inline int __memcpy_toio_inuser(void __iomem *dst,
return rc;
}
-static long get_pfn(unsigned long user_addr, unsigned long access,
- unsigned long *pfn)
-{
- struct vm_area_struct *vma;
- long ret;
-
- mmap_read_lock(current->mm);
- ret = -EINVAL;
- vma = find_vma(current->mm, user_addr);
- if (!vma)
- goto out;
- ret = -EACCES;
- if (!(vma->vm_flags & access))
- goto out;
- ret = follow_pfn(vma, user_addr, pfn);
-out:
- mmap_read_unlock(current->mm);
- return ret;
-}
-
SYSCALL_DEFINE3(s390_pci_mmio_write, unsigned long, mmio_addr,
const void __user *, user_buffer, size_t, length)
{
u8 local_buf[64];
void __iomem *io_addr;
void *buf;
- unsigned long pfn;
+ struct vm_area_struct *vma;
+ pte_t *ptep;
+ spinlock_t *ptl;
long ret;
if (!zpci_is_enabled())
@@ -158,7 +140,7 @@ SYSCALL_DEFINE3(s390_pci_mmio_write, unsigned long,
mmio_addr,
* We only support write access to MIO capable devices if we are on
* a MIO enabled system. Otherwise we would have to check for every
* address if it is a special ZPCI_ADDR and would have to do
-* a get_pfn() which we don't need for MIO capable devices. Currently
+* a pfn lookup which we don't need for MIO capable devices. Currently
* ISM devices are the only devices without MIO support and there is no
* known need for accessing these from userspace.
*/
@@ -176,21 +158,37 @@ SYSCALL_DEFINE3(s390_pci_mmio_write, unsigned long,
mmio_addr,
} else
buf = local_buf;
- ret = get_pfn(mmio_addr, VM_WRITE, );
+ ret = -EFAULT;
+ if (copy_from_user(buf, user_buffer, length))
+ goto out_free;
+
+ mmap_read_lock(current->mm);
+ ret = -EINVAL;
+ vma = find_vma(current->mm, mmio_addr);
+ if (!vma)
+ goto out_unlock_mmap;
+ if (!(vma->vm_flags & (VM_IO | VM_PFNMAP)))
+ goto out_unlock_mmap;
+ ret = -EACCES;
+ if (!(vma->vm_flags & VM_WRITE))
+ goto out_unlock_mmap;
+
+ ret = follow_pte_pmd(vma->vm_mm, mmio_addr, NULL, , NULL, );
if (ret)
- goto out;
- io_addr = (void __iomem *)((pfn << PAGE_SHIFT) |
+ goto out_unlock_mmap;
+
+ io_addr = (void __iomem *)((pte_pfn(*ptep) << PAGE_SHIFT) |
(mmio_addr & ~PAGE_MASK));
- ret = -EFAULT;
if ((unsigned long) io_addr < ZPCI_IOMAP_ADDR_BASE)
- goto out;
-
- if (copy_from_user(buf, user_buffer, length))
- goto out;
+ goto out_unlock_pt;
ret = zpci_memcpy_toio(io_addr, buf, length);
-out:
+out_unlock_pt:
+ pte_unmap_unlock(ptep, ptl);
+out_unlock_mmap:
+ mmap_read_unlock(current->mm);
+out_free:
if (buf != local_buf)
kfree(buf);
[PATCH v3 02/16] drm/exynos: Use FOLL_LONGTERM for g2d cmdlists
The exynos g2d interface is very unusual, but it looks like the
userptr objects are persistent. Hence they need FOLL_LONGTERM.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index ecede41af9b9..1e0c5a7f206e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -475,7 +475,8 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct g2d_data
*g2d,
goto err_free;
}
- ret = pin_user_pages_fast(start, npages, FOLL_FORCE | FOLL_WRITE,
+ ret = pin_user_pages_fast(start, npages,
+ FOLL_FORCE | FOLL_WRITE | FOLL_LONGTERM,
g2d_userptr->pages);
if (ret != npages) {
DRM_DEV_ERROR(g2d->dev,
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 04/16] misc/habana: Use FOLL_LONGTERM for userptr
These are persistent, not just for the duration of a dma operation.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Oded Gabbay
Cc: Omer Shpigelman
Cc: Ofir Bitton
Cc: Tomer Tayar
Cc: Moti Haimovski
Cc: Daniel Vetter
Cc: Greg Kroah-Hartman
Cc: Pawel Piskorski
Signed-off-by: Daniel Vetter
---
drivers/misc/habanalabs/common/memory.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/habanalabs/common/memory.c
b/drivers/misc/habanalabs/common/memory.c
index 327b64479f97..767d3644c033 100644
--- a/drivers/misc/habanalabs/common/memory.c
+++ b/drivers/misc/habanalabs/common/memory.c
@@ -1288,7 +1288,8 @@ static int get_user_memory(struct hl_device *hdev, u64
addr, u64 size,
return -ENOMEM;
}
- rc = pin_user_pages_fast(start, npages, FOLL_FORCE | FOLL_WRITE,
+ rc = pin_user_pages_fast(start, npages,
+FOLL_FORCE | FOLL_WRITE | FOLL_LONGTERM,
userptr->pages);
if (rc != npages) {
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 06/16] media: videobuf2: Move frame_vector into media subsystem
It's the only user. This also garbage collects the CONFIG_FRAME_VECTOR
symbol from all over the tree (well just one place, somehow omap media
driver still had this in its Kconfig, despite not using it).
Reviewed-by: John Hubbard
Acked-by: Mauro Carvalho Chehab
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Pawel Osciak
Cc: Marek Szyprowski
Cc: Kyungmin Park
Cc: Tomasz Figa
Cc: Mauro Carvalho Chehab
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Daniel Vetter
Signed-off-by: Daniel Vetter
--
v3:
- Create a new frame_vector.h header for this (Mauro)
---
drivers/media/common/videobuf2/Kconfig| 1 -
drivers/media/common/videobuf2/Makefile | 1 +
.../media/common/videobuf2}/frame_vector.c| 2 +
drivers/media/platform/omap/Kconfig | 1 -
include/linux/mm.h| 42 -
include/media/frame_vector.h | 47 +++
include/media/videobuf2-core.h| 1 +
mm/Kconfig| 3 --
mm/Makefile | 1 -
9 files changed, 51 insertions(+), 48 deletions(-)
rename {mm => drivers/media/common/videobuf2}/frame_vector.c (99%)
create mode 100644 include/media/frame_vector.h
diff --git a/drivers/media/common/videobuf2/Kconfig
b/drivers/media/common/videobuf2/Kconfig
index edbc99ebba87..d2223a12c95f 100644
--- a/drivers/media/common/videobuf2/Kconfig
+++ b/drivers/media/common/videobuf2/Kconfig
@@ -9,7 +9,6 @@ config VIDEOBUF2_V4L2
config VIDEOBUF2_MEMOPS
tristate
- select FRAME_VECTOR
config VIDEOBUF2_DMA_CONTIG
tristate
diff --git a/drivers/media/common/videobuf2/Makefile
b/drivers/media/common/videobuf2/Makefile
index 77bebe8b202f..54306f8d096c 100644
--- a/drivers/media/common/videobuf2/Makefile
+++ b/drivers/media/common/videobuf2/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
videobuf2-common-objs := videobuf2-core.o
+videobuf2-common-objs += frame_vector.o
ifeq ($(CONFIG_TRACEPOINTS),y)
videobuf2-common-objs += vb2-trace.o
diff --git a/mm/frame_vector.c b/drivers/media/common/videobuf2/frame_vector.c
similarity index 99%
rename from mm/frame_vector.c
rename to drivers/media/common/videobuf2/frame_vector.c
index d44779e56313..6590987c14bd 100644
--- a/mm/frame_vector.c
+++ b/drivers/media/common/videobuf2/frame_vector.c
@@ -8,6 +8,8 @@
#include
#include
+#include
+
/**
* get_vaddr_frames() - map virtual addresses to pfns
* @start: starting user address
diff --git a/drivers/media/platform/omap/Kconfig
b/drivers/media/platform/omap/Kconfig
index f73b5893220d..de16de46c0f4 100644
--- a/drivers/media/platform/omap/Kconfig
+++ b/drivers/media/platform/omap/Kconfig
@@ -12,6 +12,5 @@ config VIDEO_OMAP2_VOUT
depends on VIDEO_V4L2
select VIDEOBUF2_DMA_CONTIG
select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3
- select FRAME_VECTOR
help
V4L2 Display driver support for OMAP2/3 based boards.
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 16b799a0522c..acd60fbf1a5a 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1743,48 +1743,6 @@ int account_locked_vm(struct mm_struct *mm, unsigned
long pages, bool inc);
int __account_locked_vm(struct mm_struct *mm, unsigned long pages, bool inc,
struct task_struct *task, bool bypass_rlim);
-/* Container for pinned pfns / pages */
-struct frame_vector {
- unsigned int nr_allocated; /* Number of frames we have space for */
- unsigned int nr_frames; /* Number of frames stored in ptrs array */
- bool got_ref; /* Did we pin pages by getting page ref? */
- bool is_pfns; /* Does array contain pages or pfns? */
- void *ptrs[]; /* Array of pinned pfns / pages. Use
-* pfns_vector_pages() or pfns_vector_pfns()
-* for access */
-};
-
-struct frame_vector *frame_vector_create(unsigned int nr_frames);
-void frame_vector_destroy(struct frame_vector *vec);
-int get_vaddr_frames(unsigned long start, unsigned int nr_pfns,
-unsigned int gup_flags, struct frame_vector *vec);
-void put_vaddr_frames(struct frame_vector *vec);
-int frame_vector_to_pages(struct frame_vector *vec);
-void frame_vector_to_pfns(struct frame_vector *vec);
-
-static inline unsigned int frame_vector_count(struct frame_vector *vec)
-{
- return vec->nr_frames;
-}
-
-static inline struct page **frame_vector_pages(struct frame_vector *vec)
-{
- if (vec->is_pfns) {
- int err = frame_vector_to_pages(vec);
-
- if (err)
- return ERR_PTR(err);
- }
- return (struct page **)(vec->ptrs);
-}
-
-static inline
Re: [PATCH] drm: add client cap to expose low power modes
On Wed, Oct 21, 2020 at 07:40:48AM +, Simon Ser wrote: > On Wednesday, October 21, 2020 8:54 AM, Ken Huang > wrote: > > > From: Adrian Salido sali...@google.com > > > > Some displays may support Low Power modes, however, these modes may > > require special handling as they would usually require lower OPR > > content on framebuffers. > > I'm not familiar with OPR. Can you explain what it is and what it means > for user-space? Also since this is new uapi, I guess best explanation would include the userspace code that makes sensible use of this. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/ttm: avoid multihop moves in drivers.
On Wed, Oct 21, 2020 at 02:40:31PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Currently drivers get called to move a buffer, but if they have to
> move it temporarily through another space (SYSTEM->VRAM via TT)
> then they can end up with a lot of ttm->driver->ttm call stacks,
> if the temprorary space moves requires eviction.
>
> Instead of letting the driver do all the placement/space for the
> temporary, allow it to report back (-EMULTIHOP) a placement (hop)
> to the move code, which will then do the temporary move, and the
> correct placement move afterwards.
>
> This removes a lot of code from drivers, at the expense of
> adding some midlayering. I've some further ideas on how to turn
> it inside out, but I think this is a good solution to the call
> stack problems.
>
> Signed-off-by: Dave Airlie
So at first I freaked out about this a bit on irc, as in "this is horrible
midlayer madness". But it does look a lot cleaner, it's definitely a step
in the right direction, and I guess for most drivers it's going to be good
enough. Maybe there's going to be drivers which want to have even better
control over where buffers are placed, who's victimized, and what
intermediate steps to take. But doing that demidlayering can be done when
there's a need, I think all the building blocks with the in-flight
untangling are there now.
So I guess I like this now after the initial shock passed :-)
-Daniel
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 139 +++--
> drivers/gpu/drm/drm_gem_vram_helper.c | 3 +-
> drivers/gpu/drm/nouveau/nouveau_bo.c | 115 +++--
> drivers/gpu/drm/qxl/qxl_ttm.c | 3 +-
> drivers/gpu/drm/radeon/radeon_ttm.c| 122 +++---
> drivers/gpu/drm/ttm/ttm_bo.c | 62 +++--
> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 3 +-
> include/drm/ttm/ttm_bo_driver.h| 5 +-
> 8 files changed, 108 insertions(+), 344 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 62f9194b1dd1..0fd4f270d794 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -515,119 +515,6 @@ static int amdgpu_move_blit(struct ttm_buffer_object
> *bo,
> return r;
> }
>
> -/**
> - * amdgpu_move_vram_ram - Copy VRAM buffer to RAM buffer
> - *
> - * Called by amdgpu_bo_move().
> - */
> -static int amdgpu_move_vram_ram(struct ttm_buffer_object *bo, bool evict,
> - struct ttm_operation_ctx *ctx,
> - struct ttm_resource *new_mem)
> -{
> - struct ttm_resource *old_mem = >mem;
> - struct ttm_resource tmp_mem;
> - struct ttm_place placements;
> - struct ttm_placement placement;
> - int r;
> -
> - /* create space/pages for new_mem in GTT space */
> - tmp_mem = *new_mem;
> - tmp_mem.mm_node = NULL;
> - placement.num_placement = 1;
> - placement.placement =
> - placement.num_busy_placement = 1;
> - placement.busy_placement =
> - placements.fpfn = 0;
> - placements.lpfn = 0;
> - placements.mem_type = TTM_PL_TT;
> - placements.flags = 0;
> - r = ttm_bo_mem_space(bo, , _mem, ctx);
> - if (unlikely(r)) {
> - pr_err("Failed to find GTT space for blit from VRAM\n");
> - return r;
> - }
> -
> - r = ttm_tt_populate(bo->bdev, bo->ttm, ctx);
> - if (unlikely(r))
> - goto out_cleanup;
> -
> - /* Bind the memory to the GTT space */
> - r = amdgpu_ttm_backend_bind(bo->bdev, bo->ttm, _mem);
> - if (unlikely(r)) {
> - goto out_cleanup;
> - }
> -
> - /* blit VRAM to GTT */
> - r = amdgpu_move_blit(bo, evict, _mem, old_mem);
> - if (unlikely(r)) {
> - goto out_cleanup;
> - }
> -
> - r = ttm_bo_wait_ctx(bo, ctx);
> - if (unlikely(r))
> - goto out_cleanup;
> -
> - amdgpu_ttm_backend_unbind(bo->bdev, bo->ttm);
> - ttm_resource_free(bo, >mem);
> - ttm_bo_assign_mem(bo, new_mem);
> -out_cleanup:
> - ttm_resource_free(bo, _mem);
> - return r;
> -}
> -
> -/**
> - * amdgpu_move_ram_vram - Copy buffer from RAM to VRAM
> - *
> - * Called by amdgpu_bo_move().
> - */
> -static int amdgpu_move_ram_vram(struct ttm_buffer_object *bo, bool evict,
> - struct ttm_operation_ctx *ctx,
> - struct ttm_resource *new_mem)
> -{
> - struct ttm_resource *old_mem = >mem;
> - struct ttm_resource tmp_mem;
> - struct ttm_placement placement;
> - struct ttm_place placements;
> - int r;
> -
> - /* make space in GTT for old_mem buffer */
> - tmp_mem = *new_mem;
> - tmp_mem.mm_node = NULL;
> - placement.num_placement = 1;
> - placement.placement =
> - placement.num_busy_placement = 1;
> - placement.busy_placement =
> - placements.fpfn = 0;
> -
Re: It appears drm-next TTM cleanup broke something . . .
Hi On 21.10.20 10:14, Daniel Vetter wrote: > On Wed, Oct 21, 2020 at 10:03 AM Thomas Zimmermann > wrote: >> >> Hi >> >> On 19.10.20 21:43, Kevin Brace wrote: >>> Hi Sam, >>> >>> Thanks for asking the question. >>> The current OpenChrome DRM code has these two major issues. >>> >>> 1) It does not support atomic modesetting >>> >>> I do internally have working code to support atomic modesetting, but it is >>> not ready for committing into the upstream OpenChrome DRM repository. >>> In particular, it suffers from a freeze relating to a cursor plane. >>> The freeze is a bad kind that kern.log does not really tell me what is >>> wrong. >>> If I disable hardware cursor, the atomic modesetting based OpenChrome DRM >>> appears to work okay. >>> In other words, I am getting close to getting atomic modesetting working, >>> but I am stuck. >> >> This could be related to the memory problems. See below. Otherwise, I >> suggest to reduce the driver to the minimum functionality that is >> required for modesetting (even without HW cursors) and submit this code >> for review and merging. >> >>> >>> >>> 2) Double allocation of visible portion of frame buffer >>> >>> This is a big problem left behind from the previous developer who developed >>> OpenChrome prior to me. >>> For some reason, the developer wanted to allocate visible portion of the >>> frame buffer to be the maximum possible size supported by the detected >>> monitor when initializing the frame buffer inside OpenChrome DRM code. >>> I believe Radeon DRM does something similar to that. >>> The problem is, OpenChrome DDX allocates an equal sized frame buffer >>> visible portion during the DDX's initialization. >>> This means that we got two same sized visible portions allocated, but >>> OpenChrome DDX and OpenChrome DRM combined should really be allocating only >>> one. >>> At this point, OpenChrome is not supporting double buffering. >>> This double allocation of a visible portion of the frame buffer contributes >>> to a X Server crash when the screen is resized and 16 MB or less (i.e., 8 >>> MB) shared frame buffer is reserved by the system via BIOS setup. >>> I personally think letting OpenChrome DRM allocate the visible portion of >>> the frame buffer is the way to go, but if so, how do I get the DDX or >>> shadow FB to access the frame buffer visible portion allocated by >>> OpenChrome DRM? >>> Any suggestions on what to do about this issue will be greatly appreciated. >>> Perhaps, I should post a question to dri-devel regarding this issue. >>> I really do not know what I should do at this point. >> >> The double allocation is expected. Atomic modesetting requires two >> framebuffers in video memory during the pageflip. You have to sort out >> the modes where 2 framebuffers do not fit into video memory at the same >> time. > > What we have done on severly restricted discrete gpu is to keep one > framebuffer for everyone in vram, and blt the kms framebuffers over as > needed. With all the dirty tracking helpers for atomic that's like a > one-liner to set up (or just slightly more). I think cirrus works like > that (but it's using cpu memcpy since that's the only thing that > exists, I guess openchrome could even use the blitter for this). A yes, converting to SHMEM is also an option. But it prevents any kind of 3d acceleration, if you want to add that as well. > > The more usual approach is what nouveau guys already explained: Just > run fbcon at very low resolution so it doesn't consume too much space. A better approach is to kill openchromes custom fbdev implementation entirely. During a review, we'd probably ask you to do this anyway. :) Go for the generic fbdev emulation and set struct drm_mode_config.prefer_shadow_fbdev to true. This will give you a shadow buffer for the console, and the actual fbdev framebuffer can be evicted from video memory when the space is required. Best regards Thomas > -Daniel > >> The mode_valid callback in struct drm_mode_config_funcs [1] is a good >> place to do this. Check the mode's pixels with the maximum BPC against >> the available memory. Example code is at [2]. You should also plane for >> common additional layers, such as HW cursors, to require video memory. >> So maybe test the mode against 80% of the video memory. >> >> Best regards >> Thomas >> >> [1] >> https://cgit.freedesktop.org/openchrome/drm-openchrome/tree/drivers/gpu/drm/openchrome/openchrome_fb.c?h=drm-next-5.10=22e0ee2460b4b70cde562b7a3818ae94c2786f46#n102 >> >> [2] >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_gem_vram_helper.c?h=v5.9#n1285 >> >>> >>> Regards, >>> >>> Kevin Brace >>> Brace Computer Laboratory blog >>> https://bracecomputerlab.com >>> >>> Sent: Sunday, October 18, 2020 at 2:04 PM From: "Sam Ravnborg" To: "Kevin Brace" Cc: dri-devel@lists.freedesktop.org, "Dave Airlie" Subject: Re: It appears drm-next TTM cleanup broke something . . .
Re: [PATCH 0/3] drm/msm: kthread_worker conversion
On Tue, Oct 20, 2020 at 01:26:29PM -0700, Rob Clark wrote: > On Tue, Oct 20, 2020 at 11:14 AM Daniel Vetter wrote: > > > > On Tue, Oct 20, 2020 at 7:23 PM Rob Clark wrote: > > > > > > On Tue, Oct 20, 2020 at 10:02 AM Daniel Vetter wrote: > > > > > > > > On Tue, Oct 20, 2020 at 5:08 PM Rob Clark wrote: > > > > > > > > > > On Tue, Oct 20, 2020 at 7:29 AM Daniel Vetter wrote: > > > > > > > > > > > > On Tue, Oct 20, 2020 at 4:01 PM Rob Clark > > > > > > wrote: > > > > > > > > > > > > > > On Tue, Oct 20, 2020 at 1:24 AM Daniel Vetter > > > > > > > wrote: > > > > > > > > > > > > > > > > On Mon, Oct 19, 2020 at 02:10:50PM -0700, Rob Clark wrote: > > > > > > > > > From: Rob Clark > > > > > > > > > > > > > > > > > > In particular, converting the async atomic commit (for cursor > > > > > > > > > updates, > > > > > > > > > etc) to SCHED_FIFO kthread_worker helps with some cases where > > > > > > > > > we > > > > > > > > > wouldn't manage to flush the updates within the > > > > > > > > > 1ms-before-vblank > > > > > > > > > deadline resulting in fps drops when there is cursor movement. > > > > > > > > > > > > > > > > > > Rob Clark (3): > > > > > > > > > drm/msm/gpu: Convert retire/recover work to kthread_worker > > > > > > > > > drm/msm/kms: Update msm_kms_init/destroy > > > > > > > > > drm/msm/atomic: Convert to per-CRTC kthread_work > > > > > > > > > > > > > > > > So i915 has it's own commit worker already for $reasons, but I > > > > > > > > don't think > > > > > > > > that's a good path to go down with more drivers. And the > > > > > > > > problem seems > > > > > > > > entirely generic in nature ... > > > > > > > > > > > > > > I'm not *entirely* sure what your point is here? This is just > > > > > > > migrating away from a shared ordered wq to per-crtc kthread so > > > > > > > that we > > > > > > > don't miss vblank deadlines for silly reasons (and then stall on > > > > > > > the > > > > > > > next frame's pageflip because we are still waiting for the cursor > > > > > > > update to latch). Kind of like vblank-work but scheduled prior > > > > > > > to, > > > > > > > rather than after, vblank. > > > > > > > > > > > > > > And you're right that the problem is partially generic.. hw that > > > > > > > (a) > > > > > > > doesn't have true async (cursor and/or otherwise) updates, and > > > > > > > (b) has > > > > > > > various flush bits that latch register updates on vblank, is not > > > > > > > that > > > > > > > uncommon. But the current atomic helper API would have to be a > > > > > > > bit > > > > > > > redesigned to look more like the interface between msm_atomic and > > > > > > > the > > > > > > > display backend. That is a fair bit of churn for re-using a > > > > > > > small bit > > > > > > > of code. > > > > > > > > > > > > I was making some assumptions about what you're doing, and I was > > > > > > wrong. So I went and tried to understand what's actually going on > > > > > > here. > > > > > > > > > > > > I'm trying to understand what exactly you've added with that async > > > > > > msm > > > > > > support 2d99ced787e3d. I think this breaks the state structure > > > > > > update > > > > > > model, you can't access any ->state pointers from the commit > > > > > > functions > > > > > > after you've called drm_atomic_helper_commit_hw_done, or you might > > > > > > have a use after free. And that seems to be happening from this > > > > > > commit > > > > > > work thing you added to your existing commit work that the atomic > > > > > > helpers provide already. > > > > > > > > > > > > The various commit functions seem to grab various state objects by > > > > > > just chasing pointers from the objects (instead of the > > > > > > drm_atomic_state stuff), so this all feels like it's yolo > > > > > > free-wheeling. > > > > > > > > > > > > You also seem to be using the async_commit stuff from the atomic > > > > > > helpers (which is actually synchronous (i.e. blocking) from the pov > > > > > > of > > > > > > how the code runs, but seems to be for mdp5 only and not others. > > > > > > Also > > > > > > your can_do_async still checks for legacy_cursor_update (maybe a > > > > > > leftover, or needed on !mdp5 platforms) and ->async_update. > > > > > > > > > > > > I'm thoroughly confused how this all works. > > > > > > > > > > The legacy_cursor_update is really the thing that motivated the async > > > > > commit support in the first place. Sadly we still have userspace that > > > > > expects to be able to use legacy cursor API, and that it will be > > > > > nonblocking (and not cause fps drop). (I'm not a fan of the legacy > > > > > cursor UAPI.. don't hate the player..) > > > > > > > > Yeah this is why we have these atomic_async_check/commit functions, > > > > and msm is even using them for mdp5. Not hating the player here at > > > > all. > > > > > > > > > The premise is to do everything in terms of crtc_mask, although yeah, > > > > > it looks like there are a few points that need to look
Re: It appears drm-next TTM cleanup broke something . . .
On Wed, Oct 21, 2020 at 10:03 AM Thomas Zimmermann wrote: > > Hi > > On 19.10.20 21:43, Kevin Brace wrote: > > Hi Sam, > > > > Thanks for asking the question. > > The current OpenChrome DRM code has these two major issues. > > > > 1) It does not support atomic modesetting > > > > I do internally have working code to support atomic modesetting, but it is > > not ready for committing into the upstream OpenChrome DRM repository. > > In particular, it suffers from a freeze relating to a cursor plane. > > The freeze is a bad kind that kern.log does not really tell me what is > > wrong. > > If I disable hardware cursor, the atomic modesetting based OpenChrome DRM > > appears to work okay. > > In other words, I am getting close to getting atomic modesetting working, > > but I am stuck. > > This could be related to the memory problems. See below. Otherwise, I > suggest to reduce the driver to the minimum functionality that is > required for modesetting (even without HW cursors) and submit this code > for review and merging. > > > > > > > 2) Double allocation of visible portion of frame buffer > > > > This is a big problem left behind from the previous developer who developed > > OpenChrome prior to me. > > For some reason, the developer wanted to allocate visible portion of the > > frame buffer to be the maximum possible size supported by the detected > > monitor when initializing the frame buffer inside OpenChrome DRM code. > > I believe Radeon DRM does something similar to that. > > The problem is, OpenChrome DDX allocates an equal sized frame buffer > > visible portion during the DDX's initialization. > > This means that we got two same sized visible portions allocated, but > > OpenChrome DDX and OpenChrome DRM combined should really be allocating only > > one. > > At this point, OpenChrome is not supporting double buffering. > > This double allocation of a visible portion of the frame buffer contributes > > to a X Server crash when the screen is resized and 16 MB or less (i.e., 8 > > MB) shared frame buffer is reserved by the system via BIOS setup. > > I personally think letting OpenChrome DRM allocate the visible portion of > > the frame buffer is the way to go, but if so, how do I get the DDX or > > shadow FB to access the frame buffer visible portion allocated by > > OpenChrome DRM? > > Any suggestions on what to do about this issue will be greatly appreciated. > > Perhaps, I should post a question to dri-devel regarding this issue. > > I really do not know what I should do at this point. > > The double allocation is expected. Atomic modesetting requires two > framebuffers in video memory during the pageflip. You have to sort out > the modes where 2 framebuffers do not fit into video memory at the same > time. What we have done on severly restricted discrete gpu is to keep one framebuffer for everyone in vram, and blt the kms framebuffers over as needed. With all the dirty tracking helpers for atomic that's like a one-liner to set up (or just slightly more). I think cirrus works like that (but it's using cpu memcpy since that's the only thing that exists, I guess openchrome could even use the blitter for this). The more usual approach is what nouveau guys already explained: Just run fbcon at very low resolution so it doesn't consume too much space. -Daniel > The mode_valid callback in struct drm_mode_config_funcs [1] is a good > place to do this. Check the mode's pixels with the maximum BPC against > the available memory. Example code is at [2]. You should also plane for > common additional layers, such as HW cursors, to require video memory. > So maybe test the mode against 80% of the video memory. > > Best regards > Thomas > > [1] > https://cgit.freedesktop.org/openchrome/drm-openchrome/tree/drivers/gpu/drm/openchrome/openchrome_fb.c?h=drm-next-5.10=22e0ee2460b4b70cde562b7a3818ae94c2786f46#n102 > > [2] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_gem_vram_helper.c?h=v5.9#n1285 > > > > > Regards, > > > > Kevin Brace > > Brace Computer Laboratory blog > > https://bracecomputerlab.com > > > > > >> Sent: Sunday, October 18, 2020 at 2:04 PM > >> From: "Sam Ravnborg" > >> To: "Kevin Brace" > >> Cc: dri-devel@lists.freedesktop.org, "Dave Airlie" > >> Subject: Re: It appears drm-next TTM cleanup broke something . . . > >> > >> Hi Kevin. > >> > >> On Sun, Oct 18, 2020 at 09:15:17PM +0200, Kevin Brace wrote: > >>> As usual, I pulled in DRM repository code for an out of tree OpenChrome > >>> DRM repository a few days ago. > >> > >> I know you have been working on and off on the openchrome driver for a > >> long time now. Any chance we will see the driver submitted for upstream > >> soon? > >> > >> Sam > >> > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > -- > Thomas Zimmermann > Graphics Driver Developer >
Re: It appears drm-next TTM cleanup broke something . . .
Hi On 19.10.20 21:43, Kevin Brace wrote: > Hi Sam, > > Thanks for asking the question. > The current OpenChrome DRM code has these two major issues. > > 1) It does not support atomic modesetting > > I do internally have working code to support atomic modesetting, but it is > not ready for committing into the upstream OpenChrome DRM repository. > In particular, it suffers from a freeze relating to a cursor plane. > The freeze is a bad kind that kern.log does not really tell me what is wrong. > If I disable hardware cursor, the atomic modesetting based OpenChrome DRM > appears to work okay. > In other words, I am getting close to getting atomic modesetting working, but > I am stuck. This could be related to the memory problems. See below. Otherwise, I suggest to reduce the driver to the minimum functionality that is required for modesetting (even without HW cursors) and submit this code for review and merging. > > > 2) Double allocation of visible portion of frame buffer > > This is a big problem left behind from the previous developer who developed > OpenChrome prior to me. > For some reason, the developer wanted to allocate visible portion of the > frame buffer to be the maximum possible size supported by the detected > monitor when initializing the frame buffer inside OpenChrome DRM code. > I believe Radeon DRM does something similar to that. > The problem is, OpenChrome DDX allocates an equal sized frame buffer visible > portion during the DDX's initialization. > This means that we got two same sized visible portions allocated, but > OpenChrome DDX and OpenChrome DRM combined should really be allocating only > one. > At this point, OpenChrome is not supporting double buffering. > This double allocation of a visible portion of the frame buffer contributes > to a X Server crash when the screen is resized and 16 MB or less (i.e., 8 MB) > shared frame buffer is reserved by the system via BIOS setup. > I personally think letting OpenChrome DRM allocate the visible portion of the > frame buffer is the way to go, but if so, how do I get the DDX or shadow FB > to access the frame buffer visible portion allocated by OpenChrome DRM? > Any suggestions on what to do about this issue will be greatly appreciated. > Perhaps, I should post a question to dri-devel regarding this issue. > I really do not know what I should do at this point. The double allocation is expected. Atomic modesetting requires two framebuffers in video memory during the pageflip. You have to sort out the modes where 2 framebuffers do not fit into video memory at the same time. The mode_valid callback in struct drm_mode_config_funcs [1] is a good place to do this. Check the mode's pixels with the maximum BPC against the available memory. Example code is at [2]. You should also plane for common additional layers, such as HW cursors, to require video memory. So maybe test the mode against 80% of the video memory. Best regards Thomas [1] https://cgit.freedesktop.org/openchrome/drm-openchrome/tree/drivers/gpu/drm/openchrome/openchrome_fb.c?h=drm-next-5.10=22e0ee2460b4b70cde562b7a3818ae94c2786f46#n102 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_gem_vram_helper.c?h=v5.9#n1285 > > Regards, > > Kevin Brace > Brace Computer Laboratory blog > https://bracecomputerlab.com > > >> Sent: Sunday, October 18, 2020 at 2:04 PM >> From: "Sam Ravnborg" >> To: "Kevin Brace" >> Cc: dri-devel@lists.freedesktop.org, "Dave Airlie" >> Subject: Re: It appears drm-next TTM cleanup broke something . . . >> >> Hi Kevin. >> >> On Sun, Oct 18, 2020 at 09:15:17PM +0200, Kevin Brace wrote: >>> As usual, I pulled in DRM repository code for an out of tree OpenChrome DRM >>> repository a few days ago. >> >> I know you have been working on and off on the openchrome driver for a >> long time now. Any chance we will see the driver submitted for upstream soon? >> >> Sam >> > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_0x680DC11D530B7A23.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: add client cap to expose low power modes
On Wednesday, October 21, 2020 8:54 AM, Ken Huang wrote: > From: Adrian Salido sali...@google.com > > Some displays may support Low Power modes, however, these modes may > require special handling as they would usually require lower OPR > content on framebuffers. I'm not familiar with OPR. Can you explain what it is and what it means for user-space? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4] drm/bridge: add it6505 driver
This adds support for the iTE IT6505. This device can convert DPI signal to DP output. From: Allen Chen Signed-off-by: Jitao Shi Signed-off-by: Pi-Hsun Shih Signed-off-by: Yilun Lin Signed-off-by: Hermes Wu Signed-off-by: Allen Chen --- drivers/gpu/drm/bridge/Kconfig |7 + drivers/gpu/drm/bridge/Makefile |1 + drivers/gpu/drm/bridge/ite-it6505.c | 3344 +++ 3 files changed, 3352 insertions(+) create mode 100644 drivers/gpu/drm/bridge/ite-it6505.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index ef91646441b16..1e9c6ade786b1 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -61,6 +61,13 @@ config DRM_LONTIUM_LT9611 HDMI signals Please say Y if you have such hardware. +config DRM_ITE_IT6505 + tristate "ITE IT6505 DisplayPort bridge" + depends on OF + select DRM_KMS_HELPER + help + ITE IT6505 DisplayPort bridge chip driver. + config DRM_LVDS_CODEC tristate "Transparent LVDS encoders and decoders support" depends on OF diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index 2b3aff104e466..1f8cbc27a0643 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o +obj-$(CONFIG_DRM_ITE_IT6505) += ite-it6505.o obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += megachips-stdp-ge-b850v3-fw.o obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o diff --git a/drivers/gpu/drm/bridge/ite-it6505.c b/drivers/gpu/drm/bridge/ite-it6505.c new file mode 100644 index 0..8ffcaf1158801 --- /dev/null +++ b/drivers/gpu/drm/bridge/ite-it6505.c @@ -0,0 +1,3344 @@ +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +/* + * Copyright (c) 2020, The Linux Foundation. All rights reserved. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#define REG_IC_VER 0x04 + +#define REG_RESET_CTRL 0x05 +#define VIDEO_RESET BIT(0) +#define AUDIO_RESET BIT(1) +#define ALL_LOGIC_RESET BIT(2) +#define AUX_RESET BIT(3) +#define HDCP_RESET BIT(4) + +#define INT_STATUS_01 0x06 +#define INT_MASK_01 0x09 +#define INT_HPD_CHANGE BIT(0) +#define INT_RECEIVE_HPD_IRQ BIT(1) +#define INT_SCDT_CHANGE BIT(2) +#define INT_HDCP_FAIL BIT(3) +#define INT_HDCP_DONE BIT(4) + +#define INT_STATUS_02 0x07 +#define INT_MASK_02 0x0A +#define INT_AUX_CMD_FAIL BIT(0) +#define INT_HDCP_KSV_CHECK BIT(1) +#define INT_AUDIO_FIFO_ERROR BIT(2) + +#define INT_STATUS_03 0x08 +#define INT_MASK_03 0x0B +#define INT_LINK_TRAIN_FAIL BIT(4) +#define INT_VID_FIFO_ERROR BIT(5) +#define INT_IO_LATCH_FIFO_OVERFLOW BIT(7) + +#define REG_SYSTEM_STS 0x0D +#define INT_STS BIT(0) +#define HPD_STS BIT(1) +#define VIDEO_STB BIT(2) + +#define REG_LINK_TRAIN_STS 0x0E +#define LINK_STATE_CR BIT(2) +#define LINK_STATE_EQ BIT(3) +#define LINK_STATE_NORP BIT(4) + +#define REG_BANK_SEL 0x0F +#define REG_CLK_CTRL0 0x10 +#define M_PCLK_DELAY 0x03 + +#define REG_AUX_OPT 0x11 +#define AUX_AUTO_RST BIT(0) +#define AUX_FIX_FREQ BIT(3) + +#define REG_DATA_CTRL0 0x12 +#define VIDEO_LATCH_EDGE BIT(4) +#define ENABLE_PCLK_COUNTER BIT(7) + +#define REG_PCLK_COUNTER_VALUE 0x13 + +#define REG_501_FIFO_CTRL 0x15 +#define RST_501_FIFO BIT(1) + +#define REG_TRAIN_CTRL0 0x16 +#define FORCE_LBR BIT(0) +#define LANE_COUNT_MASK 0x06 +#define LANE_SWAP BIT(3) +#define SPREAD_AMP_5 BIT(4) +#define FORCE_CR_DONE BIT(5) +#define FORCE_EQ_DONE BIT(6) + +#define REG_TRAIN_CTRL1 0x17 +#define AUTO_TRAIN BIT(0) +#define MANUAL_TRAIN BIT(1) +#define FORCE_RETRAIN BIT(2) + +#define REG_AUX_CTRL 0x23 +#define CLR_EDID_FIFO BIT(0) +#define AUX_USER_MODE BIT(1) +#define AUX_NO_SEGMENT_WR BIT(6) +#define AUX_EN_FIFO_READ BIT(7) + +#define REG_AUX_ADR_0_7 0x24 +#define REG_AUX_ADR_8_15 0x25 +#define REG_AUX_ADR_16_19 0x26 +#define REG_AUX_OUT_DATA0 0x27 + +#define REG_AUX_CMD_REQ 0x2B +#define AUX_BUSY BIT(5) + +#define REG_AUX_DATA_0_7 0x2C +#define REG_AUX_DATA_8_15 0x2D +#define REG_AUX_DATA_16_23 0x2E +#define REG_AUX_DATA_24_31 0x2F + +#define REG_AUX_DATA_FIFO 0x2F + +#define REG_AUX_ERROR_STS 0x9F +#define M_AUX_REQ_FAIL 0x03 + +#define REG_HDCP_CTRL1 0x38 +#define HDCP_CP_ENABLE BIT(0) + +#define REG_HDCP_TRIGGER 0x39 +#define HDCP_TRIGGER_START BIT(0) +#define HDCP_TRIGGER_CPIRQ BIT(1) +#define HDCP_TRIGGER_KSV_DONE BIT(4) +#define HDCP_TRIGGER_KSV_FAIL BIT(5) + +#define REG_HDCP_CTRL2 0x3A +#define HDCP_AN_SEL BIT(0) +#define
[PATCH v3] drm/msm/dp: add opp_table corner voting support base on dp_ink_clk rate
Set link rate by using OPP set rate api so that CX level will be set
accordingly based on the link rate.
Changes in v2:
-- remove dev from dp_ctrl_put() parameters
-- Add more information to commit message
Changes in v3:
-- return when dev_pm_opp_set_clkname() failed
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_ctrl.c| 28 ++
drivers/gpu/drm/msm/dp/dp_display.c | 2 +-
drivers/gpu/drm/msm/dp/dp_power.c | 44 ++---
drivers/gpu/drm/msm/dp/dp_power.h | 2 +-
4 files changed, 70 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 76e891c91c6e..f12767793211 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -76,6 +77,8 @@ struct dp_ctrl_private {
struct dp_parser *parser;
struct dp_catalog *catalog;
+ struct opp_table *opp_table;
+
struct completion idle_comp;
struct completion video_comp;
};
@@ -1833,6 +1836,7 @@ struct dp_ctrl *dp_ctrl_get(struct device *dev, struct
dp_link *link,
struct dp_parser *parser)
{
struct dp_ctrl_private *ctrl;
+ int ret;
if (!dev || !panel || !aux ||
!link || !catalog) {
@@ -1846,6 +1850,21 @@ struct dp_ctrl *dp_ctrl_get(struct device *dev, struct
dp_link *link,
return ERR_PTR(-ENOMEM);
}
+ ctrl->opp_table = dev_pm_opp_set_clkname(dev, "ctrl_link");
+ if (IS_ERR(ctrl->opp_table)) {
+ dev_err(dev, "invalid DP OPP table in device tree\n");
+ /* caller do PTR_ERR(ctrl->opp_table) */
+ return (struct dp_ctrl *)ctrl->opp_table;
+ }
+
+ /* OPP table is optional */
+ ret = dev_pm_opp_of_add_table(dev);
+ if (ret) {
+ dev_err(dev, "failed to add DP OPP table\n");
+ dev_pm_opp_put_clkname(ctrl->opp_table);
+ ctrl->opp_table = NULL;
+ }
+
init_completion(>idle_comp);
init_completion(>video_comp);
@@ -1863,4 +1882,13 @@ struct dp_ctrl *dp_ctrl_get(struct device *dev, struct
dp_link *link,
void dp_ctrl_put(struct dp_ctrl *dp_ctrl)
{
+ struct dp_ctrl_private *ctrl;
+
+ ctrl = container_of(dp_ctrl, struct dp_ctrl_private, dp_ctrl);
+
+ if (ctrl->opp_table) {
+ dev_pm_opp_of_remove_table(ctrl->dev);
+ dev_pm_opp_put_clkname(ctrl->opp_table);
+ ctrl->opp_table = NULL;
+ }
}
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index c0665a0a4c78..f76139dd495a 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -702,7 +702,7 @@ static int dp_init_sub_modules(struct dp_display_private
*dp)
goto error;
}
- dp->power = dp_power_get(dp->parser);
+ dp->power = dp_power_get(dev, dp->parser);
if (IS_ERR(dp->power)) {
rc = PTR_ERR(dp->power);
DRM_ERROR("failed to initialize power, rc = %d\n", rc);
diff --git a/drivers/gpu/drm/msm/dp/dp_power.c
b/drivers/gpu/drm/msm/dp/dp_power.c
index 17c1fc6a2d44..9c4ea00a5f2a 100644
--- a/drivers/gpu/drm/msm/dp/dp_power.c
+++ b/drivers/gpu/drm/msm/dp/dp_power.c
@@ -8,12 +8,14 @@
#include
#include
#include
+#include
#include "dp_power.h"
#include "msm_drv.h"
struct dp_power_private {
struct dp_parser *parser;
struct platform_device *pdev;
+ struct device *dev;
struct clk *link_clk_src;
struct clk *pixel_provider;
struct clk *link_provider;
@@ -148,18 +150,51 @@ static int dp_power_clk_deinit(struct dp_power_private
*power)
return 0;
}
+static int dp_power_clk_set_link_rate(struct dp_power_private *power,
+ struct dss_clk *clk_arry, int num_clk, int enable)
+{
+ u32 rate;
+ int i, rc = 0;
+
+ for (i = 0; i < num_clk; i++) {
+ if (clk_arry[i].clk) {
+ if (clk_arry[i].type == DSS_CLK_PCLK) {
+ if (enable)
+ rate = clk_arry[i].rate;
+ else
+ rate = 0;
+
+ rc = dev_pm_opp_set_rate(power->dev, rate);
+ if (rc)
+ break;
+ }
+
+ }
+ }
+ return rc;
+}
+
static int dp_power_clk_set_rate(struct dp_power_private *power,
enum dp_pm_type module, bool enable)
{
int rc = 0;
struct dss_module_power *mp = >parser->mp[module];
- if (enable) {
- rc = msm_dss_clk_set_rate(mp->clk_config, mp->num_clk);
+ if (module == DP_CTRL_PM) {
+ rc =
[PATCH] drm/bridge: lvds-codec: Use dev_err_probe for error handling
dev_err_probe function simplifies error handling. So use the same in probe
function wherever possible.
Signed-off-by: Biju Das
---
drivers/gpu/drm/bridge/lvds-codec.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
b/drivers/gpu/drm/bridge/lvds-codec.c
index f52ccffc1bd1..dcf579a4cf83 100644
--- a/drivers/gpu/drm/bridge/lvds-codec.c
+++ b/drivers/gpu/drm/bridge/lvds-codec.c
@@ -80,7 +80,6 @@ static int lvds_codec_probe(struct platform_device *pdev)
struct device_node *panel_node;
struct drm_panel *panel;
struct lvds_codec *lvds_codec;
- int ret;
lvds_codec = devm_kzalloc(dev, sizeof(*lvds_codec), GFP_KERNEL);
if (!lvds_codec)
@@ -90,13 +89,9 @@ static int lvds_codec_probe(struct platform_device *pdev)
lvds_codec->connector_type = (uintptr_t)of_device_get_match_data(dev);
lvds_codec->vcc = devm_regulator_get(lvds_codec->dev, "power");
- if (IS_ERR(lvds_codec->vcc)) {
- ret = PTR_ERR(lvds_codec->vcc);
- if (ret != -EPROBE_DEFER)
- dev_err(lvds_codec->dev,
- "Unable to get \"vcc\" supply: %d\n", ret);
- return ret;
- }
+ if (IS_ERR(lvds_codec->vcc))
+ return dev_err_probe(dev, PTR_ERR(lvds_codec->vcc),
+"Unable to get \"vcc\" supply\n");
lvds_codec->powerdown_gpio = devm_gpiod_get_optional(dev, "powerdown",
GPIOD_OUT_HIGH);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH resend] vgacon: fix a UAF in do_update_region()
I got a UAF report in do_update_region() when I doing fuzz test. [ 51.161905] BUG: KASAN: use-after-free in do_update_region+0x579/0x600 [ 51.161918] Read of size 2 at addr 88800010 by task test/295 [ 51.161957] CPU: 2 PID: 295 Comm: test Not tainted 5.7.0+ #975 [ 51.161969] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 51.161976] Call Trace: [ 51.162001] dump_stack+0xc6/0x11e [ 51.162019] ? do_update_region+0x579/0x600 [ 51.162047] print_address_description.constprop.6+0x1a/0x220 [ 51.162083] ? vprintk_func+0x66/0xed [ 51.162100] ? do_update_region+0x579/0x600 [ 51.162112] ? do_update_region+0x579/0x600 [ 51.162128] kasan_report.cold.9+0x37/0x7c [ 51.162151] ? do_update_region+0x579/0x600 [ 51.162173] do_update_region+0x579/0x600 [ 51.162207] ? con_get_trans_old+0x230/0x230 [ 51.162229] ? retint_kernel+0x10/0x10 [ 51.162278] csi_J+0x557/0xa00 [ 51.162307] do_con_trol+0x49af/0x5cc0 [ 51.162330] ? lock_downgrade+0x720/0x720 [ 51.162347] ? reset_palette+0x1b0/0x1b0 [ 51.162369] ? lockdep_hardirqs_on_prepare+0x379/0x540 [ 51.162393] ? notifier_call_chain+0x11b/0x160 [ 51.162438] do_con_write.part.24+0xb0a/0x1a30 [ 51.162501] ? do_con_trol+0x5cc0/0x5cc0 [ 51.162522] ? console_unlock+0x7b8/0xb00 [ 51.162555] ? __mutex_unlock_slowpath+0xd4/0x670 [ 51.162574] ? this_tty+0xe0/0xe0 [ 51.162589] ? console_unlock+0x559/0xb00 [ 51.162605] ? wait_for_completion+0x260/0x260 [ 51.162638] con_write+0x31/0xb0 [ 51.162658] n_tty_write+0x4fa/0xd40 [ 51.162710] ? n_tty_read+0x1800/0x1800 [ 51.162730] ? prepare_to_wait_exclusive+0x270/0x270 [ 51.162754] ? __might_fault+0x175/0x1b0 [ 51.162783] tty_write+0x42b/0x8d0 [ 51.162795] ? n_tty_read+0x1800/0x1800 [ 51.162825] ? tty_lookup_driver+0x450/0x450 [ 51.162848] __vfs_write+0x7c/0x100 [ 51.162875] vfs_write+0x1c9/0x510 [ 51.162901] ksys_write+0xff/0x200 [ 51.162918] ? __ia32_sys_read+0xb0/0xb0 [ 51.162940] ? do_syscall_64+0x1a/0x520 [ 51.162957] ? lockdep_hardirqs_on_prepare+0x379/0x540 [ 51.162984] do_syscall_64+0xa1/0x520 [ 51.163008] entry_SYSCALL_64_after_hwframe+0x49/0xb3 After vgacon_set_origin() is called in set_origin(), the vc_origin is set to vga_vram_base, the vc_pos should between vga_vram_base and vga_vram_end. But we still use vc_screenbuf_size, if the vga_vram_size is smaller than vc_screenbuf_size, vc_pos may be out of bound, using it will cause a use-after-free(or out-of-bounds). Fix this by calling vc_resize() if vga_vram_size is smaller than vc_screenbuf_size. Signed-off-by: Yang Yingliang --- drivers/video/console/vgacon.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c index 998b0de..2ee3d62 100644 --- a/drivers/video/console/vgacon.c +++ b/drivers/video/console/vgacon.c @@ -1336,6 +1336,9 @@ static int vgacon_set_origin(struct vc_data *c) if (vga_is_gfx || /* We don't play origin tricks in graphic modes */ (console_blanked && !vga_palette_blanked)) /* Nor we write to blanked screens */ return 0; + + if (c->vc_screenbuf_size > vga_vram_size) + vc_resize(c, screen_info.orig_video_cols, screen_info.orig_video_lines); c->vc_origin = c->vc_visible_origin = vga_vram_base; vga_set_mem_top(c); vga_rolled_over = 0; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH resend] vgacon: fix a UAF in do_update_region()
C reproducer:
// autogenerated by syzkaller (https://github.com/google/syzkaller)
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
static long syz_open_dev(volatile long a0, volatile long a1, volatile
long a2)
{
if (a0 == 0xc || a0 == 0xb) {
char buf[128];
sprintf(buf, "/dev/%s/%d:%d", a0 == 0xc ? "char" : "block",
(uint8_t)a1, (uint8_t)a2);
return open(buf, O_RDWR, 0);
} else {
char buf[1024];
char* hash;
strncpy(buf, (char*)a0, sizeof(buf) - 1);
buf[sizeof(buf) - 1] = 0;
while ((hash = strchr(buf, '#'))) {
*hash = '0' + (char)(a1 % 10);
a1 /= 10;
}
return open(buf, a2, 0);
}
}
uint64_t r[4] = {0x, 0x,
0x, 0x};
int main(void)
{
syscall(__NR_mmap, 0x2000ul, 0x100ul, 3ul, 0x32ul, -1, 0);
intptr_t res = 0;
res = syz_open_dev(0xc, 4, 1);
if (res != -1)
r[0] = res;
syscall(__NR_ioctl, r[0], 0x4b3aul, 1ul);
res = syz_open_dev(0xc, 4, 1);
if (res != -1)
r[1] = res;
*(uint16_t*)0x2000 = 0x4d;
*(uint16_t*)0x2002 = 0x1000;
*(uint16_t*)0x2004 = 0xf1;
syscall(__NR_ioctl, r[1], 0x5609ul, 0x2000ul);
res = syz_open_dev(0xc, 4, 1);
if (res != -1)
r[2] = res;
syscall(__NR_ioctl, r[2], 0x4b3aul, 0ul);
res = syz_open_dev(0xc, 4, 1);
if (res != -1)
r[3] = res;
*(uint8_t*)0x2840 = 0x7f;
*(uint8_t*)0x2841 = 0x45;
*(uint8_t*)0x2842 = 0x4c;
*(uint8_t*)0x2843 = 0x46;
*(uint8_t*)0x2844 = 5;
*(uint8_t*)0x2845 = 6;
*(uint8_t*)0x2846 = 5;
*(uint8_t*)0x2847 = 9;
*(uint64_t*)0x2848 = 0xfffa;
*(uint16_t*)0x2850 = 3;
*(uint16_t*)0x2852 = 3;
*(uint32_t*)0x2854 = 0x117;
*(uint32_t*)0x2858 = 0x45;
*(uint32_t*)0x285c = 0x38;
*(uint32_t*)0x2860 = 0x1df;
*(uint32_t*)0x2864 = 5;
*(uint16_t*)0x2868 = 4;
*(uint16_t*)0x286a = 0x20;
*(uint16_t*)0x286c = 2;
*(uint16_t*)0x286e = 0x1ff;
*(uint16_t*)0x2870 = 0x55;
*(uint16_t*)0x2872 = 0xfffb;
*(uint32_t*)0x2878 = 4;
*(uint32_t*)0x287c = 4;
*(uint32_t*)0x2880 = 4;
*(uint32_t*)0x2884 = 1;
*(uint32_t*)0x2888 = 1;
*(uint32_t*)0x288c = 3;
*(uint32_t*)0x2890 = 7;
*(uint32_t*)0x2894 = 0xfff;
*(uint32_t*)0x2898 = 3;
*(uint32_t*)0x289c = 5;
*(uint32_t*)0x28a0 = 3;
*(uint32_t*)0x28a4 = 1;
*(uint32_t*)0x28a8 = 0x3f;
*(uint32_t*)0x28ac = 0x200;
*(uint32_t*)0x28b0 = 4;
*(uint32_t*)0x28b4 = 7;
memcpy((void*)0x28b8,
[PULL] drm-misc-next-fixes
Hi! Here's a couple of patches that should be merged in the current merge-window. Thanks! Maxime drm-misc-next-fixes-2020-10-20: Two patches to prevent out-of-bands accesses on fonts buffers The following changes since commit d3c8f2784d3266d27956659c78835ee1d1925ad2: drm/ingenic: Fix bad revert (2020-10-12 20:26:14 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2020-10-20 for you to fetch changes up to 272d70895113ef00c03ab325787d159ee51718c8: Fonts: Support FONT_EXTRA_WORDS macros for font_6x8 (2020-10-19 17:55:10 +0200) Two patches to prevent out-of-bands accesses on fonts buffers Peilin Ye (2): docs: fb: Add font_6x8 to available built-in fonts Fonts: Support FONT_EXTRA_WORDS macros for font_6x8 Documentation/fb/fbcon.rst | 2 +- lib/fonts/font_6x8.c | 8 2 files changed, 5 insertions(+), 5 deletions(-) signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v3] drm/bridge: add it6505 driver
Hi sam This bridge will be used with mtk_dpi.c(https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/mediatek/mtk_dpi.c). Thanks for your comments. -Original Message- From: Sam Ravnborg [mailto:s...@ravnborg.org] Sent: Saturday, October 17, 2020 3:27 PM To: Allen Chen (陳柏宇) Cc: Kenneth Hung (洪家倫); Jitao Shi; kernel test robot; Jau-Chih Tseng (曾昭智); Yilun Lin; David Airlie; Neil Armstrong; Jernej Skrabec; open list:DRM DRIVERS; open list; Andrzej Hajda; Hermes Wu (吳佳宏); moderated list:ARM/Mediatek SoC support; Laurent Pinchart; Pi-Hsun Shih; Matthias Brugger; moderated list:ARM/Mediatek SoC support; Jonas Karlman Subject: Re: [PATCH v3] drm/bridge: add it6505 driver Hi Allen On Fri, Sep 04, 2020 at 10:10:23AM +0800, allen wrote: > This adds support for the iTE IT6505. > This device can convert DPI signal to DP output. > > From: Allen Chen > Signed-off-by: Jitao Shi > Signed-off-by: Pi-Hsun Shih > Signed-off-by: Yilun Lin > Signed-off-by: Hermes Wu > Signed-off-by: Allen Chen > Reported-by: kernel test robot Sorry for being so late with the feedback - have been offline for a while. One high-level comment - the bridge does not respect the flags arguments in the it6505_bridge_attach function. And will unconditionally create the connector. The correct approach is that the display driver creates the connector, and pass a flag to the bridge driver to tell it not to create the connector. Could we please update the relevant display drivers to create the connector and then drop it from the bridge driver. So we avoid adding backward compatible code to a new bridge driver. What display driver will this bridge be used with? Sam > --- > drivers/gpu/drm/bridge/Kconfig |7 + > drivers/gpu/drm/bridge/Makefile |1 + > drivers/gpu/drm/bridge/ite-it6505.c | 3338 +++ > 3 files changed, 3346 insertions(+) > create mode 100644 drivers/gpu/drm/bridge/ite-it6505.c > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index 3e11af4e9f63e..f21dce3fabeb9 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -61,6 +61,13 @@ config DRM_LONTIUM_LT9611 > HDMI signals > Please say Y if you have such hardware. > > +config DRM_ITE_IT6505 > + tristate "ITE IT6505 DisplayPort bridge" > + depends on OF > + select DRM_KMS_HELPER > + help > + ITE IT6505 DisplayPort bridge chip driver. > + > config DRM_LVDS_CODEC > tristate "Transparent LVDS encoders and decoders support" > depends on OF > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > index c589a6a7cbe1d..8a118fd901ad7 100644 > --- a/drivers/gpu/drm/bridge/Makefile > +++ b/drivers/gpu/drm/bridge/Makefile > @@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o > obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o > obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o > obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o > +obj-$(CONFIG_DRM_ITE_IT6505) += ite-it6505.o > obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o > obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += > megachips-stdp-ge-b850v3-fw.o > obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o > diff --git a/drivers/gpu/drm/bridge/ite-it6505.c > b/drivers/gpu/drm/bridge/ite-it6505.c > new file mode 100644 > index 0..0ed19673431ee > --- /dev/null > +++ b/drivers/gpu/drm/bridge/ite-it6505.c > @@ -0,0 +1,3338 @@ > +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +/* > + * Copyright (c) 2020, The Linux Foundation. All rights reserved. > + */ > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > + > +#define REG_IC_VER 0x04 > + > +#define REG_RESET_CTRL 0x05 > +#define VIDEO_RESET BIT(0) > +#define AUDIO_RESET BIT(1) > +#define ALL_LOGIC_RESET BIT(2) > +#define AUX_RESET BIT(3) > +#define HDCP_RESET BIT(4) > + > +#define INT_STATUS_01 0x06 > +#define INT_MASK_01 0x09 > +#define INT_HPD_CHANGE BIT(0) > +#define INT_RECEIVE_HPD_IRQ BIT(1) > +#define INT_SCDT_CHANGE BIT(2) > +#define INT_HDCP_FAIL BIT(3) > +#define INT_HDCP_DONE BIT(4) > + > +#define INT_STATUS_02 0x07 > +#define INT_MASK_02 0x0A > +#define INT_AUX_CMD_FAIL BIT(0) > +#define INT_HDCP_KSV_CHECK BIT(1) > +#define INT_AUDIO_FIFO_ERROR BIT(2) > + > +#define INT_STATUS_03 0x08 > +#define INT_MASK_03 0x0B > +#define INT_LINK_TRAIN_FAIL BIT(4) > +#define INT_VID_FIFO_ERROR BIT(5) > +#define INT_IO_LATCH_FIFO_OVERFLOW BIT(7) > + > +#define REG_SYSTEM_STS 0x0D > +#define INT_STS BIT(0) > +#define HPD_STS BIT(1) > +#define VIDEO_STB BIT(2) > + > +#define REG_LINK_TRAIN_STS 0x0E >
[PATCH 2/8] dt-bindings: display: mediatek: dsi: add documentation for MT8167 SoC
Add binding documentation for the MT8167 SoC. The SoC needs an additional clock compared to the already supported SoC: mipi26m. Signed-off-by: Fabien Parent --- .../devicetree/bindings/display/mediatek/mediatek,dsi.txt | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt index f06f24d405a5..10ae6be7225e 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt @@ -7,12 +7,13 @@ channel output. Required properties: - compatible: "mediatek,-dsi" -- the supported chips are mt2701, mt7623, mt8173 and mt8183. +- the supported chips are mt2701, mt7623, mt8167, mt8173 and mt8183. - reg: Physical base address and length of the controller's registers - interrupts: The interrupt signal from the function block. - clocks: device clocks See Documentation/devicetree/bindings/clock/clock-bindings.txt for details. -- clock-names: must contain "engine", "digital", and "hs" +- clock-names: must contain "engine", "digital", "hs" + Can optionnally also contain "mipi26m" - phys: phandle link to the MIPI D-PHY controller. - phy-names: must contain "dphy" - port: Output port node with endpoint definitions as described in @@ -26,7 +27,7 @@ The MIPI TX configuration module controls the MIPI D-PHY. Required properties: - compatible: "mediatek,-mipi-tx" -- the supported chips are mt2701, 7623, mt8173 and mt8183. +- the supported chips are mt2701, 7623, mt8167, mt8173 and mt8183. - reg: Physical base address and length of the controller's registers - clocks: PLL reference clock - clock-output-names: name of the output clock line to the DSI encoder -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panel: panel-simple: Add connector_type for EDT ETM0700G0DH6 panel
Fix the warning message "missing connector type" by adding connector_type
for EDT ETM0700G0DH6 panel.
Signed-off-by: Biju Das
---
drivers/gpu/drm/panel/panel-simple.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 8b82ec33f08a..41bab82dffea 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1812,6 +1812,7 @@ static const struct panel_desc edt_etm0700g0dh6 = {
},
.bus_format = MEDIA_BUS_FMT_RGB666_1X18,
.bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
};
static const struct panel_desc edt_etm0700g0bdh6 = {
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/8] drm/mediatek: Add support for main DDP path on MT8167
Add the main (DSI) drm display path for MT8167.
Signed-off-by: Fabien Parent
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 59c85c63b7cc..3952435093fe 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -112,6 +112,17 @@ static const enum mtk_ddp_comp_id mt2712_mtk_ddp_third[] =
{
DDP_COMPONENT_PWM2,
};
+static enum mtk_ddp_comp_id mt8167_mtk_ddp_main[] = {
+ DDP_COMPONENT_OVL0,
+ DDP_COMPONENT_COLOR0,
+ DDP_COMPONENT_CCORR,
+ DDP_COMPONENT_AAL0,
+ DDP_COMPONENT_GAMMA,
+ DDP_COMPONENT_DITHER,
+ DDP_COMPONENT_RDMA0,
+ DDP_COMPONENT_DSI0,
+};
+
static const enum mtk_ddp_comp_id mt8173_mtk_ddp_main[] = {
DDP_COMPONENT_OVL0,
DDP_COMPONENT_COLOR0,
@@ -163,6 +174,11 @@ static const struct mtk_mmsys_driver_data
mt8173_mmsys_driver_data = {
.ext_len = ARRAY_SIZE(mt8173_mtk_ddp_ext),
};
+static const struct mtk_mmsys_driver_data mt8167_mmsys_driver_data = {
+ .main_path = mt8167_mtk_ddp_main,
+ .main_len = ARRAY_SIZE(mt8167_mtk_ddp_main),
+};
+
static int mtk_drm_kms_init(struct drm_device *drm)
{
struct mtk_drm_private *private = drm->dev_private;
@@ -401,26 +417,42 @@ static const struct component_master_ops mtk_drm_ops = {
static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
{ .compatible = "mediatek,mt2701-disp-ovl",
.data = (void *)MTK_DISP_OVL },
+ { .compatible = "mediatek,mt8167-disp-ovl",
+ .data = (void *)MTK_DISP_OVL },
{ .compatible = "mediatek,mt8173-disp-ovl",
.data = (void *)MTK_DISP_OVL },
{ .compatible = "mediatek,mt2701-disp-rdma",
.data = (void *)MTK_DISP_RDMA },
+ { .compatible = "mediatek,mt8167-disp-rdma",
+ .data = (void *)MTK_DISP_RDMA },
{ .compatible = "mediatek,mt8173-disp-rdma",
.data = (void *)MTK_DISP_RDMA },
{ .compatible = "mediatek,mt8173-disp-wdma",
.data = (void *)MTK_DISP_WDMA },
+ { .compatible = "mediatek,mt8167-disp-ccorr",
+ .data = (void *)MTK_DISP_CCORR },
{ .compatible = "mediatek,mt2701-disp-color",
.data = (void *)MTK_DISP_COLOR },
+ { .compatible = "mediatek,mt8167-disp-color",
+ .data = (void *)MTK_DISP_COLOR },
{ .compatible = "mediatek,mt8173-disp-color",
.data = (void *)MTK_DISP_COLOR },
+ { .compatible = "mediatek,mt8167-disp-aal",
+ .data = (void *)MTK_DISP_AAL},
{ .compatible = "mediatek,mt8173-disp-aal",
.data = (void *)MTK_DISP_AAL},
+ { .compatible = "mediatek,mt8167-disp-gamma",
+ .data = (void *)MTK_DISP_GAMMA, },
{ .compatible = "mediatek,mt8173-disp-gamma",
.data = (void *)MTK_DISP_GAMMA, },
+ { .compatible = "mediatek,mt8167-disp-dither",
+ .data = (void *)MTK_DISP_DITHER },
{ .compatible = "mediatek,mt8173-disp-ufoe",
.data = (void *)MTK_DISP_UFOE },
{ .compatible = "mediatek,mt2701-dsi",
.data = (void *)MTK_DSI },
+ { .compatible = "mediatek,mt8167-dsi",
+ .data = (void *)MTK_DSI },
{ .compatible = "mediatek,mt8173-dsi",
.data = (void *)MTK_DSI },
{ .compatible = "mediatek,mt2701-dpi",
@@ -431,10 +463,14 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
.data = (void *)MTK_DISP_MUTEX },
{ .compatible = "mediatek,mt2712-disp-mutex",
.data = (void *)MTK_DISP_MUTEX },
+ { .compatible = "mediatek,mt8167-disp-mutex",
+ .data = (void *)MTK_DISP_MUTEX },
{ .compatible = "mediatek,mt8173-disp-mutex",
.data = (void *)MTK_DISP_MUTEX },
{ .compatible = "mediatek,mt2701-disp-pwm",
.data = (void *)MTK_DISP_BLS },
+ { .compatible = "mediatek,mt8167-disp-pwm",
+ .data = (void *)MTK_DISP_PWM },
{ .compatible = "mediatek,mt8173-disp-pwm",
.data = (void *)MTK_DISP_PWM },
{ .compatible = "mediatek,mt8173-disp-od",
@@ -449,6 +485,8 @@ static const struct of_device_id mtk_drm_of_ids[] = {
.data = _mmsys_driver_data},
{ .compatible = "mediatek,mt2712-mmsys",
.data = _mmsys_driver_data},
+ { .compatible = "mediatek,mt8167-mmsys",
+ .data = _mmsys_driver_data},
{ .compatible = "mediatek,mt8173-mmsys",
.data = _mmsys_driver_data},
{ }
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/3] dt-bindings: display: sii902x: Add supply bindings
The sii902x chip family requires IO and core voltages to reach the correct voltage before chip initialization. Add binding for describing the two supplies. Signed-off-by: Alexandru Gagniuc Acked-by: Rob Herring --- Changes since v1, v2: * Nothing. version incremented to stay in sync with sii902x regulator patch * Added Rob's acked-by line Documentation/devicetree/bindings/display/bridge/sii902x.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/display/bridge/sii902x.txt b/Documentation/devicetree/bindings/display/bridge/sii902x.txt index 0d1db3f9da84..02c21b584741 100644 --- a/Documentation/devicetree/bindings/display/bridge/sii902x.txt +++ b/Documentation/devicetree/bindings/display/bridge/sii902x.txt @@ -8,6 +8,8 @@ Optional properties: - interrupts: describe the interrupt line used to inform the host about hotplug events. - reset-gpios: OF device-tree gpio specification for RST_N pin. + - iovcc-supply: I/O Supply Voltage (1.8V or 3.3V) + - cvcc12-supply: Digital Core Supply Voltage (1.2V) HDMI audio properties: - #sound-dai-cells: <0> or <1>. <0> if only i2s or spdif pin @@ -54,6 +56,8 @@ Example: compatible = "sil,sii9022"; reg = <0x39>; reset-gpios = < 1 0>; + iovcc-supply = <_hdmi>; + cvcc12-supply = <_hdmi>; #sound-dai-cells = <0>; sil,i2s-data-lanes = < 0 1 2 >; -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Ocfs2-devel] [RFC] treewide: cleanup unreachable breaks
> On 19 Oct 2020, at 20:42, Nick Desaulniers wrote: > > We probably should add all 3 to W=2 builds (wrapped in cc-option). > I've filed https://github.com/ClangBuiltLinux/linux/issues/1180 to > follow up on. It looks as though the URL mangling has been fixed. If anyone sees that specific URL mangled, please let me know. jch signature.asc Description: Message signed with OpenPGP ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RIP: 0010:g84_gr_tlb_flush+0x2eb/0x300 [nouveau]
Hi there, Could someone please comment on the following hard-lock (*). Staring at the code, I see `nvkm_rd32` calls are enclosed in a timeout detection, except one. drivers/gpu/drm/nouveau/nvkm/engine/gr/g84.c#L171 ... nvkm_msec(device, 2000, if (!(nvkm_rd32(device, 0x100c80) & 0x0001)) break; ); ... Would it make sense to also enclose this in the do/while loop ? Full ref: * https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/-/issues/536 Thanks (*) Oct 20 08:44:13 vostrodell kernel: [55669.783436] [ cut here ] Oct 20 08:44:13 vostrodell kernel: [55669.783446] nouveau :01:00.0: timeout Oct 20 08:44:13 vostrodell kernel: [55669.783527] WARNING: CPU: 1 PID: 7812 at drivers/gpu/drm/nouveau/nvkm/engine/gr/g84.c:171 g84_gr_tlb_flush+0x2eb/0x300 [nouveau] Oct 20 08:44:13 vostrodell kernel: [55669.783527] Modules linked in: cdc_acm(OE) fuse md4 sha512_ssse3 sha512_generic cmac nls_utf8 cifs dns_resolver fscache libdes intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm ath9k irqbypass ath9k_common ath9k_hw crc32_pclmul ath snd_hda_codec_conexant ghash_clmulni_intel snd_hda_codec_generic snd_hda_codec_hdmi ledtrig_audio mac80211 snd_hda_intel snd_intel_dspcfg aesni_intel libaes crypto_simd snd_hda_codec snd_hda_core cryptd snd_hwdep cfg80211 glue_helper dcdbas snd_pcm rapl iTCO_wdt snd_timer intel_pmc_bxt mei_me intel_cstate rfkill iTCO_vendor_support snd intel_uncore dell_smm_hwmon mei serio_raw soundcore watchdog libarc4 at24 sg pcspkr evdev binfmt_misc ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic sd_mod sr_mod t10_pi cdrom crc_t10dif crct10dif_generic hid_generic usbhid hid uas ata_generic usb_storage nouveau mxm_wmi wmi ata_piix crct10dif_pclmul crct10dif_common video i2c_algo_bit libata ttm crc32c_intel Oct 20 08:44:13 vostrodell kernel: [55669.783551] drm_kms_helper psmouse scsi_mod i2c_i801 i2c_smbus cec lpc_ich ehci_pci ehci_hcd drm usbcore r8169 realtek libphy usb_common button [last unloaded: cdc_acm] Oct 20 08:44:13 vostrodell kernel: [55669.783558] CPU: 1 PID: 7812 Comm: kworker/1:0 Tainted: G OE 5.8.0-0.bpo.2-amd64 #1 Debian 5.8.10-1~bpo10+1 Oct 20 08:44:13 vostrodell kernel: [55669.783559] Hardware name: Dell Inc. Vostro 260 /0GDG8Y , BIOS A10 02/22/2013 Oct 20 08:44:13 vostrodell kernel: [55669.783595] Workqueue: events nouveau_cli_work [nouveau] Oct 20 08:44:13 vostrodell kernel: [55669.783631] RIP: 0010:g84_gr_tlb_flush+0x2eb/0x300 [nouveau] Oct 20 08:44:13 vostrodell kernel: [55669.783633] Code: 8b 40 10 48 8b 78 10 4c 8b 67 50 4d 85 e4 75 03 4c 8b 27 e8 87 e7 ab e7 4c 89 e2 48 c7 c7 6c 43 63 c0 48 89 c6 e8 30 af 58 e7 <0f> 0b e9 44 ff ff ff e8 d9 d7 cf e7 66 0f 1f 84 00 00 00 00 00 66 Oct 20 08:44:13 vostrodell kernel: [55669.783634] RSP: 0018:ae76c66db998 EFLAGS: 00010082 Oct 20 08:44:13 vostrodell kernel: [55669.783634] RAX: RBX: 9dc2450f8c00 RCX: 0027 Oct 20 08:44:13 vostrodell kernel: [55669.783635] RDX: 0027 RSI: 9dc277498ac0 RDI: 9dc277498ac8 Oct 20 08:44:13 vostrodell kernel: [55669.783636] RBP: R08: 04df R09: 0004 Oct 20 08:44:13 vostrodell kernel: [55669.783636] R10: R11: 0001 R12: 9dc26fc42290 Oct 20 08:44:13 vostrodell kernel: [55669.783637] R13: 32a15d0363a0 R14: 9dc277560580 R15: 0001 Oct 20 08:44:13 vostrodell kernel: [55669.783638] FS: () GS:9dc27748() knlGS: Oct 20 08:44:13 vostrodell kernel: [55669.783639] CS: 0010 DS: ES: CR0: 80050033 Oct 20 08:44:13 vostrodell kernel: [55669.783639] CR2: 7f72949e5000 CR3: 00020480a001 CR4: 000606e0 Oct 20 08:44:13 vostrodell kernel: [55669.783640] Call Trace: Oct 20 08:44:13 vostrodell kernel: [55669.783648] ? enqueue_task_fair+0x8e/0x690 Oct 20 08:44:13 vostrodell kernel: [55669.783683] ? nv04_timer_read+0x42/0x60 [nouveau] Oct 20 08:44:13 vostrodell kernel: [55669.831715] nv50_vmm_flush+0x1f1/0x220 [nouveau] Oct 20 08:44:13 vostrodell kernel: [55669.831719] ? refcount_dec_and_mutex_lock+0x26/0x60 Oct 20 08:44:13 vostrodell kernel: [55669.831751] nvkm_vmm_iter.constprop.10+0x364/0x820 [nouveau] Oct 20 08:44:13 vostrodell kernel: [55669.831783] ? nvkm_vmm_map_choose+0xa0/0xa0 [nouveau] Oct 20 08:44:13 vostrodell kernel: [55669.831815] ? nv44_vmm_new+0xe0/0xe0 [nouveau] Oct 20 08:44:13 vostrodell kernel: [55669.831847] nvkm_vmm_ptes_unmap_put+0x2c/0x40 [nouveau] Oct 20 08:44:13 vostrodell kernel: [55669.831885] ? nvkm_vmm_map_choose+0xa0/0xa0 [nouveau] Oct 20 08:44:13 vostrodell kernel: [55669.831922] ? nv44_vmm_new+0xe0/0xe0 [nouveau] Oct 20 08:44:13 vostrodell kernel: [55669.831968] nvkm_vmm_put_locked+0x203/0x240 [nouveau] Oct 20 08:44:13 vostrodell kernel: [55669.832000] nvkm_uvmm_mthd+0x249/0x710 [nouveau] Oct 20 08:44:13 vostrodell kernel: [55669.832022]
[PATCH 7/8] drm/mediatek: add DDP support for MT8167
Add DDP support for MT8167 SoC.
Signed-off-by: Fabien Parent
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 50 ++
1 file changed, 50 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 014c1bbe1df2..bb62fdcf3d71 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -25,6 +25,19 @@
#define INT_MUTEX BIT(1)
+#define MT8167_MUTEX_MOD_DISP_PWM 1
+#define MT8167_MUTEX_MOD_DISP_OVL0 6
+#define MT8167_MUTEX_MOD_DISP_OVL1 7
+#define MT8167_MUTEX_MOD_DISP_RDMA08
+#define MT8167_MUTEX_MOD_DISP_RDMA19
+#define MT8167_MUTEX_MOD_DISP_WDMA010
+#define MT8167_MUTEX_MOD_DISP_CCORR11
+#define MT8167_MUTEX_MOD_DISP_COLOR12
+#define MT8167_MUTEX_MOD_DISP_AAL 13
+#define MT8167_MUTEX_MOD_DISP_GAMMA14
+#define MT8167_MUTEX_MOD_DISP_DITHER 15
+#define MT8167_MUTEX_MOD_DISP_UFOE 16
+
#define MT8173_MUTEX_MOD_DISP_OVL0 11
#define MT8173_MUTEX_MOD_DISP_OVL1 12
#define MT8173_MUTEX_MOD_DISP_RDMA013
@@ -73,6 +86,8 @@
#define MUTEX_SOF_DPI1 4
#define MUTEX_SOF_DSI2 5
#define MUTEX_SOF_DSI3 6
+#define MT8167_MUTEX_SOF_DPI0 2
+#define MT8167_MUTEX_SOF_DPI1 3
struct mtk_disp_mutex {
@@ -135,6 +150,21 @@ static const unsigned int
mt2712_mutex_mod[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_WDMA1] = MT2712_MUTEX_MOD_DISP_WDMA1,
};
+static const unsigned int mt8167_mutex_mod[DDP_COMPONENT_ID_MAX] = {
+ [DDP_COMPONENT_AAL0] = MT8167_MUTEX_MOD_DISP_AAL,
+ [DDP_COMPONENT_CCORR] = MT8167_MUTEX_MOD_DISP_CCORR,
+ [DDP_COMPONENT_COLOR0] = MT8167_MUTEX_MOD_DISP_COLOR,
+ [DDP_COMPONENT_DITHER] = MT8167_MUTEX_MOD_DISP_DITHER,
+ [DDP_COMPONENT_GAMMA] = MT8167_MUTEX_MOD_DISP_GAMMA,
+ [DDP_COMPONENT_OVL0] = MT8167_MUTEX_MOD_DISP_OVL0,
+ [DDP_COMPONENT_OVL1] = MT8167_MUTEX_MOD_DISP_OVL1,
+ [DDP_COMPONENT_PWM0] = MT8167_MUTEX_MOD_DISP_PWM,
+ [DDP_COMPONENT_RDMA0] = MT8167_MUTEX_MOD_DISP_RDMA0,
+ [DDP_COMPONENT_RDMA1] = MT8167_MUTEX_MOD_DISP_RDMA1,
+ [DDP_COMPONENT_UFOE] = MT8167_MUTEX_MOD_DISP_UFOE,
+ [DDP_COMPONENT_WDMA0] = MT8167_MUTEX_MOD_DISP_WDMA0,
+};
+
static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_AAL0] = MT8173_MUTEX_MOD_DISP_AAL,
[DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
@@ -163,6 +193,16 @@ static const unsigned int
mt2712_mutex_sof[DDP_MUTEX_SOF_DSI3 + 1] = {
[DDP_MUTEX_SOF_DSI3] = MUTEX_SOF_DSI3,
};
+static const unsigned int mt8167_mutex_sof[DDP_MUTEX_SOF_DSI3 + 1] = {
+ [DDP_MUTEX_SOF_SINGLE_MODE] = MUTEX_SOF_SINGLE_MODE,
+ [DDP_MUTEX_SOF_DSI0] = MUTEX_SOF_DSI0,
+ [DDP_MUTEX_SOF_DSI1] = MUTEX_SOF_DSI1,
+ [DDP_MUTEX_SOF_DPI0] = MT8167_MUTEX_SOF_DPI0,
+ [DDP_MUTEX_SOF_DPI1] = MT8167_MUTEX_SOF_DPI1,
+ [DDP_MUTEX_SOF_DSI2] = MUTEX_SOF_DSI2,
+ [DDP_MUTEX_SOF_DSI3] = MUTEX_SOF_DSI3,
+};
+
static const struct mtk_ddp_data mt2701_ddp_driver_data = {
.mutex_mod = mt2701_mutex_mod,
.mutex_sof = mt2712_mutex_sof,
@@ -177,6 +217,14 @@ static const struct mtk_ddp_data mt2712_ddp_driver_data = {
.mutex_sof_reg = MT2701_DISP_MUTEX0_SOF0,
};
+static const struct mtk_ddp_data mt8167_ddp_driver_data = {
+ .mutex_mod = mt8167_mutex_mod,
+ .mutex_sof = mt8167_mutex_sof,
+ .mutex_mod_reg = MT2701_DISP_MUTEX0_MOD0,
+ .mutex_sof_reg = MT2701_DISP_MUTEX0_SOF0,
+ .no_clk = true,
+};
+
static const struct mtk_ddp_data mt8173_ddp_driver_data = {
.mutex_mod = mt8173_mutex_mod,
.mutex_sof = mt2712_mutex_sof,
@@ -400,6 +448,8 @@ static const struct of_device_id ddp_driver_dt_match[] = {
.data = _ddp_driver_data},
{ .compatible = "mediatek,mt2712-disp-mutex",
.data = _ddp_driver_data},
+ { .compatible = "mediatek,mt8167-disp-mutex",
+ .data = _ddp_driver_data},
{ .compatible = "mediatek,mt8173-disp-mutex",
.data = _ddp_driver_data},
{},
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/8] dt-bindings: display: mediatek: disp: add documentation for MT8167 SoC
Add binding documentation for the MT8167 SoC Signed-off-by: Fabien Parent --- .../devicetree/bindings/display/mediatek/mediatek,disp.txt| 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt index 121220745d46..33977e15bebd 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt @@ -43,7 +43,7 @@ Required properties (all function blocks): "mediatek,-dpi" - DPI controller, see mediatek,dpi.txt "mediatek,-disp-mutex"- display mutex "mediatek,-disp-od" - overdrive - the supported chips are mt2701, mt7623, mt2712 and mt8173. + the supported chips are mt2701, mt7623, mt2712, mt8167 and mt8173. - reg: Physical base address and length of the function block register space - interrupts: The interrupt signal from the function block (required, except for merge and split function blocks). @@ -59,7 +59,7 @@ Required properties (DMA function blocks): "mediatek,-disp-ovl" "mediatek,-disp-rdma" "mediatek,-disp-wdma" - the supported chips are mt2701 and mt8173. + the supported chips are mt2701, mt8167 and mt8173. - larb: Should contain a phandle pointing to the local arbiter device as defined in Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt - iommus: Should point to the respective IOMMU block with master port as -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm/dp: skip checking LINK_STATUS_UPDATED bit
No need to check LINK_STATuS_UPDATED bit before
return 6 bytes of link status during link training.
This patch also fix phy compliance test link rate
conversion error.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_ctrl.c | 20 ++--
drivers/gpu/drm/msm/dp/dp_link.c | 24 +++-
2 files changed, 17 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 6bdaec778c4c..76e891c91c6e 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1061,23 +1061,15 @@ static bool dp_ctrl_train_pattern_set(struct
dp_ctrl_private *ctrl,
static int dp_ctrl_read_link_status(struct dp_ctrl_private *ctrl,
u8 *link_status)
{
- int len = 0;
- u32 const offset = DP_LANE_ALIGN_STATUS_UPDATED - DP_LANE0_1_STATUS;
- u32 link_status_read_max_retries = 100;
-
- while (--link_status_read_max_retries) {
- len = drm_dp_dpcd_read_link_status(ctrl->aux,
- link_status);
- if (len != DP_LINK_STATUS_SIZE) {
- DRM_ERROR("DP link status read failed, err: %d\n", len);
- return len;
- }
+ int ret = 0, len;
- if (!(link_status[offset] & DP_LINK_STATUS_UPDATED))
- return 0;
+ len = drm_dp_dpcd_read_link_status(ctrl->aux, link_status);
+ if (len != DP_LINK_STATUS_SIZE) {
+ DRM_ERROR("DP link status read failed, err: %d\n", len);
+ ret = len;
}
- return -ETIMEDOUT;
+ return ret;
}
static int dp_ctrl_link_train_1(struct dp_ctrl_private *ctrl,
diff --git a/drivers/gpu/drm/msm/dp/dp_link.c b/drivers/gpu/drm/msm/dp/dp_link.c
index c811da515fb3..58d65daae3b3 100644
--- a/drivers/gpu/drm/msm/dp/dp_link.c
+++ b/drivers/gpu/drm/msm/dp/dp_link.c
@@ -773,7 +773,8 @@ static int dp_link_process_link_training_request(struct
dp_link_private *link)
link->request.test_lane_count);
link->dp_link.link_params.num_lanes = link->request.test_lane_count;
- link->dp_link.link_params.rate = link->request.test_link_rate;
+ link->dp_link.link_params.rate =
+ drm_dp_bw_code_to_link_rate(link->request.test_link_rate);
return 0;
}
@@ -939,20 +940,17 @@ static u8 get_link_status(const u8
link_status[DP_LINK_STATUS_SIZE], int r)
*/
static int dp_link_process_link_status_update(struct dp_link_private *link)
{
- if (!(get_link_status(link->link_status,
- DP_LANE_ALIGN_STATUS_UPDATED) &
- DP_LINK_STATUS_UPDATED) ||
- (drm_dp_clock_recovery_ok(link->link_status,
- link->dp_link.link_params.num_lanes) &&
- drm_dp_channel_eq_ok(link->link_status,
- link->dp_link.link_params.num_lanes)))
- return -EINVAL;
+ bool channel_eq_done = drm_dp_channel_eq_ok(link->link_status,
+ link->dp_link.link_params.num_lanes);
+
+ bool clock_recovery_done = drm_dp_clock_recovery_ok(link->link_status,
+ link->dp_link.link_params.num_lanes);
DRM_DEBUG_DP("channel_eq_done = %d, clock_recovery_done = %d\n",
- drm_dp_clock_recovery_ok(link->link_status,
- link->dp_link.link_params.num_lanes),
- drm_dp_clock_recovery_ok(link->link_status,
- link->dp_link.link_params.num_lanes));
+ channel_eq_done, clock_recovery_done);
+
+ if (channel_eq_done && clock_recovery_done)
+ return -EINVAL;
return 0;
}
base-commit: 0855cb4b31953b8c539e57b970da8146bcd4405a
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
