[Bug 111983] quan ly
https://bugs.freedesktop.org/show_bug.cgi?id=111983 Andre Klapper changed: What|Removed |Added Component|General |Two Status|NEW |RESOLVED Group||spam Resolution|--- |INVALID Product|DRI |Spam Version|XOrg git|unspecified --- Comment #1 from Andre Klapper --- Go away and test somewhere else. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 7/8] dt-bindings: display: panel: add AUO auo,b101uan08.3 panel documentation
Add dcumentation for auo,b101uan08.3, which is mipi dsi video panel
and resolution is 1200x1920.
Signed-off-by: Jitao Shi
---
.../display/panel/auo,b101uan08.3.yaml| 67 +++
1 file changed, 67 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/auo,b101uan08.3.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/auo,b101uan08.3.yaml
b/Documentation/devicetree/bindings/display/panel/auo,b101uan08.3.yaml
new file mode 100644
index ..c0939f8c7274
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/auo,b101uan08.3.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/auo,b101uan08.3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AUO B101UAN08.3 DSI Display Panel
+
+maintainers:
+ - Thierry Reding
+ - Sam Ravnborg
+ - Rob Herring
+
+properties:
+ compatible:
+const: auo,b101uan08.3
+
+ reg:
+description: the virtual channel number of a DSI peripheral
+
+ enable-gpios:
+description: a GPIO spec for the enable pin
+
+ pp1800-supply:
+description: core voltage supply
+
+ avdd-supply:
+description: phandle of the regulator that provides positive voltage
+
+ avee-supply:
+description: phandle of the regulator that provides negative voltage
+
+ backlight:
+description: phandle of the backlight device attached to the panel
+
+required:
+ - compatible
+ - reg
+ - enable-gpios
+ - pp1800-supply
+ - avdd-supply
+ - avee-supply
+ - backlight
+
+additionalProperties: false
+
+examples:
+ - |
+ {
+panel@0 {
+compatible = "auo,b101uan08.3";
+reg = <0>;
+enable-gpios = < 45 0>;
+avdd-supply = <_lcd>;
+avee-supply = <_lcd>;
+pp1800-supply = <_lcd>;
+backlight = <_lcd0>;
+status = "okay";
+port {
+panel_in: endpoint {
+remote-endpoint = <_out>;
+};
+};
+};
+};
+
+...
--
2.21.0
[PATCH v7 8/8] drm/panel: support for auo,b101uan08.3 wuxga dsi video mode panel
Auo,auo,b101uan08.3's connector is same as boe,tv101wum-nl6.
The most codes can be reuse.
So auo,b101uan08.3 and boe,tv101wum-nl6 use one driver file.
Add the different parts in driver data.
Signed-off-by: Jitao Shi
---
.../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 78 +++
1 file changed, 78 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index 7b47619675f5..e2496a334ab6 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -382,6 +382,53 @@ static const struct panel_init_cmd
auo_kd101n80_45na_init_cmd[] = {
{},
};
+static const struct panel_init_cmd auo_b101uan08_3_init_cmd[] = {
+ _INIT_DELAY_CMD(24),
+ _INIT_DCS_CMD(0xB0, 0x01),
+ _INIT_DCS_CMD(0xC0, 0x48),
+ _INIT_DCS_CMD(0xC1, 0x48),
+ _INIT_DCS_CMD(0xC2, 0x47),
+ _INIT_DCS_CMD(0xC3, 0x47),
+ _INIT_DCS_CMD(0xC4, 0x46),
+ _INIT_DCS_CMD(0xC5, 0x46),
+ _INIT_DCS_CMD(0xC6, 0x45),
+ _INIT_DCS_CMD(0xC7, 0x45),
+ _INIT_DCS_CMD(0xC8, 0x64),
+ _INIT_DCS_CMD(0xC9, 0x64),
+ _INIT_DCS_CMD(0xCA, 0x4F),
+ _INIT_DCS_CMD(0xCB, 0x4F),
+ _INIT_DCS_CMD(0xCC, 0x40),
+ _INIT_DCS_CMD(0xCD, 0x40),
+ _INIT_DCS_CMD(0xCE, 0x66),
+ _INIT_DCS_CMD(0xCF, 0x66),
+ _INIT_DCS_CMD(0xD0, 0x4F),
+ _INIT_DCS_CMD(0xD1, 0x4F),
+ _INIT_DCS_CMD(0xD2, 0x41),
+ _INIT_DCS_CMD(0xD3, 0x41),
+ _INIT_DCS_CMD(0xD4, 0x48),
+ _INIT_DCS_CMD(0xD5, 0x48),
+ _INIT_DCS_CMD(0xD6, 0x47),
+ _INIT_DCS_CMD(0xD7, 0x47),
+ _INIT_DCS_CMD(0xD8, 0x46),
+ _INIT_DCS_CMD(0xD9, 0x46),
+ _INIT_DCS_CMD(0xDA, 0x45),
+ _INIT_DCS_CMD(0xDB, 0x45),
+ _INIT_DCS_CMD(0xDC, 0x64),
+ _INIT_DCS_CMD(0xDD, 0x64),
+ _INIT_DCS_CMD(0xDE, 0x4F),
+ _INIT_DCS_CMD(0xDF, 0x4F),
+ _INIT_DCS_CMD(0xE0, 0x40),
+ _INIT_DCS_CMD(0xE1, 0x40),
+ _INIT_DCS_CMD(0xE2, 0x66),
+ _INIT_DCS_CMD(0xE3, 0x66),
+ _INIT_DCS_CMD(0xE4, 0x4F),
+ _INIT_DCS_CMD(0xE5, 0x4F),
+ _INIT_DCS_CMD(0xE6, 0x41),
+ _INIT_DCS_CMD(0xE7, 0x41),
+ _INIT_DELAY_CMD(150),
+ {},
+};
+
static inline struct boe_panel *to_boe_panel(struct drm_panel *panel)
{
return container_of(panel, struct boe_panel, base);
@@ -652,6 +699,34 @@ static const struct panel_desc boe_tv101wum_n53_desc = {
.init_cmds = boe_init_cmd,
};
+static const struct drm_display_mode auo_b101uan08_3_default_mode = {
+ .clock = 159667,
+ .hdisplay = 1200,
+ .hsync_start = 1200 + 60,
+ .hsync_end = 1200 + 60 + 4,
+ .htotal = 1200 + 60 + 4 + 80,
+ .vdisplay = 1920,
+ .vsync_start = 1920 + 34,
+ .vsync_end = 1920 + 34 + 2,
+ .vtotal = 1920 + 34 + 2 + 24,
+ .vrefresh = 60,
+ .type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
+};
+
+static const struct panel_desc auo_b101uan08_3_desc = {
+ .modes = _b101uan08_3_default_mode,
+ .bpc = 8,
+ .size = {
+ .width_mm = 135,
+ .height_mm = 216,
+ },
+ .lanes = 4,
+ .format = MIPI_DSI_FMT_RGB888,
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+ MIPI_DSI_MODE_LPM,
+ .init_cmds = auo_b101uan08_3_init_cmd,
+};
+
static int boe_panel_get_modes(struct drm_panel *panel)
{
struct boe_panel *boe = to_boe_panel(panel);
@@ -782,6 +857,9 @@ static const struct of_device_id boe_of_match[] = {
{ .compatible = "boe,tv101wum-n53",
.data = _tv101wum_n53_desc
},
+ { .compatible = "auo,b101uan08.3",
+ .data = _b101uan08_3_desc
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, boe_of_match);
--
2.21.0
[PATCH v7 5/8] dt-bindings: display: panel: add boe tv101wum-n53 panel documentation
Add dcumentation for boe,tv101wum-n53, which is mipi dsi video panel
and resolution is 1200x1920.
Signed-off-by: Jitao Shi
---
.../display/panel/boe,tv101wum-n53.yaml | 67 +++
1 file changed, 67 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/boe,tv101wum-n53.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-n53.yaml
b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-n53.yaml
new file mode 100644
index ..ceeba8d95486
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-n53.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/boe,tv101wum-n53.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: BOE TV101WUM-N53 DSI Display Panel
+
+maintainers:
+ - Thierry Reding
+ - Sam Ravnborg
+ - Rob Herring
+
+properties:
+ compatible:
+const: boe,tv101wum-n53
+
+ reg:
+description: the virtual channel number of a DSI peripheral
+
+ enable-gpios:
+description: a GPIO spec for the enable pin
+
+ pp1800-supply:
+description: core voltage supply
+
+ avdd-supply:
+description: phandle of the regulator that provides positive voltage
+
+ avee-supply:
+description: phandle of the regulator that provides negative voltage
+
+ backlight:
+description: phandle of the backlight device attached to the panel
+
+required:
+ - compatible
+ - reg
+ - enable-gpios
+ - pp1800-supply
+ - avdd-supply
+ - avee-supply
+ - backlight
+
+additionalProperties: false
+
+examples:
+ - |
+ {
+panel@0 {
+compatible = "boe,tv101wum-n53";
+reg = <0>;
+enable-gpios = < 45 0>;
+avdd-supply = <_lcd>;
+avee-supply = <_lcd>;
+pp1800-supply = <_lcd>;
+backlight = <_lcd0>;
+status = "okay";
+port {
+panel_in: endpoint {
+remote-endpoint = <_out>;
+};
+};
+};
+};
+
+...
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 6/8] drm/panel: support for boe,tv101wum-n53 wuxga dsi video mode panel
Boe,tv101wum-n53's connector is same as boe,tv101wum-nl6.
The most codes can be reuse.
So boe,tv101wum-n53 and boe,tv101wum-nl6 use one driver file.
Add the different parts in driver data.
Signed-off-by: Jitao Shi
---
.../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index e6457f87bc61..7b47619675f5 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -624,6 +624,34 @@ static const struct panel_desc auo_kd101n80_45na_desc = {
.discharge_on_disable = true,
};
+static const struct drm_display_mode boe_tv101wum_n53_default_mode = {
+ .clock = 159833,
+ .hdisplay = 1200,
+ .hsync_start = 1200 + 114,
+ .hsync_end = 1200 + 114 + 10,
+ .htotal = 1200 + 114 + 10 + 40,
+ .vdisplay = 1920,
+ .vsync_start = 1920 + 19,
+ .vsync_end = 1920 + 19 + 4,
+ .vtotal = 1920 + 19 + 4 + 10,
+ .vrefresh = 60,
+ .type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
+};
+
+static const struct panel_desc boe_tv101wum_n53_desc = {
+ .modes = _tv101wum_n53_default_mode,
+ .bpc = 8,
+ .size = {
+ .width_mm = 135,
+ .height_mm = 216,
+ },
+ .lanes = 4,
+ .format = MIPI_DSI_FMT_RGB888,
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+ MIPI_DSI_MODE_LPM,
+ .init_cmds = boe_init_cmd,
+};
+
static int boe_panel_get_modes(struct drm_panel *panel)
{
struct boe_panel *boe = to_boe_panel(panel);
@@ -751,6 +779,9 @@ static const struct of_device_id boe_of_match[] = {
{ .compatible = "auo,kd101n80-45na",
.data = _kd101n80_45na_desc
},
+ { .compatible = "boe,tv101wum-n53",
+ .data = _tv101wum_n53_desc
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, boe_of_match);
--
2.21.0
[PATCH v7 4/8] drm/panel: support for auo, kd101n80-45na wuxga dsi video mode panel
Auo,kd101n80-45na's connector is same as boe,tv101wum-nl6.
The most codes can be reuse.
So auo,kd101n80-45na and boe,tv101wum-nl6 use one driver file.
Add the different parts in driver data.
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/panel/Kconfig | 6 +-
.../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 86 ---
2 files changed, 75 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index afcadb3585fb..0e887c978796 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -19,13 +19,13 @@ config DRM_PANEL_ARM_VERSATILE
in the Versatile family syscon registers.
config DRM_PANEL_BOE_TV101WUM_NL6
- tristate "BOE TV101WUM 1200x1920 panel"
+ tristate "BOE TV101WUM and AUO KD101N80 45NA 1200x1920 panel"
depends on OF
depends on DRM_MIPI_DSI
depends on BACKLIGHT_CLASS_DEVICE
help
- Say Y here if you want to support for BOE TV101WUM WUXGA PANEL
- DSI Video Mode panel
+ Say Y here if you want to support for BOE TV101WUM and AUO KD101N80
+ 45NA WUXGA PANEL DSI Video Mode panel
config DRM_PANEL_LVDS
tristate "Generic LVDS panel driver"
diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index af68236ea0e8..e6457f87bc61 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -35,6 +35,7 @@ struct panel_desc {
enum mipi_dsi_pixel_format format;
const struct panel_init_cmd *init_cmds;
unsigned int lanes;
+ bool discharge_on_disable;
};
struct boe_panel {
@@ -372,6 +373,15 @@ static const struct panel_init_cmd boe_init_cmd[] = {
{},
};
+static const struct panel_init_cmd auo_kd101n80_45na_init_cmd[] = {
+ _INIT_DELAY_CMD(24),
+ _INIT_DCS_CMD(0x11),
+ _INIT_DELAY_CMD(120),
+ _INIT_DCS_CMD(0x29),
+ _INIT_DELAY_CMD(120),
+ {},
+};
+
static inline struct boe_panel *to_boe_panel(struct drm_panel *panel)
{
return container_of(panel, struct boe_panel, base);
@@ -452,20 +462,30 @@ static int boe_panel_unprepare(struct drm_panel *panel)
if (!boe->prepared)
return 0;
- ret = boe_panel_off(boe);
- if (ret < 0) {
- dev_err(panel->dev, "failed to set panel off: %d\n", ret);
- return ret;
+ if (boe->desc->discharge_on_disable) {
+ msleep(150);
+ regulator_disable(boe->avee);
+ regulator_disable(boe->avdd);
+ usleep_range(5000, 7000);
+ gpiod_set_value(boe->enable_gpio, 0);
+ usleep_range(5000, 7000);
+ regulator_disable(boe->pp1800);
+ } else {
+ ret = boe_panel_off(boe);
+ if (ret < 0) {
+ dev_err(panel->dev, "failed to set panel off: %d\n",
+ ret);
+ return ret;
+ }
+ msleep(150);
+ gpiod_set_value(boe->enable_gpio, 0);
+ usleep_range(500, 1000);
+ regulator_disable(boe->avee);
+ regulator_disable(boe->avdd);
+ usleep_range(5000, 7000);
+ regulator_disable(boe->pp1800);
}
- msleep(150);
- gpiod_set_value(boe->enable_gpio, 0);
- usleep_range(500, 1000);
- regulator_disable(boe->avee);
- regulator_disable(boe->avdd);
- usleep_range(5000, 7000);
- regulator_disable(boe->pp1800);
-
boe->prepared = false;
return 0;
@@ -495,10 +515,14 @@ static int boe_panel_prepare(struct drm_panel *panel)
if (ret < 0)
goto poweroffavdd;
- msleep(100);
+ usleep_range(5000, 1);
gpiod_set_value(boe->enable_gpio, 1);
- usleep_range(1, 12000);
+ usleep_range(1000, 2000);
+ gpiod_set_value(boe->enable_gpio, 0);
+ usleep_range(1000, 2000);
+ gpiod_set_value(boe->enable_gpio, 1);
+ usleep_range(6000, 1);
ret = boe_panel_init(boe);
if (ret < 0) {
@@ -530,6 +554,8 @@ static int boe_panel_enable(struct drm_panel *panel)
if (boe->enabled)
return 0;
+ msleep(130);
+
ret = backlight_enable(boe->backlight);
if (ret) {
dev_err(panel->dev, "Failed to enable backlight %d\n",
@@ -567,6 +593,35 @@ static const struct panel_desc boe_tv101wum_nl6_desc = {
.mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
MIPI_DSI_MODE_LPM,
.init_cmds = boe_init_cmd,
+ .discharge_on_disable = false,
+};
+
+static const struct drm_display_mode auo_kd101n80_45na_default_mode = {
+ .clock = 157000,
+ .hdisplay = 1200,
+ .hsync_start = 1200 + 80,
+ .hsync_end = 1200 +
[PATCH v7 3/8] dt-bindings: display: panel: add auo kd101n80-45na panel bindings
Add documentation for auo kd101n80-45na panel.
Signed-off-by: Jitao Shi
Reviewed-by: Sam Ravnborg
---
.../display/panel/auo,kd101n80-45na.yaml | 67 +++
1 file changed, 67 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/auo,kd101n80-45na.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/auo,kd101n80-45na.yaml
b/Documentation/devicetree/bindings/display/panel/auo,kd101n80-45na.yaml
new file mode 100644
index ..46ba7e8a3896
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/auo,kd101n80-45na.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/auo,kd101n80-45na.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AUO KD101N80-45NA DSI Display Panel
+
+maintainers:
+ - Thierry Reding
+ - Sam Ravnborg
+ - Rob Herring
+
+properties:
+ compatible:
+const: auo,kd101n80-45na
+
+ reg:
+description: the virtual channel number of a DSI peripheral
+
+ enable-gpios:
+description: a GPIO spec for the enable pin
+
+ pp1800-supply:
+description: core voltage supply
+
+ avdd-supply:
+description: phandle of the regulator that provides positive voltage
+
+ avee-supply:
+description: phandle of the regulator that provides negative voltage
+
+ backlight:
+description: phandle of the backlight device attached to the panel
+
+required:
+ - compatible
+ - reg
+ - enable-gpios
+ - pp1800-supply
+ - avdd-supply
+ - avee-supply
+ - backlight
+
+additionalProperties: false
+
+examples:
+ - |
+ {
+panel@0 {
+compatible = "auo,kd101n80-45na";
+reg = <0>;
+enable-gpios = < 45 0>;
+avdd-supply = <_lcd>;
+avee-supply = <_lcd>;
+pp1800-supply = <_lcd>;
+backlight = <_lcd0>;
+status = "okay";
+port {
+panel_in: endpoint {
+remote-endpoint = <_out>;
+};
+};
+};
+};
+
+...
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 1/8] dt-bindings: display: panel: Add BOE tv101wum-n16 panel bindings
Add documentation for boe tv101wum-n16 panel.
Signed-off-by: Jitao Shi
Reviewed-by: Sam Ravnborg
---
.../display/panel/boe,tv101wum-nl6.yaml | 67 +++
1 file changed, 67 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
new file mode 100644
index ..25447682f826
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/boe,tv101wum-nl6.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: BOE TV101WUM-Nl6 DSI Display Panel
+
+maintainers:
+ - Thierry Reding
+ - Sam Ravnborg
+ - Rob Herring
+
+properties:
+ compatible:
+const: boe,tv101wum-nl6
+
+ reg:
+description: the virtual channel number of a DSI peripheral
+
+ enable-gpios:
+description: a GPIO spec for the enable pin
+
+ pp1800-supply:
+description: core voltage supply
+
+ avdd-supply:
+description: phandle of the regulator that provides positive voltage
+
+ avee-supply:
+description: phandle of the regulator that provides negative voltage
+
+ backlight:
+description: phandle of the backlight device attached to the panel
+
+required:
+ - compatible
+ - reg
+ - enable-gpios
+ - pp1800-supply
+ - avdd-supply
+ - avee-supply
+ - backlight
+
+additionalProperties: false
+
+examples:
+ - |
+ {
+panel@0 {
+compatible = "boe,tv101wum-nl6";
+reg = <0>;
+enable-gpios = < 45 0>;
+avdd-supply = <_lcd>;
+avee-supply = <_lcd>;
+pp1800-supply = <_lcd>;
+backlight = <_lcd0>;
+status = "okay";
+port {
+panel_in: endpoint {
+remote-endpoint = <_out>;
+};
+};
+};
+};
+
+...
--
2.21.0
[PATCH v7 0/8] add driver for "boe, tv101wum-nl6", "boe, tv101wum-n53", "auo, kd101n80-45na" and "auo, b101uan08.3" panels
Changes since v6: - fix boe_panel_init err uninit. - adjust the delay of backlight on. Changes since v5: - covert the documents to yaml - fine tune boe, tv101wum-n53 panel video timine Changes since v4: - add auo,b101uan08.3 panel for this driver. - add boe,tv101wum-n53 panel for this driver. Changes since v3: - remove check enable_gpio. - fine tune the auo,kd101n80-45na panel's power on timing. Changes since v2: - correct the panel size - remove blank line in Kconfig - move auo,kd101n80-45na panel driver in this series. Changes since v1: - update typo nl6 -> n16. - update new panel config and makefile are added in alphabetically order. - add the panel mode and panel info in driver data. - merge auo,kd101n80-45a and boe,tv101wum-nl6 in one driver Jitao Shi (8): dt-bindings: display: panel: Add BOE tv101wum-n16 panel bindings drm/panel: support for BOE tv101wum-nl6 wuxga dsi video mode panel dt-bindings: display: panel: add auo kd101n80-45na panel bindings drm/panel: support for auo,kd101n80-45na wuxga dsi video mode panel dt-bindings: display: panel: add boe tv101wum-n53 panel documentation drm/panel: support for boe,tv101wum-n53 wuxga dsi video mode panel dt-bindings: display: panel: add AUO auo,b101uan08.3 panel documentation drm/panel: support for auo,b101uan08.3 wuxga dsi video mode panel .../display/panel/auo,b101uan08.3.yaml| 67 ++ .../display/panel/auo,kd101n80-45na.yaml | 67 ++ .../display/panel/boe,tv101wum-n53.yaml | 67 ++ .../display/panel/boe,tv101wum-nl6.yaml | 67 ++ drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 880 ++ 7 files changed, 1158 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/auo,b101uan08.3.yaml create mode 100644 Documentation/devicetree/bindings/display/panel/auo,kd101n80-45na.yaml create mode 100644 Documentation/devicetree/bindings/display/panel/boe,tv101wum-n53.yaml create mode 100644 Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml create mode 100644 drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 2/8] drm/panel: support for BOE tv101wum-nl6 wuxga dsi video mode panel
Add driver for BOE tv101wum-nl6 panel is a 10.1" 1200x1920 panel.
Signed-off-by: Jitao Shi
Reviewed-by: Sam Ravnborg
---
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 713 ++
3 files changed, 723 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index d9d931aa6e26..afcadb3585fb 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -18,6 +18,15 @@ config DRM_PANEL_ARM_VERSATILE
reference designs. The panel is detected using special registers
in the Versatile family syscon registers.
+config DRM_PANEL_BOE_TV101WUM_NL6
+ tristate "BOE TV101WUM 1200x1920 panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to support for BOE TV101WUM WUXGA PANEL
+ DSI Video Mode panel
+
config DRM_PANEL_LVDS
tristate "Generic LVDS panel driver"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index fb0cb3aaa9e6..bd26b6ac039e 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) += panel-arm-versatile.o
+obj-$(CONFIG_DRM_PANEL_BOE_TV101WUM_NL6) += panel-boe-tv101wum-nl6.o
obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) +=
panel-feiyang-fy07024di26a30d.o
diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
new file mode 100644
index ..af68236ea0e8
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -0,0 +1,713 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Jitao Shi
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+
+struct panel_desc {
+ const struct drm_display_mode *modes;
+ unsigned int bpc;
+
+ /**
+* @width_mm: width of the panel's active display area
+* @height_mm: height of the panel's active display area
+*/
+ struct {
+ unsigned int width_mm;
+ unsigned int height_mm;
+ } size;
+
+ unsigned long mode_flags;
+ enum mipi_dsi_pixel_format format;
+ const struct panel_init_cmd *init_cmds;
+ unsigned int lanes;
+};
+
+struct boe_panel {
+ struct drm_panel base;
+ struct mipi_dsi_device *dsi;
+
+ const struct panel_desc *desc;
+
+ struct backlight_device *backlight;
+ struct regulator *pp1800;
+ struct regulator *avee;
+ struct regulator *avdd;
+ struct gpio_desc *enable_gpio;
+
+ bool prepared;
+ bool enabled;
+
+ const struct drm_display_mode *mode;
+};
+
+enum dsi_cmd_type {
+ INIT_DCS_CMD,
+ DELAY_CMD,
+};
+
+struct panel_init_cmd {
+ enum dsi_cmd_type type;
+ size_t len;
+ const char *data;
+};
+
+#define _INIT_DCS_CMD(...) { \
+ .type = INIT_DCS_CMD, \
+ .len = sizeof((char[]){__VA_ARGS__}), \
+ .data = (char[]){__VA_ARGS__} }
+
+#define _INIT_DELAY_CMD(...) { \
+ .type = DELAY_CMD,\
+ .len = sizeof((char[]){__VA_ARGS__}), \
+ .data = (char[]){__VA_ARGS__} }
+
+static const struct panel_init_cmd boe_init_cmd[] = {
+ _INIT_DELAY_CMD(24),
+ _INIT_DCS_CMD(0xB0, 0x05),
+ _INIT_DCS_CMD(0xB1, 0xE5),
+ _INIT_DCS_CMD(0xB3, 0x52),
+ _INIT_DCS_CMD(0xB0, 0x00),
+ _INIT_DCS_CMD(0xB3, 0x88),
+ _INIT_DCS_CMD(0xB0, 0x04),
+ _INIT_DCS_CMD(0xB8, 0x00),
+ _INIT_DCS_CMD(0xB0, 0x00),
+ _INIT_DCS_CMD(0xB6, 0x03),
+ _INIT_DCS_CMD(0xBA, 0x8B),
+ _INIT_DCS_CMD(0xBF, 0x1A),
+ _INIT_DCS_CMD(0xC0, 0x0F),
+ _INIT_DCS_CMD(0xC2, 0x0C),
+ _INIT_DCS_CMD(0xC3, 0x02),
+ _INIT_DCS_CMD(0xC4, 0x0C),
+ _INIT_DCS_CMD(0xC5, 0x02),
+ _INIT_DCS_CMD(0xB0, 0x01),
+ _INIT_DCS_CMD(0xE0, 0x26),
+ _INIT_DCS_CMD(0xE1, 0x26),
+ _INIT_DCS_CMD(0xDC, 0x00),
+ _INIT_DCS_CMD(0xDD, 0x00),
+ _INIT_DCS_CMD(0xCC, 0x26),
+ _INIT_DCS_CMD(0xCD, 0x26),
+ _INIT_DCS_CMD(0xC8, 0x00),
+ _INIT_DCS_CMD(0xC9, 0x00),
+ _INIT_DCS_CMD(0xD2, 0x03),
+ _INIT_DCS_CMD(0xD3, 0x03),
+ _INIT_DCS_CMD(0xE6, 0x04),
+ _INIT_DCS_CMD(0xE7, 0x04),
+ _INIT_DCS_CMD(0xC4, 0x09),
+ _INIT_DCS_CMD(0xC5, 0x09),
+ _INIT_DCS_CMD(0xD8, 0x0A),
+ _INIT_DCS_CMD(0xD9, 0x0A),
+ _INIT_DCS_CMD(0xC2, 0x0B),
+ _INIT_DCS_CMD(0xC3, 0x0B),
+ _INIT_DCS_CMD(0xD6, 0x0C),
+ _INIT_DCS_CMD(0xD7,
[Bug 111983] quan ly
https://bugs.freedesktop.org/show_bug.cgi?id=111983 Bug ID: 111983 Summary: quan ly Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: not set Priority: not set Component: General Assignee: dri-devel@lists.freedesktop.org Reporter: mongkhan...@gmail.com quan ly -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #87 from Marko Popovic --- All of the hangs are still present for me, so this patch changed nothing. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201957] amdgpu: ring gfx timeout
https://bugzilla.kernel.org/show_bug.cgi?id=201957 Matthias Heinz (m...@familie-heinz.name) changed: What|Removed |Added CC||m...@familie-heinz.name --- Comment #12 from Matthias Heinz (m...@familie-heinz.name) --- Hi, I think I have the same bug and opened https://bugzilla.kernel.org/show_bug.cgi?id=204683. At first it looked a bit different, because in newer kernels the error message has changed. But as you can see I did some testing and this seems to go way back. Sadly I couldn't test a 4.18 kernel. Can somebody mark my report as duplicate? Because I think it is. And Would some more debug info help? -- 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
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #86 from Shmerl --- Looks stable so far, no hangs. I'll continue using it, and will post if it occurs again. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/6] drm/amdgpu/dm/mst: Report possible_crtcs incorrectly, for now
a little late but: i915 does have this hack (or rather-possible_crtcs with MST in i915 has been broken for a while and got fixed, but had to get reverted because of this issue), it's where this originally came from. On Wed, 2019-10-09 at 17:01 +0200, Daniel Vetter wrote: > On Fri, Sep 27, 2019 at 11:27:41AM -0400, Sean Paul wrote: > > On Thu, Sep 26, 2019 at 06:51:07PM -0400, Lyude Paul wrote: > > > This commit is seperate from the previous one to make it easier to > > > revert in the future. Basically, there's multiple userspace applications > > > that interpret possible_crtcs very wrong: > > > > > > https://gitlab.freedesktop.org/xorg/xserver/merge_requests/277 > > > https://gitlab.gnome.org/GNOME/mutter/issues/759 > > > > > > While work is ongoing to fix these issues in userspace, we need to > > > report ->possible_crtcs incorrectly for now in order to avoid > > > introducing a regression in in userspace. Once these issues get fixed, > > > this commit should be reverted. > > > > > > Signed-off-by: Lyude Paul > > > Cc: Ville Syrjälä > > > --- > > > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 11 +++ > > > 1 file changed, 11 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > > > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > > > index b404f1ae6df7..fe8ac801d7a5 100644 > > > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > > > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > > > @@ -4807,6 +4807,17 @@ static int amdgpu_dm_crtc_init(struct > > > amdgpu_display_manager *dm, > > > if (!acrtc->mst_encoder) > > > goto fail; > > > > > > + /* > > > + * FIXME: This is a hack to workaround the following issues: > > > + * > > > + * https://gitlab.gnome.org/GNOME/mutter/issues/759 > > > + * https://gitlab.freedesktop.org/xorg/xserver/merge_requests/277 > > > + * > > > + * One these issues are closed, this should be removed > > > > Even when these issues are closed, we'll still be introducing a regression > > if we > > revert this change. Time for actually_possible_crtcs? :) > > > > You also might want to briefly explain the u/s bug in case the links go > > sour. > > > > > + */ > > > + acrtc->mst_encoder->base.possible_crtcs = > > > + amdgpu_dm_get_encoder_crtc_mask(dm->adev); > > > > Why don't we put this hack in amdgpu_dm_dp_create_fake_mst_encoder()? > > If we don't have the same hack for i915 mst I think we shouldn't merge > this ... broken userspace is broken. > -Daniel -- Cheers, Lyude Paul ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204241] amdgpu fails to resume from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=204241 --- Comment #23 from Alex Deucher (alexdeuc...@gmail.com) --- Created attachment 285475 --> https://bugzilla.kernel.org/attachment.cgi?id=285475=edit possible fix uvd7 Same fix for uvd7. -- 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
[Bug 204241] amdgpu fails to resume from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=204241 --- Comment #22 from Alex Deucher (alexdeuc...@gmail.com) --- Created attachment 285473 --> https://bugzilla.kernel.org/attachment.cgi?id=285473=edit possible fix uvd6 Nice work. I think the attached patch should fix it. -- 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
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #85 from Shmerl --- (In reply to Shmerl from comment #84) > Testing this patch now, using Firefox with nodma. without* nodma. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #84 from Shmerl --- Testing this patch now, using Firefox with nodma. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111980] Rebbot and shutdown doesn't work on specific hardware
https://bugs.freedesktop.org/show_bug.cgi?id=111980 --- Comment #2 from lei.p...@gmail.com --- (In reply to Tim Cuthbertson from comment #1) > My system does this, too, since kernel 5.3.5-arch1-1-ARCH on Arch Linux. Can you test it without this commit? Same for me 5.3.5-arch1-1-ARCH introduced the bug. I've used git revert 894c414129a8d9ef1b2de443015e4dde6085f64f to exclude that commit in stable branch (after bisecting) for 5.4-rc2 and it worked fine without it. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204241] amdgpu fails to resume from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=204241 --- Comment #21 from a...@tutanota.com --- Created attachment 285471 --> https://bugzilla.kernel.org/attachment.cgi?id=285471=edit Patch to prevent kernel NULL pointer dereferences By the way, some of the kernel NULL pointer dereferences, that can happen after a resume failure, also happen always on shutdown: RIP: 0010:build_audio_output.isra.0+0x97/0x110 [amdgpu] RIP: 0010:enable_link_dp+0x186/0x300 [amdgpu] Attached patch prevents them. Note that these oopses are difficult to notice on shutdown, because they only leave traces in /sys/fs/pstore, not on the disk, as they happen after unmounting. -- 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
[Bug 204241] amdgpu fails to resume from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=204241
a...@tutanota.com changed:
What|Removed |Added
Attachment #285349|0 |1
is obsolete||
--- Comment #20 from a...@tutanota.com ---
Created attachment 285469
--> https://bugzilla.kernel.org/attachment.cgi?id=285469=edit
Patch to fix the resume failures
(In reply to Alex Deucher from comment #17)
> I'm not sure I understand why the patch helps. You are just changing the
> order of two memory allocations. The order shouldn't matter.
My hypothesis is that the order here is not the root cause of the problem, but
rather affects the likelihood of that manifesting itself.
This is based on the fact that I have seen a resume failure typical for this
bug on linux 5.0 once, but I'm unable to reproduce it with that version.
As commit 533aed278afe apparently makes the failures much more likely to
happen, it provides an opportunity to debug this further by backporting it to
older linux versions.
Doing that for versions down to linux 4.15 exposes the resume failures, but not
on linux 4.14.
A bisection between these two, while backporting 533aed278afe on every step,
lead to commit 2a91f272e34c, which failed to boot and thus had to be skipped,
and:
commit e0128efb08b3d628d767ec8578e77cdd7ecc8f81
Author: James Zhu
Date: Fri Sep 29 16:42:27 2017 -0400
drm/amdgpu: add uvd enc ib test
Generate create/destroy messages to test UVD encode indirect buffer
function.
And enable UVD encode IB test during device initialization.
Signed-off-by: James Zhu
Reviewed-and-Tested-by: Leo Liu
Reviewed-by: Christian König
Signed-off-by: Alex Deucher
This looks like a likely root cause. Indeed, adding 'return 0;' at the
beginning of uvd_v6_0_enc_ring_test_ib makes the problem unreproducible, even
on the latest linux 5.4-rc2.
Comparing with amdgpu_uvd_get_{create,destroy}_msg shows that these use 0 as
dummy GPU pointer, while uvd_v6_0_enc_get_{create,destroy}_msg use a real GPU
memory address.
Changing them to also use 0 as dummy pointer, as is done in the attached patch,
actually fixes the resume failures.
Maybe a similar change should also be made for UVD 7.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/msm/dsi: Implement reset correctly
On Fri, Oct 11, 2019 at 06:39:39AM -0700, Jeffrey Hugo wrote:
> On msm8998, vblank timeouts are observed because the DSI controller is not
> reset properly, which ends up stalling the MDP. This is because the reset
> logic is not correct per the hardware documentation.
>
> The documentation states that after asserting reset, software should wait
> some time (no indication of how long), or poll the status register until it
> returns 0 before deasserting reset.
>
> wmb() is insufficient for this purpose since it just ensures ordering, not
> timing between writes. Since asserting and deasserting reset occurs on the
> same register, ordering is already guaranteed by the architecture, making
> the wmb extraneous.
>
> Since we would define a timeout for polling the status register to avoid a
> possible infinite loop, lets just use a static delay of 20 ms, since 16.666
> ms is the time available to process one frame at 60 fps.
>
> Fixes: a689554ba6ed (drm/msm: Initial add DSI connector support)
> Signed-off-by: Jeffrey Hugo
Pushed to drm-misc-fixes for 5.4
Thanks!
Sean
> Reviewed-by: Sean Paul
> ---
>
> v2:
> -make a DEFINE for the delay
>
> drivers/gpu/drm/msm/dsi/dsi_host.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
> b/drivers/gpu/drm/msm/dsi/dsi_host.c
> index 663ff9f4fac9..9a81705301c6 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> @@ -26,6 +26,8 @@
> #include "dsi_cfg.h"
> #include "msm_kms.h"
>
> +#define RESET_DELAY 20
> +
> static int dsi_get_version(const void __iomem *base, u32 *major, u32 *minor)
> {
> u32 ver;
> @@ -986,7 +988,7 @@ static void dsi_sw_reset(struct msm_dsi_host *msm_host)
> wmb(); /* clocks need to be enabled before reset */
>
> dsi_write(msm_host, REG_DSI_RESET, 1);
> - wmb(); /* make sure reset happen */
> + msleep(RESET_DELAY); /* make sure reset happen */
> dsi_write(msm_host, REG_DSI_RESET, 0);
> }
>
> @@ -1396,7 +1398,7 @@ static void dsi_sw_reset_restore(struct msm_dsi_host
> *msm_host)
>
> /* dsi controller can only be reset while clocks are running */
> dsi_write(msm_host, REG_DSI_RESET, 1);
> - wmb(); /* make sure reset happen */
> + msleep(RESET_DELAY);/* make sure reset happen */
> dsi_write(msm_host, REG_DSI_RESET, 0);
> wmb(); /* controller out of reset */
> dsi_write(msm_host, REG_DSI_CTRL, data0);
> --
> 2.17.1
>
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111980] Rebbot and shutdown doesn't work on specific hardware
https://bugs.freedesktop.org/show_bug.cgi?id=111980 --- Comment #1 from Tim Cuthbertson --- My system does this, too, since kernel 5.3.5-arch1-1-ARCH on Arch Linux. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/meson: fix max mode_config height/width
On 2019-10-09 03:47, Daniel Vetter wrote:
On Tue, Sep 24, 2019 at 10:28:48AM -0700, Jeykumar Sankaran wrote:
Reviving this thread from the context of the below conversion:
https://lore.kernel.org/linux-arm-msm/db26145b-3f64-a334-f698-76f972332881
@baylibre.com/T/#u
On 2018-10-05 01:19, Neil Armstrong wrote:
> On 05/10/2018 09:58, Daniel Vetter wrote:
> > On Fri, Oct 5, 2018 at 9:39 AM Neil Armstrong
> > wrote:
> > >
>
> [...]
>
> > > OK, won't this be enough ?
> > > --- a/include/drm/drm_mode_config.h
> > > +++ b/include/drm/drm_mode_config.h
> > > @@ -333,6 +333,8 @@ struct drm_mode_config_funcs {
> > > * @min_height: minimum fb pixel height on this device
> > > * @max_width: maximum fb pixel width on this device
> > > * @max_height: maximum fb pixel height on this device
> > > + * @max_fb_width: maximum fb buffer width if differs from
max_width
> > > + * @max_fb_height: maximum fb buffer height if differs from
> > > max_height
> > > * @funcs: core driver provided mode setting functions
> > > * @fb_base: base address of the framebuffer
> > > * @poll_enabled: track polling support for this device
> > > @@ -508,6 +510,7 @@ struct drm_mode_config {
> > >
> > > int min_width, min_height;
> > > int max_width, max_height;
> > > + int max_fb_width, max_fb_height;
> > > const struct drm_mode_config_funcs *funcs;
> > > resource_size_t fb_base;
> > >
> > > --- a/drivers/gpu/drm/drm_framebuffer.c
> > > +++ b/drivers/gpu/drm/drm_framebuffer.c
> > > @@ -283,14 +283,20 @@ drm_internal_framebuffer_create(struct
> > > drm_device *dev,
> > > return ERR_PTR(-EINVAL);
> > > }
> > >
> > > - if ((config->min_width > r->width) || (r->width >
> > > config->max_width)) {
> > > + if ((config->min_width > r->width) ||
> > > + (!config->max_fb_width && r->width >
> > > config->max_width) ||
> > > + (config->max_fb_width && r->width >
> > > config->max_fb_width)) {
> > > DRM_DEBUG_KMS("bad framebuffer width %d, should
> > > be >= %d && <= %d\n",
> > > - r->width, config->min_width,
> > > config->max_width);
> > > + r->width, config->min_width,
> > > config->max_fb_width ?
> > > + config->max_fb_width :
config->max_width);
> > > return ERR_PTR(-EINVAL);
> > > }
> > > - if ((config->min_height > r->height) || (r->height >
> > > config->max_height)) {
> > > + if ((config->min_height > r->height) ||
> > > + (!config->max_fb_height && r->height >
> > > config->max_height) ||
> > > + (config->max_fb_height && r->height >
> > > config->max_fb_height)) {
> > > DRM_DEBUG_KMS("bad framebuffer height %d, should
> > > be >= %d && <= %d\n",
> > > - r->height, config->min_height,
> > > config->max_height);
> > > + r->height, config->min_height,
> > > config->max_fb_height ?
> > > + config->max_fb_height :
> > > config->max_height);
> > > return ERR_PTR(-EINVAL);
> > > }
> > >
> > > and in the driver :
> > >
> > > + drm->mode_config.max_width = 4096;
> > > + drm->mode_config.max_height = 3840;
> > > + drm->mode_config.max_fb_width = 16384;
> > > + drm->mode_config.max_fb_height = 8192;
> > >
> > > With this I leave the mode filtering intact.
> >
> > Not enough. See
> >
https://dri.freedesktop.org/docs/drm/gpu/drm-kms-helpers.html#c.drm_connec
tor_helper_funcs
> > and scroll down to mode_valid. You need to filter modes both in the
> > detect paths, and the atomic_check paths.
> >
> > Detect is explicitly filtered out, but atomic_check was only
> > implicitly filtered, through the max fb size checks. Ok, you could
> > light up a mode that's bigger than max fb, but in practice, no
> > userspace ever did that.
Daniel, MSM and few other vendor hardware have upscale blocks where
the
driver can expose fb sizes smaller than
the mode resolution and use h/w upscaling to fill the screen. This
would
optimize the fetch bandwidth.
But with your code we're missing crucial
> > validation now, and userspace could fall over that. What I think we
> > need is to add mode filter against mode_config.max_width/height in
> > drm_atomic_helper_check_modeset(). Probably best to stuff that into
> > the mode_valid() function.
>
Agreed! Since the above patch from Niel is taking care of cases where
max/min fb values
are not set, by checking against the original max/min values, can we
separate out this
core change from the driver level mode_valid changes? If Niel couldn't
find
the time, I can
repost the above change.
Sure, I think Neil wouldn't mind if you take this over and get it ready
for merging. Just need to make sure we're not leaving any validation
gaps
in core/helper code.
-Daniel
I guess you are a bit late for the party!
I did post the patch on the forum. The
Re: [PATCH 7/7] drm/dp-mst: fix warning on unused var
+dri, +Daniel
On Thu, Oct 10, 2019 at 06:09:07PM -0700, Lucas De Marchi wrote:
Fixes: 83fa9842afe7 ("drm/dp-mst: Drop connection_mutex check")
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/drm_dp_mst_topology.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 9364e4f42975..95e63309 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -4184,8 +4184,6 @@ EXPORT_SYMBOL(drm_dp_mst_topology_state_funcs);
struct drm_dp_mst_topology_state *drm_atomic_get_mst_topology_state(struct
drm_atomic_state *state,
struct
drm_dp_mst_topology_mgr *mgr)
{
- struct drm_device *dev = mgr->dev;
-
return to_dp_mst_topology_state(drm_atomic_get_private_obj_state(state,
>base));
}
EXPORT_SYMBOL(drm_atomic_get_mst_topology_state);
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] drm/ioctl: Add a ioctl to label GEM objects
Hi Am 11.10.19 um 19:09 schrieb Daniel Stone: Hi Rohan, On Fri, 11 Oct 2019 at 15:30, Rohan Garg wrote: DRM_IOCTL_DUMB_SET_LABEL lets you label GEM objects, making it easier to debug issues in userspace applications. I'm not sure if this was pointed out already, but dumb buffers != GEM buffers. GEM buffers _can_ be dumb, but might not be. Could you please rename to GEM_SET_LABEL? This change to build upon dumb buffers was suggested by me, as dumb buffers is the closes thing there is to a buffer management interface. Drivers with 'smart buffers' would have to add their own ioctl interfaces. What I really miss here is a userspace application that uses this functionality. It would be much easier to discuss if there was an actual example. Best regards Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Thomas Zimmermann Graphics Driver Developer SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] drm/ioctl: Add a ioctl to label GEM objects
Hello Rohan,
On Fri, 11 Oct 2019 16:30:09 +0200
Rohan Garg wrote:
> DRM_IOCTL_DUMB_SET_LABEL lets you label GEM objects, making it
> easier to debug issues in userspace applications.
>
> Changes in v2:
> - Hoist the IOCTL up into the drm_driver framework
>
> Changes in v3:
> - Introduce a drm_gem_set_label for drivers to use internally
> in order to label a GEM object
> - Hoist string copying up into the IOCTL
> - Fix documentation
> - Move actual gem labeling into drm_gem_adopt_label
>
> Changes in v4:
> - Refactor IOCTL call to only perform string duplication and move
> all gem lookup logic into GEM specific call
>
> Signed-off-by: Rohan Garg
> ---
> drivers/gpu/drm/drm_gem.c | 70 ++
> drivers/gpu/drm/drm_internal.h | 8
> drivers/gpu/drm/drm_ioctl.c| 1 +
> include/drm/drm_drv.h | 16
> include/drm/drm_gem.h | 7
> include/uapi/drm/drm.h | 20 ++
> 6 files changed, 122 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 6854f5867d51..0fa4609b2817 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -941,6 +941,71 @@ drm_gem_release(struct drm_device *dev, struct drm_file
> *file_private)
> idr_destroy(_private->object_idr);
> }
>
> +int drm_dumb_set_label_ioctl(struct drm_device *dev,
Why dumb? Not sure what a smart set_label_ioctl() function would
do differently :-).
Oh, and if this function can be used to label TTM BOs it should be moved
somewhere else (drm_ioctl.c ?).
> + void *data, struct drm_file *file_priv)
Indentation is broken here.
> +{
> + char *label;
> + struct drm_dumb_set_label_object *args = data;
> + int ret = 0;
> +
> + if (!args->len || !args->name)
Hm, I thought args->len == 0 was a valid case and meant "free the
existing label". Has it changed. The case that's not allowed is
args->len && !args->name.
> + return -EINVAL;
> +
> + if (!dev->driver->label)
> + return -EOPNOTSUPP;
> +
> + label = strndup_user(u64_to_user_ptr(args->name), args->len);
> +
Remove this blank line.
> + if (IS_ERR(label)) {
> + ret = PTR_ERR(label);
> + goto err;
> + }
> +
> + ret = dev->driver->label(dev, file_priv, args->handle, label);
> +
> +err:
I would s/err/out/ as this is not an error-only path.
> + kfree(label);
> + return ret;
> +}
> +
> +int drm_gem_set_label(struct drm_device *dev,
> +struct drm_file *file_priv,
> +uint32_t handle,
> +const char *label)
> +{
> + struct drm_gem_object *gem_obj;
> + int ret = 0;
> +
> + gem_obj = drm_gem_object_lookup(file_priv, handle);
> + if (!gem_obj) {
> + DRM_DEBUG("Failed to look up GEM BO %d\n", handle);
> + ret = -ENOENT;
> + goto err;
> + }
> + drm_gem_adopt_label(gem_obj, label);
> +
> +err:
Ditto: s/err/out/
> + drm_gem_object_put_unlocked(gem_obj);
> + return ret;
> +}
> +EXPORT_SYMBOL(drm_gem_set_label);
> +
> +void drm_gem_adopt_label(struct drm_gem_object *gem_obj, const char *label)
> +{
> + char *adopted_label = NULL;
> +
> + if (label)
> + adopted_label = kstrdup(label, GFP_KERNEL);
Add
WARN_ON(adopted_label);
> +
> + if (gem_obj->label) {
> + kfree(gem_obj->label);
> + gem_obj->label = NULL;
This assignment is useless since gem_obj->label is assigned below.
> + }
> +
> + gem_obj->label = adopted_label;
> +}
> +EXPORT_SYMBOL(drm_gem_adopt_label);
> +
> /**
> * drm_gem_object_release - release GEM buffer object resources
> * @obj: GEM buffer object
> @@ -958,6 +1023,11 @@ drm_gem_object_release(struct drm_gem_object *obj)
>
> dma_resv_fini(>_resv);
> drm_gem_free_mmap_offset(obj);
> +
> + if (obj->label) {
> + kfree(obj->label);
> + obj->label = NULL;
> + }
You can call kfree(obj->label) directly (kfree() checks for NULL vals),
and no need to reset obj->label (obj should be free when the function
returns).
> }
> EXPORT_SYMBOL(drm_gem_object_release);
>
> diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
> index 51a2055c8f18..cbc3f7b7fb9b 100644
> --- a/drivers/gpu/drm/drm_internal.h
> +++ b/drivers/gpu/drm/drm_internal.h
> @@ -137,6 +137,14 @@ int drm_gem_pin(struct drm_gem_object *obj);
> void drm_gem_unpin(struct drm_gem_object *obj);
> void *drm_gem_vmap(struct drm_gem_object *obj);
> void drm_gem_vunmap(struct drm_gem_object *obj, void *vaddr);
> +int drm_dumb_set_label_ioctl(struct drm_device *dev,
> + void *data,
> + struct drm_file *file_priv);
> +int drm_gem_set_label(struct drm_device *dev,
> + struct drm_file *file_priv,
> +
Re: [PATCH 4/7] drm/meson: plane: add support for AFBC mode for OSD1 plane
On Fri, Oct 11, 2019 at 12:56 PM Brian Starkey wrote: > > Hi, > > On Fri, Oct 11, 2019 at 11:14:43AM +0200, Neil Armstrong wrote: > > Hi Brian, > > > > On 11/10/2019 10:41, Brian Starkey wrote: > > > Are you sure the GPU supports other orders? I think any Arm driver > > > will only be producing DRM_FORMATs with "BGR" order e.g. ABGR888> > > > I'm not convinced the GPU HW actually supports any other order, but > > > it's all rather confusing with texture swizzling. What I can tell you > > > for sure is that it _does_ support BGR order (in DRM naming > > > convention). > > > > Well, since the Bifrost Mali blobs are closed-source and delivered > > by licensees, it's hard to define what is supported from a closed > > GPU HW, closed SW implementation to a closed pixel format implementation. > > > > I hear you. IMO the only way to make any of this clear is to publish > reference data and tests which make sure implementations match each > other. It's something I'm trying to make happen. *cough* igt test with crc/writeback validation *cough* And you don't even need anything that actually compresses. All you need is the minimal enough AFBC knowledge to set up the metadata that everything is uncompressed. We're doing that for our intel compression formats already, and it works great in making sure that we have end-to-end agreement on all the bits and ordering and everything. Ofc it doesn't validate the decoder, but that's not really igts job. Should be possible to convince ARM to release that (as open source, in igt), since it would be fairly valuable for the entire ecosystem here ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v4 14/16] drm, cgroup: Introduce lgpu as DRM cgroup resource
Hello, Daniel. On Wed, Oct 09, 2019 at 06:06:52PM +0200, Daniel Vetter wrote: > That's not the point I was making. For cpu cgroups there's a very well > defined connection between the cpu bitmasks/numbers in cgroups and the cpu > bitmasks you use in various system calls (they match). And that stuff > works across vendors. Please note that there are a lot of limitations even to cpuset. Affinity is easy to implement and seems attractive in terms of absolute isolation but it's inherently cumbersome and limited in granularity and can lead to surprising failure modes where contention on one cpu can't be resolved by the load balancer and leads to system wide slowdowns / stalls caused by the dependency chain anchored at the affinity limited tasks. Maybe this is a less of a problem for gpu workloads but in general the more constraints are put on scheduling, the more likely is the system to develop twisted dependency chains while other parts of the system are sitting idle. How does scheduling currently work when there are competing gpu workloads? There gotta be some fairness provision whether that's unit allocation based or time slicing, right? If that's the case, it might be best to implement proportional control on top of that. Work-conserving mechanisms are the most versatile, easiest to use and least likely to cause regressions. Thanks. -- tejun ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] drm/ioctl: Add a ioctl to label GEM objects
Hi Rohan, On Fri, 11 Oct 2019 at 15:30, Rohan Garg wrote: > DRM_IOCTL_DUMB_SET_LABEL lets you label GEM objects, making it > easier to debug issues in userspace applications. I'm not sure if this was pointed out already, but dumb buffers != GEM buffers. GEM buffers _can_ be dumb, but might not be. Could you please rename to GEM_SET_LABEL? Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Kernel crash on 4.19.77-1-lts (Arch Linux / ThinkPad T470p)
> Just use Cc. We want all replies to go to the list(s) as well. Sorry, I wasn't sure and wanted to err on the side of not spamming the wrong people. > Oct 10 12:53:30 scorpion kernel: RIP: 0010:dma_fence_signal_locked+0x30/0xe0 > > Looks like it could be > https://bugs.freedesktop.org/show_bug.cgi?id=111381 > > in which case you just need to upgrade to 4.19.78 and it should be > fixed. Thanks a bunch, not sure how I missed there was a new LTS kernel out. I have upgraded and will report back if I continue to see the issue. Thanks for the quick support, John On Fri, Oct 11, 2019 at 6:12 AM Ville Syrjälä wrote: > On Thu, Oct 10, 2019 at 01:15:09PM -0400, John Maguire wrote: > > Hi there, > > > > I wasn't sure which mailing list to use so I BCC'd > > intel-...@lists.freedesktop.org and dri-devel@lists.freedesktop.org > > Just use Cc. We want all replies to go to the list(s) as well. > > > > > I'm using a Lenovo Thinkpad T470p and running the 4.19.77-1-lts kernel on > > Arch Linux. Recently, I've started getting freezes each day. Audio can > > still be heard, but video output stops. I was able to retrieve a call > trace > > from journald. > > > > I've attached the output of "sudo lspci -vvv" as well as the message from > > journald (null pointer dereference). > > Oct 10 12:53:30 scorpion kernel: RIP: > 0010:dma_fence_signal_locked+0x30/0xe0 > > > Looks like it could be > https://bugs.freedesktop.org/show_bug.cgi?id=111381 > > in which case you just need to upgrade to 4.19.78 and it should be > fixed. > > -- > Ville Syrjälä > Intel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2 7/7] drm/omap: hdmi4: fix use of uninitialized var
* Tomi Valkeinen [191011 10:25]: > On 10/10/2019 16:24, Tony Lindgren wrote: > > > Hmm so what register does this clock actually change? > > > > I'm seeing an increase of few tens of extra mW, which means at > > least one day of standby time less for me :) It does not happen > > always, maybe half of the time. > > I have no idea why this would affect power consumption. As far as I can > understand, the bits written here are a clk divider MCLK. I don't see why > that would affect. Yeah you're right, and I just got lucky initially. I have seen the power consumption stay higher already with the patch applied. The clocks seem just fine. > Maybe Jyri or Peter has an idea, I have never looked at the HDMI audio side. I'll try dumping out the hdmi registers before and after when I get a chance. Regards, Tony ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm/amd/display/dc/dce: remove some not used variables
Thanks for the patches. I think for all of them we should just drop the REG_READ calls completely. They look like leftovers from when we had a different register update scheme that would read the register, then update or get the field value. Now we just use the REG_ macros that will combine the read with the GET or UPDATE operations. Harry On 2019-10-09 2:25 a.m., zhengbin wrote: > zhengbin (3): > drm/amd/display: Remove set but not used variables > 'bl_pwm_cntl','pwm_period_cntl' > drm/amd/display: Remove set but not used variable 'value0' > drm/amd/display: Remove set but not used variables 'regval','speakers' > > drivers/gpu/drm/amd/display/dc/dce/dce_abm.c| 8 > drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c | 3 +-- > drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c | 5 + > 3 files changed, 6 insertions(+), 10 deletions(-) > > -- > 2.7.4 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111691] inconsistent cursor movement speed when using AMD 5700 XT
https://bugs.freedesktop.org/show_bug.cgi?id=111691 --- Comment #17 from Jaap Buurman --- (In reply to takios+fdbugs from comment #16) > I ran into the same issue but after installing linux kernel 5.4rc2 it was > fixed. That's good to hear! Does anyone know whether the fix will be backported to the 5.3 kernel? It's gonna take a while before 5.4 becomes mainline. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111691] inconsistent cursor movement speed when using AMD 5700 XT
https://bugs.freedesktop.org/show_bug.cgi?id=111691 --- Comment #16 from takios+fdb...@takios.de --- I ran into the same issue but after installing linux kernel 5.4rc2 it was fixed. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes for 5.4-rc3
The pull request you sent on Fri, 11 Oct 2019 14:36:03 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-10-11 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/9892f9f6cf83e8ecaacc5ec7847cf5ba033119d2 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [Intel-gfx] [PATCH v7 0/3] CRTC background color
On Wed, Oct 09, 2019 at 02:27:41PM -0700, Matt Roper wrote: > On Wed, Oct 09, 2019 at 05:01:20PM -0400, Daniele Castagna wrote: > > On Wed, Oct 9, 2019 at 1:34 PM Matt Roper wrote: > > > > > > The previous version of this series was posted in February here: > > > > > > https://lists.freedesktop.org/archives/dri-devel/2019-February/208068.html > > > > > > Right before we merged this in February Maarten noticed that we should > > > be setting up the initial property state in a CRTC reset function (which > > > didn't exist yet) instead of when the property was attached. Maarten > > > landed the CRTC reset functionality a week or two later, but I was busy > > > with travel and other work at the time, so revisiting and rebasing this > > > background color series fell through the cracks and I'm just getting > > > back to it now. > > > > > > Userspace consumer is chromeos; these are the links the ChromeOS folks > > > gave me back in February: > > > https://chromium-review.googlesource.com/c/chromium/src/+/1278858 > > > > > > https://chromium-review.googlesource.com/c/chromiumos/platform/drm-tests/+/1241436 > > > > Please note that the current state of the background color on Chrome > > OS side is that while the property plumbing landed, the property is > > currently not used by the compositor and no one is working on making > > that happen. > > Hmm, in that case it sounds like we probably don't actually have enough > userspace support yet to justify merging the kernel changes at this > time. I'm not too familiar with Chrome OS' userspace stack; is the rest > of the work to actually make use of ozone stuff in the links above a > heavy lift? Is it something someone is likely to work on that once > they're freed up from other tasks or is there just not enough benefit to > justify the effort of utilizing it at the compositor level right now? > AFAIK, there are no plans for the Chrome team to spend time utilising this feature. If you look at the bug [1], there's no correspondance with CrOS and there is no clear usecase for the feature. The patches are basically just copy/paste of how other properties are surfaced and that's it. A few months later, we get more stub implementations [2]/[3] again with no feedback from the Chrome team on the bugs [4]/[5]. On the first review, Daniele asked if the submitter was going to finish the background work before adding more properties. The answer is that CRTC BG isn't seen on Chrome, so it's not useful on the platform. We should not have landed the crtc-bg stub in the first place, it's just dead code and it's clear from the comments in [2] that it's going to stay that way. So I think the best course of action is to revert this change from Chrome until we have a usecase for the feature which is blessed by the Chrome team and it is implemented fully. Going forward, we're going to keep a closer eye on the HW enablement in Chrome so as to avoid adding dead code to Chrome and to avoid skirting the spirit of the "opensource userspace" rule by just implementing getters/setters. Sean ps: As for the stubs referenced in [2] and [3], that's more of a Chrome matter. There are already other existing userspace implementations for these 2 features, so Chrome is not being used as an upstreaming vehicle for the kernel patches. [1] https://bugs.chromium.org/p/chromium/issues/detail?id=894259 [2] https://polymer2-chromium-review.googlesource.com/c/chromium/src/+/1504300 [3] https://polymer2-chromium-review.googlesource.com/c/chromium/src/+/1572247 [4] https://bugs.chromium.org/p/chromium/issues/detail?id=940683 [5] https://bugs.chromium.org/p/chromium/issues/detail?id=938536 > > Matt > > > The kernel patches have not landed on the ChromeOS kernel either. > > > > > > > > > > > > > IGT is still the same as posted in February: > > > https://lists.freedesktop.org/archives/igt-dev/2019-February/009637.html > > > > > > Cc: Maarten Lankhorst > > > > > > Matt Roper (3): > > > drm: Add CRTC background color property > > > drm/i915/gen9+: Add support for pipe background color > > > drm/i915: Add background color hardware readout and state check > > > > > > drivers/gpu/drm/drm_atomic_state_helper.c| 4 +- > > > drivers/gpu/drm/drm_atomic_uapi.c| 4 ++ > > > drivers/gpu/drm/drm_blend.c | 35 +-- > > > drivers/gpu/drm/drm_mode_config.c| 6 +++ > > > drivers/gpu/drm/i915/display/intel_color.c | 11 +++-- > > > drivers/gpu/drm/i915/display/intel_display.c | 45 > > > drivers/gpu/drm/i915/i915_debugfs.c | 9 > > > include/drm/drm_blend.h | 1 + > > > include/drm/drm_crtc.h | 12 ++ > > > include/drm/drm_mode_config.h| 5 +++ > > > include/uapi/drm/drm_mode.h | 28 > > > 11 files changed, 153 insertions(+), 7 deletions(-) > > > > > > -- > > > 2.21.0 > > > > > >
Re: [PATCH 3/3] drm/atmel-hlcdc: Use swap() where appropriate
On Thu, Oct 10, 2019 at 03:24:28PM +0200, Boris Brezillon wrote:
> On Thu, 10 Oct 2019 16:11:59 +0300
> Ville Syrjala wrote:
>
> > From: Ville Syrjälä
> >
> > @swap@
> > identifier TEMP;
> > expression A,B;
> > @@
> > - TEMP = A;
> > - A = B;
> > - B = TEMP;
> > + swap(A, B);
> >
> > @@
> > type T;
> > identifier swap.TEMP;
> > @@
> > (
> > - T TEMP;
> > |
> > - T TEMP = {...};
> > )
> > ... when != TEMP
> >
> > Cc: Sam Ravnborg
> > Cc: Boris Brezillon
> > Signed-off-by: Ville Syrjälä
>
> Reviewed-by: Boris Brezillon
Ta. Pushed to drm-misc-next.
>
> > ---
> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 5 +
> > 1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> > b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> > index 89f5a756fa37..034f202dfe8f 100644
> > --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> > +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> > @@ -601,7 +601,6 @@ static int atmel_hlcdc_plane_atomic_check(struct
> > drm_plane *p,
> > struct drm_framebuffer *fb = state->base.fb;
> > const struct drm_display_mode *mode;
> > struct drm_crtc_state *crtc_state;
> > - unsigned int tmp;
> > int ret;
> > int i;
> >
> > @@ -694,9 +693,7 @@ static int atmel_hlcdc_plane_atomic_check(struct
> > drm_plane *p,
> > * Swap width and size in case of 90 or 270 degrees rotation
> > */
> > if (drm_rotation_90_or_270(state->base.rotation)) {
> > - tmp = state->src_w;
> > - state->src_w = state->src_h;
> > - state->src_h = tmp;
> > + swap(state->src_w, state->src_h);
> > }
> >
> > if (!desc->layout.size &&
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111980] Rebbot and shutdown doesn't work on specific hardware
https://bugs.freedesktop.org/show_bug.cgi?id=111980 Bug ID: 111980 Summary: Rebbot and shutdown doesn't work on specific hardware Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: not set Priority: not set Component: DRM/Radeon Assignee: dri-devel@lists.freedesktop.org Reporter: lei.p...@gmail.com When system shutdown/reboot is initiated, everything works as it should, journal doesn't show any error and it reaches target reboot (for example), display shuts down properly, but PC stays powered on (requiring hard reset) indefinitely. This happened after kernel upgrade, after bisectiing, commit that was to blame was bellow, after removing just that specific commit, it would work as expected: 894c414129a8d9ef1b2de443015e4dde6085f64f is the first bad commit commit 894c414129a8d9ef1b2de443015e4dde6085f64f Author: KyleMahlkuch Date: Wed Jul 31 17:10:14 2019 -0500 drm/radeon: Fix EEH during kexec [ Upstream commit 6f7fe9a93e6c09bf988c5059403f5f88e17e21e6 ] During kexec some adapters hit an EEH since they are not properly shut down in the radeon_pci_shutdown() function. Adding radeon_suspend_kms() fixes this issue. Signed-off-by: KyleMahlkuch Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin drivers/gpu/drm/radeon/radeon_drv.c | 8 1 file changed, 8 insertions(+) Issue is described here, seems like others have similar issue that might be connected with this as well: https://bbs.archlinux.org/viewtopic.php?id=249787 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] dt-bindings: power: Convert Generic Power Domain bindings to json-schema
On Wed, Oct 02, 2019 at 06:06:30PM +0200, Krzysztof Kozlowski wrote:
> Convert Generic Power Domain bindings to DT schema format using
> json-schema. The consumer bindings are split to separate file.
>
> Signed-off-by: Krzysztof Kozlowski
>
> ---
>
> Changes since v1:
> 1. Select all nodes for consumers,
> 2. Remove from consumers duplicated properties with dt-schema,
> 3. Fix power domain pattern,
> 4. Remove unneeded types.
> ---
> .../devicetree/bindings/arm/arm,scmi.txt | 2 +-
> .../devicetree/bindings/arm/arm,scpi.txt | 2 +-
> .../bindings/arm/freescale/fsl,scu.txt| 2 +-
> .../bindings/clock/clk-exynos-audss.txt | 2 +-
> .../bindings/clock/exynos5433-clock.txt | 4 +-
> .../bindings/clock/renesas,cpg-mssr.txt | 2 +-
> .../clock/renesas,r8a7778-cpg-clocks.txt | 2 +-
> .../clock/renesas,r8a7779-cpg-clocks.txt | 2 +-
> .../clock/renesas,rcar-gen2-cpg-clocks.txt| 2 +-
> .../bindings/clock/renesas,rz-cpg-clocks.txt | 2 +-
> .../bindings/clock/ti/davinci/psc.txt | 2 +-
> .../bindings/display/etnaviv/etnaviv-drm.txt | 2 +-
> .../devicetree/bindings/display/msm/dpu.txt | 2 +-
> .../devicetree/bindings/display/msm/mdp5.txt | 2 +-
> .../devicetree/bindings/dsp/fsl,dsp.yaml | 2 +-
> .../firmware/nvidia,tegra186-bpmp.txt | 2 +-
> .../bindings/media/imx7-mipi-csi2.txt | 3 +-
> .../bindings/media/mediatek-jpeg-decoder.txt | 3 +-
> .../bindings/media/mediatek-mdp.txt | 3 +-
> .../bindings/opp/qcom-nvmem-cpufreq.txt | 2 +-
> .../devicetree/bindings/pci/pci-keystone.txt | 2 +-
> .../bindings/phy/ti,phy-am654-serdes.txt | 2 +-
> .../bindings/power/amlogic,meson-gx-pwrc.txt | 2 +-
> .../devicetree/bindings/power/fsl,imx-gpc.txt | 2 +-
> .../bindings/power/fsl,imx-gpcv2.txt | 2 +-
> .../power/power-domain-consumers.yaml | 105 +
> .../bindings/power/power-domain.yaml | 134
> .../bindings/power/power_domain.txt | 205 --
> .../devicetree/bindings/power/qcom,rpmpd.txt | 2 +-
> .../bindings/power/renesas,rcar-sysc.txt | 2 +-
> .../bindings/power/renesas,sysc-rmobile.txt | 2 +-
> .../bindings/power/xlnx,zynqmp-genpd.txt | 2 +-
> .../bindings/soc/bcm/brcm,bcm2835-pm.txt | 2 +-
> .../bindings/soc/mediatek/scpsys.txt | 2 +-
> .../bindings/soc/ti/sci-pm-domain.txt | 2 +-
> .../bindings/usb/nvidia,tegra124-xusb.txt | 4 +-
> MAINTAINERS | 2 +-
> 37 files changed, 278 insertions(+), 241 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/power/power-domain-consumers.yaml
> create mode 100644 Documentation/devicetree/bindings/power/power-domain.yaml
> delete mode 100644 Documentation/devicetree/bindings/power/power_domain.txt
> diff --git
> a/Documentation/devicetree/bindings/power/power-domain-consumers.yaml
> b/Documentation/devicetree/bindings/power/power-domain-consumers.yaml
> new file mode 100644
> index ..f65078e1260e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/power-domain-consumers.yaml
> @@ -0,0 +1,105 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/power/power-domain-consumers.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: PM domain consumers
> +
> +maintainers:
> + - Rafael J. Wysocki
> + - Kevin Hilman
> + - Ulf Hansson
> +
> +description: |+
> + See power-domain.yaml
> +
> +select: true
> +
> +allOf:
> + - $ref: /schemas/power-domain/power-domain-consumer.yaml
I don't like this split. We should move the contents of this file to the
above file.
I checked the authorship of the relevant lines and they are all except
for a small number of lines from Linaro authors (Viresh and Ulf). I have
permission from Linaro to dual license Linaro authored bindings, so it's
not a problem to move this. I can do that and you can just drop this file.
> +
> +properties:
> + required-opps:
> +$ref: /schemas/types.yaml#/definitions/phandle
> +description:
> + This contains phandle to an OPP node in another device's OPP table.
> + It may contain an array of phandles, where each phandle points to an
> OPP
> + of a different device. It should not contain multiple phandles to the
> OPP
> + nodes in the same OPP table. This specifies the minimum required OPP
> + of the device(s), whose OPP's phandle is present in this property,
> + for the functioning of the current device at the current OPP (where
> this
> + property is present).
> +
> +examples:
> + - |
> +leaky-device@1235 {
> + compatible = "foo,i-leak-current";
> + reg = <0x1235 0x1000>;
> + power-domains = < 0>;
> + power-domain-names = "io";
> +};
> +
> +leaky-device@12351000 {
> +
[Bug 204683] amdgpu: ring sdma0 timeout
https://bugzilla.kernel.org/show_bug.cgi?id=204683 --- Comment #12 from Matthias Heinz (m...@familie-heinz.name) --- My last update, because I have no way to go forward from here on. This bug seems to go way back longer than I initially thought. I'm currently at "drm-fixes-2018-08-31" in linux-drm and it's already in there, so it's probably pretty old. I can't use any older kernel, because I need steam to run the games to test this. But steam wont work with anything older than 4.19. BUT I found a game that almost instantly triggers this bug on startup: Insurgency. Just start it and if that doesn't trigger it immediately, quit the game and start it again. It can take two to three times, joining a match helps, too, but it takes less than 5 minutes for each test. So, please go ahead and fix this already, it's annoying. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] dt-bindings: display: imx: add bindings for DCSS
:u?wc??m5?^?㞾?}4-??z{b???r?+?׀u???ا#????ek
?W?J^?(???h}??-??z{b???r?Z+?jW.?\?oۊwb?
?v+)l?b? &??,?&??ξW???!jx w?ǫ?*'??+y?^??^?M:???r鞞֭???u??q?ky?ۊwb?
?v+)l?b? &??,?&????? uޮ?G???h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4] drm/ioctl: Add a ioctl to label GEM objects
DRM_IOCTL_DUMB_SET_LABEL lets you label GEM objects, making it
easier to debug issues in userspace applications.
Changes in v2:
- Hoist the IOCTL up into the drm_driver framework
Changes in v3:
- Introduce a drm_gem_set_label for drivers to use internally
in order to label a GEM object
- Hoist string copying up into the IOCTL
- Fix documentation
- Move actual gem labeling into drm_gem_adopt_label
Changes in v4:
- Refactor IOCTL call to only perform string duplication and move
all gem lookup logic into GEM specific call
Signed-off-by: Rohan Garg
---
drivers/gpu/drm/drm_gem.c | 70 ++
drivers/gpu/drm/drm_internal.h | 8
drivers/gpu/drm/drm_ioctl.c| 1 +
include/drm/drm_drv.h | 16
include/drm/drm_gem.h | 7
include/uapi/drm/drm.h | 20 ++
6 files changed, 122 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 6854f5867d51..0fa4609b2817 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -941,6 +941,71 @@ drm_gem_release(struct drm_device *dev, struct drm_file
*file_private)
idr_destroy(_private->object_idr);
}
+int drm_dumb_set_label_ioctl(struct drm_device *dev,
+ void *data, struct drm_file *file_priv)
+{
+ char *label;
+ struct drm_dumb_set_label_object *args = data;
+ int ret = 0;
+
+ if (!args->len || !args->name)
+ return -EINVAL;
+
+ if (!dev->driver->label)
+ return -EOPNOTSUPP;
+
+ label = strndup_user(u64_to_user_ptr(args->name), args->len);
+
+ if (IS_ERR(label)) {
+ ret = PTR_ERR(label);
+ goto err;
+ }
+
+ ret = dev->driver->label(dev, file_priv, args->handle, label);
+
+err:
+ kfree(label);
+ return ret;
+}
+
+int drm_gem_set_label(struct drm_device *dev,
+ struct drm_file *file_priv,
+ uint32_t handle,
+ const char *label)
+{
+ struct drm_gem_object *gem_obj;
+ int ret = 0;
+
+ gem_obj = drm_gem_object_lookup(file_priv, handle);
+ if (!gem_obj) {
+ DRM_DEBUG("Failed to look up GEM BO %d\n", handle);
+ ret = -ENOENT;
+ goto err;
+ }
+ drm_gem_adopt_label(gem_obj, label);
+
+err:
+ drm_gem_object_put_unlocked(gem_obj);
+ return ret;
+}
+EXPORT_SYMBOL(drm_gem_set_label);
+
+void drm_gem_adopt_label(struct drm_gem_object *gem_obj, const char *label)
+{
+ char *adopted_label = NULL;
+
+ if (label)
+ adopted_label = kstrdup(label, GFP_KERNEL);
+
+ if (gem_obj->label) {
+ kfree(gem_obj->label);
+ gem_obj->label = NULL;
+ }
+
+ gem_obj->label = adopted_label;
+}
+EXPORT_SYMBOL(drm_gem_adopt_label);
+
/**
* drm_gem_object_release - release GEM buffer object resources
* @obj: GEM buffer object
@@ -958,6 +1023,11 @@ drm_gem_object_release(struct drm_gem_object *obj)
dma_resv_fini(>_resv);
drm_gem_free_mmap_offset(obj);
+
+ if (obj->label) {
+ kfree(obj->label);
+ obj->label = NULL;
+ }
}
EXPORT_SYMBOL(drm_gem_object_release);
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 51a2055c8f18..cbc3f7b7fb9b 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -137,6 +137,14 @@ int drm_gem_pin(struct drm_gem_object *obj);
void drm_gem_unpin(struct drm_gem_object *obj);
void *drm_gem_vmap(struct drm_gem_object *obj);
void drm_gem_vunmap(struct drm_gem_object *obj, void *vaddr);
+int drm_dumb_set_label_ioctl(struct drm_device *dev,
+ void *data,
+ struct drm_file *file_priv);
+int drm_gem_set_label(struct drm_device *dev,
+ struct drm_file *file_priv,
+ uint32_t handle,
+ const char *label);
+void drm_gem_adopt_label(struct drm_gem_object *gem_obj, const char *label);
/* drm_debugfs.c drm_debugfs_crc.c */
#if defined(CONFIG_DEBUG_FS)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index fcd728d7cf72..f34e1571d70f 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -714,6 +714,7 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_MODE_LIST_LESSEES, drm_mode_list_lessees_ioctl,
DRM_MASTER),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GET_LEASE, drm_mode_get_lease_ioctl,
DRM_MASTER),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_REVOKE_LEASE, drm_mode_revoke_lease_ioctl,
DRM_MASTER),
+ DRM_IOCTL_DEF(DRM_IOCTL_DUMB_SET_LABEL, drm_dumb_set_label_ioctl,
DRM_RENDER_ALLOW),
};
#define DRM_CORE_IOCTL_COUNT ARRAY_SIZE( drm_ioctls )
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index cf13470810a5..501a3924354a 100644
Re: [PATCH v2 04/21] drm/exynos: Fix potential unbalanced calls to pm_runtime_put
On Fri, 11 Oct 2019 15:54:53 +0200
Andrzej Hajda wrote:
> On 26.08.2019 17:26, Boris Brezillon wrote:
> > The encoder->enable() can't report errors and is expected to always
> > succeed. If we call pm_runtime_put() in the exynos_dsi_enable() error
> > path (as currently done) we'll have unbalanced get/put calls when
> > encoder->disable() is called.
>
>
> True
>
>
> >
> > The situation is not ideal since drm_panel_{prepare,enable}() can
> > theoretically return an error (even if in practice I don't think any
> > panel driver does that).
>
>
> So why do you want to fix it at all, if you think return value is always
> 0 :) ?
>
>
> git grep -p -A30 '_prepare' drivers/gpu/drm/panel/ shows that many of
> them can return errors.
Then I was wrong :-).
>
>
> > Putting a WARN_ON() is the best we can do,
> > unfortunately.
>
>
> I guess optimally we should use DRM_MODE_LINK_STATUS_BAD, but I am not
> sure how exactly it should be handled.
You mean call
drm_connector_set_link_status_property(DRM_MODE_LINK_STATUS_BAD) ?
>
>
> > Note that -ENOSYS is actually a valid case, it just
> > means the panel driver does not implement the hook.
>
>
> It would be good then to fix it in panel framework, ie without hook
> drm_panel_* function should return 0, ENOSYS makes no sense here.
I'm fine with that. Thierry, Sam, any opinion?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] drm/omap: Remove some set but not used variables
Hi, On 08/10/2019 10:15, zhengbin wrote: zhengbin (4): drm/omap: Remove set but not used variable 'plane' drm/omap: Remove set but not used variable 'tclk_trail' drm/omap: Remove set but not used variable 'err' in hdmi5_audio_config drm/omap: Remove set but not used variable 'err' in hdmi4_audio_config drivers/gpu/drm/omapdrm/dss/dsi.c| 3 +-- drivers/gpu/drm/omapdrm/dss/hdmi4_core.c | 4 ++-- drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 4 ++-- drivers/gpu/drm/omapdrm/omap_fb.c| 3 --- 4 files changed, 5 insertions(+), 9 deletions(-) Thanks! I'll pick these up. 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 v5 0/8] drm/omap: OMAP_BO flags
On 10/10/2019 14:59, Jean-Jacques Hiblot wrote: A first version of this work had been sent by Tomi Valkeinen in may 2017 (https://www.spinics.net/lists/dri-devel/msg140663.html). This series adds a few new OMAP_BO flags to help the userspace manage situations where it needs to use lots of buffers, and would currently run out of TILER space. The TILER space is limited to mapping 128MB at any given time and some applications might need more. This seres is also the opportunity to do some cleanup in the flags and improve the comments describing them. The user-space patches for libdrm, although ready, haven't been posted yet. It will be be done when this series have been discussed and hopefully in the process of getting merged. Thanks! I'll queue these up. 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
[Bug 111763] ring_gfx hangs/freezes on Navi gpus
https://bugs.freedesktop.org/show_bug.cgi?id=111763 --- Comment #11 from Marko Popovic --- (In reply to takios+fdbugs from comment #10) > (In reply to Marko Popovic from comment #9) > > https://cgit.freedesktop.org/mesa/mesa/commit/ > > ?id=a2a68d551c1c2a4f13761ffa8f3f6f13fee7a384 > > > > This might actually fix the ring_gfx type hangs or even sdma ones at least > > for Vulkan API? Not exactly sure but will also be testing the latest MESA > > builds from Oibaf's PPA in following days and report back on the issue :) > > Sadly, I'm still getting the ring_gfx hangs after a few minutes of playing > Trackmania 2. Oh yes I forgot to add a reply here. It didn't solve any of the hangs for me either. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 04/21] drm/exynos: Fix potential unbalanced calls to pm_runtime_put
On 26.08.2019 17:26, Boris Brezillon wrote:
> The encoder->enable() can't report errors and is expected to always
> succeed. If we call pm_runtime_put() in the exynos_dsi_enable() error
> path (as currently done) we'll have unbalanced get/put calls when
> encoder->disable() is called.
True
>
> The situation is not ideal since drm_panel_{prepare,enable}() can
> theoretically return an error (even if in practice I don't think any
> panel driver does that).
So why do you want to fix it at all, if you think return value is always
0 :) ?
git grep -p -A30 '_prepare' drivers/gpu/drm/panel/ shows that many of
them can return errors.
> Putting a WARN_ON() is the best we can do,
> unfortunately.
I guess optimally we should use DRM_MODE_LINK_STATUS_BAD, but I am not
sure how exactly it should be handled.
> Note that -ENOSYS is actually a valid case, it just
> means the panel driver does not implement the hook.
It would be good then to fix it in panel framework, ie without hook
drm_panel_* function should return 0, ENOSYS makes no sense here.
Regards
Andrzej
>
> Signed-off-by: Boris Brezillon
> ---
> Changes in v2:
> * New patch
> ---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 14 ++
> 1 file changed, 2 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 8e655ae1fb0c..c555cecfe1f5 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -1387,8 +1387,7 @@ static void exynos_dsi_enable(struct drm_encoder
> *encoder)
>
> if (dsi->panel) {
> ret = drm_panel_prepare(dsi->panel);
> - if (ret < 0)
> - goto err_put_sync;
> + WARN_ON(ret && ret != -ENOSYS);
> } else {
> drm_bridge_pre_enable(dsi->out_bridge);
> }
> @@ -1398,22 +1397,13 @@ static void exynos_dsi_enable(struct drm_encoder
> *encoder)
>
> if (dsi->panel) {
> ret = drm_panel_enable(dsi->panel);
> - if (ret < 0)
> - goto err_display_disable;
> + WARN_ON(ret && ret != -ENOSYS);
> } else {
> drm_bridge_enable(dsi->out_bridge);
> }
>
> dsi->state |= DSIM_STATE_VIDOUT_AVAILABLE;
> return;
> -
> -err_display_disable:
> - exynos_dsi_set_display_enable(dsi, false);
> - drm_panel_unprepare(dsi->panel);
> -
> -err_put_sync:
> - dsi->state &= ~DSIM_STATE_ENABLED;
> - pm_runtime_put(dsi->dev);
> }
>
> static void exynos_dsi_disable(struct drm_encoder *encoder)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] drm/vboxvideo: Use generic fbdev and framebuffer
The vboxvideo driver provides its own implementation for fbdev emulation and framebuffers. Both can be replaced by DRM's generic code. All patches have been tested on VirtualBox 6.0.12. Thomas Zimmermann (3): drm/vboxvideo: Switch to generic fbdev emulation drm/vboxvideo: Switch to drm_atomic_helper_dirty_fb() drm/vboxvideo: Replace struct vram_framebuffer with generic implemenation drivers/gpu/drm/vboxvideo/Makefile| 2 +- drivers/gpu/drm/vboxvideo/vbox_drv.c | 14 +-- drivers/gpu/drm/vboxvideo/vbox_drv.h | 25 - drivers/gpu/drm/vboxvideo/vbox_fb.c | 149 -- drivers/gpu/drm/vboxvideo/vbox_main.c | 119 +--- drivers/gpu/drm/vboxvideo/vbox_mode.c | 86 +++ 6 files changed, 49 insertions(+), 346 deletions(-) delete mode 100644 drivers/gpu/drm/vboxvideo/vbox_fb.c -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/vboxvideo: Switch to drm_atomic_helper_dirty_fb()
The vboxvideo driver provides struct drm_framebuffer_funcs.dirty_fb from
its own implementation. Switch over to drm_atomic_helper_dirty_fb() and
handle screen updates in the primary plane's atomic_update function.
With dirty_fb out of the way, we can further replace struct vbox_frammebuffer
with generic code.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vboxvideo/vbox_drv.h | 4 --
drivers/gpu/drm/vboxvideo/vbox_main.c | 61 +--
drivers/gpu/drm/vboxvideo/vbox_mode.c | 34 +++
3 files changed, 36 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.h
b/drivers/gpu/drm/vboxvideo/vbox_drv.h
index bb0c39fe7911..9976554b58cb 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.h
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.h
@@ -143,10 +143,6 @@ void vbox_mode_fini(struct vbox_private *vbox);
void vbox_report_caps(struct vbox_private *vbox);
-void vbox_framebuffer_dirty_rectangles(struct drm_framebuffer *fb,
- struct drm_clip_rect *rects,
- unsigned int num_rects);
-
int vbox_framebuffer_init(struct vbox_private *vbox,
struct vbox_framebuffer *vbox_fb,
const struct drm_mode_fb_cmd2 *mode_cmd,
diff --git a/drivers/gpu/drm/vboxvideo/vbox_main.c
b/drivers/gpu/drm/vboxvideo/vbox_main.c
index 02fa8277ff1e..ba24a9293d17 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_main.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_main.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include "vbox_drv.h"
#include "vboxvideo_guest.h"
@@ -38,67 +39,9 @@ void vbox_report_caps(struct vbox_private *vbox)
hgsmi_send_caps_info(vbox->guest_pool, caps);
}
-/* Send information about dirty rectangles to VBVA. */
-void vbox_framebuffer_dirty_rectangles(struct drm_framebuffer *fb,
- struct drm_clip_rect *rects,
- unsigned int num_rects)
-{
- struct vbox_private *vbox = fb->dev->dev_private;
- struct drm_display_mode *mode;
- struct drm_crtc *crtc;
- int crtc_x, crtc_y;
- unsigned int i;
-
- mutex_lock(>hw_mutex);
- list_for_each_entry(crtc, >dev->mode_config.crtc_list, head) {
- if (crtc->primary->state->fb != fb)
- continue;
-
- mode = >state->mode;
- crtc_x = crtc->primary->state->src_x >> 16;
- crtc_y = crtc->primary->state->src_y >> 16;
-
- for (i = 0; i < num_rects; ++i) {
- struct vbva_cmd_hdr cmd_hdr;
- unsigned int crtc_id = to_vbox_crtc(crtc)->crtc_id;
-
- if (rects[i].x1 > crtc_x + mode->hdisplay ||
- rects[i].y1 > crtc_y + mode->vdisplay ||
- rects[i].x2 < crtc_x ||
- rects[i].y2 < crtc_y)
- continue;
-
- cmd_hdr.x = (s16)rects[i].x1;
- cmd_hdr.y = (s16)rects[i].y1;
- cmd_hdr.w = (u16)rects[i].x2 - rects[i].x1;
- cmd_hdr.h = (u16)rects[i].y2 - rects[i].y1;
-
- if (!vbva_buffer_begin_update(>vbva_info[crtc_id],
- vbox->guest_pool))
- continue;
-
- vbva_write(>vbva_info[crtc_id], vbox->guest_pool,
- _hdr, sizeof(cmd_hdr));
- vbva_buffer_end_update(>vbva_info[crtc_id]);
- }
- }
- mutex_unlock(>hw_mutex);
-}
-
-static int vbox_user_framebuffer_dirty(struct drm_framebuffer *fb,
- struct drm_file *file_priv,
- unsigned int flags, unsigned int color,
- struct drm_clip_rect *rects,
- unsigned int num_rects)
-{
- vbox_framebuffer_dirty_rectangles(fb, rects, num_rects);
-
- return 0;
-}
-
static const struct drm_framebuffer_funcs vbox_fb_funcs = {
.destroy = vbox_user_framebuffer_destroy,
- .dirty = vbox_user_framebuffer_dirty,
+ .dirty = drm_atomic_helper_dirtyfb,
};
int vbox_framebuffer_init(struct vbox_private *vbox,
diff --git a/drivers/gpu/drm/vboxvideo/vbox_mode.c
b/drivers/gpu/drm/vboxvideo/vbox_mode.c
index dd9ad3fdd919..70754e9a087e 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_mode.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_mode.c
@@ -284,10 +284,44 @@ static void vbox_primary_atomic_update(struct drm_plane
*plane,
{
struct drm_crtc *crtc = plane->state->crtc;
struct drm_framebuffer *fb = plane->state->fb;
+ struct vbox_private *vbox = fb->dev->dev_private;
+ struct drm_mode_rect *clips;
+ uint32_t num_clips, i;
[PATCH 1/3] drm/vboxvideo: Switch to generic fbdev emulation
There's nothing special about vboxvideo's fbdev emulation that is
not provided by the generic implementation. Switch over and remove
the driver's code.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vboxvideo/Makefile| 2 +-
drivers/gpu/drm/vboxvideo/vbox_drv.c | 14 +--
drivers/gpu/drm/vboxvideo/vbox_drv.h | 7 --
drivers/gpu/drm/vboxvideo/vbox_fb.c | 149 --
drivers/gpu/drm/vboxvideo/vbox_mode.c | 3 +-
5 files changed, 6 insertions(+), 169 deletions(-)
delete mode 100644 drivers/gpu/drm/vboxvideo/vbox_fb.c
diff --git a/drivers/gpu/drm/vboxvideo/Makefile
b/drivers/gpu/drm/vboxvideo/Makefile
index 55d798c76b21..f2e968b5ffa6 100644
--- a/drivers/gpu/drm/vboxvideo/Makefile
+++ b/drivers/gpu/drm/vboxvideo/Makefile
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
vboxvideo-y := hgsmi_base.o modesetting.o vbva_base.o \
- vbox_drv.o vbox_fb.o vbox_hgsmi.o vbox_irq.o vbox_main.o \
+ vbox_drv.o vbox_hgsmi.o vbox_irq.o vbox_main.o \
vbox_mode.o vbox_ttm.o
obj-$(CONFIG_DRM_VBOXVIDEO) += vboxvideo.o
diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c
b/drivers/gpu/drm/vboxvideo/vbox_drv.c
index 862db495d111..6ee308b453da 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c
@@ -14,6 +14,7 @@
#include
#include
+#include
#include
#include
@@ -32,10 +33,6 @@ static const struct pci_device_id pciidlist[] = {
};
MODULE_DEVICE_TABLE(pci, pciidlist);
-static const struct drm_fb_helper_funcs vbox_fb_helper_funcs = {
- .fb_probe = vboxfb_create,
-};
-
static int vbox_pci_probe(struct pci_dev *pdev, const struct pci_device_id
*ent)
{
struct vbox_private *vbox;
@@ -79,20 +76,16 @@ static int vbox_pci_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
if (ret)
goto err_mode_fini;
- ret = drm_fb_helper_fbdev_setup(>ddev, >fb_helper,
- _fb_helper_funcs, 32,
- vbox->num_crtcs);
+ ret = drm_fbdev_generic_setup(>ddev, 32);
if (ret)
goto err_irq_fini;
ret = drm_dev_register(>ddev, 0);
if (ret)
- goto err_fbdev_fini;
+ goto err_irq_fini;
return 0;
-err_fbdev_fini:
- vbox_fbdev_fini(vbox);
err_irq_fini:
vbox_irq_fini(vbox);
err_mode_fini:
@@ -113,7 +106,6 @@ static void vbox_pci_remove(struct pci_dev *pdev)
struct vbox_private *vbox = pci_get_drvdata(pdev);
drm_dev_unregister(>ddev);
- vbox_fbdev_fini(vbox);
vbox_irq_fini(vbox);
vbox_mode_fini(vbox);
vbox_mm_fini(vbox);
diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.h
b/drivers/gpu/drm/vboxvideo/vbox_drv.h
index fb436ec760ea..bb0c39fe7911 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.h
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.h
@@ -16,7 +16,6 @@
#include
#include
-#include
#include
#include
@@ -54,8 +53,6 @@ struct vbox_framebuffer {
struct vbox_private {
/* Must be first; or we must define our own release callback */
struct drm_device ddev;
- struct drm_fb_helper fb_helper;
- struct vbox_framebuffer afb;
u8 __iomem *guest_heap;
u8 __iomem *vbva_buffers;
@@ -155,10 +152,6 @@ int vbox_framebuffer_init(struct vbox_private *vbox,
const struct drm_mode_fb_cmd2 *mode_cmd,
struct drm_gem_object *obj);
-int vboxfb_create(struct drm_fb_helper *helper,
- struct drm_fb_helper_surface_size *sizes);
-void vbox_fbdev_fini(struct vbox_private *vbox);
-
int vbox_mm_init(struct vbox_private *vbox);
void vbox_mm_fini(struct vbox_private *vbox);
diff --git a/drivers/gpu/drm/vboxvideo/vbox_fb.c
b/drivers/gpu/drm/vboxvideo/vbox_fb.c
deleted file mode 100644
index 8f74bcffc034..
--- a/drivers/gpu/drm/vboxvideo/vbox_fb.c
+++ /dev/null
@@ -1,149 +0,0 @@
-// SPDX-License-Identifier: MIT
-/*
- * Copyright (C) 2013-2017 Oracle Corporation
- * This file is based on ast_fb.c
- * Copyright 2012 Red Hat Inc.
- * Authors: Dave Airlie
- * Michael Thayer
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-#include
-#include
-#include
-
-#include "vbox_drv.h"
-#include "vboxvideo.h"
-
-#ifdef CONFIG_DRM_KMS_FB_HELPER
-static struct fb_deferred_io vbox_defio = {
- .delay = HZ / 30,
- .deferred_io = drm_fb_helper_deferred_io,
-};
-#endif
-
-static struct fb_ops vboxfb_ops = {
- .owner = THIS_MODULE,
- DRM_FB_HELPER_DEFAULT_OPS,
- .fb_fillrect = drm_fb_helper_sys_fillrect,
- .fb_copyarea = drm_fb_helper_sys_copyarea,
- .fb_imageblit = drm_fb_helper_sys_imageblit,
-};
-
-int vboxfb_create(struct drm_fb_helper *helper,
- struct drm_fb_helper_surface_size *sizes)
-{
- struct vbox_private
[PATCH 3/3] drm/vboxvideo: Replace struct vram_framebuffer with generic implemenation
The vboxvideo driver's struct vram_framebuffer stores a DRM framebuffer
with an assiciated GEM object. This functionality is also provided by
generic code. Switch vboxvideo over.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vboxvideo/vbox_drv.h | 14 ---
drivers/gpu/drm/vboxvideo/vbox_main.c | 60 ---
drivers/gpu/drm/vboxvideo/vbox_mode.c | 49 --
3 files changed, 8 insertions(+), 115 deletions(-)
diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.h
b/drivers/gpu/drm/vboxvideo/vbox_drv.h
index 9976554b58cb..87421903816c 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.h
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.h
@@ -45,11 +45,6 @@
sizeof(struct hgsmi_host_flags))
#define HOST_FLAGS_OFFSET GUEST_HEAP_USABLE_SIZE
-struct vbox_framebuffer {
- struct drm_framebuffer base;
- struct drm_gem_object *obj;
-};
-
struct vbox_private {
/* Must be first; or we must define our own release callback */
struct drm_device ddev;
@@ -132,7 +127,6 @@ struct vbox_encoder {
#define to_vbox_crtc(x) container_of(x, struct vbox_crtc, base)
#define to_vbox_connector(x) container_of(x, struct vbox_connector, base)
#define to_vbox_encoder(x) container_of(x, struct vbox_encoder, base)
-#define to_vbox_framebuffer(x) container_of(x, struct vbox_framebuffer, base)
bool vbox_check_supported(u16 id);
int vbox_hw_init(struct vbox_private *vbox);
@@ -143,17 +137,9 @@ void vbox_mode_fini(struct vbox_private *vbox);
void vbox_report_caps(struct vbox_private *vbox);
-int vbox_framebuffer_init(struct vbox_private *vbox,
- struct vbox_framebuffer *vbox_fb,
- const struct drm_mode_fb_cmd2 *mode_cmd,
- struct drm_gem_object *obj);
-
int vbox_mm_init(struct vbox_private *vbox);
void vbox_mm_fini(struct vbox_private *vbox);
-int vbox_gem_create(struct vbox_private *vbox,
- u32 size, bool iskernel, struct drm_gem_object **obj);
-
/* vbox_irq.c */
int vbox_irq_init(struct vbox_private *vbox);
void vbox_irq_fini(struct vbox_private *vbox);
diff --git a/drivers/gpu/drm/vboxvideo/vbox_main.c
b/drivers/gpu/drm/vboxvideo/vbox_main.c
index ba24a9293d17..9dcab115a261 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_main.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_main.c
@@ -17,17 +17,6 @@
#include "vboxvideo_guest.h"
#include "vboxvideo_vbe.h"
-static void vbox_user_framebuffer_destroy(struct drm_framebuffer *fb)
-{
- struct vbox_framebuffer *vbox_fb = to_vbox_framebuffer(fb);
-
- if (vbox_fb->obj)
- drm_gem_object_put_unlocked(vbox_fb->obj);
-
- drm_framebuffer_cleanup(fb);
- kfree(fb);
-}
-
void vbox_report_caps(struct vbox_private *vbox)
{
u32 caps = VBVACAPS_DISABLE_CURSOR_INTEGRATION |
@@ -39,29 +28,6 @@ void vbox_report_caps(struct vbox_private *vbox)
hgsmi_send_caps_info(vbox->guest_pool, caps);
}
-static const struct drm_framebuffer_funcs vbox_fb_funcs = {
- .destroy = vbox_user_framebuffer_destroy,
- .dirty = drm_atomic_helper_dirtyfb,
-};
-
-int vbox_framebuffer_init(struct vbox_private *vbox,
- struct vbox_framebuffer *vbox_fb,
- const struct drm_mode_fb_cmd2 *mode_cmd,
- struct drm_gem_object *obj)
-{
- int ret;
-
- drm_helper_mode_fill_fb_struct(>ddev, _fb->base, mode_cmd);
- vbox_fb->obj = obj;
- ret = drm_framebuffer_init(>ddev, _fb->base, _fb_funcs);
- if (ret) {
- DRM_ERROR("framebuffer init failed %d\n", ret);
- return ret;
- }
-
- return 0;
-}
-
static int vbox_accel_init(struct vbox_private *vbox)
{
struct vbva_buffer *vbva;
@@ -213,29 +179,3 @@ void vbox_hw_fini(struct vbox_private *vbox)
gen_pool_destroy(vbox->guest_pool);
pci_iounmap(vbox->ddev.pdev, vbox->guest_heap);
}
-
-int vbox_gem_create(struct vbox_private *vbox,
- u32 size, bool iskernel, struct drm_gem_object **obj)
-{
- struct drm_gem_vram_object *gbo;
- int ret;
-
- *obj = NULL;
-
- size = roundup(size, PAGE_SIZE);
- if (size == 0)
- return -EINVAL;
-
- gbo = drm_gem_vram_create(>ddev, >ddev.vram_mm->bdev,
- size, 0, false);
- if (IS_ERR(gbo)) {
- ret = PTR_ERR(gbo);
- if (ret != -ERESTARTSYS)
- DRM_ERROR("failed to allocate GEM object\n");
- return ret;
- }
-
- *obj = >bo.base;
-
- return 0;
-}
diff --git a/drivers/gpu/drm/vboxvideo/vbox_mode.c
b/drivers/gpu/drm/vboxvideo/vbox_mode.c
index 70754e9a087e..e09f5f38fbff 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_mode.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_mode.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -173,8 +174,7 @@ static
[PATCH v2] drm/msm/dsi: Implement reset correctly
On msm8998, vblank timeouts are observed because the DSI controller is not
reset properly, which ends up stalling the MDP. This is because the reset
logic is not correct per the hardware documentation.
The documentation states that after asserting reset, software should wait
some time (no indication of how long), or poll the status register until it
returns 0 before deasserting reset.
wmb() is insufficient for this purpose since it just ensures ordering, not
timing between writes. Since asserting and deasserting reset occurs on the
same register, ordering is already guaranteed by the architecture, making
the wmb extraneous.
Since we would define a timeout for polling the status register to avoid a
possible infinite loop, lets just use a static delay of 20 ms, since 16.666
ms is the time available to process one frame at 60 fps.
Fixes: a689554ba6ed (drm/msm: Initial add DSI connector support)
Signed-off-by: Jeffrey Hugo
Reviewed-by: Sean Paul
---
v2:
-make a DEFINE for the delay
drivers/gpu/drm/msm/dsi/dsi_host.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 663ff9f4fac9..9a81705301c6 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -26,6 +26,8 @@
#include "dsi_cfg.h"
#include "msm_kms.h"
+#define RESET_DELAY 20
+
static int dsi_get_version(const void __iomem *base, u32 *major, u32 *minor)
{
u32 ver;
@@ -986,7 +988,7 @@ static void dsi_sw_reset(struct msm_dsi_host *msm_host)
wmb(); /* clocks need to be enabled before reset */
dsi_write(msm_host, REG_DSI_RESET, 1);
- wmb(); /* make sure reset happen */
+ msleep(RESET_DELAY); /* make sure reset happen */
dsi_write(msm_host, REG_DSI_RESET, 0);
}
@@ -1396,7 +1398,7 @@ static void dsi_sw_reset_restore(struct msm_dsi_host
*msm_host)
/* dsi controller can only be reset while clocks are running */
dsi_write(msm_host, REG_DSI_RESET, 1);
- wmb(); /* make sure reset happen */
+ msleep(RESET_DELAY);/* make sure reset happen */
dsi_write(msm_host, REG_DSI_RESET, 0);
wmb(); /* controller out of reset */
dsi_write(msm_host, REG_DSI_CTRL, data0);
--
2.17.1
[Bug 111763] ring_gfx hangs/freezes on Navi gpus
https://bugs.freedesktop.org/show_bug.cgi?id=111763 --- Comment #10 from takios+fdb...@takios.de --- (In reply to Marko Popovic from comment #9) > https://cgit.freedesktop.org/mesa/mesa/commit/ > ?id=a2a68d551c1c2a4f13761ffa8f3f6f13fee7a384 > > This might actually fix the ring_gfx type hangs or even sdma ones at least > for Vulkan API? Not exactly sure but will also be testing the latest MESA > builds from Oibaf's PPA in following days and report back on the issue :) Sadly, I'm still getting the ring_gfx hangs after a few minutes of playing Trackmania 2. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/msm: Sanitize the modeset_is_locked checks in dpu
On Thu, Oct 10, 2019 at 02:17:44PM -0400, Sean Paul wrote:
> From: Sean Paul
>
> As Daniel mentions in his email [1], non-blocking commits don't hold the
> modeset locks, so we can safely access state as long as these functions
> are in the commit path. So remove the WARN_ON in dpu_kms_encoder_enable.
>
> In dpu_crtc_get_intf_mode, things are a bit more complicated. So keep
> the WARN_ON, but add a comment explaining the situation and hope someone
> comes along and fixes the issue.
>
> [1]- https://lists.freedesktop.org/archives/dri-devel/2019-October/239441.html
>
> Link to v1:
> https://patchwork.freedesktop.org/patch/msgid/20191010151351.126735-1-s...@poorly.run
>
> Changes in v2:
> - Restored the WARN_ON in get_intf_mode and added a clarifying comment
> (Daniel)
>
> Fixes: 1dfdb0e107db ("drm/msm: dpu: Add modeset lock checks where applicable")
> Cc: Jeykumar Sankaran
> Cc: Rob Clark
> Suggested-by: Daniel Vetter
> Partially-Reviewed-by: Daniel Vetter
Applied to msm-next with danvet's full irc r-b, thanks for the report and
review!
Sean
> Signed-off-by: Sean Paul
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 9 +
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 -
> 2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index 0b9dc042d2e22..f197dce545761 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -271,6 +271,15 @@ enum dpu_intf_mode dpu_crtc_get_intf_mode(struct
> drm_crtc *crtc)
> return INTF_MODE_NONE;
> }
>
> + /*
> + * TODO: This function is called from dpu debugfs and as part of atomic
> + * check. When called from debugfs, the crtc->mutex must be held to
> + * read crtc->state. However reading crtc->state from atomic check isn't
> + * allowed (unless you have a good reason, a big comment, and a deep
> + * understanding of how the atomic/modeset locks work (<- and this is
> + * probably not possible)). So we'll keep the WARN_ON here for now, but
> + * really we need to figure out a better way to track our operating mode
> + */
> WARN_ON(!drm_modeset_is_locked(>mutex));
>
> /* TODO: Returns the first INTF_MODE, could there be multiple values? */
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> index b1645ad83a1e1..6c92f0fbeac98 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> @@ -316,7 +316,6 @@ void dpu_kms_encoder_enable(struct drm_encoder *encoder)
> if (funcs && funcs->commit)
> funcs->commit(encoder);
>
> - WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
> drm_for_each_crtc(crtc, dev) {
> if (!(crtc->state->encoder_mask & drm_encoder_mask(encoder)))
> continue;
> --
> Sean Paul, Software Engineer, Google / Chromium OS
>
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] drm/msm: Remove four set but not used variables
On Thu, Oct 10, 2019 at 02:55:02PM +0800, zhengbin wrote: > zhengbin (4): > drm/msm/mdp5: Remove set but not used variable 'fmt' > drm/msm/mdp5: Remove set but not used variable 'hw_cfg' in blend_setup > drm/msm/dsi: Remove set but not used variable 'lpx' > drm/msm/dsi: Remove set but not used variable 'lp' Applied the set to msm-next, thanks for the patches! Sean > > drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 3 --- > drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c | 2 -- > drivers/gpu/drm/msm/dsi/dsi_host.c| 3 +-- > drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 6 ++ > 4 files changed, 3 insertions(+), 11 deletions(-) > > -- > 2.7.4 > -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/mdp5: make config variables static
On Wed, Oct 09, 2019 at 01:05:22PM +0100, Ben Dooks wrote:
> A number of the config structs are not exported so make
> them static to avoid the following sparse warnings:
>
> drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c:17:26: warning: symbol
> 'msm8x74v1_config' was not declared. Should it be static?
> drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c:101:26: warning: symbol
> 'msm8x74v2_config' was not declared. Should it be static?
> drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c:183:26: warning: symbol
> 'apq8084_config' was not declared. Should it be static?
> drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c:278:26: warning: symbol
> 'msm8x16_config' was not declared. Should it be static?
> drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c:345:26: warning: symbol
> 'msm8x94_config' was not declared. Should it be static?
> drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c:440:26: warning: symbol
> 'msm8x96_config' was not declared. Should it be static?
> drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c:548:26: warning: symbol
> 'msm8917_config' was not declared. Should it be static?
> drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c:633:26: warning: symbol
> 'msm8998_config' was not declared. Should it be static?
>
> Signed-off-by: Ben Dooks
Applied to msm-next, thanks for the patch!
Sean
> ---
> Cc: Rob Clark
> Cc: Sean Paul
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: linux-arm-...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: freedr...@lists.freedesktop.org
> ---
> drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
> index f6e71ff539ca..7c9c1ddae821 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
> @@ -14,7 +14,7 @@ struct mdp5_cfg_handler {
> /* mdp5_cfg must be exposed (used in mdp5.xml.h) */
> const struct mdp5_cfg_hw *mdp5_cfg = NULL;
>
> -const struct mdp5_cfg_hw msm8x74v1_config = {
> +static const struct mdp5_cfg_hw msm8x74v1_config = {
> .name = "msm8x74v1",
> .mdp = {
> .count = 1,
> @@ -98,7 +98,7 @@ const struct mdp5_cfg_hw msm8x74v1_config = {
> .max_clk = 2,
> };
>
> -const struct mdp5_cfg_hw msm8x74v2_config = {
> +static const struct mdp5_cfg_hw msm8x74v2_config = {
> .name = "msm8x74",
> .mdp = {
> .count = 1,
> @@ -180,7 +180,7 @@ const struct mdp5_cfg_hw msm8x74v2_config = {
> .max_clk = 2,
> };
>
> -const struct mdp5_cfg_hw apq8084_config = {
> +static const struct mdp5_cfg_hw apq8084_config = {
> .name = "apq8084",
> .mdp = {
> .count = 1,
> @@ -275,7 +275,7 @@ const struct mdp5_cfg_hw apq8084_config = {
> .max_clk = 32000,
> };
>
> -const struct mdp5_cfg_hw msm8x16_config = {
> +static const struct mdp5_cfg_hw msm8x16_config = {
> .name = "msm8x16",
> .mdp = {
> .count = 1,
> @@ -342,7 +342,7 @@ const struct mdp5_cfg_hw msm8x16_config = {
> .max_clk = 32000,
> };
>
> -const struct mdp5_cfg_hw msm8x94_config = {
> +static const struct mdp5_cfg_hw msm8x94_config = {
> .name = "msm8x94",
> .mdp = {
> .count = 1,
> @@ -437,7 +437,7 @@ const struct mdp5_cfg_hw msm8x94_config = {
> .max_clk = 4,
> };
>
> -const struct mdp5_cfg_hw msm8x96_config = {
> +static const struct mdp5_cfg_hw msm8x96_config = {
> .name = "msm8x96",
> .mdp = {
> .count = 1,
> @@ -545,7 +545,7 @@ const struct mdp5_cfg_hw msm8x96_config = {
> .max_clk = 41250,
> };
>
> -const struct mdp5_cfg_hw msm8917_config = {
> +static const struct mdp5_cfg_hw msm8917_config = {
> .name = "msm8917",
> .mdp = {
> .count = 1,
> @@ -630,7 +630,7 @@ const struct mdp5_cfg_hw msm8917_config = {
> .max_clk = 32000,
> };
>
> -const struct mdp5_cfg_hw msm8998_config = {
> +static const struct mdp5_cfg_hw msm8998_config = {
> .name = "msm8998",
> .mdp = {
> .count = 1,
> --
> 2.23.0
>
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm: make a5xx_show and a5xx_gpu_state_put static
On Wed, Oct 09, 2019 at 09:44:06AM -0600, Jordan Crouse wrote:
> On Wed, Oct 09, 2019 at 12:46:07PM +0100, Ben Dooks wrote:
> > The a5xx_show and a5xx_gpu_state_put objects are not exported
> > outside of the file, so make them static to avoid the following
> > warnings from sparse:
> >
> > drivers/gpu/drm/msm/adreno/a5xx_gpu.c:1292:5: warning: symbol
> > 'a5xx_gpu_state_put' was not declared. Should it be static?
> > drivers/gpu/drm/msm/adreno/a5xx_gpu.c:1302:6: warning: symbol 'a5xx_show'
> > was not declared. Should it be static?
>
> Reviewed-by: Jordan Crouse
>
Applied to msm-next, thanks for the review and patch!
Sean
> > Signed-off-by: Ben Dooks
> > ---
> > Cc: Rob Clark
> > Cc: Sean Paul
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Cc: linux-arm-...@vger.kernel.org
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: freedr...@lists.freedesktop.org
> > ---
> > drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> > b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> > index e9c55d1d6c04..7fdc9e2bcaac 100644
> > --- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> > +++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> > @@ -1289,7 +1289,7 @@ static void a5xx_gpu_state_destroy(struct kref *kref)
> > kfree(a5xx_state);
> > }
> >
> > -int a5xx_gpu_state_put(struct msm_gpu_state *state)
> > +static int a5xx_gpu_state_put(struct msm_gpu_state *state)
> > {
> > if (IS_ERR_OR_NULL(state))
> > return 1;
> > @@ -1299,8 +1299,8 @@ int a5xx_gpu_state_put(struct msm_gpu_state *state)
> >
> >
> > #if defined(CONFIG_DEBUG_FS) || defined(CONFIG_DEV_COREDUMP)
> > -void a5xx_show(struct msm_gpu *gpu, struct msm_gpu_state *state,
> > - struct drm_printer *p)
> > +static void a5xx_show(struct msm_gpu *gpu, struct msm_gpu_state *state,
> > + struct drm_printer *p)
> > {
> > int i, j;
> > u32 pos = 0;
> > --
> > 2.23.0
> >
>
> --
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 04/21] drm/exynos: Fix potential unbalanced calls to pm_runtime_put
Hi Inki,
On Mon, 26 Aug 2019 17:26:32 +0200
Boris Brezillon wrote:
> The encoder->enable() can't report errors and is expected to always
> succeed. If we call pm_runtime_put() in the exynos_dsi_enable() error
> path (as currently done) we'll have unbalanced get/put calls when
> encoder->disable() is called.
>
> The situation is not ideal since drm_panel_{prepare,enable}() can
> theoretically return an error (even if in practice I don't think any
> panel driver does that). Putting a WARN_ON() is the best we can do,
> unfortunately. Note that -ENOSYS is actually a valid case, it just
> means the panel driver does not implement the hook.
>
> Signed-off-by: Boris Brezillon
Did you have a chance to look at this patch 4 and 5 of this series? I'd
really like to get those 2 patches merged.
Thanks,
Boris
> ---
> Changes in v2:
> * New patch
> ---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 14 ++
> 1 file changed, 2 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 8e655ae1fb0c..c555cecfe1f5 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -1387,8 +1387,7 @@ static void exynos_dsi_enable(struct drm_encoder
> *encoder)
>
> if (dsi->panel) {
> ret = drm_panel_prepare(dsi->panel);
> - if (ret < 0)
> - goto err_put_sync;
> + WARN_ON(ret && ret != -ENOSYS);
> } else {
> drm_bridge_pre_enable(dsi->out_bridge);
> }
> @@ -1398,22 +1397,13 @@ static void exynos_dsi_enable(struct drm_encoder
> *encoder)
>
> if (dsi->panel) {
> ret = drm_panel_enable(dsi->panel);
> - if (ret < 0)
> - goto err_display_disable;
> + WARN_ON(ret && ret != -ENOSYS);
> } else {
> drm_bridge_enable(dsi->out_bridge);
> }
>
> dsi->state |= DSIM_STATE_VIDOUT_AVAILABLE;
> return;
> -
> -err_display_disable:
> - exynos_dsi_set_display_enable(dsi, false);
> - drm_panel_unprepare(dsi->panel);
> -
> -err_put_sync:
> - dsi->state &= ~DSIM_STATE_ENABLED;
> - pm_runtime_put(dsi->dev);
> }
>
> static void exynos_dsi_disable(struct drm_encoder *encoder)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/3] RK3288 Gamma LUT
On Fri, Oct 11, 2019 at 03:22:00PM +0200, Heiko Stübner wrote: > Am Donnerstag, 10. Oktober 2019, 21:43:48 CEST schrieb Ezequiel Garcia: > > New iteration, seems that we are finally converging. > > > > For this v5, we are only doing some changes on > > the gamma_set implementation. As a result, the code > > is more readable. See the changelog in patch 2 for more > > information. > > > > Thanks! > > on rk3288 (and rk3399+rk3328 to make sure nothing breaks) > Tested-by: Heiko Stuebner > Applied the first 2 patches to drm-misc-next for 5.5. I'll leave 3/3 for Heiko and the rockchip tree. Thanks to all for the reviews and testing, thanks to Ezequiel for sticking with this to completion! Sean > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu: Bail earlier when amdgpu.cik_/si_support is not set to 1
On Fri, Oct 11, 2019 at 5:27 AM Hans de Goede wrote:
>
> Hi,
>
> On 10-10-2019 18:59, Daniel Vetter wrote:
> > On Thu, Oct 10, 2019 at 6:28 PM Hans de Goede wrote:
> >>
> >> Bail from the pci_driver probe function instead of from the drm_driver
> >> load function.
> >>
> >> This avoid /dev/dri/card0 temporarily getting registered and then
> >> unregistered again, sending unwanted add / remove udev events to
> >> userspace.
> >>
> >> Specifically this avoids triggering the (userspace) bug fixed by this
> >> plymouth merge-request:
> >> https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/59
> >>
> >> Note that despite that being a userspace bug, not sending unnecessary
> >> udev events is a good idea in general.
> >
> > I think even better would be getting rid of the load/unload callbacks,
> > this issue here isn't the only problem with them.
> >
> > Reviewed-by: Daniel Vetter
>
> Thanks,
>
> > I guess also cc: stable material?
>
> Yes.
>
> amdgpu maintainers, can you please add a Cc: stable while merging?
> Let me know if you want a new version with this added.
I'll take care of it when I merge this. Thanks!
Alex
>
> Regards,
>
> Hans
>
>
>
> >> BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1490490
> >> Signed-off-by: Hans de Goede
> >> ---
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 35 +
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 35 -
> >> 2 files changed, 35 insertions(+), 35 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> >> index 6f8aaf655a9f..2a00a36106b2 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> >> @@ -1048,6 +1048,41 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
> >> return -ENODEV;
> >> }
> >>
> >> +#ifdef CONFIG_DRM_AMDGPU_SI
> >> + if (!amdgpu_si_support) {
> >> + switch (flags & AMD_ASIC_MASK) {
> >> + case CHIP_TAHITI:
> >> + case CHIP_PITCAIRN:
> >> + case CHIP_VERDE:
> >> + case CHIP_OLAND:
> >> + case CHIP_HAINAN:
> >> + dev_info(>dev,
> >> +"SI support provided by radeon.\n");
> >> + dev_info(>dev,
> >> +"Use radeon.si_support=0
> >> amdgpu.si_support=1 to override.\n"
> >> + );
> >> + return -ENODEV;
> >> + }
> >> + }
> >> +#endif
> >> +#ifdef CONFIG_DRM_AMDGPU_CIK
> >> + if (!amdgpu_cik_support) {
> >> + switch (flags & AMD_ASIC_MASK) {
> >> + case CHIP_KAVERI:
> >> + case CHIP_BONAIRE:
> >> + case CHIP_HAWAII:
> >> + case CHIP_KABINI:
> >> + case CHIP_MULLINS:
> >> + dev_info(>dev,
> >> +"CIK support provided by radeon.\n");
> >> + dev_info(>dev,
> >> +"Use radeon.cik_support=0
> >> amdgpu.cik_support=1 to override.\n"
> >> + );
> >> + return -ENODEV;
> >> + }
> >> + }
> >> +#endif
> >> +
> >> /* Get rid of things like offb */
> >> ret = drm_fb_helper_remove_conflicting_pci_framebuffers(pdev, 0,
> >> "amdgpudrmfb");
> >> if (ret)
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> >> index f2c097983f48..d55f5baa83d3 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> >> @@ -144,41 +144,6 @@ int amdgpu_driver_load_kms(struct drm_device *dev,
> >> unsigned long flags)
> >> struct amdgpu_device *adev;
> >> int r, acpi_status;
> >>
> >> -#ifdef CONFIG_DRM_AMDGPU_SI
> >> - if (!amdgpu_si_support) {
> >> - switch (flags & AMD_ASIC_MASK) {
> >> - case CHIP_TAHITI:
> >> - case CHIP_PITCAIRN:
> >> - case CHIP_VERDE:
> >> - case CHIP_OLAND:
> >> - case CHIP_HAINAN:
> >> - dev_info(dev->dev,
> >> -"SI support provided by radeon.\n");
> >> - dev_info(dev->dev,
> >> -"Use radeon.si_support=0
> >> amdgpu.si_support=1 to override.\n"
> >> - );
> >> - return -ENODEV;
> >> - }
> >> - }
> >> -#endif
> >> -#ifdef CONFIG_DRM_AMDGPU_CIK
> >> - if (!amdgpu_cik_support) {
> >> - switch (flags & AMD_ASIC_MASK) {
> >> - case CHIP_KAVERI:
> >> - case CHIP_BONAIRE:
> >> - case CHIP_HAWAII:
> >> - case CHIP_KABINI:
> >> -
Re: [PATCH v5 0/3] RK3288 Gamma LUT
Am Donnerstag, 10. Oktober 2019, 21:43:48 CEST schrieb Ezequiel Garcia: > New iteration, seems that we are finally converging. > > For this v5, we are only doing some changes on > the gamma_set implementation. As a result, the code > is more readable. See the changelog in patch 2 for more > information. > > Thanks! on rk3288 (and rk3399+rk3328 to make sure nothing breaks) Tested-by: Heiko Stuebner ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] dt-bindings: display: Convert stm32 display bindings to json-schema
Convert the STM32 display binding to DT schema format using json-schema.
Split the original bindings in two yaml files:
- one for display controller (ltdc)
- one for DSI controller
Signed-off-by: Benjamin Gaignard
---
changes in v2:
- use BSD-2-Clause license
- add panel property
- fix identation
- remove pinctrl-names: true
- remove pinctrl-[0-9]+: true
- rework ports block to include port@0 and port@1
- use const for #adress-cells and #size-cells
- add additionalProperties: false
.../devicetree/bindings/display/st,stm32-dsi.yaml | 151 +
.../devicetree/bindings/display/st,stm32-ltdc.txt | 144
.../devicetree/bindings/display/st,stm32-ltdc.yaml | 81 +++
3 files changed, 232 insertions(+), 144 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/st,stm32-dsi.yaml
delete mode 100644 Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
create mode 100644 Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml
diff --git a/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml
b/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml
new file mode 100644
index ..88a176662ac2
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml
@@ -0,0 +1,151 @@
+# SPDX-License-Identifier: BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/st,stm32-dsi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STM32 DSI host controller
+
+maintainers:
+ - Philippe Cornu
+ - Yannick Fertre
+
+description:
+ The STMicroelectronics STM32 DSI controller uses the Synopsys DesignWare
MIPI-DSI host controller.
+
+properties:
+ compatible:
+const: st,stm32-dsi
+
+ reg:
+maxItems: 1
+
+ clocks:
+items:
+ - description: Module Clock
+ - description: DSI bus clock
+ - description: Pixel clock
+minItems: 2
+maxItems: 3
+
+ clock-names:
+items:
+ - const: pclk
+ - const: ref
+ - const: px_clk
+minItems: 2
+maxItems: 3
+
+ resets:
+maxItems: 1
+
+ reset-names:
+items:
+ - const: apb
+
+ phy-dsi-supply:
+maxItems: 1
+description:
+Phandle of the regulator that provides the supply voltage.
+
+ ports:
+type: object
+description:
+ A node containing DSI input & output port nodes with endpoint
+ definitions as documented in
+ Documentation/devicetree/bindings/media/video-interfaces.txt
+ Documentation/devicetree/bindings/graph.txt
+properties:
+ port@0:
+type: object
+description:
+ DSI input port node, connected to the ltdc rgb output port.
+
+ port@1:
+type: object
+description:
+ DSI output port node, connected to a panel or a bridge input port"
+
+patternProperties:
+ "^(panel|panel-dsi)@[0-9]$":
+type: object
+description:
+ A node containing the panel or bridge description as documented in
+ Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
+properties:
+ port@0:
+type: object
+description:
+ Panel or bridge port node, connected to the DSI output port (port@1)
+
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 0
+
+required:
+ - "#address-cells"
+ - "#size-cells"
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+#include
+dsi: dsi@5a00 {
+compatible = "st,stm32-dsi";
+reg = <0x5a00 0x800>;
+clocks = < DSI_K>, <_hse>, < DSI_PX>;
+clock-names = "pclk", "ref", "px_clk";
+resets = < DSI_R>;
+reset-names = "apb";
+phy-dsi-supply = <>;
+
+#address-cells = <1>;
+#size-cells = <0>;
+
+ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+reg = <0>;
+dsi_in: endpoint {
+remote-endpoint = <_ep1_out>;
+};
+ };
+
+ port@1 {
+reg = <1>;
+dsi_out: endpoint {
+remote-endpoint = <_in>;
+};
+ };
+};
+
+panel-dsi@0 {
+ compatible = "orisetech,otm8009a";
+ reg = <0>;
+ reset-gpios = < 4 GPIO_ACTIVE_LOW>;
+ power-supply = <>;
+
+ port {
+panel_in: endpoint {
+remote-endpoint = <_out>;
+};
+ };
+};
+};
+
+...
+
+
diff --git a/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
deleted file mode 100644
index 60c54da4e526..
---
Re: [PATCH] drm/scheduler: make unexported items static
Already applied. thanks.
Alex
On Fri, Oct 11, 2019 at 2:48 AM Ben Dooks wrote:
>
> On 09/10/2019 13:14, Ben Dooks wrote:
> > The drm_sched_fence_ops_{scheduled,finished} are not exported
> > from the file so make them static to avoid the following
> > warnings from sparse:
> >
> > drivers/gpu/drm/scheduler/sched_fence.c:131:28: warning: symbol
> > 'drm_sched_fence_ops_scheduled' was not declared. Should it be static?
> > drivers/gpu/drm/scheduler/sched_fence.c:137:28: warning: symbol
> > 'drm_sched_fence_ops_finished' was not declared. Should it be static?
> >
> > Signed-off-by: Ben Dooks
>
> If it is useful I can get these into a public git repo and send
> a pull request.
>
> --
> Ben Dooks http://www.codethink.co.uk/
> Senior Engineer Codethink - Providing Genius
>
> https://www.codethink.co.uk/privacy.html
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding
Hi Andrzej,
On Fri, Oct 11, 2019 at 01:21:43PM +0200, Andrzej Hajda wrote:
> On 11.10.2019 04:21, Xin Ji wrote:
> > The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
> > for portable device. It converts MIPI to DisplayPort 1.3 4K.
> >
> > You can add support to your board with binding.
> >
> > Example:
> > anx7625_bridge: encoder@58 {
> > compatible = "analogix,anx7625";
> > reg = <0x58>;
> > status = "okay";
> > panel-flags = <1>;
> > enable-gpios = < 45 GPIO_ACTIVE_HIGH>;
> > reset-gpios = < 73 GPIO_ACTIVE_HIGH>;
> > #address-cells = <1>;
> > #size-cells = <0>;
> >
> > port@0 {
> > reg = <0>;
> > anx_1_in: endpoint {
> > remote-endpoint = <_dsi>;
> > };
> > };
> >
> > port@3 {
> > reg = <3>;
> > anx_1_out: endpoint {
> > remote-endpoint = <_in>;
> > };
> > };
> > };
> >
> > Signed-off-by: Xin Ji
> > ---
> > .../bindings/display/bridge/anx7625.yaml | 96
> > ++
> > 1 file changed, 96 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/bridge/anx7625.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
> > b/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
> > new file mode 100644
> > index 000..fc84683
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
> > @@ -0,0 +1,96 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +# Copyright 2019 Analogix Semiconductor, Inc.
> > +%YAML 1.2
> > +---
> > +$id: "http://devicetree.org/schemas/display/bridge/anx7625.yaml#;
> > +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
> > +
> > +title: Analogix ANX7625 SlimPort (4K Mobile HD Transmitter)
> > +
> > +maintainers:
> > + - Xin Ji
> > +
> > +description: |
> > + The ANX7625 is an ultra-low power 4K Mobile HD Transmitter
> > + designed for portable devices.
> > +
> > +properties:
> > + "#address-cells": true
> > + "#size-cells": true
> > +
> > + compatible:
> > +items:
> > + - const: analogix,anx7625
> > +
> > + reg:
> > +maxItems: 1
> > +
> > + panel-flags:
> > +description: indicate the panel is internal or external
> > +maxItems: 1
> > +
> > + interrupts:
> > +maxItems: 1
> > +
> > + enable-gpios:
> > +description: used for power on chip control, POWER_EN pin D2.
> > +maxItems: 1
> > +
> > + reset-gpios:
> > +description: used for reset chip control, RESET_N pin B7.
> > +maxItems: 1
> > +
> > + port@0:
> > +type: object
> > +description:
> > + A port node pointing to MIPI DSI host port node.
> > +
> > + port@1:
> > +type: object
> > +description:
> > + A port node pointing to MIPI DPI host port node.
> > +
> > + port@2:
> > +type: object
> > +description:
> > + A port node pointing to external connector port node.
> > +
> > + port@3:
> > +type: object
> > +description:
> > + A port node pointing to eDP port node.
>
>
> Decrypting available product brief[1], there are following physical lines:
>
> Input:
>
> - MIPI DSI/DPI - video data, are DSI and DPI lines shared?
It would be much easier if we could have access to more complete
information. I believe the DSI and DPI pins could be muxed, but there
should be more DPI pins than DSI pins.
>
> - I2S - audio data,
>
> - I2C - control line,
>
> - ALERT/INTP - interrupt,
>
> - USB 3.1 SSRc/Tx - for USB forwarding,
>
> Output:
>
> - SS1, SS2,
>
> - SBU/AUX,
>
> - CC1/2.
>
>
> Having this information I try to understand ports defined by you:
>
> - port@2 you have defined as pointing to external port, but here the
> port should be rather subnode of ANX7625 - the chip has CC lines, see
> beginning of [2].
>
> - port@3 describes SS1, SS2 and SBU/AUX lines together, am I right? In
> USB-C binding SBU and SS lines are represented by different ports,
> different approach, but maybe better in this case.
I believe that, when connected to a DP display (either DP or eDP), the
DisplayPort signals are output on SS1 and/or SS2. I this really wonder
if we need two separate ports for this, it seems that port@2 and port@3
should be merged.
> Maybe it would be good to add 2nd example with USB-C port.
That would help with the discussion, yes.
> [1]:
> https://www.analogix.com/system/files/AA-002291-PB-6-ANX7625_ProductBrief.pdf
>
> [2]: Documentation/devicetree/bindings/connector/usb-connector.txt
>
> > +
> > +required:
> > + - "#address-cells"
> > + - "#size-cells"
> > + - compatible
> > + - reg
> > + - port@0
> > + - port@3
> > +
> > +example:
> > + - |
> > +anx7625_bridge: encoder@58 {
> > +compatible = "analogix,anx7625";
> > +reg = <0x58>;
> > +status = "okay";
Re: [PATCH] drm/dp: Remove the unused drm_device to get rid of build warning
On Thu, Oct 10, 2019 at 02:01:32PM -0700, Manasi Navare wrote:
> We no longer use the connection mutex and hence no need to
> define drm_device *dev, it causes a unused variable build warning
>
> Fixes: 83fa9842afe7 ("drm/dp-mst: Drop connection_mutex check")
> Cc: Sean Paul
Reviewed-by: Sean Paul
> Cc: Lyude Paul
> Cc: Daniel Vetter
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 9364e4f42975..95e63309 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -4184,8 +4184,6 @@ EXPORT_SYMBOL(drm_dp_mst_topology_state_funcs);
> struct drm_dp_mst_topology_state *drm_atomic_get_mst_topology_state(struct
> drm_atomic_state *state,
> struct
> drm_dp_mst_topology_mgr *mgr)
> {
> - struct drm_device *dev = mgr->dev;
> -
> return to_dp_mst_topology_state(drm_atomic_get_private_obj_state(state,
> >base));
> }
> EXPORT_SYMBOL(drm_atomic_get_mst_topology_state);
> --
> 2.19.1
>
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/7] drm/meson: plane: add support for AFBC mode for OSD1 plane
On 11/10/2019 12:56, Brian Starkey wrote:
> Hi,
>
> On Fri, Oct 11, 2019 at 11:14:43AM +0200, Neil Armstrong wrote:
>> Hi Brian,
>>
>> On 11/10/2019 10:41, Brian Starkey wrote:
>>> Hi Neil,
>>>
>>> On Thu, Oct 10, 2019 at 03:41:15PM +0200, Neil Armstrong wrote:
Hi Ayan,
On 10/10/2019 15:26, Ayan Halder wrote:
> On Thu, Oct 10, 2019 at 11:25:23AM +0200, Neil Armstrong wrote:
>> This adds all the OSD configuration plumbing to support the AFBC decoders
>> path to display of the OSD1 plane.
>>
>> The Amlogic GXM and G12A AFBC decoders are integrated very differently.
>>
>> The Amlogic GXM has a direct output path to the OSD1 VIU pixel input,
>> because the GXM AFBC decoder seem to be a custom IP developed by Amlogic.
>>
>> On the other side, the Amlogic G12A AFBC decoder seems to be an external
>> IP that emit pixels on an AXI master hooked to a "Mali Unpack" block
>> feeding the OSD1 VIU pixel input.
>> This uses a weird "0x100" internal HW physical address on both
>> sides to transfer the pixels.
>>
>> For Amlogic GXM, the supported pixel formats are the same as the normal
>> linear OSD1 mode.
>>
>> On the other side, Amlogic added support for all AFBC v1.2 formats for
>> the G12A AFBC integration.
>>
>> For simplicity, we stick to the already supported formats for now.
>>
>> Signed-off-by: Neil Armstrong
>> ---
>> drivers/gpu/drm/meson/meson_crtc.c | 2 +
>> drivers/gpu/drm/meson/meson_drv.h | 4 +
>> drivers/gpu/drm/meson/meson_plane.c | 215
>> 3 files changed, 190 insertions(+), 31 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/meson/meson_crtc.c
>> b/drivers/gpu/drm/meson/meson_crtc.c
>> index 57ae1c13d1e6..d478fa232951 100644
>> --- a/drivers/gpu/drm/meson/meson_crtc.c
>> +++ b/drivers/gpu/drm/meson/meson_crtc.c
>> @@ -281,6 +281,8 @@ void meson_crtc_irq(struct meson_drm *priv)
>> if (priv->viu.osd1_enabled && priv->viu.osd1_commit) {
>> writel_relaxed(priv->viu.osd1_ctrl_stat,
>> priv->io_base +
>> _REG(VIU_OSD1_CTRL_STAT));
>> +writel_relaxed(priv->viu.osd1_ctrl_stat2,
>> +priv->io_base +
>> _REG(VIU_OSD1_CTRL_STAT2));
>> writel_relaxed(priv->viu.osd1_blk0_cfg[0],
>> priv->io_base +
>> _REG(VIU_OSD1_BLK0_CFG_W0));
>> writel_relaxed(priv->viu.osd1_blk0_cfg[1],
>> diff --git a/drivers/gpu/drm/meson/meson_drv.h
>> b/drivers/gpu/drm/meson/meson_drv.h
>> index 60f13c6f34e5..de25349be8aa 100644
>> --- a/drivers/gpu/drm/meson/meson_drv.h
>> +++ b/drivers/gpu/drm/meson/meson_drv.h
>> @@ -53,8 +53,12 @@ struct meson_drm {
>> bool osd1_enabled;
>> bool osd1_interlace;
>> bool osd1_commit;
>> +bool osd1_afbcd;
>> uint32_t osd1_ctrl_stat;
>> +uint32_t osd1_ctrl_stat2;
>> uint32_t osd1_blk0_cfg[5];
>> +uint32_t osd1_blk1_cfg4;
>> +uint32_t osd1_blk2_cfg4;
>> uint32_t osd1_addr;
>> uint32_t osd1_stride;
>> uint32_t osd1_height;
>> diff --git a/drivers/gpu/drm/meson/meson_plane.c
>> b/drivers/gpu/drm/meson/meson_plane.c
>> index 5e798c276037..412941aa8402 100644
>> --- a/drivers/gpu/drm/meson/meson_plane.c
>> +++ b/drivers/gpu/drm/meson/meson_plane.c
>> @@ -23,6 +23,7 @@
>> #include "meson_plane.h"
>> #include "meson_registers.h"
>> #include "meson_viu.h"
>> +#include "meson_osd_afbcd.h"
>>
>> /* OSD_SCI_WH_M1 */
>> #define SCI_WH_M1_W(w) FIELD_PREP(GENMASK(28, 16), w)
>> @@ -92,12 +93,38 @@ static int meson_plane_atomic_check(struct drm_plane
>> *plane,
>> false, true);
>> }
>>
>> +#define MESON_MOD_AFBC_VALID_BITS (AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 |
>> \
>> + AFBC_FORMAT_MOD_BLOCK_SIZE_32x8 |
>> \
>> + AFBC_FORMAT_MOD_YTR |
>> \
>> + AFBC_FORMAT_MOD_SPARSE |
>> \
>> + AFBC_FORMAT_MOD_SPLIT)
>> +
>> /* Takes a fixed 16.16 number and converts it to integer. */
>> static inline int64_t fixed16_to_int(int64_t value)
>> {
>> return value >> 16;
>> }
>>
>> +static u32 meson_g12a_afbcd_line_stride(struct meson_drm *priv)
>> +{
>> +u32 line_stride = 0;
>> +
>> +switch (priv->afbcd.format) {
>> +
Re: [PATCH 2/2] drm/rockchip: Add support for afbc
Hi Andrzej,
On Fri, 11 Oct 2019 at 12:18, Andrzej Pietrasiewicz
wrote:
> @@ -32,6 +35,46 @@ rockchip_fb_alloc(struct drm_device *dev, const struct
> drm_mode_fb_cmd2 *mode_cm
> int ret;
> int i;
>
> + if (mode_cmd->modifier[0]) {
> + const struct drm_format_info *info;
> + int bpp;
> +
> + if (mode_cmd->modifier[0] &
Use != here, not &~.
> + case DRM_FORMAT_BGR888:
> + return AFBC_FMT_U8U8U8;
> + case DRM_FORMAT_RGB565:
> + case DRM_FORMAT_BGR565:
> + return AFBC_FMT_RGB565;
> + default:
> + DRM_ERROR("unsupported afbc format[%08x]\n", format);
This should not be reachable, because you shouldn't be able to create
a framebuffer with an unsupported format/modifier combination.
> +static bool rockchip_mod_supported(struct drm_plane *plane,
> + u32 format, u64 modifier)
> +{
> + const struct drm_format_info *info;
> +
> + if (WARN_ON(modifier == DRM_FORMAT_MOD_INVALID))
> + return false;
> +
> + if (modifier == DRM_FORMAT_MOD_LINEAR)
> + return true;
> +
> + if (modifier & ~DRM_FORMAT_MOD_ARM_AFBC(
Again use != here.
> + AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 |
> + AFBC_FORMAT_MOD_SPARSE
> + )
> + ) {
> + DRM_DEBUG_KMS("Unsupported format modifer 0x%llx\n",
> modifier);
> +
> + return false;
> + }
> +
> + info = drm_format_info(format);
> + if (info->num_planes != 1) {
> + DRM_DEBUG_KMS("AFBC buffers expect one plane\n");
> + return false;
> + }
This is where you should reject unsupported format + AFBC
combinations. Doing it here prevents it from ever being advertised to
userspace in the first place.
> @@ -808,6 +919,24 @@ static void vop_plane_atomic_update(struct drm_plane
> *plane,
>
> spin_lock(>reg_lock);
>
> + if (fb->modifier == DRM_FORMAT_MOD_ARM_AFBC(
> + AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 | AFBC_FORMAT_MOD_SPARSE)) {
> + int afbc_format = vop_convert_afbc_format(fb->format->format);
> +
> + VOP_AFBC_SET(vop, format, afbc_format | 1 << 4);
I assume the (1 << 4) programs the 16x16 block size. Can we support
other block sizes?
> + VOP_AFBC_SET(vop, hreg_block_split, 0);
Does this mean we can also support AFBC_FORMAT_MOD_SPLIT?
> + VOP_AFBC_SET(vop, win_sel, VOP_WIN_TO_INDEX(vop_win));
> + VOP_AFBC_SET(vop, hdr_ptr, dma_addr);
> + VOP_AFBC_SET(vop, pic_size, act_info);
> +
> + /*
> +* The window being udated becomes the AFBC window
> +*/
> + vop->afbc_win = vop_win;
> +
> + pr_info("AFBC on plane %s\n", plane->name);
Please do not use pr_info() here. Userspace should not be able to
trigger logging, apart from DRM_DEBUG.
> +static const uint64_t format_modifiers_win_full[] = {
> + DRM_FORMAT_MOD_NONE,
*DRM_FORMAT_MOD_LINEAR
Cheers,
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111691] inconsistent cursor movement speed when using AMD 5700 XT
https://bugs.freedesktop.org/show_bug.cgi?id=111691 --- Comment #15 from Jaap Buurman --- I am running into the same issue. Arch Kernel: 5.3.5 llvm: 9.0.0 Mesa: 19.2.0 xf86-video-amdgpu: 19.0.1 Linux-firmware: 20190923 Let me know if I can supply any additional information. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] staging: fbtft: fbtft-core: Fix last line displayed on fbcon
From: Michael Hennerich
For the special case when fbtft_mkdirty() is called with with -1 for the y
coordinate, the height is truncated by 1.
This isn't required, and causes the last line to not update.
Signed-off-by: Michael Hennerich
Signed-off-by: Alexandru Ardelean
---
drivers/staging/fbtft/fbtft-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/fbtft/fbtft-core.c
b/drivers/staging/fbtft/fbtft-core.c
index cf5700a2ea66..90eec45d11fc 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -317,7 +317,7 @@ static void fbtft_mkdirty(struct fb_info *info, int y, int
height)
/* special case, needed ? */
if (y == -1) {
y = 0;
- height = info->var.yres - 1;
+ height = info->var.yres;
}
/* Mark display lines/area as dirty */
--
2.20.1
Re: [PATCH v2 1/2] dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding
On 11.10.2019 04:21, Xin Ji wrote:
> The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
> for portable device. It converts MIPI to DisplayPort 1.3 4K.
>
> You can add support to your board with binding.
>
> Example:
> anx7625_bridge: encoder@58 {
> compatible = "analogix,anx7625";
> reg = <0x58>;
> status = "okay";
> panel-flags = <1>;
> enable-gpios = < 45 GPIO_ACTIVE_HIGH>;
> reset-gpios = < 73 GPIO_ACTIVE_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
>
> port@0 {
> reg = <0>;
> anx_1_in: endpoint {
> remote-endpoint = <_dsi>;
> };
> };
>
> port@3 {
> reg = <3>;
> anx_1_out: endpoint {
> remote-endpoint = <_in>;
> };
> };
> };
>
> Signed-off-by: Xin Ji
> ---
> .../bindings/display/bridge/anx7625.yaml | 96
> ++
> 1 file changed, 96 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/anx7625.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
> b/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
> new file mode 100644
> index 000..fc84683
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
> @@ -0,0 +1,96 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2019 Analogix Semiconductor, Inc.
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/display/bridge/anx7625.yaml#;
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
> +
> +title: Analogix ANX7625 SlimPort (4K Mobile HD Transmitter)
> +
> +maintainers:
> + - Xin Ji
> +
> +description: |
> + The ANX7625 is an ultra-low power 4K Mobile HD Transmitter
> + designed for portable devices.
> +
> +properties:
> + "#address-cells": true
> + "#size-cells": true
> +
> + compatible:
> +items:
> + - const: analogix,anx7625
> +
> + reg:
> +maxItems: 1
> +
> + panel-flags:
> +description: indicate the panel is internal or external
> +maxItems: 1
> +
> + interrupts:
> +maxItems: 1
> +
> + enable-gpios:
> +description: used for power on chip control, POWER_EN pin D2.
> +maxItems: 1
> +
> + reset-gpios:
> +description: used for reset chip control, RESET_N pin B7.
> +maxItems: 1
> +
> + port@0:
> +type: object
> +description:
> + A port node pointing to MIPI DSI host port node.
> +
> + port@1:
> +type: object
> +description:
> + A port node pointing to MIPI DPI host port node.
> +
> + port@2:
> +type: object
> +description:
> + A port node pointing to external connector port node.
> +
> + port@3:
> +type: object
> +description:
> + A port node pointing to eDP port node.
Decrypting available product brief[1], there are following physical lines:
Input:
- MIPI DSI/DPI - video data, are DSI and DPI lines shared?
- I2S - audio data,
- I2C - control line,
- ALERT/INTP - interrupt,
- USB 3.1 SSRc/Tx - for USB forwarding,
Output:
- SS1, SS2,
- SBU/AUX,
- CC1/2.
Having this information I try to understand ports defined by you:
- port@2 you have defined as pointing to external port, but here the
port should be rather subnode of ANX7625 - the chip has CC lines, see
beginning of [2].
- port@3 describes SS1, SS2 and SBU/AUX lines together, am I right? In
USB-C binding SBU and SS lines are represented by different ports,
different approach, but maybe better in this case.
Maybe it would be good to add 2nd example with USB-C port.
[1]:
https://www.analogix.com/system/files/AA-002291-PB-6-ANX7625_ProductBrief.pdf
[2]: Documentation/devicetree/bindings/connector/usb-connector.txt
Regards
Andrzej
> +
> +required:
> + - "#address-cells"
> + - "#size-cells"
> + - compatible
> + - reg
> + - port@0
> + - port@3
> +
> +example:
> + - |
> +anx7625_bridge: encoder@58 {
> +compatible = "analogix,anx7625";
> +reg = <0x58>;
> +status = "okay";
> +panel-flags = <1>;
> +enable-gpios = < 45 GPIO_ACTIVE_HIGH>;
> +reset-gpios = < 73 GPIO_ACTIVE_HIGH>;
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> + reg = <0>;
> + anx_1_in: endpoint {
> +remote-endpoint = <_dsi>;
> + };
> +};
> +
> +port@3 {
> + reg = <3>;
> + anx_1_out: endpoint {
> +remote-endpoint = <_in>;
> + };
> +};
> +};
[PATCH 2/2] drm/rockchip: Add support for afbc
This patch adds support for afbc handling. afbc is a compressed format
which reduces the necessary memory bandwidth.
Co-developed-by: Mark Yao
Signed-off-by: Mark Yao
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/rockchip/Kconfig| 1 +
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 43 ++
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 140 +++-
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 12 ++
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 86 +++-
5 files changed, 278 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 6f4222f8beeb..ff491efc52a5 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -5,6 +5,7 @@ config DRM_ROCKCHIP
select DRM_GEM_CMA_HELPER
select DRM_KMS_HELPER
select DRM_PANEL
+ select DRM_AFBC
select VIDEOMODE_HELPERS
select DRM_ANALOGIX_DP if ROCKCHIP_ANALOGIX_DP
select DRM_DW_HDMI if ROCKCHIP_DW_HDMI
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index 64ca87cf6d50..873185b3a721 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -18,6 +19,8 @@
#include "rockchip_drm_gem.h"
#include "rockchip_drm_psr.h"
+#define ROCKCHIP_MAX_AFBC_WIDTH2560
+
static const struct drm_framebuffer_funcs rockchip_drm_fb_funcs = {
.destroy = drm_gem_fb_destroy,
.create_handle = drm_gem_fb_create_handle,
@@ -32,6 +35,46 @@ rockchip_fb_alloc(struct drm_device *dev, const struct
drm_mode_fb_cmd2 *mode_cm
int ret;
int i;
+ if (mode_cmd->modifier[0]) {
+ const struct drm_format_info *info;
+ int bpp;
+
+ if (mode_cmd->modifier[0] &
+ ~DRM_FORMAT_MOD_ARM_AFBC(
+ AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 |
+ AFBC_FORMAT_MOD_SPARSE
+)
+ ) {
+ DRM_DEV_ERROR(dev->dev,
+ "Unsupported format modifer 0x%llx\n",
+ mode_cmd->modifier[0]
+ );
+
+ return ERR_PTR(-EINVAL);
+ }
+
+ if (!drm_afbc_check_offset(dev, mode_cmd))
+ return ERR_PTR(-EINVAL);
+
+ if (!drm_afbc_check_size_align(dev, mode_cmd))
+ return ERR_PTR(-EINVAL);
+
+ if (mode_cmd->width > ROCKCHIP_MAX_AFBC_WIDTH) {
+ DRM_DEV_ERROR(dev->dev,
+ "Unsupported width %d>%d\n",
+ mode_cmd->width,
+ ROCKCHIP_MAX_AFBC_WIDTH);
+
+ return ERR_PTR(-EINVAL);
+ }
+
+ info = drm_get_format_info(dev, mode_cmd);
+ bpp = info->cpp[0] * 8;
+
+ if (!drm_afbc_check_fb_size(dev, mode_cmd, obj[0], bpp))
+ return ERR_PTR(-EINVAL);
+ }
+
fb = kzalloc(sizeof(*fb), GFP_KERNEL);
if (!fb)
return ERR_PTR(-ENOMEM);
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 21b68eea46cc..0ac9ab3be3f1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -90,9 +90,20 @@
#define VOP_WIN_TO_INDEX(vop_win) \
((vop_win) - (vop_win)->vop->win)
+#define VOP_AFBC_SET(vop, name, v) \
+ do { \
+ if ((vop)->data->afbc) \
+ vop_reg_set((vop), &(vop)->data->afbc->name, \
+ 0, ~0, v, #name); \
+ } while (0)
+
#define to_vop(x) container_of(x, struct vop, crtc)
#define to_vop_win(x) container_of(x, struct vop_win, base)
+#define AFBC_FMT_RGB5650x0
+#define AFBC_FMT_U8U8U8U8 0x5
+#define AFBC_FMT_U8U8U80x4
+
/*
* The coefficients of the following matrix are all fixed points.
* The format is S2.10 for the 3x3 part of the matrix, and S9.12 for the
offsets.
@@ -163,6 +174,7 @@ struct vop {
/* optional internal rgb encoder */
struct rockchip_rgb *rgb;
+ struct vop_win *afbc_win;
struct vop_win win[];
};
@@ -271,6 +283,27 @@ static enum vop_data_format vop_convert_format(uint32_t
format)
}
}
+static int vop_convert_afbc_format(uint32_t format)
+{
+ switch (format) {
+ case DRM_FORMAT_XRGB:
+ case DRM_FORMAT_ARGB:
+ case DRM_FORMAT_XBGR:
+ case DRM_FORMAT_ABGR:
+ return AFBC_FMT_U8U8U8U8;
+ case DRM_FORMAT_RGB888:
+ case DRM_FORMAT_BGR888:
+ return
[PATCH 0/2] AFBC for Rockchip
This series adds AFBC support for Rockchip. It is inspired by: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads/factory-gru-9017.B-chromeos-4.4/drivers/gpu/drm/rockchip/rockchip_drm_vop.c The first patch factors out some afbc helper functions from malidp, as they are useful in general. The second patch adds implementation proper of AFBC support for Rockchip. Andrzej Pietrasiewicz (2): drm/arm: Factor out generic afbc helpers drm/rockchip: Add support for afbc drivers/gpu/drm/Kconfig | 4 + drivers/gpu/drm/Makefile| 1 + drivers/gpu/drm/arm/Kconfig | 1 + drivers/gpu/drm/arm/malidp_drv.c| 58 +--- drivers/gpu/drm/drm_afbc.c | 114 drivers/gpu/drm/rockchip/Kconfig| 1 + drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 43 ++ drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 140 +++- drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 12 ++ drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 86 +++- include/drm/drm_afbc.h | 25 11 files changed, 427 insertions(+), 58 deletions(-) create mode 100644 drivers/gpu/drm/drm_afbc.c create mode 100644 include/drm/drm_afbc.h -- 2.17.1
[PATCH 1/2] drm/arm: Factor out generic afbc helpers
These are useful for other users of afbc, e.g. rockchip.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/Kconfig | 4 ++
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/arm/Kconfig | 1 +
drivers/gpu/drm/arm/malidp_drv.c | 58 ++--
drivers/gpu/drm/drm_afbc.c | 114 +++
include/drm/drm_afbc.h | 25 +++
6 files changed, 149 insertions(+), 54 deletions(-)
create mode 100644 drivers/gpu/drm/drm_afbc.c
create mode 100644 include/drm/drm_afbc.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 3c88420e3497..00e3f90557f4 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -195,6 +195,10 @@ config DRM_SCHED
tristate
depends on DRM
+config DRM_AFBC
+ tristate
+ depends on DRM
+
source "drivers/gpu/drm/i2c/Kconfig"
source "drivers/gpu/drm/arm/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 9f0d2ee35794..55368b668355 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -31,6 +31,7 @@ drm-$(CONFIG_OF) += drm_of.o
drm-$(CONFIG_AGP) += drm_agpsupport.o
drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
+drm-$(CONFIG_DRM_AFBC) += drm_afbc.o
drm_vram_helper-y := drm_gem_vram_helper.o \
drm_vram_helper_common.o \
diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig
index a204103b3efb..25c3dc408cda 100644
--- a/drivers/gpu/drm/arm/Kconfig
+++ b/drivers/gpu/drm/arm/Kconfig
@@ -29,6 +29,7 @@ config DRM_MALI_DISPLAY
select DRM_KMS_HELPER
select DRM_KMS_CMA_HELPER
select DRM_GEM_CMA_HELPER
+ select DRM_AFBC
select VIDEOMODE_HELPERS
help
Choose this option if you want to compile the ARM Mali Display
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index f25ec4382277..a67b69e08f63 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -16,6 +16,7 @@
#include
#include
+#include
#include
#include
#include
@@ -33,8 +34,6 @@
#include "malidp_hw.h"
#define MALIDP_CONF_VALID_TIMEOUT 250
-#define AFBC_HEADER_SIZE 16
-#define AFBC_SUPERBLK_ALIGNMENT128
static void malidp_write_gamma_table(struct malidp_hw_device *hwdev,
u32 data[MALIDP_COEFFTAB_NUM_COEFFS])
@@ -275,24 +274,8 @@ malidp_verify_afbc_framebuffer_caps(struct drm_device *dev,
mode_cmd->modifier[0]) == false)
return false;
- if (mode_cmd->offsets[0] != 0) {
- DRM_DEBUG_KMS("AFBC buffers' plane offset should be 0\n");
- return false;
- }
-
- switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
- case AFBC_SIZE_16X16:
- if ((mode_cmd->width % 16) || (mode_cmd->height % 16)) {
- DRM_DEBUG_KMS("AFBC buffers must be aligned to 16
pixels\n");
- return false;
- }
- break;
- default:
- DRM_DEBUG_KMS("Unsupported AFBC block size\n");
- return false;
- }
-
- return true;
+ return drm_afbc_check_offset(dev, mode_cmd) &&
+ drm_afbc_check_size_align(dev, mode_cmd);
}
static bool
@@ -300,53 +283,20 @@ malidp_verify_afbc_framebuffer_size(struct drm_device
*dev,
struct drm_file *file,
const struct drm_mode_fb_cmd2 *mode_cmd)
{
- int n_superblocks = 0;
const struct drm_format_info *info;
struct drm_gem_object *objs = NULL;
- u32 afbc_superblock_size = 0, afbc_superblock_height = 0;
- u32 afbc_superblock_width = 0, afbc_size = 0;
int bpp = 0;
- switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
- case AFBC_SIZE_16X16:
- afbc_superblock_height = 16;
- afbc_superblock_width = 16;
- break;
- default:
- DRM_DEBUG_KMS("AFBC superblock size is not supported\n");
- return false;
- }
-
info = drm_get_format_info(dev, mode_cmd);
-
- n_superblocks = (mode_cmd->width / afbc_superblock_width) *
- (mode_cmd->height / afbc_superblock_height);
-
bpp = malidp_format_get_bpp(info->format);
- afbc_superblock_size = (bpp * afbc_superblock_width *
afbc_superblock_height)
- / BITS_PER_BYTE;
-
- afbc_size = ALIGN(n_superblocks * AFBC_HEADER_SIZE,
AFBC_SUPERBLK_ALIGNMENT);
- afbc_size += n_superblocks * ALIGN(afbc_superblock_size,
AFBC_SUPERBLK_ALIGNMENT);
-
- if ((mode_cmd->width * bpp) != (mode_cmd->pitches[0] * BITS_PER_BYTE)) {
- DRM_DEBUG_KMS("Invalid value of (pitch * BITS_PER_BYTE) (=%u) "
-
Re: [PATCH 4/7] drm/meson: plane: add support for AFBC mode for OSD1 plane
Hi,
On Fri, Oct 11, 2019 at 11:14:43AM +0200, Neil Armstrong wrote:
> Hi Brian,
>
> On 11/10/2019 10:41, Brian Starkey wrote:
> > Hi Neil,
> >
> > On Thu, Oct 10, 2019 at 03:41:15PM +0200, Neil Armstrong wrote:
> >> Hi Ayan,
> >>
> >> On 10/10/2019 15:26, Ayan Halder wrote:
> >>> On Thu, Oct 10, 2019 at 11:25:23AM +0200, Neil Armstrong wrote:
> This adds all the OSD configuration plumbing to support the AFBC decoders
> path to display of the OSD1 plane.
>
> The Amlogic GXM and G12A AFBC decoders are integrated very differently.
>
> The Amlogic GXM has a direct output path to the OSD1 VIU pixel input,
> because the GXM AFBC decoder seem to be a custom IP developed by Amlogic.
>
> On the other side, the Amlogic G12A AFBC decoder seems to be an external
> IP that emit pixels on an AXI master hooked to a "Mali Unpack" block
> feeding the OSD1 VIU pixel input.
> This uses a weird "0x100" internal HW physical address on both
> sides to transfer the pixels.
>
> For Amlogic GXM, the supported pixel formats are the same as the normal
> linear OSD1 mode.
>
> On the other side, Amlogic added support for all AFBC v1.2 formats for
> the G12A AFBC integration.
>
> For simplicity, we stick to the already supported formats for now.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/gpu/drm/meson/meson_crtc.c | 2 +
> drivers/gpu/drm/meson/meson_drv.h | 4 +
> drivers/gpu/drm/meson/meson_plane.c | 215
> 3 files changed, 190 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/meson/meson_crtc.c
> b/drivers/gpu/drm/meson/meson_crtc.c
> index 57ae1c13d1e6..d478fa232951 100644
> --- a/drivers/gpu/drm/meson/meson_crtc.c
> +++ b/drivers/gpu/drm/meson/meson_crtc.c
> @@ -281,6 +281,8 @@ void meson_crtc_irq(struct meson_drm *priv)
> if (priv->viu.osd1_enabled && priv->viu.osd1_commit) {
> writel_relaxed(priv->viu.osd1_ctrl_stat,
> priv->io_base +
> _REG(VIU_OSD1_CTRL_STAT));
> +writel_relaxed(priv->viu.osd1_ctrl_stat2,
> +priv->io_base +
> _REG(VIU_OSD1_CTRL_STAT2));
> writel_relaxed(priv->viu.osd1_blk0_cfg[0],
> priv->io_base +
> _REG(VIU_OSD1_BLK0_CFG_W0));
> writel_relaxed(priv->viu.osd1_blk0_cfg[1],
> diff --git a/drivers/gpu/drm/meson/meson_drv.h
> b/drivers/gpu/drm/meson/meson_drv.h
> index 60f13c6f34e5..de25349be8aa 100644
> --- a/drivers/gpu/drm/meson/meson_drv.h
> +++ b/drivers/gpu/drm/meson/meson_drv.h
> @@ -53,8 +53,12 @@ struct meson_drm {
> bool osd1_enabled;
> bool osd1_interlace;
> bool osd1_commit;
> +bool osd1_afbcd;
> uint32_t osd1_ctrl_stat;
> +uint32_t osd1_ctrl_stat2;
> uint32_t osd1_blk0_cfg[5];
> +uint32_t osd1_blk1_cfg4;
> +uint32_t osd1_blk2_cfg4;
> uint32_t osd1_addr;
> uint32_t osd1_stride;
> uint32_t osd1_height;
> diff --git a/drivers/gpu/drm/meson/meson_plane.c
> b/drivers/gpu/drm/meson/meson_plane.c
> index 5e798c276037..412941aa8402 100644
> --- a/drivers/gpu/drm/meson/meson_plane.c
> +++ b/drivers/gpu/drm/meson/meson_plane.c
> @@ -23,6 +23,7 @@
> #include "meson_plane.h"
> #include "meson_registers.h"
> #include "meson_viu.h"
> +#include "meson_osd_afbcd.h"
>
> /* OSD_SCI_WH_M1 */
> #define SCI_WH_M1_W(w) FIELD_PREP(GENMASK(28, 16), w)
> @@ -92,12 +93,38 @@ static int meson_plane_atomic_check(struct drm_plane
> *plane,
> false, true);
> }
>
> +#define MESON_MOD_AFBC_VALID_BITS (AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 |
> \
> + AFBC_FORMAT_MOD_BLOCK_SIZE_32x8 |
> \
> + AFBC_FORMAT_MOD_YTR |
> \
> + AFBC_FORMAT_MOD_SPARSE |
> \
> + AFBC_FORMAT_MOD_SPLIT)
> +
> /* Takes a fixed 16.16 number and converts it to integer. */
> static inline int64_t fixed16_to_int(int64_t value)
> {
> return value >> 16;
> }
>
> +static u32 meson_g12a_afbcd_line_stride(struct meson_drm *priv)
> +{
> +u32 line_stride = 0;
> +
> +switch (priv->afbcd.format) {
> +case DRM_FORMAT_RGB565:
> +
[Bug 111979] [5.2/5.3][drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted!
https://bugs.freedesktop.org/show_bug.cgi?id=111979 --- Comment #1 from udo --- This is on AMD Ryzen 5 3400G with Radeon Vega Graphics, Fedora 30, git mesa, git amdgpu, kernel.org kernel. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111979] [5.2/5.3][drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted!
https://bugs.freedesktop.org/show_bug.cgi?id=111979 Bug ID: 111979 Summary: [5.2/5.3][drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted! Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: major Priority: not set Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: udo...@xs4all.nl Seen on both AMD 2400g and 3400g APU's, we find these in dmesg of 5.3.5.: 85.232749] fuse: init (API version 7.31) [18161.173791] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted! [18166.037697] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but soft recovered [18171.153568] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted! [18186.261621] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but soft recovered or on 5.2.17 sometimes: [ 7596.392996] sd 11:0:0:0: [sde] Synchronize Cache(10) failed: Result: hostbyte=0x01 driverbyte=0x00 [97954.657336] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted! [97959.535278] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=2542528, emitted seq=2542531 [97959.535342] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process pid 0 thread pid 0 [97959.535346] [drm] GPU recovery disabled. Then the graphics stop working and the machine GUI is unusable until reboot. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/2] Add initial support for slimport anx7625
On Fri, Oct 11, 2019 at 02:20:47AM +, Xin Ji wrote: > Hi all, > > The following series add initial support for the Slimport ANX7625 > transmitter, a > ultra-low power Full-HD 4K MIPI to DP transmitter designed for portable > device. > > This is the initial version, any mistakes, please let me know, I will fix it > in > the next series. > > Thanks, > Xin > I'm not a domain expert but I like these patches now. Reviewed-by: Dan Carpenter regards, dan carpenter
Re: [PATCH v2 4/4] drm/komeda: Adds gamma and color-transform support for DOU-IPS
On Friday, 11 October 2019 11:12:51 BST Lowry Li (Arm Technology China) wrote:
> Hi Mihail,
> On Fri, Oct 11, 2019 at 08:54:03AM +, Mihail Atanassov wrote:
> > Hi James, Lowry,
> >
> > On Friday, 11 October 2019 06:45:50 BST james qian wang (Arm Technology
> > China) wrote:
> > > From: "Lowry Li (Arm Technology China)"
> > >
> > > Adds gamma and color-transform support for DOU-IPS.
> > > Adds two caps members fgamma_coeffs and ctm_coeffs to komeda_improc_state.
> > > If color management changed, set gamma and color-transform accordingly.
> > >
> > > Signed-off-by: Lowry Li (Arm Technology China)
> > > ---
> > > .../arm/display/komeda/d71/d71_component.c| 24 +++
> > > .../gpu/drm/arm/display/komeda/komeda_crtc.c | 2 ++
> > > .../drm/arm/display/komeda/komeda_pipeline.h | 3 +++
> > > .../display/komeda/komeda_pipeline_state.c| 6 +
> > > 4 files changed, 35 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > > b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > > index c3d29c0b051b..e7e5a8e4430e 100644
> > > --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > > +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > > @@ -942,15 +942,39 @@ static int d71_merger_init(struct d71_dev *d71,
> > > static void d71_improc_update(struct komeda_component *c,
> > > struct komeda_component_state *state)
> > > {
> > > + struct drm_crtc_state *crtc_st = state->crtc->state;
> > I'm not sure it's a good idea to introduce a dependency on drm state
> > so far down in the HW funcs, is there a good reason for the direct prod?
> We dicussed about this before. To decide using this way is to avoid of
> duplicated state between DRM and Komeda.
Fair, r-b me.
>
> Regards,
> Lowry
> > > struct komeda_improc_state *st = to_improc_st(state);
> > > + struct d71_pipeline *pipe = to_d71_pipeline(c->pipeline);
> > > u32 __iomem *reg = c->reg;
> > > u32 index;
> > > + u32 mask = 0, ctrl = 0;
> > >
> > > for_each_changed_input(state, index)
> > > malidp_write32(reg, BLK_INPUT_ID0 + index * 4,
> > > to_d71_input_id(state, index));
> > >
> > > malidp_write32(reg, BLK_SIZE, HV_SIZE(st->hsize, st->vsize));
> > > +
> > > + if (crtc_st->color_mgmt_changed) {
> > > + mask |= IPS_CTRL_FT | IPS_CTRL_RGB;
> > > +
> > > + if (crtc_st->gamma_lut) {
> > > + malidp_write_group(pipe->dou_ft_coeff_addr, FT_COEFF0,
> > > +KOMEDA_N_GAMMA_COEFFS,
> > > +st->fgamma_coeffs);
> > > + ctrl |= IPS_CTRL_FT; /* enable gamma */
> > > + }
> > > +
> > > + if (crtc_st->ctm) {
> > > + malidp_write_group(reg, IPS_RGB_RGB_COEFF0,
> > > +KOMEDA_N_CTM_COEFFS,
> > > +st->ctm_coeffs);
> > > + ctrl |= IPS_CTRL_RGB; /* enable gamut */
> > > + }
> > > + }
> > > +
> > > + if (mask)
> > > + malidp_write32_mask(reg, BLK_CONTROL, mask, ctrl);
> > > }
> > >
> > > static void d71_improc_dump(struct komeda_component *c, struct seq_file
> > > *sf)
> > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > > b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > > index 9beeda04818b..406b9d0ca058 100644
> > > --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > > @@ -590,6 +590,8 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
> > >
> > > crtc->port = kcrtc->master->of_output_port;
> > >
> > > + drm_crtc_enable_color_mgmt(crtc, 0, true, KOMEDA_COLOR_LUT_SIZE);
> > > +
> > > return err;
> > > }
> > >
> > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> > > b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> > > index b322f52ba8f2..c5ab8096c85d 100644
> > > --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> > > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> > > @@ -11,6 +11,7 @@
> > > #include
> > > #include
> > > #include "malidp_utils.h"
> > > +#include "komeda_color_mgmt.h"
> > >
> > > #define KOMEDA_MAX_PIPELINES 2
> > > #define KOMEDA_PIPELINE_MAX_LAYERS 4
> > > @@ -324,6 +325,8 @@ struct komeda_improc {
> > > struct komeda_improc_state {
> > > struct komeda_component_state base;
> > > u16 hsize, vsize;
> > > + u32 fgamma_coeffs[KOMEDA_N_GAMMA_COEFFS];
> > > + u32 ctm_coeffs[KOMEDA_N_CTM_COEFFS];
> > > };
> > >
> > > /* display timing controller */
> > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> > > b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> > > index 0ba9c6aa3708..4a40b37eb1a6 100644
> > > --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> > > +++
Re: [PATCHv2 7/7] drm/omap: hdmi4: fix use of uninitialized var
On 10/10/2019 16:24, Tony Lindgren wrote: Hmm so what register does this clock actually change? I'm seeing an increase of few tens of extra mW, which means at least one day of standby time less for me :) It does not happen always, maybe half of the time. I have no idea why this would affect power consumption. As far as I can understand, the bits written here are a clk divider MCLK. I don't see why that would affect. Maybe Jyri or Peter has an idea, I have never looked at the HDMI audio side. 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
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #83 from Pierre-Eric Pelloux-Prayer --- Another kernel patch worth trying: https://patchwork.freedesktop.org/patch/335077/ -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/4] drm/komeda: Adds gamma and color-transform support for DOU-IPS
Hi Mihail,
On Fri, Oct 11, 2019 at 08:54:03AM +, Mihail Atanassov wrote:
> Hi James, Lowry,
>
> On Friday, 11 October 2019 06:45:50 BST james qian wang (Arm Technology
> China) wrote:
> > From: "Lowry Li (Arm Technology China)"
> >
> > Adds gamma and color-transform support for DOU-IPS.
> > Adds two caps members fgamma_coeffs and ctm_coeffs to komeda_improc_state.
> > If color management changed, set gamma and color-transform accordingly.
> >
> > Signed-off-by: Lowry Li (Arm Technology China)
> > ---
> > .../arm/display/komeda/d71/d71_component.c| 24 +++
> > .../gpu/drm/arm/display/komeda/komeda_crtc.c | 2 ++
> > .../drm/arm/display/komeda/komeda_pipeline.h | 3 +++
> > .../display/komeda/komeda_pipeline_state.c| 6 +
> > 4 files changed, 35 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > index c3d29c0b051b..e7e5a8e4430e 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > @@ -942,15 +942,39 @@ static int d71_merger_init(struct d71_dev *d71,
> > static void d71_improc_update(struct komeda_component *c,
> > struct komeda_component_state *state)
> > {
> > + struct drm_crtc_state *crtc_st = state->crtc->state;
> I'm not sure it's a good idea to introduce a dependency on drm state
> so far down in the HW funcs, is there a good reason for the direct prod?
We dicussed about this before. To decide using this way is to avoid of
duplicated state between DRM and Komeda.
Regards,
Lowry
> > struct komeda_improc_state *st = to_improc_st(state);
> > + struct d71_pipeline *pipe = to_d71_pipeline(c->pipeline);
> > u32 __iomem *reg = c->reg;
> > u32 index;
> > + u32 mask = 0, ctrl = 0;
> >
> > for_each_changed_input(state, index)
> > malidp_write32(reg, BLK_INPUT_ID0 + index * 4,
> >to_d71_input_id(state, index));
> >
> > malidp_write32(reg, BLK_SIZE, HV_SIZE(st->hsize, st->vsize));
> > +
> > + if (crtc_st->color_mgmt_changed) {
> > + mask |= IPS_CTRL_FT | IPS_CTRL_RGB;
> > +
> > + if (crtc_st->gamma_lut) {
> > + malidp_write_group(pipe->dou_ft_coeff_addr, FT_COEFF0,
> > + KOMEDA_N_GAMMA_COEFFS,
> > + st->fgamma_coeffs);
> > + ctrl |= IPS_CTRL_FT; /* enable gamma */
> > + }
> > +
> > + if (crtc_st->ctm) {
> > + malidp_write_group(reg, IPS_RGB_RGB_COEFF0,
> > + KOMEDA_N_CTM_COEFFS,
> > + st->ctm_coeffs);
> > + ctrl |= IPS_CTRL_RGB; /* enable gamut */
> > + }
> > + }
> > +
> > + if (mask)
> > + malidp_write32_mask(reg, BLK_CONTROL, mask, ctrl);
> > }
> >
> > static void d71_improc_dump(struct komeda_component *c, struct seq_file
> > *sf)
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > index 9beeda04818b..406b9d0ca058 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > @@ -590,6 +590,8 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
> >
> > crtc->port = kcrtc->master->of_output_port;
> >
> > + drm_crtc_enable_color_mgmt(crtc, 0, true, KOMEDA_COLOR_LUT_SIZE);
> > +
> > return err;
> > }
> >
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> > b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> > index b322f52ba8f2..c5ab8096c85d 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> > @@ -11,6 +11,7 @@
> > #include
> > #include
> > #include "malidp_utils.h"
> > +#include "komeda_color_mgmt.h"
> >
> > #define KOMEDA_MAX_PIPELINES 2
> > #define KOMEDA_PIPELINE_MAX_LAYERS 4
> > @@ -324,6 +325,8 @@ struct komeda_improc {
> > struct komeda_improc_state {
> > struct komeda_component_state base;
> > u16 hsize, vsize;
> > + u32 fgamma_coeffs[KOMEDA_N_GAMMA_COEFFS];
> > + u32 ctm_coeffs[KOMEDA_N_CTM_COEFFS];
> > };
> >
> > /* display timing controller */
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> > b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> > index 0ba9c6aa3708..4a40b37eb1a6 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> > @@ -756,6 +756,12 @@ komeda_improc_validate(struct komeda_improc *improc,
> > st->hsize = dflow->in_w;
> > st->vsize = dflow->in_h;
> >
> > + if (kcrtc_st->base.color_mgmt_changed) {
> > +
Re: Kernel crash on 4.19.77-1-lts (Arch Linux / ThinkPad T470p)
On Thu, Oct 10, 2019 at 01:15:09PM -0400, John Maguire wrote: > Hi there, > > I wasn't sure which mailing list to use so I BCC'd > intel-...@lists.freedesktop.org and dri-devel@lists.freedesktop.org Just use Cc. We want all replies to go to the list(s) as well. > > I'm using a Lenovo Thinkpad T470p and running the 4.19.77-1-lts kernel on > Arch Linux. Recently, I've started getting freezes each day. Audio can > still be heard, but video output stops. I was able to retrieve a call trace > from journald. > > I've attached the output of "sudo lspci -vvv" as well as the message from > journald (null pointer dereference). Oct 10 12:53:30 scorpion kernel: RIP: 0010:dma_fence_signal_locked+0x30/0xe0 Looks like it could be https://bugs.freedesktop.org/show_bug.cgi?id=111381 in which case you just need to upgrade to 4.19.78 and it should be fixed. -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107877] deepin-desktop: xdg-email: no method available for opening 'mailto:'
https://bugs.freedesktop.org/show_bug.cgi?id=107877 Michel Dänzer changed: What|Removed |Added URL|https://www.monktech.us/| -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] drm: Add some new format DRM_FORMAT_NVXX_10
Hi, james, ville syrjala, david,
在 2019/10/11 下午4:32, james qian wang (Arm Technology China) 写道:
On Fri, Oct 11, 2019 at 03:32:17PM +0800, sandy.huang wrote:
在 2019/10/11 下午3:22, james qian wang (Arm Technology China) 写道:
On Fri, Oct 11, 2019 at 03:07:22PM +0800, sandy.huang wrote:
在 2019/10/11 下午2:44, james qian wang (Arm Technology China) 写道:
On Fri, Oct 11, 2019 at 11:35:53AM +0800, sandy.huang wrote:
Hi james.qian.wang,
Thank for you remind, fou some unknow reason, i miss the the mail from
you:(, i get this message from https://patchwork.kernel.org/patch/11161937/
sorry about that.
About the format block describe, I also found some unreasonable, this
format need 2 line aligned, so the block_h need to sed as 2, and the
char_per_block need set as w * h * 10 for y plane, and w * h * 2 * 10 for uv
plane, so the following describe maybe more correct, thanks.
{ .format = DRM_FORMAT_NV12_10, .depth = 0, .num_planes = 2,
.char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 }, .block_h
= { 2, 2, 0 },
.hsub = 2, .vsub = 2, .is_yuv = true},
Hi Sandy:
I think for such NV12 YUV-422 (hsub = 2, vsub = 2) 2x2 subsampled format
the block size can be:
the Y plane: 2x2;
The UV plane: 1x2; (H direction sample 1 Cb and 1Cr, V direction 2 lines got 2)
Then:
.char_per_block = {5, 5, 0} block_w = {2, 1, 0}. block_h = {2, 2, 0};
Thanks
James
Hi James,
If the block_w is 2 pixel, one line size at block is 2*10 bit %8 != 0,
Hi Sandy:
you got a mistake here, the bpp of UV plane is 20, 10bit Cb + 10 bit Cr.
here is for y plane.
Sorry, Are we talking about the block size calcaltion here ?
block_size = block_w * block_h * plane_bpp
for you Y plane a 2x2 block is: 2 x 2 * 10 bpp = 40bits
And the block info is for computing the minimum pitch, and don't
consider the specific hardware alignment here.
see: drm_format_info_min_pitch()
If you hardware need alignment, you need to put that consideration into your
specific driver.
James.
Hi david and ville syrjala,
Do you have any Suggestions?
James think Y plane 2x2 block size is enough to describe this
format, but i prefer to use 4x2 block size, this can include the
alignment message.
just like the malidp_de_plane_check()@malidp_plane.c have the following
code, here use the block size to check alignment.
block_w = drm_format_info_block_width(fb->format, 0);
block_h = drm_format_info_block_height(fb->format, 0);
if (fb->width % block_w || fb->height % block_h) {
DRM_DEBUG_KMS("Buffer width/height needs to be a multiple of
tile sizes");
return -EINVAL;
}
if ((state->src_x >> 16) % block_w || (state->src_y >> 16) % block_h) {
DRM_DEBUG_KMS("Plane src_x/src_y needs to be a multiple of tile
sizes");
return -EINVAL;
}
can you give me some suggestions?
thanks,
sandy.huang
although we use block to describe this format, but actually the data is
still stored one line by one line, still need 4 pixel aligned. so i think
here need use 4pixel*2line for per block
I think this is your hardware specific requirement.
Thanks
James
yes, this is a new format first used at rockchip platform.
Thanks,
sandy.huang
Thanks,
sandy.huang.
.hsub = 2, .vsub = 2, .is_yuv = true},
{ .format = DRM_FORMAT_NV21_10, .depth = 0, .num_planes = 2,
.char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 }, .block_h
= { 2, 2, 0 },
.hsub = 2, .vsub = 2, .is_yuv = true},
{ .format = DRM_FORMAT_NV16_10, .depth = 0, .num_planes = 2,
.char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 }, .block_h
= { 2, 2, 0 },
.hsub = 2, .vsub = 1, .is_yuv = true},
{ .format = DRM_FORMAT_NV61_10, .depth = 0, .num_planes = 2,
.char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 }, .block_h
= { 2, 2, 0 },
.hsub = 2, .vsub = 1, .is_yuv = true},
{ .format = DRM_FORMAT_NV24_10, .depth = 0, .num_planes = 2,
.char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 }, .block_h
= { 2, 2, 0 },
.hsub = 1, .vsub = 1, .is_yuv = true},
{ .format = DRM_FORMAT_NV42_10, .depth = 0, .num_planes = 2,
.char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 }, .block_h
= { 2, 2, 0 },
.hsub = 1, .vsub = 1, .is_yuv = true},
{ .format = DRM_FORMAT_P016, .depth = 0, .num_planes =
2,
.char_per_block = { 2, 4, 0 }, .block_w = { 1, 0, 0 },
.block_h = { 1, 0, 0 },
.hsub = 2, .vsub = 2, .is_yuv = true},
+ { .format = DRM_FORMAT_NV12_10, .depth = 0, .num_planes
= 2,
+ .char_per_block = { 5, 10, 0 }, .block_w = { 4, 4, 0 },
.block_h = { 4, 4, 0 },
Hi Sandy:
Their is a problem here for char_per_block size of plane[0]:
Since: 5 * 8 != 4 * 4 * 10;
Seems you mis-set the block_w/h, per your
Re: [PATCH 0/4] treewide: fix interrupted release
On Thu, Oct 10, 2019 at 03:50:43PM +0200, Daniel Vetter wrote: > On Thu, Oct 10, 2019 at 03:13:29PM +0200, Johan Hovold wrote: > > Two old USB drivers had a bug in them which could lead to memory leaks > > if an interrupted process raced with a disconnect event. > > > > Turns out we had a few more driver in other subsystems with the same > > kind of bug in them. > Random funny idea: Could we do some debug annotations (akin to > might_sleep) that splats when you might_sleep_interruptible somewhere > where interruptible sleeps are generally a bad idea? Like in > fops->release? There's nothing wrong with interruptible sleep in fops->release per se, it's just that drivers cannot return -ERESTARTSYS and friends and expect to be called again later. The return value from release() is ignored by vfs, and adding a splat in __fput() to catch these buggy drivers might be overkill. Johan
Re: [PATCH] drm/amdgpu: Bail earlier when amdgpu.cik_/si_support is not set to 1
Hi,
On 10-10-2019 18:59, Daniel Vetter wrote:
On Thu, Oct 10, 2019 at 6:28 PM Hans de Goede wrote:
Bail from the pci_driver probe function instead of from the drm_driver
load function.
This avoid /dev/dri/card0 temporarily getting registered and then
unregistered again, sending unwanted add / remove udev events to
userspace.
Specifically this avoids triggering the (userspace) bug fixed by this
plymouth merge-request:
https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/59
Note that despite that being a userspace bug, not sending unnecessary
udev events is a good idea in general.
I think even better would be getting rid of the load/unload callbacks,
this issue here isn't the only problem with them.
Reviewed-by: Daniel Vetter
Thanks,
I guess also cc: stable material?
Yes.
amdgpu maintainers, can you please add a Cc: stable while merging?
Let me know if you want a new version with this added.
Regards,
Hans
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1490490
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 35 +
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 35 -
2 files changed, 35 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 6f8aaf655a9f..2a00a36106b2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1048,6 +1048,41 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
return -ENODEV;
}
+#ifdef CONFIG_DRM_AMDGPU_SI
+ if (!amdgpu_si_support) {
+ switch (flags & AMD_ASIC_MASK) {
+ case CHIP_TAHITI:
+ case CHIP_PITCAIRN:
+ case CHIP_VERDE:
+ case CHIP_OLAND:
+ case CHIP_HAINAN:
+ dev_info(>dev,
+"SI support provided by radeon.\n");
+ dev_info(>dev,
+"Use radeon.si_support=0 amdgpu.si_support=1 to
override.\n"
+ );
+ return -ENODEV;
+ }
+ }
+#endif
+#ifdef CONFIG_DRM_AMDGPU_CIK
+ if (!amdgpu_cik_support) {
+ switch (flags & AMD_ASIC_MASK) {
+ case CHIP_KAVERI:
+ case CHIP_BONAIRE:
+ case CHIP_HAWAII:
+ case CHIP_KABINI:
+ case CHIP_MULLINS:
+ dev_info(>dev,
+"CIK support provided by radeon.\n");
+ dev_info(>dev,
+"Use radeon.cik_support=0 amdgpu.cik_support=1 to
override.\n"
+ );
+ return -ENODEV;
+ }
+ }
+#endif
+
/* Get rid of things like offb */
ret = drm_fb_helper_remove_conflicting_pci_framebuffers(pdev, 0,
"amdgpudrmfb");
if (ret)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index f2c097983f48..d55f5baa83d3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -144,41 +144,6 @@ int amdgpu_driver_load_kms(struct drm_device *dev,
unsigned long flags)
struct amdgpu_device *adev;
int r, acpi_status;
-#ifdef CONFIG_DRM_AMDGPU_SI
- if (!amdgpu_si_support) {
- switch (flags & AMD_ASIC_MASK) {
- case CHIP_TAHITI:
- case CHIP_PITCAIRN:
- case CHIP_VERDE:
- case CHIP_OLAND:
- case CHIP_HAINAN:
- dev_info(dev->dev,
-"SI support provided by radeon.\n");
- dev_info(dev->dev,
-"Use radeon.si_support=0 amdgpu.si_support=1 to
override.\n"
- );
- return -ENODEV;
- }
- }
-#endif
-#ifdef CONFIG_DRM_AMDGPU_CIK
- if (!amdgpu_cik_support) {
- switch (flags & AMD_ASIC_MASK) {
- case CHIP_KAVERI:
- case CHIP_BONAIRE:
- case CHIP_HAWAII:
- case CHIP_KABINI:
- case CHIP_MULLINS:
- dev_info(dev->dev,
-"CIK support provided by radeon.\n");
- dev_info(dev->dev,
-"Use radeon.cik_support=0 amdgpu.cik_support=1 to
override.\n"
- );
- return -ENODEV;
- }
- }
-#endif
-
adev = kzalloc(sizeof(struct amdgpu_device), GFP_KERNEL);
if (adev == NULL) {
return -ENOMEM;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
[Bug 107877] deepin-desktop: xdg-email: no method available for opening 'mailto:'
https://bugs.freedesktop.org/show_bug.cgi?id=107877 andrerushell changed: What|Removed |Added URL|https://www.monktech.us/Gma |https://www.monktech.us/ |il-Help-Phone-number.html | --- Comment #34 from andrerushell --- If you are one of those who are confronting with any sort of technical or non technical issues during the course of composing a mail on Gmail, you should take Gmail Help by using our toll free helpline number. Here, you will get the best in class solution to your problems at an affordable cost. https://www.monktech.us/Gmail-Help-Phone-number.html -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107877] deepin-desktop: xdg-email: no method available for opening 'mailto:'
https://bugs.freedesktop.org/show_bug.cgi?id=107877 andrerushell changed: What|Removed |Added URL||https://www.monktech.us/Gma ||il-Help-Phone-number.html --- Comment #33 from andrerushell --- If you are one of those who are confronting with any sort of technical or non technical issues during the course of composing a mail on Gmail, you should take Gmail Help by using our toll free helpline number. Here, you will get the best in class solution to your problems at an affordable cost. https://www.monktech.us/Gmail-Help-Phone-number.html -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/7] drm/meson: plane: add support for AFBC mode for OSD1 plane
Hi Brian,
On 11/10/2019 10:41, Brian Starkey wrote:
> Hi Neil,
>
> On Thu, Oct 10, 2019 at 03:41:15PM +0200, Neil Armstrong wrote:
>> Hi Ayan,
>>
>> On 10/10/2019 15:26, Ayan Halder wrote:
>>> On Thu, Oct 10, 2019 at 11:25:23AM +0200, Neil Armstrong wrote:
This adds all the OSD configuration plumbing to support the AFBC decoders
path to display of the OSD1 plane.
The Amlogic GXM and G12A AFBC decoders are integrated very differently.
The Amlogic GXM has a direct output path to the OSD1 VIU pixel input,
because the GXM AFBC decoder seem to be a custom IP developed by Amlogic.
On the other side, the Amlogic G12A AFBC decoder seems to be an external
IP that emit pixels on an AXI master hooked to a "Mali Unpack" block
feeding the OSD1 VIU pixel input.
This uses a weird "0x100" internal HW physical address on both
sides to transfer the pixels.
For Amlogic GXM, the supported pixel formats are the same as the normal
linear OSD1 mode.
On the other side, Amlogic added support for all AFBC v1.2 formats for
the G12A AFBC integration.
For simplicity, we stick to the already supported formats for now.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_crtc.c | 2 +
drivers/gpu/drm/meson/meson_drv.h | 4 +
drivers/gpu/drm/meson/meson_plane.c | 215
3 files changed, 190 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_crtc.c
b/drivers/gpu/drm/meson/meson_crtc.c
index 57ae1c13d1e6..d478fa232951 100644
--- a/drivers/gpu/drm/meson/meson_crtc.c
+++ b/drivers/gpu/drm/meson/meson_crtc.c
@@ -281,6 +281,8 @@ void meson_crtc_irq(struct meson_drm *priv)
if (priv->viu.osd1_enabled && priv->viu.osd1_commit) {
writel_relaxed(priv->viu.osd1_ctrl_stat,
priv->io_base + _REG(VIU_OSD1_CTRL_STAT));
+ writel_relaxed(priv->viu.osd1_ctrl_stat2,
+ priv->io_base + _REG(VIU_OSD1_CTRL_STAT2));
writel_relaxed(priv->viu.osd1_blk0_cfg[0],
priv->io_base + _REG(VIU_OSD1_BLK0_CFG_W0));
writel_relaxed(priv->viu.osd1_blk0_cfg[1],
diff --git a/drivers/gpu/drm/meson/meson_drv.h
b/drivers/gpu/drm/meson/meson_drv.h
index 60f13c6f34e5..de25349be8aa 100644
--- a/drivers/gpu/drm/meson/meson_drv.h
+++ b/drivers/gpu/drm/meson/meson_drv.h
@@ -53,8 +53,12 @@ struct meson_drm {
bool osd1_enabled;
bool osd1_interlace;
bool osd1_commit;
+ bool osd1_afbcd;
uint32_t osd1_ctrl_stat;
+ uint32_t osd1_ctrl_stat2;
uint32_t osd1_blk0_cfg[5];
+ uint32_t osd1_blk1_cfg4;
+ uint32_t osd1_blk2_cfg4;
uint32_t osd1_addr;
uint32_t osd1_stride;
uint32_t osd1_height;
diff --git a/drivers/gpu/drm/meson/meson_plane.c
b/drivers/gpu/drm/meson/meson_plane.c
index 5e798c276037..412941aa8402 100644
--- a/drivers/gpu/drm/meson/meson_plane.c
+++ b/drivers/gpu/drm/meson/meson_plane.c
@@ -23,6 +23,7 @@
#include "meson_plane.h"
#include "meson_registers.h"
#include "meson_viu.h"
+#include "meson_osd_afbcd.h"
/* OSD_SCI_WH_M1 */
#define SCI_WH_M1_W(w)FIELD_PREP(GENMASK(28, 16), w)
@@ -92,12 +93,38 @@ static int meson_plane_atomic_check(struct drm_plane
*plane,
false, true);
}
+#define MESON_MOD_AFBC_VALID_BITS (AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 |
\
+ AFBC_FORMAT_MOD_BLOCK_SIZE_32x8 |\
+ AFBC_FORMAT_MOD_YTR |\
+ AFBC_FORMAT_MOD_SPARSE | \
+ AFBC_FORMAT_MOD_SPLIT)
+
/* Takes a fixed 16.16 number and converts it to integer. */
static inline int64_t fixed16_to_int(int64_t value)
{
return value >> 16;
}
+static u32 meson_g12a_afbcd_line_stride(struct meson_drm *priv)
+{
+ u32 line_stride = 0;
+
+ switch (priv->afbcd.format) {
+ case DRM_FORMAT_RGB565:
+ line_stride = ((priv->viu.osd1_width << 4) + 127) >> 7;
+ break;
+ case DRM_FORMAT_RGB888:
+ case DRM_FORMAT_XRGB:
+ case DRM_FORMAT_ARGB:
+ case DRM_FORMAT_XBGR:
+ case DRM_FORMAT_ABGR:
>>> Please have a look at
>>> https://www.kernel.org/doc/html/latest/gpu/afbc.html for our
>>> recommendation. We suggest that *X* formats are avoided.
>>>
>>> Also, for interoperability and maximum compression efficiency (with
>>> AFBC_FORMAT_MOD_YTR), we
Re: [PATCH v2 4/4] drm/komeda: Adds gamma and color-transform support for DOU-IPS
Hi James, Lowry,
On Friday, 11 October 2019 06:45:50 BST james qian wang (Arm Technology China)
wrote:
> From: "Lowry Li (Arm Technology China)"
>
> Adds gamma and color-transform support for DOU-IPS.
> Adds two caps members fgamma_coeffs and ctm_coeffs to komeda_improc_state.
> If color management changed, set gamma and color-transform accordingly.
>
> Signed-off-by: Lowry Li (Arm Technology China)
> ---
> .../arm/display/komeda/d71/d71_component.c| 24 +++
> .../gpu/drm/arm/display/komeda/komeda_crtc.c | 2 ++
> .../drm/arm/display/komeda/komeda_pipeline.h | 3 +++
> .../display/komeda/komeda_pipeline_state.c| 6 +
> 4 files changed, 35 insertions(+)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> index c3d29c0b051b..e7e5a8e4430e 100644
> --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> @@ -942,15 +942,39 @@ static int d71_merger_init(struct d71_dev *d71,
> static void d71_improc_update(struct komeda_component *c,
> struct komeda_component_state *state)
> {
> + struct drm_crtc_state *crtc_st = state->crtc->state;
I'm not sure it's a good idea to introduce a dependency on drm state
so far down in the HW funcs, is there a good reason for the direct prod?
> struct komeda_improc_state *st = to_improc_st(state);
> + struct d71_pipeline *pipe = to_d71_pipeline(c->pipeline);
> u32 __iomem *reg = c->reg;
> u32 index;
> + u32 mask = 0, ctrl = 0;
>
> for_each_changed_input(state, index)
> malidp_write32(reg, BLK_INPUT_ID0 + index * 4,
> to_d71_input_id(state, index));
>
> malidp_write32(reg, BLK_SIZE, HV_SIZE(st->hsize, st->vsize));
> +
> + if (crtc_st->color_mgmt_changed) {
> + mask |= IPS_CTRL_FT | IPS_CTRL_RGB;
> +
> + if (crtc_st->gamma_lut) {
> + malidp_write_group(pipe->dou_ft_coeff_addr, FT_COEFF0,
> +KOMEDA_N_GAMMA_COEFFS,
> +st->fgamma_coeffs);
> + ctrl |= IPS_CTRL_FT; /* enable gamma */
> + }
> +
> + if (crtc_st->ctm) {
> + malidp_write_group(reg, IPS_RGB_RGB_COEFF0,
> +KOMEDA_N_CTM_COEFFS,
> +st->ctm_coeffs);
> + ctrl |= IPS_CTRL_RGB; /* enable gamut */
> + }
> + }
> +
> + if (mask)
> + malidp_write32_mask(reg, BLK_CONTROL, mask, ctrl);
> }
>
> static void d71_improc_dump(struct komeda_component *c, struct seq_file *sf)
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> index 9beeda04818b..406b9d0ca058 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> @@ -590,6 +590,8 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
>
> crtc->port = kcrtc->master->of_output_port;
>
> + drm_crtc_enable_color_mgmt(crtc, 0, true, KOMEDA_COLOR_LUT_SIZE);
> +
> return err;
> }
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> index b322f52ba8f2..c5ab8096c85d 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> @@ -11,6 +11,7 @@
> #include
> #include
> #include "malidp_utils.h"
> +#include "komeda_color_mgmt.h"
>
> #define KOMEDA_MAX_PIPELINES 2
> #define KOMEDA_PIPELINE_MAX_LAYERS 4
> @@ -324,6 +325,8 @@ struct komeda_improc {
> struct komeda_improc_state {
> struct komeda_component_state base;
> u16 hsize, vsize;
> + u32 fgamma_coeffs[KOMEDA_N_GAMMA_COEFFS];
> + u32 ctm_coeffs[KOMEDA_N_CTM_COEFFS];
> };
>
> /* display timing controller */
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> index 0ba9c6aa3708..4a40b37eb1a6 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> @@ -756,6 +756,12 @@ komeda_improc_validate(struct komeda_improc *improc,
> st->hsize = dflow->in_w;
> st->vsize = dflow->in_h;
>
> + if (kcrtc_st->base.color_mgmt_changed) {
> + drm_lut_to_fgamma_coeffs(kcrtc_st->base.gamma_lut,
> + st->fgamma_coeffs);
> + drm_ctm_to_coeffs(kcrtc_st->base.ctm, st->ctm_coeffs);
> + }
> +
> komeda_component_add_input(>base, >input, 0);
> komeda_component_set_output(>input, >base, 0);
>
>
--
Mihail
Re: [PATCH 4/7] drm/meson: plane: add support for AFBC mode for OSD1 plane
Hi Neil,
On Thu, Oct 10, 2019 at 03:41:15PM +0200, Neil Armstrong wrote:
> Hi Ayan,
>
> On 10/10/2019 15:26, Ayan Halder wrote:
> > On Thu, Oct 10, 2019 at 11:25:23AM +0200, Neil Armstrong wrote:
> >> This adds all the OSD configuration plumbing to support the AFBC decoders
> >> path to display of the OSD1 plane.
> >>
> >> The Amlogic GXM and G12A AFBC decoders are integrated very differently.
> >>
> >> The Amlogic GXM has a direct output path to the OSD1 VIU pixel input,
> >> because the GXM AFBC decoder seem to be a custom IP developed by Amlogic.
> >>
> >> On the other side, the Amlogic G12A AFBC decoder seems to be an external
> >> IP that emit pixels on an AXI master hooked to a "Mali Unpack" block
> >> feeding the OSD1 VIU pixel input.
> >> This uses a weird "0x100" internal HW physical address on both
> >> sides to transfer the pixels.
> >>
> >> For Amlogic GXM, the supported pixel formats are the same as the normal
> >> linear OSD1 mode.
> >>
> >> On the other side, Amlogic added support for all AFBC v1.2 formats for
> >> the G12A AFBC integration.
> >>
> >> For simplicity, we stick to the already supported formats for now.
> >>
> >> Signed-off-by: Neil Armstrong
> >> ---
> >> drivers/gpu/drm/meson/meson_crtc.c | 2 +
> >> drivers/gpu/drm/meson/meson_drv.h | 4 +
> >> drivers/gpu/drm/meson/meson_plane.c | 215
> >> 3 files changed, 190 insertions(+), 31 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/meson/meson_crtc.c
> >> b/drivers/gpu/drm/meson/meson_crtc.c
> >> index 57ae1c13d1e6..d478fa232951 100644
> >> --- a/drivers/gpu/drm/meson/meson_crtc.c
> >> +++ b/drivers/gpu/drm/meson/meson_crtc.c
> >> @@ -281,6 +281,8 @@ void meson_crtc_irq(struct meson_drm *priv)
> >>if (priv->viu.osd1_enabled && priv->viu.osd1_commit) {
> >>writel_relaxed(priv->viu.osd1_ctrl_stat,
> >>priv->io_base + _REG(VIU_OSD1_CTRL_STAT));
> >> + writel_relaxed(priv->viu.osd1_ctrl_stat2,
> >> + priv->io_base + _REG(VIU_OSD1_CTRL_STAT2));
> >>writel_relaxed(priv->viu.osd1_blk0_cfg[0],
> >>priv->io_base + _REG(VIU_OSD1_BLK0_CFG_W0));
> >>writel_relaxed(priv->viu.osd1_blk0_cfg[1],
> >> diff --git a/drivers/gpu/drm/meson/meson_drv.h
> >> b/drivers/gpu/drm/meson/meson_drv.h
> >> index 60f13c6f34e5..de25349be8aa 100644
> >> --- a/drivers/gpu/drm/meson/meson_drv.h
> >> +++ b/drivers/gpu/drm/meson/meson_drv.h
> >> @@ -53,8 +53,12 @@ struct meson_drm {
> >>bool osd1_enabled;
> >>bool osd1_interlace;
> >>bool osd1_commit;
> >> + bool osd1_afbcd;
> >>uint32_t osd1_ctrl_stat;
> >> + uint32_t osd1_ctrl_stat2;
> >>uint32_t osd1_blk0_cfg[5];
> >> + uint32_t osd1_blk1_cfg4;
> >> + uint32_t osd1_blk2_cfg4;
> >>uint32_t osd1_addr;
> >>uint32_t osd1_stride;
> >>uint32_t osd1_height;
> >> diff --git a/drivers/gpu/drm/meson/meson_plane.c
> >> b/drivers/gpu/drm/meson/meson_plane.c
> >> index 5e798c276037..412941aa8402 100644
> >> --- a/drivers/gpu/drm/meson/meson_plane.c
> >> +++ b/drivers/gpu/drm/meson/meson_plane.c
> >> @@ -23,6 +23,7 @@
> >> #include "meson_plane.h"
> >> #include "meson_registers.h"
> >> #include "meson_viu.h"
> >> +#include "meson_osd_afbcd.h"
> >>
> >> /* OSD_SCI_WH_M1 */
> >> #define SCI_WH_M1_W(w)FIELD_PREP(GENMASK(28, 16), w)
> >> @@ -92,12 +93,38 @@ static int meson_plane_atomic_check(struct drm_plane
> >> *plane,
> >> false, true);
> >> }
> >>
> >> +#define MESON_MOD_AFBC_VALID_BITS (AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 |
> >> \
> >> + AFBC_FORMAT_MOD_BLOCK_SIZE_32x8 |\
> >> + AFBC_FORMAT_MOD_YTR |\
> >> + AFBC_FORMAT_MOD_SPARSE | \
> >> + AFBC_FORMAT_MOD_SPLIT)
> >> +
> >> /* Takes a fixed 16.16 number and converts it to integer. */
> >> static inline int64_t fixed16_to_int(int64_t value)
> >> {
> >>return value >> 16;
> >> }
> >>
> >> +static u32 meson_g12a_afbcd_line_stride(struct meson_drm *priv)
> >> +{
> >> + u32 line_stride = 0;
> >> +
> >> + switch (priv->afbcd.format) {
> >> + case DRM_FORMAT_RGB565:
> >> + line_stride = ((priv->viu.osd1_width << 4) + 127) >> 7;
> >> + break;
> >> + case DRM_FORMAT_RGB888:
> >> + case DRM_FORMAT_XRGB:
> >> + case DRM_FORMAT_ARGB:
> >> + case DRM_FORMAT_XBGR:
> >> + case DRM_FORMAT_ABGR:
> > Please have a look at
> > https://www.kernel.org/doc/html/latest/gpu/afbc.html for our
> > recommendation. We suggest that *X* formats are avoided.
> >
> > Also, for interoperability and maximum compression efficiency (with
> > AFBC_FORMAT_MOD_YTR), we suggest the following order :-
> >
> > Component 0: R
>
Re: [PATCH v2 3/4] drm/komeda: Add drm_ctm_to_coeffs()
On Friday, 11 October 2019 06:45:42 BST james qian wang (Arm Technology China)
wrote:
> This function is for converting drm_color_ctm matrix to komeda hardware
> required required Q2.12 2's complement CSC matrix.
>
> v2:
> Move the fixpoint conversion function s31_32_to_q2_12() to drm core
> as a shared helper.
>
> Signed-off-by: james qian wang (Arm Technology China)
>
> ---
> .../gpu/drm/arm/display/komeda/komeda_color_mgmt.c | 14 ++
> .../gpu/drm/arm/display/komeda/komeda_color_mgmt.h | 1 +
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> index c180ce70c26c..ad668accbdf4 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> @@ -117,3 +117,17 @@ void drm_lut_to_fgamma_coeffs(struct drm_property_blob
> *lut_blob, u32 *coeffs)
> {
> drm_lut_to_coeffs(lut_blob, coeffs, sector_tbl, ARRAY_SIZE(sector_tbl));
> }
> +
> +void drm_ctm_to_coeffs(struct drm_property_blob *ctm_blob, u32 *coeffs)
[nit] Could do with an extra const or two on the drm_property_blob,
otherwise...
> +{
> + struct drm_color_ctm *ctm;
> + u32 i;
> +
> + if (!ctm_blob)
> + return;
> +
> + ctm = ctm_blob->data;
> +
> + for (i = 0; i < KOMEDA_N_CTM_COEFFS; i++)
> + coeffs[i] = drm_color_ctm_s31_32_to_qm_n(ctm->matrix[i], 2, 12);
> +}
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.h
> b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.h
> index 08ab69281648..2f4668466112 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.h
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.h
> @@ -18,6 +18,7 @@
> #define KOMEDA_N_CTM_COEFFS 9
>
> void drm_lut_to_fgamma_coeffs(struct drm_property_blob *lut_blob, u32
> *coeffs);
> +void drm_ctm_to_coeffs(struct drm_property_blob *ctm_blob, u32 *coeffs);
>
> const s32 *komeda_select_yuv2rgb_coeffs(u32 color_encoding, u32 color_range);
>
>
...
Reviewed-by: Mihail Atanassov
--
Mihail
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] drm: Add some new format DRM_FORMAT_NVXX_10
On Fri, Oct 11, 2019 at 03:32:17PM +0800, sandy.huang wrote:
>
> 在 2019/10/11 下午3:22, james qian wang (Arm Technology China) 写道:
> > On Fri, Oct 11, 2019 at 03:07:22PM +0800, sandy.huang wrote:
> > > 在 2019/10/11 下午2:44, james qian wang (Arm Technology China) 写道:
> > > > On Fri, Oct 11, 2019 at 11:35:53AM +0800, sandy.huang wrote:
> > > > > Hi james.qian.wang,
> > > > >
> > > > > Thank for you remind, fou some unknow reason, i miss the the
> > > > > mail from
> > > > > you:(, i get this message from
> > > > > https://patchwork.kernel.org/patch/11161937/
> > > > >
> > > > > sorry about that.
> > > > >
> > > > > About the format block describe, I also found some
> > > > > unreasonable, this
> > > > > format need 2 line aligned, so the block_h need to sed as 2, and the
> > > > > char_per_block need set as w * h * 10 for y plane, and w * h * 2 * 10
> > > > > for uv
> > > > > plane, so the following describe maybe more correct, thanks.
> > > > >
> > > > > { .format = DRM_FORMAT_NV12_10, .depth = 0,
> > > > > .num_planes = 2,
> > > > > .char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 },
> > > > > .block_h
> > > > > = { 2, 2, 0 },
> > > > > .hsub = 2, .vsub = 2, .is_yuv = true},
> > > > Hi Sandy:
> > > > I think for such NV12 YUV-422 (hsub = 2, vsub = 2) 2x2 subsampled format
> > > > the block size can be:
> > > >
> > > > the Y plane: 2x2;
> > > > The UV plane: 1x2; (H direction sample 1 Cb and 1Cr, V direction 2
> > > > lines got 2)
> > > >
> > > > Then:
> > > >
> > > > .char_per_block = {5, 5, 0} block_w = {2, 1, 0}. block_h = {2, 2, 0};
> > > >
> > > > Thanks
> > > > James
> > > Hi James,
> > >
> > > If the block_w is 2 pixel, one line size at block is 2*10 bit %8 != 0,
> > Hi Sandy:
> > you got a mistake here, the bpp of UV plane is 20, 10bit Cb + 10 bit Cr.
> here is for y plane.
Sorry, Are we talking about the block size calcaltion here ?
block_size = block_w * block_h * plane_bpp
for you Y plane a 2x2 block is: 2 x 2 * 10 bpp = 40bits
And the block info is for computing the minimum pitch, and don't
consider the specific hardware alignment here.
see: drm_format_info_min_pitch()
If you hardware need alignment, you need to put that consideration into your
specific driver.
James.
> > > although we use block to describe this format, but actually the data is
> > > still stored one line by one line, still need 4 pixel aligned. so i think
> > > here need use 4pixel*2line for per block
> > I think this is your hardware specific requirement.
> >
> > Thanks
> > James
>
> yes, this is a new format first used at rockchip platform.
>
>
> Thanks,
>
> sandy.huang
>
> > > Thanks,
> > >
> > > sandy.huang.
> > >
> > > > > .hsub = 2, .vsub = 2, .is_yuv = true},
> > > > > { .format = DRM_FORMAT_NV21_10, .depth = 0,
> > > > > .num_planes = 2,
> > > > > .char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 },
> > > > > .block_h
> > > > > = { 2, 2, 0 },
> > > > > .hsub = 2, .vsub = 2, .is_yuv = true},
> > > > > { .format = DRM_FORMAT_NV16_10, .depth = 0,
> > > > > .num_planes = 2,
> > > > > .char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 },
> > > > > .block_h
> > > > > = { 2, 2, 0 },
> > > > > .hsub = 2, .vsub = 1, .is_yuv = true},
> > > > > { .format = DRM_FORMAT_NV61_10, .depth = 0,
> > > > > .num_planes = 2,
> > > > > .char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 },
> > > > > .block_h
> > > > > = { 2, 2, 0 },
> > > > > .hsub = 2, .vsub = 1, .is_yuv = true},
> > > > > { .format = DRM_FORMAT_NV24_10, .depth = 0,
> > > > > .num_planes = 2,
> > > > > .char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 },
> > > > > .block_h
> > > > > = { 2, 2, 0 },
> > > > > .hsub = 1, .vsub = 1, .is_yuv = true},
> > > > > { .format = DRM_FORMAT_NV42_10, .depth = 0,
> > > > > .num_planes = 2,
> > > > > .char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 },
> > > > > .block_h
> > > > > = { 2, 2, 0 },
> > > > > .hsub = 1, .vsub = 1, .is_yuv = true},
> > > > >
> > > > >
> > > > > > > { .format = DRM_FORMAT_P016, .depth = 0,
> > > > > > > .num_planes =
> > > > > 2,
> > > > > > > .char_per_block = { 2, 4, 0 }, .block_w = { 1, 0, 0
> > > > > > > },
> > > > > .block_h = { 1, 0, 0 },
> > > > > > > .hsub = 2, .vsub = 2, .is_yuv = true},
> > > > > > > + { .format = DRM_FORMAT_NV12_10, .depth = 0,
> > > > > > > .num_planes
> > > > > = 2,
> > > > > > > + .char_per_block = { 5, 10, 0 }, .block_w = { 4, 4, 0 },
> > > > > .block_h = { 4, 4, 0 },
> > > > >
> > > > > > Hi Sandy:
> > > > > > Their is a problem here for char_per_block size of plane[0]:
> > > > > > Since: 5 * 8 != 4 * 4 * 10;
> > > > > > Seems you mis-set the block_w/h, per your block size
Re: [PATCH v2 2/4] drm/komeda: Add drm_lut_to_fgamma_coeffs()
On Friday, 11 October 2019 06:45:35 BST james qian wang (Arm Technology China)
wrote:
> This function is used to convert drm 3dlut to komeda HW required 1d curve
> coeffs values.
>
> Signed-off-by: james qian wang (Arm Technology China)
>
> ---
> .../arm/display/komeda/komeda_color_mgmt.c| 52 +++
> .../arm/display/komeda/komeda_color_mgmt.h| 9 +++-
> 2 files changed, 60 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> index 9d14a92dbb17..c180ce70c26c 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> @@ -65,3 +65,55 @@ const s32 *komeda_select_yuv2rgb_coeffs(u32
> color_encoding, u32 color_range)
>
> return coeffs;
> }
> +
> +struct gamma_curve_sector {
> + u32 boundary_start;
> + u32 num_of_segments;
> + u32 segment_width;
> +};
> +
> +struct gamma_curve_segment {
> + u32 start;
> + u32 end;
> +};
> +
> +static struct gamma_curve_sector sector_tbl[] = {
[bikeshed] I'd name this fgamma_sector_tbl (didn't the previous version
of this patch stack have an gamma_curve_sector for igamma?).
> + { 0,4, 4 },
> + { 16, 4, 4 },
> + { 32, 4, 8 },
> + { 64, 4, 16 },
> + { 128, 4, 32 },
> + { 256, 4, 64 },
> + { 512, 16, 32 },
> + { 1024, 24, 128 },
> +};
> +
> +static void
> +drm_lut_to_coeffs(struct drm_property_blob *lut_blob, u32 *coeffs,
> + struct gamma_curve_sector *sector_tbl, u32 num_sectors)
> +{
> + struct drm_color_lut *lut;
> + u32 i, j, in, num = 0;
> +
> + if (!lut_blob)
> + return;
> +
> + lut = lut_blob->data;
> +
> + for (i = 0; i < num_sectors; i++) {
> + for (j = 0; j < sector_tbl[i].num_of_segments; j++) {
> + in = sector_tbl[i].boundary_start +
> + j * sector_tbl[i].segment_width;
> +
> + coeffs[num++] = drm_color_lut_extract(lut[in].red,
> + KOMEDA_COLOR_PRECISION);
> + }
> + }
> +
> + coeffs[num] = BIT(KOMEDA_COLOR_PRECISION);
> +}
> +
> +void drm_lut_to_fgamma_coeffs(struct drm_property_blob *lut_blob, u32
> *coeffs)
> +{
> + drm_lut_to_coeffs(lut_blob, coeffs, sector_tbl, ARRAY_SIZE(sector_tbl));
> +}
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.h
> b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.h
> index a2df218f58e7..08ab69281648 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.h
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.h
> @@ -11,7 +11,14 @@
> #include
>
> #define KOMEDA_N_YUV2RGB_COEFFS 12
> +#define KOMEDA_N_RGB2YUV_COEFFS 12
> +#define KOMEDA_COLOR_PRECISION 12
> +#define KOMEDA_N_GAMMA_COEFFS65
> +#define KOMEDA_COLOR_LUT_SIZEBIT(KOMEDA_COLOR_PRECISION)
> +#define KOMEDA_N_CTM_COEFFS 9
[nit] The alignment with the group above seems a bit off.
> +
> +void drm_lut_to_fgamma_coeffs(struct drm_property_blob *lut_blob, u32
> *coeffs);
>
> const s32 *komeda_select_yuv2rgb_coeffs(u32 color_encoding, u32 color_range);
>
> -#endif
> +#endif /*_KOMEDA_COLOR_MGMT_H_*/
>
Reviewed-by: Mihail Atanassov
--
Mihail
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110361] [CI][DRMTIP] igt@kms_chamelium@hdmi-cmp-planes-random - fail - Failed assertion: false, Conversion not implemented
https://bugs.freedesktop.org/show_bug.cgi?id=110361 --- Comment #6 from CI Bug Log --- The CI Bug Log issue associated to this bug has been archived. New failures matching the above filters will not be associated to this bug anymore. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/4] drm: Add a new helper drm_color_ctm_s31_32_to_qm_n()
Hi James,
On Friday, 11 October 2019 06:45:27 BST james qian wang (Arm Technology China)
wrote:
> Add a new helper function drm_color_ctm_s31_32_to_qm_n() for driver to
> convert S31.32 sign-magnitude to Qm.n 2's complement that supported by
> hardware.
>
> Signed-off-by: james qian wang (Arm Technology China)
>
> ---
> drivers/gpu/drm/drm_color_mgmt.c | 23 +++
> include/drm/drm_color_mgmt.h | 2 ++
> 2 files changed, 25 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_color_mgmt.c
> b/drivers/gpu/drm/drm_color_mgmt.c
> index 4ce5c6d8de99..3d533d0b45af 100644
> --- a/drivers/gpu/drm/drm_color_mgmt.c
> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> @@ -132,6 +132,29 @@ uint32_t drm_color_lut_extract(uint32_t user_input,
> uint32_t bit_precision)
> }
> EXPORT_SYMBOL(drm_color_lut_extract);
>
> +/**
> + * drm_color_ctm_s31_32_to_qm_n
> + *
> + * @user_input: input value
> + * @m: number of integer bits
> + * @n: number of fractinal bits
> + *
> + * Convert and clamp S31.32 sign-magnitude to Qm.n 2's complement.
> + */
> +uint64_t drm_color_ctm_s31_32_to_qm_n(uint64_t user_input,
> + uint32_t m, uint32_t n)
> +{
> + u64 mag = (user_input & ~BIT_ULL(63)) >> (32 - n);
This doesn't account for n > 32, which is perfectly possible (e.g. Q1.63).
> + bool negative = !!(user_input & BIT_ULL(63));
> + s64 val;
> +
> + /* the range of signed 2s complement is [-2^n+m, 2^n+m - 1] */
> + val = clamp_val(mag, 0, negative ? BIT(n + m) : BIT(n + m) - 1);
This also doesn't account for n + m == 64.
> +
> + return negative ? 0ll - val : val;
> +}
> +EXPORT_SYMBOL(drm_color_ctm_s31_32_to_qm_n);
> +
> /**
> * drm_crtc_enable_color_mgmt - enable color management properties
> * @crtc: DRM CRTC
> diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> index d1c662d92ab7..60fea5501886 100644
> --- a/include/drm/drm_color_mgmt.h
> +++ b/include/drm/drm_color_mgmt.h
> @@ -30,6 +30,8 @@ struct drm_crtc;
> struct drm_plane;
>
> uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t bit_precision);
> +uint64_t drm_color_ctm_s31_32_to_qm_n(uint64_t user_input,
> + uint32_t m, uint32_t n);
>
> void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
> uint degamma_lut_size,
> --
> 2.20.1
>
--
Mihail
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V3 7/7] docs: sample driver to demonstrate how to implement virtio-mdev framework
This sample driver creates mdev device that simulate virtio net device
over virtio mdev transport. The device is implemented through vringh
and workqueue. A device specific dma ops is to make sure HVA is used
directly as the IOVA. This should be sufficient for kernel virtio
driver to work.
Only 'virtio' type is supported right now. I plan to add 'vhost' type
on top which requires some virtual IOMMU implemented in this sample
driver.
Signed-off-by: Jason Wang
---
MAINTAINERS| 1 +
samples/Kconfig| 7 +
samples/vfio-mdev/Makefile | 1 +
samples/vfio-mdev/mvnet.c | 691 +
4 files changed, 700 insertions(+)
create mode 100644 samples/vfio-mdev/mvnet.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 3d196a023b5e..cb51351cd5c9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17254,6 +17254,7 @@ F: include/linux/virtio*.h
F: include/uapi/linux/virtio_*.h
F: drivers/crypto/virtio/
F: mm/balloon_compaction.c
+F: samples/vfio-mdev/mvnet.c
VIRTIO BLOCK AND SCSI DRIVERS
M: "Michael S. Tsirkin"
diff --git a/samples/Kconfig b/samples/Kconfig
index c8dacb4dda80..a1a1ca2c00b7 100644
--- a/samples/Kconfig
+++ b/samples/Kconfig
@@ -131,6 +131,13 @@ config SAMPLE_VFIO_MDEV_MDPY
mediated device. It is a simple framebuffer and supports
the region display interface (VFIO_GFX_PLANE_TYPE_REGION).
+config SAMPLE_VIRTIO_MDEV_NET
+tristate "Build virtio mdev net example mediated device sample code --
loadable modules only"
+ depends on VIRTIO_MDEV_DEVICE && VHOST_RING && m
+ help
+ Build a networking sample device for use as a virtio
+ mediated device.
+
config SAMPLE_VFIO_MDEV_MDPY_FB
tristate "Build VFIO mdpy example guest fbdev driver -- loadable module
only"
depends on FB && m
diff --git a/samples/vfio-mdev/Makefile b/samples/vfio-mdev/Makefile
index 10d179c4fdeb..f34af90ed0a0 100644
--- a/samples/vfio-mdev/Makefile
+++ b/samples/vfio-mdev/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_SAMPLE_VFIO_MDEV_MTTY) += mtty.o
obj-$(CONFIG_SAMPLE_VFIO_MDEV_MDPY) += mdpy.o
obj-$(CONFIG_SAMPLE_VFIO_MDEV_MDPY_FB) += mdpy-fb.o
obj-$(CONFIG_SAMPLE_VFIO_MDEV_MBOCHS) += mbochs.o
+obj-$(CONFIG_SAMPLE_VIRTIO_MDEV_NET) += mvnet.o
diff --git a/samples/vfio-mdev/mvnet.c b/samples/vfio-mdev/mvnet.c
new file mode 100644
index ..b218e7075611
--- /dev/null
+++ b/samples/vfio-mdev/mvnet.c
@@ -0,0 +1,691 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Mediated virtual virtio-net device driver.
+ *
+ * Copyright (c) 2019, Red Hat Inc. All rights reserved.
+ * Author: Jason Wang
+ *
+ * Sample driver that creates mdev device that simulates ethernet loopback
+ * device.
+ *
+ * Usage:
+ *
+ * # modprobe virtio_mdev
+ * # modprobe mvnet
+ * # cd /sys/devices/virtual/mvnet/mvnet/mdev_supported_types/mvnet-virtio
+ * # echo "83b8f4f2-509f-382f-3c1e-e6bfe0fa1001" > ./create
+ * # cd devices/83b8f4f2-509f-382f-3c1e-e6bfe0fa1001
+ * # ls -d virtio0
+ * virtio0
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define VERSION_STRING "0.1"
+#define DRIVER_AUTHOR "Red Hat Corporation"
+
+#define MVNET_CLASS_NAME "mvnet"
+#define MVNET_NAME "mvnet"
+
+/*
+ * Global Structures
+ */
+
+static struct mvnet_dev {
+ struct class*vd_class;
+ struct idr vd_idr;
+ struct device dev;
+} mvnet_dev;
+
+struct mvnet_virtqueue {
+ struct vringh vring;
+ struct vringh_kiov iov;
+ unsigned short head;
+ bool ready;
+ u64 desc_addr;
+ u64 device_addr;
+ u64 driver_addr;
+ u32 num;
+ void *private;
+ irqreturn_t (*cb)(void *data);
+};
+
+#define MVNET_QUEUE_ALIGN PAGE_SIZE
+#define MVNET_QUEUE_MAX 256
+#define MVNET_DEVICE_ID 0x1
+#define MVNET_VENDOR_ID 0
+
+u64 mvnet_features = (1ULL << VIRTIO_F_ANY_LAYOUT) |
+(1ULL << VIRTIO_F_VERSION_1) |
+(1ULL << VIRTIO_F_IOMMU_PLATFORM);
+
+/* State of each mdev device */
+struct mvnet_state {
+ struct mvnet_virtqueue vqs[2];
+ struct work_struct work;
+ spinlock_t lock;
+ struct mdev_device *mdev;
+ struct virtio_net_config config;
+ void *buffer;
+ u32 status;
+ u32 generation;
+ u64 features;
+ struct list_head next;
+};
+
+static struct mutex mdev_list_lock;
+static struct list_head mdev_devices_list;
+
+static void mvnet_queue_ready(struct mvnet_state *mvnet, unsigned int idx)
+{
+ struct mvnet_virtqueue *vq = >vqs[idx];
+ int ret;
+
+ ret = vringh_init_kern(>vring, mvnet_features, MVNET_QUEUE_MAX,
+ false, (struct vring_desc *)vq->desc_addr,
+ (struct vring_avail *)vq->driver_addr,
+
[PATCH V3 6/7] virtio: introduce a mdev based transport
This patch introduces a new mdev transport for virtio. This is used to
use kernel virtio driver to drive the mediated device that is capable
of populating virtqueue directly.
A new virtio-mdev driver will be registered to the mdev bus, when a
new virtio-mdev device is probed, it will register the device with
mdev based config ops. This means it is a software transport between
mdev driver and mdev device. The transport was implemented through
device specific opswhich is a part of mdev_parent_ops now.
Signed-off-by: Jason Wang
---
drivers/virtio/Kconfig | 7 +
drivers/virtio/Makefile | 1 +
drivers/virtio/virtio_mdev.c | 416 +++
3 files changed, 424 insertions(+)
create mode 100644 drivers/virtio/virtio_mdev.c
diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 078615cf2afc..8d18722ab572 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -43,6 +43,13 @@ config VIRTIO_PCI_LEGACY
If unsure, say Y.
+config VIRTIO_MDEV_DEVICE
+ tristate "VIRTIO driver for Mediated devices"
+ depends on VFIO_MDEV && VIRTIO
+ default n
+ help
+ VIRTIO based driver for Mediated devices.
+
config VIRTIO_PMEM
tristate "Support for virtio pmem driver"
depends on VIRTIO
diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
index 3a2b5c5dcf46..ebc7fa15ae82 100644
--- a/drivers/virtio/Makefile
+++ b/drivers/virtio/Makefile
@@ -6,3 +6,4 @@ virtio_pci-y := virtio_pci_modern.o virtio_pci_common.o
virtio_pci-$(CONFIG_VIRTIO_PCI_LEGACY) += virtio_pci_legacy.o
obj-$(CONFIG_VIRTIO_BALLOON) += virtio_balloon.o
obj-$(CONFIG_VIRTIO_INPUT) += virtio_input.o
+obj-$(CONFIG_VIRTIO_MDEV_DEVICE) += virtio_mdev.o
diff --git a/drivers/virtio/virtio_mdev.c b/drivers/virtio/virtio_mdev.c
new file mode 100644
index ..8516f3f0f658
--- /dev/null
+++ b/drivers/virtio/virtio_mdev.c
@@ -0,0 +1,416 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * VIRTIO based driver for Mediated device
+ *
+ * Copyright (c) 2019, Red Hat. All rights reserved.
+ * Author: Jason Wang
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_VERSION "0.1"
+#define DRIVER_AUTHOR "Red Hat Corporation"
+#define DRIVER_DESC "VIRTIO based driver for Mediated device"
+
+#define to_virtio_mdev_device(dev) \
+ container_of(dev, struct virtio_mdev_device, vdev)
+
+struct virtio_mdev_device {
+ struct virtio_device vdev;
+ struct mdev_device *mdev;
+ unsigned long version;
+
+ struct virtqueue **vqs;
+ /* The lock to protect virtqueue list */
+ spinlock_t lock;
+ struct list_head virtqueues;
+};
+
+struct virtio_mdev_vq_info {
+ /* the actual virtqueue */
+ struct virtqueue *vq;
+
+ /* the list node for the virtqueues list */
+ struct list_head node;
+};
+
+static struct mdev_device *vm_get_mdev(struct virtio_device *vdev)
+{
+ struct virtio_mdev_device *vm_dev = to_virtio_mdev_device(vdev);
+ struct mdev_device *mdev = vm_dev->mdev;
+
+ return mdev;
+}
+
+static void virtio_mdev_get(struct virtio_device *vdev, unsigned offset,
+ void *buf, unsigned len)
+{
+ struct mdev_device *mdev = vm_get_mdev(vdev);
+ const struct virtio_mdev_device_ops *ops = mdev_get_dev_ops(mdev);
+
+ ops->get_config(mdev, offset, buf, len);
+}
+
+static void virtio_mdev_set(struct virtio_device *vdev, unsigned offset,
+ const void *buf, unsigned len)
+{
+ struct mdev_device *mdev = vm_get_mdev(vdev);
+ const struct virtio_mdev_device_ops *ops = mdev_get_dev_ops(mdev);
+
+ ops->set_config(mdev, offset, buf, len);
+}
+
+static u32 virtio_mdev_generation(struct virtio_device *vdev)
+{
+ struct mdev_device *mdev = vm_get_mdev(vdev);
+ const struct virtio_mdev_device_ops *ops = mdev_get_dev_ops(mdev);
+
+ return ops->get_generation(mdev);
+}
+
+static u8 virtio_mdev_get_status(struct virtio_device *vdev)
+{
+ struct mdev_device *mdev = vm_get_mdev(vdev);
+ const struct virtio_mdev_device_ops *ops = mdev_get_dev_ops(mdev);
+
+ return ops->get_status(mdev);
+}
+
+static void virtio_mdev_set_status(struct virtio_device *vdev, u8 status)
+{
+ struct mdev_device *mdev = vm_get_mdev(vdev);
+ const struct virtio_mdev_device_ops *ops = mdev_get_dev_ops(mdev);
+
+ return ops->set_status(mdev, status);
+}
+
+static void virtio_mdev_reset(struct virtio_device *vdev)
+{
+ struct mdev_device *mdev = vm_get_mdev(vdev);
+ const struct virtio_mdev_device_ops *ops = mdev_get_dev_ops(mdev);
+
+ return ops->set_status(mdev, 0);
+}
+
+static bool virtio_mdev_notify(struct virtqueue *vq)
+{
+ struct mdev_device *mdev = vm_get_mdev(vq->vdev);
+ const struct virtio_mdev_device_ops *ops = mdev_get_dev_ops(mdev);
