dri-devel September 2021

dri-devel@lists.freedesktop.org

348 participants
817 discussions

[PATCH] drm/bridge: dw-mipi-dsi: Find the possible DSI devices
by Jagan Teki 19 Oct '21

19 Oct '21

Finding panel_or_bridge might vary based on associated DSI devices like DSI panel, bridge, and I2C based DSI bridge. 1. DSI panels and bridges will invoke the host attach from probe in order to find the panel_or_bridge. chipone_probe() dw_mipi_dsi_host_attach().start dw_mipi_dsi_panel_or_bridge() ...found the panel_or_bridge... ltdc_encoder_init().start dw_mipi_dsi_bridge_attach().start dw_mipi_dsi_host_attach().start chipone_attach(). start chipone_attach(). done dw_mipi_dsi_host_attach().done dw_mipi_dsi_bridge_attach(). done ltdc_encoder_init().done 2. I2C based DSI bridge will invoke the drm_bridge_attach from bridge attach in order to find the panel_or_bridge. ltdc_encoder_init().start dw_mipi_dsi_bridge_attach().start dw_mipi_dsi_panel_or_bridge() ...found the panel_or_bridge... dw_mipi_dsi_host_attach().start sn65dsi83_attach(). start sn65dsi83_attach(). done dw_mipi_dsi_host_attach().done dw_mipi_dsi_bridge_attach(). done ltdc_encoder_init().done So, invoke the panel_or_bridge from host attach and bridge attach in order to find all possible DSI devices. Signed-off-by: Jagan Teki <jagan(a)amarulasolutions.com> --- drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 58 ++++++++++++++----- 1 file changed, 43 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c index 6b268f9445b3..45f4515dda00 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c @@ -246,6 +246,7 @@ struct dw_mipi_dsi { struct clk *pclk; + bool device_found; unsigned int lane_mbps; /* per lane */ u32 channel; u32 lanes; @@ -309,13 +310,37 @@ static inline u32 dsi_read(struct dw_mipi_dsi *dsi, u32 reg) return readl(dsi->base + reg); } +static int dw_mipi_dsi_panel_or_bridge(struct dw_mipi_dsi *dsi, + struct device_node *node) +{ + struct drm_bridge *bridge; + struct drm_panel *panel; + int ret; + + ret = drm_of_find_panel_or_bridge(node, 1, 0, &panel, &bridge); + if (ret) + return ret; + + if (panel) { + bridge = drm_panel_bridge_add_typed(panel, + DRM_MODE_CONNECTOR_DSI); + if (IS_ERR(bridge)) + return PTR_ERR(bridge); + } + + dsi->panel_bridge = bridge; + + if (!dsi->panel_bridge) + return -EPROBE_DEFER; + + return 0; +} + static int dw_mipi_dsi_host_attach(struct mipi_dsi_host *host, struct mipi_dsi_device *device) { struct dw_mipi_dsi *dsi = host_to_dsi(host); const struct dw_mipi_dsi_plat_data *pdata = dsi->plat_data; - struct drm_bridge *bridge; - struct drm_panel *panel; int ret; if (device->lanes > dsi->plat_data->max_data_lanes) { @@ -329,22 +354,14 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host *host, dsi->format = device->format; dsi->mode_flags = device->mode_flags; - ret = drm_of_find_panel_or_bridge(host->dev->of_node, 1, 0, - &panel, &bridge); - if (ret) - return ret; + if (!dsi->device_found) { + ret = dw_mipi_dsi_panel_or_bridge(dsi, host->dev->of_node); + if (ret) + return ret; - if (panel) { - bridge = drm_panel_bridge_add_typed(panel, - DRM_MODE_CONNECTOR_DSI); - if (IS_ERR(bridge)) - return PTR_ERR(bridge); + dsi->device_found = true; } - dsi->panel_bridge = bridge; - - drm_bridge_add(&dsi->bridge); - if (pdata->host_ops && pdata->host_ops->attach) { ret = pdata->host_ops->attach(pdata->priv_data, device); if (ret < 0) @@ -999,6 +1016,16 @@ static int dw_mipi_dsi_bridge_attach(struct drm_bridge *bridge, /* Set the encoder type as caller does not know it */ bridge->encoder->encoder_type = DRM_MODE_ENCODER_DSI; + if (!dsi->device_found) { + int ret; + + ret = dw_mipi_dsi_panel_or_bridge(dsi, dsi->dev->of_node); + if (ret) + return ret; + + dsi->device_found = true; + } + /* Attach the panel-bridge to the dsi bridge */ return drm_bridge_attach(bridge->encoder, dsi->panel_bridge, bridge, flags); @@ -1181,6 +1208,7 @@ __dw_mipi_dsi_probe(struct platform_device *pdev, #ifdef CONFIG_OF dsi->bridge.of_node = pdev->dev.of_node; #endif + drm_bridge_add(&dsi->bridge); return dsi; } -- 2.25.1

6 7

[PATCH v2] drm/panel/tianma-tl057fvxp01: add panel for Motorola Moto G6
by Julian Braha 18 Oct '21

18 Oct '21

This is a 5.7" 2160x1080 panel found on the Motorola Moto G6. There may be other smartphones using it, as well. Signed-off-by: Julian Braha <julianbraha(a)gmail.com> --- drivers/gpu/drm/panel/Kconfig | 7 + drivers/gpu/drm/panel/Makefile | 1 + .../gpu/drm/panel/panel-tianma-tl057fvxp01.c | 262 ++++++++++++++++++ 3 files changed, 270 insertions(+) create mode 100644 drivers/gpu/drm/panel/panel-tianma-tl057fvxp01.c diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig index beb581b96ecd..9e8a5fffa626 100644 --- a/drivers/gpu/drm/panel/Kconfig +++ b/drivers/gpu/drm/panel/Kconfig @@ -557,6 +557,13 @@ config DRM_PANEL_TDO_TL070WSH30 24 bit RGB per pixel. It provides a MIPI DSI interface to the host, a built-in LED backlight and touch controller. +config DRM_PANEL_TIANMA_TL057FVXP01 + tristate "Tianma TL057FVXP01 panel" + select DRM_PANEL_MIPI_DSI_COMMON + help + Say Y here if you want to enable support for the Tianma TL057FVXP01 + 2160x1080 5.7" panel (found on the Motorola Moto G6). + config DRM_PANEL_TPO_TD028TTEC1 tristate "Toppoly (TPO) TD028TTEC1 panel driver" depends on OF && SPI diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile index c8132050bcec..9bdc2a12e719 100644 --- a/drivers/gpu/drm/panel/Makefile +++ b/drivers/gpu/drm/panel/Makefile @@ -57,6 +57,7 @@ obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o obj-$(CONFIG_DRM_PANEL_SONY_ACX424AKP) += panel-sony-acx424akp.o obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o obj-$(CONFIG_DRM_PANEL_TDO_TL070WSH30) += panel-tdo-tl070wsh30.o +obj-$(CONFIG_DRM_PANEL_TIANMA_TL057FVXP01) += panel-tianma-tl057fvxp01.o obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o diff --git a/drivers/gpu/drm/panel/panel-tianma-tl057fvxp01.c b/drivers/gpu/drm/panel/panel-tianma-tl057fvxp01.c new file mode 100644 index 000000000000..7dcdcbd8ef5f --- /dev/null +++ b/drivers/gpu/drm/panel/panel-tianma-tl057fvxp01.c @@ -0,0 +1,262 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Copyright (c) 2021 Julian Braha <julianbraha(a)gmail.com> + * Copyright (c) 2021, The Linux Foundation. All rights reserved. + * Generated with linux-mdss-dsi-panel-driver-generator from vendor device tree + */ + +#include <linux/delay.h> +#include <linux/gpio/consumer.h> +#include <linux/module.h> +#include <linux/of.h> + +#include <video/mipi_display.h> + +#include <drm/drm_mipi_dsi.h> +#include <drm/drm_modes.h> +#include <drm/drm_panel.h> + +struct tianma_tl057fvxp01 { + struct drm_panel panel; + struct mipi_dsi_device *dsi; + struct gpio_desc *reset_gpio; + bool prepared; +}; + +static inline struct tianma_tl057fvxp01 *to_tianma_tl057fvxp01(struct drm_panel *panel) +{ + return container_of(panel, struct tianma_tl057fvxp01, panel); +} + +#define dsi_dcs_write_seq(dsi, seq...) do { \ + static const u8 d[] = { seq }; \ + int ret; \ + ret = mipi_dsi_dcs_write_buffer(dsi, d, ARRAY_SIZE(d)); \ + if (ret < 0) \ + return ret; \ + } while (0) + +static void tianma_tl057fvxp01_reset(struct tianma_tl057fvxp01 *ctx) +{ + gpiod_set_value_cansleep(ctx->reset_gpio, 0); + usleep_range(5000, 6000); + gpiod_set_value_cansleep(ctx->reset_gpio, 1); + usleep_range(1000, 2000); + gpiod_set_value_cansleep(ctx->reset_gpio, 0); + usleep_range(10000, 11000); +} + +static int tianma_tl057fvxp01_on(struct tianma_tl057fvxp01 *ctx) +{ + struct mipi_dsi_device *dsi = ctx->dsi; + struct device *dev = &dsi->dev; + int ret; + + dsi_dcs_write_seq(dsi, 0x00, 0x00); + dsi_dcs_write_seq(dsi, 0xff, 0x19, 0x11, 0x01); + dsi_dcs_write_seq(dsi, 0x00, 0x80); + dsi_dcs_write_seq(dsi, 0xff, 0x19, 0x11); + dsi_dcs_write_seq(dsi, 0x00, 0xb0); + dsi_dcs_write_seq(dsi, 0xb3, 0x04, 0x38, 0x08, 0x70); + dsi_dcs_write_seq(dsi, 0x00, 0x00); + dsi_dcs_write_seq(dsi, 0xff, 0xff, 0xff, 0xff); + dsi_dcs_write_seq(dsi, 0x35, 0x00); + dsi_dcs_write_seq(dsi, 0x51, 0xcc, 0x08); + dsi_dcs_write_seq(dsi, 0x53, 0x2c); + dsi_dcs_write_seq(dsi, 0x55, 0x01); + + ret = mipi_dsi_dcs_exit_sleep_mode(dsi); + if (ret < 0) { + dev_err(dev, "Failed to exit sleep mode: %d\n", ret); + return ret; + } + msleep(120); + + ret = mipi_dsi_dcs_set_display_on(dsi); + if (ret < 0) { + dev_err(dev, "Failed to set display on: %d\n", ret); + return ret; + } + usleep_range(10000, 11000); + + return 0; +} + +static int tianma_tl057fvxp01_off(struct tianma_tl057fvxp01 *ctx) +{ + struct mipi_dsi_device *dsi = ctx->dsi; + struct device *dev = &dsi->dev; + int ret; + + ret = mipi_dsi_dcs_set_display_off(dsi); + if (ret < 0) { + dev_err(dev, "Failed to set display off: %d\n", ret); + return ret; + } + msleep(50); + + ret = mipi_dsi_dcs_enter_sleep_mode(dsi); + if (ret < 0) { + dev_err(dev, "Failed to enter sleep mode: %d\n", ret); + return ret; + } + msleep(70); + + return 0; +} + +static int tianma_tl057fvxp01_prepare(struct drm_panel *panel) +{ + struct tianma_tl057fvxp01 *ctx = to_tianma_tl057fvxp01(panel); + struct device *dev = &ctx->dsi->dev; + int ret; + + if (ctx->prepared) + return 0; + + tianma_tl057fvxp01_reset(ctx); + + ret = tianma_tl057fvxp01_on(ctx); + if (ret < 0) { + dev_err(dev, "Failed to initialize panel: %d\n", ret); + gpiod_set_value_cansleep(ctx->reset_gpio, 1); + return ret; + } + + ctx->prepared = true; + return 0; +} + +static int tianma_tl057fvxp01_unprepare(struct drm_panel *panel) +{ + struct tianma_tl057fvxp01 *ctx = to_tianma_tl057fvxp01(panel); + struct device *dev = &ctx->dsi->dev; + int ret; + + if (!ctx->prepared) + return 0; + + ret = tianma_tl057fvxp01_off(ctx); + if (ret < 0) + dev_err(dev, "Failed to un-initialize panel: %d\n", ret); + + gpiod_set_value_cansleep(ctx->reset_gpio, 1); + + ctx->prepared = false; + return 0; +} + +static const struct drm_display_mode tianma_tl057fvxp01_mode = { + .clock = (1080 + 53 + 4 + 53) * (2160 + 14 + 1 + 11) * 60 / 1000, + .hdisplay = 1080, + .hsync_start = 1080 + 53, + .hsync_end = 1080 + 53 + 4, + .htotal = 1080 + 53 + 4 + 53, + .vdisplay = 2160, + .vsync_start = 2160 + 14, + .vsync_end = 2160 + 14 + 1, + .vtotal = 2160 + 14 + 1 + 11, + .width_mm = 62, + .height_mm = 110, +}; + +static int tianma_tl057fvxp01_get_modes(struct drm_panel *panel, + struct drm_connector *connector) +{ + struct drm_display_mode *mode; + + mode = drm_mode_duplicate(connector->dev, &tianma_tl057fvxp01_mode); + if (!mode) + return -ENOMEM; + + drm_mode_set_name(mode); + + mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED; + connector->display_info.width_mm = mode->width_mm; + connector->display_info.height_mm = mode->height_mm; + drm_mode_probed_add(connector, mode); + + return 1; +} + +static const struct drm_panel_funcs tianma_tl057fvxp01_panel_funcs = { + .prepare = tianma_tl057fvxp01_prepare, + .unprepare = tianma_tl057fvxp01_unprepare, + .get_modes = tianma_tl057fvxp01_get_modes, +}; + +static int tianma_tl057fvxp01_probe(struct mipi_dsi_device *dsi) +{ + struct device *dev = &dsi->dev; + struct tianma_tl057fvxp01 *ctx; + int ret; + + ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL); + if (!ctx) + return -ENOMEM; + + ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH); + if (IS_ERR(ctx->reset_gpio)) + return dev_err_probe(dev, PTR_ERR(ctx->reset_gpio), + "Failed to get reset-gpios\n"); + + ctx->dsi = dsi; + mipi_dsi_set_drvdata(dsi, ctx); + + dsi->lanes = 4; + dsi->format = MIPI_DSI_FMT_RGB888; + dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST | + MIPI_DSI_CLOCK_NON_CONTINUOUS | MIPI_DSI_MODE_LPM; + + drm_panel_init(&ctx->panel, dev, &tianma_tl057fvxp01_panel_funcs, + DRM_MODE_CONNECTOR_DSI); + + ret = drm_panel_of_backlight(&ctx->panel); + if (ret) + return dev_err_probe(dev, ret, "Failed to get backlight\n"); + + drm_panel_add(&ctx->panel); + + ret = mipi_dsi_attach(dsi); + if (ret < 0) { + dev_err(dev, "Failed to attach to DSI host: %d\n", ret); + drm_panel_remove(&ctx->panel); + return ret; + } + + return 0; +} + +static int tianma_tl057fvxp01_remove(struct mipi_dsi_device *dsi) +{ + struct tianma_tl057fvxp01 *ctx = mipi_dsi_get_drvdata(dsi); + int ret; + + ret = mipi_dsi_detach(dsi); + if (ret < 0) + dev_err(&dsi->dev, "Failed to detach from DSI host: %d\n", ret); + + drm_panel_remove(&ctx->panel); + + return 0; +} + +static const struct of_device_id tianma_tl057fvxp01_of_match[] = { + { .compatible = "tianma,tl057fvxp01" }, + { /* sentinel */ } +}; +MODULE_DEVICE_TABLE(of, tianma_tl057fvxp01_of_match); + +static struct mipi_dsi_driver tianma_tl057fvxp01_driver = { + .probe = tianma_tl057fvxp01_probe, + .remove = tianma_tl057fvxp01_remove, + .driver = { + .name = "panel-tianma-tl057fvxp01", + .of_match_table = tianma_tl057fvxp01_of_match, + }, +}; +module_mipi_dsi_driver(tianma_tl057fvxp01_driver); + +MODULE_AUTHOR("Julian Braha <julianbraha(a)gmail.com>"); +MODULE_DESCRIPTION("Tianma TL057FVXP01 panel driver"); +MODULE_LICENSE("GPL v2"); -- 2.25.1

2 2

[PATCH v4 00/24] drm/bridge: Make panel and bridge probe order consistent
by Maxime Ripard 18 Oct '21

18 Oct '21

Hi, We've encountered an issue with the RaspberryPi DSI panel that prevented the whole display driver from probing. The issue is described in detail in the commit 7213246a803f ("drm/vc4: dsi: Only register our component once a DSI device is attached"), but the basic idea is that since the panel is probed through i2c, there's no synchronization between its probe and the registration of the MIPI-DSI host it's attached to. We initially moved the component framework registration to the MIPI-DSI Host attach hook to make sure we register our component only when we have a DSI device attached to our MIPI-DSI host, and then use lookup our DSI device in our bind hook. However, all the DSI bridges controlled through i2c are only registering their associated DSI device in their bridge attach hook, meaning with our change above, we never got that far, and therefore ended up in the same situation than the one we were trying to fix for panels. The best practice to avoid those issues is to register its functions only after all its dependencies are live. We also shouldn't wait any longer than we should to play nice with the other components that are waiting for us, so in our case that would mean moving the DSI device registration to the bridge probe. I also had a look at all the DSI hosts, and it seems that exynos, kirin and msm would be affected by this and wouldn't probe anymore after those changes. Exynos and kirin seems to be simple enough for a mechanical change (that still requires to be tested), but the changes in msm seemed to be far more important and I wasn't confortable doing them. Let me know what you think, Maxime --- Changes from v3: - Converted exynos and kirin - Converted all the affected bridge drivers - Reworded the documentation a bit Changes from v2: - Changed the approach as suggested by Andrzej, and aligned the bridge on the panel this time. - Fixed some typos Changes from v1: - Change the name of drm_of_get_next function to drm_of_get_bridge - Mention the revert of 87154ff86bf6 and squash the two patches that were reverting that commit - Add some documentation - Make drm_panel_attach and _detach succeed when no callback is there Maxime Ripard (24): drm/bridge: Add documentation sections drm/bridge: Document the probe issue with MIPI-DSI bridges drm/mipi-dsi: Create devm device registration drm/mipi-dsi: Create devm device attachment drm/bridge: adv7533: Switch to devm MIPI-DSI helpers drm/bridge: adv7511: Register and attach our DSI device at probe drm/bridge: anx7625: Switch to devm MIPI-DSI helpers drm/bridge: anx7625: Register and attach our DSI device at probe drm/bridge: lt8912b: Switch to devm MIPI-DSI helpers drm/bridge: lt8912b: Register and attach our DSI device at probe drm/bridge: lt9611: Switch to devm MIPI-DSI helpers drm/bridge: lt9611: Register and attach our DSI device at probe drm/bridge: lt9611uxc: Switch to devm MIPI-DSI helpers drm/bridge: lt9611uxc: Register and attach our DSI device at probe drm/bridge: ps8640: Switch to devm MIPI-DSI helpers drm/bridge: ps8640: Register and attach our DSI device at probe drm/bridge: sn65dsi83: Switch to devm MIPI-DSI helpers drm/bridge: sn65dsi83: Register and attach our DSI device at probe drm/bridge: sn65dsi86: Switch to devm MIPI-DSI helpers drm/bridge: sn65dsi86: Register and attach our DSI device at probe drm/bridge: tc358775: Switch to devm MIPI-DSI helpers drm/bridge: tc358775: Register and attach our DSI device at probe drm/kirin: dsi: Adjust probe order drm/exynos: dsi: Adjust probe order Documentation/gpu/drm-kms-helpers.rst | 12 +++ drivers/gpu/drm/bridge/adv7511/adv7511.h | 1 - drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 15 ++- drivers/gpu/drm/bridge/adv7511/adv7533.c | 20 +--- drivers/gpu/drm/bridge/analogix/anx7625.c | 40 ++++---- drivers/gpu/drm/bridge/lontium-lt8912b.c | 31 ++---- drivers/gpu/drm/bridge/lontium-lt9611.c | 62 +++++------- drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 65 +++++------- drivers/gpu/drm/bridge/parade-ps8640.c | 101 ++++++++++--------- drivers/gpu/drm/bridge/tc358775.c | 50 +++++---- drivers/gpu/drm/bridge/ti-sn65dsi83.c | 86 ++++++++-------- drivers/gpu/drm/bridge/ti-sn65dsi86.c | 94 ++++++++--------- drivers/gpu/drm/drm_bridge.c | 69 ++++++++++++- drivers/gpu/drm/drm_mipi_dsi.c | 81 +++++++++++++++ drivers/gpu/drm/exynos/exynos_drm_dsi.c | 19 ++-- drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 27 +++-- include/drm/drm_mipi_dsi.h | 4 + 17 files changed, 460 insertions(+), 317 deletions(-) -- 2.31.1

9 54

[Bug 205649] New: Daisy Chain (MST) Session Crash after Screen Lock Resume
by bugzilla-daemon＠bugzilla.kernel.org 18 Oct '21

18 Oct '21

https://bugzilla.kernel.org/show_bug.cgi?id=205649 Bug ID: 205649 Summary: Daisy Chain (MST) Session Crash after Screen Lock Resume Product: Drivers Version: 2.5 Kernel Version: 5.4 Hardware: Intel OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: michael(a)rauch.be Regression: No Error message: Nov 25 17:18:59 hoi kernel: [ 664.616065] [drm] DM_MST: stopping TM on aconnector: 00000000d2ec50d2 [id: 64] Nov 25 17:19:03 hoi kernel: [ 668.779501] [drm] DM_MST: Disabling connector: 0000000020957698 [id: 72] [master: 00000000d2ec50d2] Nov 25 17:19:03 hoi kernel: [ 668.780518] [drm] DM_MST: Disabling connector: 00000000a3e45904 [id: 67] [master: 00000000d2ec50d2] Nov 25 17:19:03 hoi kernel: [ 668.795264] [drm] DM_MST: starting TM on aconnector: 00000000d2ec50d2 [id: 64] Nov 25 17:19:03 hoi kernel: [ 668.868743] [drm] DM_MST: added connector: 00000000a5e1fa4b [id: 84] [master: 00000000d2ec50d2] Nov 25 17:19:03 hoi kernel: [ 669.018055] [drm] DM_MST: added connector: 00000000a62ddae1 [id: 102] [master: 00000000d2ec50d2] Nov 25 17:19:49 hoi kernel: [ 715.510276] [drm] DM_MST: stopping TM on aconnector: 00000000d2ec50d2 [id: 64] Nov 25 17:19:54 hoi kernel: [ 719.723556] [drm] DM_MST: Disabling connector: 00000000a62ddae1 [id: 102] [master: 00000000d2ec50d2] Nov 25 17:19:54 hoi kernel: [ 719.724562] [drm] DM_MST: Disabling connector: 00000000a5e1fa4b [id: 84] [master: 00000000d2ec50d2] Nov 25 17:19:54 hoi kernel: [ 719.738593] [drm] DM_MST: starting TM on aconnector: 00000000d2ec50d2 [id: 64] Nov 25 17:19:54 hoi kernel: [ 719.799040] [drm] DM_MST: added connector: 0000000084594915 [id: 82] [master: 00000000d2ec50d2] Nov 25 17:19:54 hoi kernel: [ 719.944380] [drm] DM_MST: added connector: 000000007a6df593 [id: 111] [master: 00000000d2ec50d2] Nov 25 17:27:56 hoi kernel: [ 1202.137752] [drm] DM_MST: stopping TM on aconnector: 00000000d2ec50d2 [id: 64] Nov 25 17:28:00 hoi kernel: [ 1206.380336] [drm] DM_MST: Disabling connector: 000000007a6df593 [id: 111] [master: 00000000d2ec50d2] Nov 25 17:28:00 hoi kernel: [ 1206.381399] [drm] DM_MST: Disabling connector: 0000000084594915 [id: 82] [master: 00000000d2ec50d2] Nov 25 17:28:00 hoi kernel: [ 1206.395858] [drm] DM_MST: starting TM on aconnector: 00000000d2ec50d2 [id: 64] Nov 25 17:28:00 hoi kernel: [ 1206.478238] [drm] DM_MST: added connector: 00000000e1e4c871 [id: 84] [master: 00000000d2ec50d2] Nov 25 17:28:01 hoi kernel: [ 1206.628767] [drm] DM_MST: added connector: 00000000a3c8d4bc [id: 109] [master: 00000000d2ec50d2] Setup: 2 monitors in Daisy Chain (MST) setup as separate displays How to reproduce the issue: 1. Enable Screen Lock for a Gnome Session 2. Wake up the session after the monitors go to sleep During the issue, the following occured: 1. Session crash for a running user session after wake up 2. User has to login to a new session System specification: Radeon PRO WX 2100 Ubuntu 18.04 I have tried the following combination: Kernel 5.3, 5.4 Mesa 19.0.8 Let me know if more logfiles are needed -- You are receiving this mail because: You are watching the assignee of the bug.

1 9

[PATCH] dma-buf: Add support for mapping buffers with DMA attributes
by guangming.cao＠mediatek.com 18 Oct '21

18 Oct '21

From: Guangming Cao <Guangming.Cao(a)mediatek.com> When mapping the memory represented by a dma-buf into a device's address space, it might be desireable to map the memory with certain DMA attributes. Thus, introduce the dma_mapping_attrs field in the dma_buf_attachment structure so that when the memory is mapped with dma_buf_map_attachment, it is mapped with the desired DMA attributes. Signed-off-by: Isaac J. Manjarres <isaacm(a)codeaurora.org> Signed-off-by: Sandeep Patil <sspatil(a)google.com> Signed-off-by: Guangming Cao <Guangming.Cao(a)mediatek.com> --- drivers/dma-buf/heaps/cma_heap.c | 6 ++++-- drivers/dma-buf/heaps/system_heap.c | 6 ++++-- include/linux/dma-buf.h | 3 +++ 3 files changed, 11 insertions(+), 4 deletions(-) diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c index 0c05b79870f9..2c9feb3bfc3e 100644 --- a/drivers/dma-buf/heaps/cma_heap.c +++ b/drivers/dma-buf/heaps/cma_heap.c @@ -99,9 +99,10 @@ static struct sg_table *cma_heap_map_dma_buf(struct dma_buf_attachment *attachme { struct dma_heap_attachment *a = attachment->priv; struct sg_table *table = &a->table; + int attrs = attachment->dma_map_attrs; int ret; - ret = dma_map_sgtable(attachment->dev, table, direction, 0); + ret = dma_map_sgtable(attachment->dev, table, direction, attrs); if (ret) return ERR_PTR(-ENOMEM); a->mapped = true; @@ -113,9 +114,10 @@ static void cma_heap_unmap_dma_buf(struct dma_buf_attachment *attachment, enum dma_data_direction direction) { struct dma_heap_attachment *a = attachment->priv; + int attrs = attachment->dma_map_attrs; a->mapped = false; - dma_unmap_sgtable(attachment->dev, table, direction, 0); + dma_unmap_sgtable(attachment->dev, table, direction, attrs); } static int cma_heap_dma_buf_begin_cpu_access(struct dma_buf *dmabuf, diff --git a/drivers/dma-buf/heaps/system_heap.c b/drivers/dma-buf/heaps/system_heap.c index 23a7e74ef966..fc7b1e02988e 100644 --- a/drivers/dma-buf/heaps/system_heap.c +++ b/drivers/dma-buf/heaps/system_heap.c @@ -130,9 +130,10 @@ static struct sg_table *system_heap_map_dma_buf(struct dma_buf_attachment *attac { struct dma_heap_attachment *a = attachment->priv; struct sg_table *table = a->table; + int attrs = attachment->dma_map_attrs; int ret; - ret = dma_map_sgtable(attachment->dev, table, direction, 0); + ret = dma_map_sgtable(attachment->dev, table, direction, attrs); if (ret) return ERR_PTR(ret); @@ -145,9 +146,10 @@ static void system_heap_unmap_dma_buf(struct dma_buf_attachment *attachment, enum dma_data_direction direction) { struct dma_heap_attachment *a = attachment->priv; + int attrs = attachment->dma_map_attrs; a->mapped = false; - dma_unmap_sgtable(attachment->dev, table, direction, 0); + dma_unmap_sgtable(attachment->dev, table, direction, attrs); } static int system_heap_dma_buf_begin_cpu_access(struct dma_buf *dmabuf, diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index efdc56b9d95f..4d650731766e 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -379,6 +379,8 @@ struct dma_buf_attach_ops { * @importer_ops: importer operations for this attachment, if provided * dma_buf_map/unmap_attachment() must be called with the dma_resv lock held. * @importer_priv: importer specific attachment data. + * @dma_map_attrs: DMA attributes to be used when the exporter maps the buffer + * through dma_buf_map_attachment. * * This structure holds the attachment information between the dma_buf buffer * and its user device(s). The list contains one attachment struct per device @@ -399,6 +401,7 @@ struct dma_buf_attachment { const struct dma_buf_attach_ops *importer_ops; void *importer_priv; void *priv; + unsigned long dma_map_attrs; }; /** -- 2.17.1

3 3

[RFC v1 0/6] drm: Add support for DRM_CAP_RELEASE_FENCE capability
by Vivek Kasireddy 18 Oct '21

18 Oct '21

The main idea behind DRM_CAP_RELEASE_FENCE is to add an additional signaling mechanism for a pageflip completion in addition to out_fence or DRM_EVENT_FLIP_COMPLETE event. This allows a compositor to start a new repaint cycle with a new buffer instead of waiting for the old buffer to be free. Why? So, an atomic pageflip completion indicates two things to a compositor: - that it can repaint again and - that the old fb is free and can be reused (that was submitted in the previous repaint cycle) Essentially, DRM_CAP_RELEASE_FENCE is about separating out the above two assumptions. DRM_EVENT_FLIP_COMPLETE event or out_fence would serve as a signal to repaint and newly added release_fence would provide a way to determine when old fbs can be re-used again. This separation is really needed when the fb(s) associated with a pageflip are shared outside of the OS -- which is indeed the case with Virtio-gpu, a Virtual KMS driver. The Virtio-gpu driver runs in a Virtual Machine and can share the fb with the Host -- via Wayland UI -- in a zero-copy way. And, in this particular environment where the Host and Guest/VM are running Wayland based compositors, it would be desirable to have the Guest compositor's scanout fb be placed directly on a hardware plane on the Host -- to improve performance when there are multiple Guests running. To ensure 60 FPS and to prevent Guest and Host compositors from using an fb at the same time, the signaling of Guest's release_fence is tied to Host's wl_buffer_release event and DRM_EVENT_FLIP_COMPLETE/ out_fence signaling is tied to Host compositor's frame callback event. Implementation: Since release_fence is almost identical to out_fence, it is implemented by making use of the existing out_fence machinery. And, although, the drm core creates the release_fence, the Virtio-gpu driver takes care of signaling it when it gets notified by the Host that the fb is free. This work is based on the idea/suggestion from Simon and Pekka. And, this patch series provides a solution for this Weston issue: https://gitlab.freedesktop.org/wayland/weston/-/issues/514 Tested with: Weston MR: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/668 and Qemu patches: https://lists.nongnu.org/archive/html/qemu-devel/2021-09/msg03463.html Earlier version/discussion of this patch series can be found at: https://lists.freedesktop.org/archives/dri-devel/2021-July/317672.html Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: Gerd Hoffmann <kraxel(a)redhat.com> Cc: Pekka Paalanen <pekka.paalanen(a)collabora.com> Cc: Simon Ser <contact(a)emersion.fr> Cc: Michel Dänzer <michel(a)daenzer.net> Cc: Tina Zhang <tina.zhang(a)intel.com> Cc: Dongwon Kim <dongwon.kim(a)intel.com> Cc: Satyeshwar Singh <satyeshwar.singh(a)intel.com> Vivek Kasireddy (6): drm/atomic: Move out_fence creation/setup into a separate function drm/atomic: Add support for release_fence and its associated property drm: Add a capability flag to support additional flip completion signalling drm/virtio: Probe and implement VIRTIO_GPU_F_RELEASE_FENCE feature drm/virtio: Prepare set_scanout_blob to accept a fence drm/virtio: Add a fence to set_scanout_blob drivers/gpu/drm/drm_atomic_uapi.c | 100 ++++++++++++++++++----- drivers/gpu/drm/drm_crtc.c | 2 + drivers/gpu/drm/drm_ioctl.c | 3 + drivers/gpu/drm/drm_mode_config.c | 6 ++ drivers/gpu/drm/virtio/virtgpu_debugfs.c | 1 + drivers/gpu/drm/virtio/virtgpu_drv.c | 1 + drivers/gpu/drm/virtio/virtgpu_drv.h | 5 +- drivers/gpu/drm/virtio/virtgpu_fence.c | 9 ++ drivers/gpu/drm/virtio/virtgpu_kms.c | 9 +- drivers/gpu/drm/virtio/virtgpu_plane.c | 63 ++++++++++++-- drivers/gpu/drm/virtio/virtgpu_vq.c | 7 +- include/drm/drm_atomic.h | 1 + include/drm/drm_file.h | 9 ++ include/drm/drm_mode_config.h | 15 ++++ include/uapi/drm/drm.h | 1 + include/uapi/linux/virtio_gpu.h | 2 + 16 files changed, 200 insertions(+), 34 deletions(-) -- 2.30.2

4 12

[PATCH v3 0/4] Fix Rockchip MIPI DSI display init timeouts
by Brian Norris 17 Oct '21

17 Oct '21

The Rockchip DSI driver has had a number of bugs over time and has usually only worked by chance. A number of users have noticed that things regressed with commit 43c2de1002d2 ("drm/rockchip: dsi: move all lane config except LCDC mux to bind()"), although it was fixing several real issues of its own that had been present forever in the upstream driver (but notably, not in the downstream/BSP driver). Patch 1 and 2 are the most important fixes here. See their description for more info. While I'm at it, fix a few error handling and cleanup issues too. Changes in v3: - New patch, to fix related PM issue discovered after patch 1 Changes in v2: - Clean up pm-runtime state in error cases. - Correct git hash for Fixes. Brian Norris (4): drm/rockchip: dsi: Hold pm-runtime across bind/unbind drm/rockchip: dsi: Reconfigure hardware on resume() drm/rockchip: dsi: Fix unbalanced clock on probe error drm/rockchip: dsi: Disable PLL clock on bind error .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 82 +++++++++++++------ 1 file changed, 59 insertions(+), 23 deletions(-) -- 2.33.0.685.g46640cef36-goog

4 11

[PATCH] drm: panel-orientation-quirks: Add quirk for GPD Win3
by Mario 17 Oct '21

17 Oct '21

--- drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c b/drivers/gpu/drm/drm_panel_orientation_quirks.c index f6bdec7fa925..f6177c1d9872 100644 --- a/drivers/gpu/drm/drm_panel_orientation_quirks.c +++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c @@ -185,6 +185,12 @@ static const struct dmi_system_id orientation_data[] = { DMI_EXACT_MATCH(DMI_BOARD_NAME, "Default string"), }, .driver_data = (void *)&gpd_win2, + }, { /* GPD Win 3 */ + .matches = { + DMI_EXACT_MATCH(DMI_SYS_VENDOR, "GPD"), + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "G1618-03") + }, + .driver_data = (void *)&lcd720x1280_rightside_up, }, { /* I.T.Works TW891 */ .matches = { DMI_EXACT_MATCH(DMI_SYS_VENDOR, "To be filled by O.E.M."), -- 2.33.0

2 1

[PATCH v2 0/2] Add Sony Tulip Truly NT35521 panel support
by Shawn Guo 17 Oct '21

17 Oct '21

It adds driver for Sony Tulip Truly NT35521 5.24" 1280x720 DSI panel, which can be found on Sony Xperia M4 Aqua phone. Changes for v2: - Add `port` node into bindings. - Re-create the driver using linux-mdss-dsi-panel-driver-generator[1]. - Rename the driver to include Sony Tulip. - Model 5V control GPIOs with regulators. - Rename Backlight GPIO as "backlight-gpios". [1] https://github.com/msm8916-mainline/linux-mdss-dsi-panel-driver-generator Shawn Guo (2): dt-bindings: display: Add Sony Tulip Truly NT35521 panel support drm/panel: Add Sony Tulip Truly NT35521 driver .../panel/sony,tulip-truly-nt35521.yaml | 72 +++ drivers/gpu/drm/panel/Kconfig | 10 + drivers/gpu/drm/panel/Makefile | 1 + .../panel/panel-sony-tulip-truly-nt35521.c | 552 ++++++++++++++++++ 4 files changed, 635 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/sony,tulip-truly-nt35521.yaml create mode 100644 drivers/gpu/drm/panel/panel-sony-tulip-truly-nt35521.c -- 2.17.1

3 7

[PATCH] drm/panel:Adjust sync values for Feixin K101-IM2BYL02 panel
by Dan Johansen 17 Oct '21

17 Oct '21

This adjusts sync values according to the datasheet Fixes: 1c243751c095bb95e2795f076ea7a0bcdd60a93a ("drm/panel: ilitek-ili9881c: add support for Feixin K101-IM2BYL02 panel") Co-developed-by: Marius Gripsgard <marius(a)ubports.com> Signed-off-by: Dan Johansen <strit(a)manjaro.org> --- drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c index 0145129d7c66..534dd7414d42 100644 --- a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c +++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c @@ -590,14 +590,14 @@ static const struct drm_display_mode k101_im2byl02_default_mode = { .clock = 69700, .hdisplay = 800, - .hsync_start = 800 + 6, - .hsync_end = 800 + 6 + 15, - .htotal = 800 + 6 + 15 + 16, + .hsync_start = 800 + 52, + .hsync_end = 800 + 52 + 8, + .htotal = 800 + 52 + 8 + 48, .vdisplay = 1280, - .vsync_start = 1280 + 8, - .vsync_end = 1280 + 8 + 48, - .vtotal = 1280 + 8 + 48 + 52, + .vsync_start = 1280 + 16, + .vsync_end = 1280 + 16 + 6, + .vtotal = 1280 + 16 + 6 + 15, .width_mm = 135, .height_mm = 217, -- 2.32.0

2 2

← Newer
1
...
10
11
12
13
14
15
16
...
82
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2021