[Bug 109327] Wolfenstein II The New Colossus - black screen after the first cutscene of the game
https://bugs.freedesktop.org/show_bug.cgi?id=109327 Ahmed Elsayed changed: What|Removed |Added Summary|Wolfenstein II The New |Wolfenstein II The New |Colossus crashes after the |Colossus - black screen |first cutscene of the game |after the first cutscene of ||the game -- 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 109327] Wolfenstein II The New Colossus - black screen after the first cutscene of the game
https://bugs.freedesktop.org/show_bug.cgi?id=109327 --- Comment #2 from Ahmed Elsayed --- To be more accurate. The game doesn't crash. It stuck at black screen after skipping the first cutscene. -- 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 201273] Fatal error during GPU init amdgpu RX560
https://bugzilla.kernel.org/show_bug.cgi?id=201273 --- Comment #29 from quirin.blae...@freenet.de --- Bug is still alive. amd-staging-drm-next 9698024e8a191481321574bec1fe886bbce797cf -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/4] add missing of_node_puts
The device node iterators perform an of_node_get on each iteration, so a jump out of the loop requires an of_node_put. The patches for drivers/gpu/drm/imx/imx-ldb.c and drivers/gpu/drm/sun4i/sun4i_backend.c contain some added of_node_puts for which the need was identified manually. Details are in the patch logs. --- drivers/gpu/drm/imx/imx-ldb.c | 25 + drivers/gpu/drm/mediatek/mtk_drm_drv.c |5 - drivers/gpu/drm/rockchip/rockchip_rgb.c |4 +++- drivers/gpu/drm/sun4i/sun4i_backend.c |1 + 4 files changed, 25 insertions(+), 10 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm/imx: imx-ldb: add missing of_node_puts
The device node iterators perform an of_node_get on each
iteration, so a jump out of the loop requires an of_node_put.
Move the initialization channel->child = child; down to just
before the call to imx_ldb_register so that intervening failures
don't need to clear it. Add a label at the end of the function to
do all the of_node_puts.
The semantic patch that finds part of this problem is as follows
(http://coccinelle.lip6.fr):
//
@@
expression root,e;
local idexpression child;
iterator name for_each_child_of_node;
@@
for_each_child_of_node(root, child) {
... when != of_node_put(child)
when != e = child
(
return child;
|
* return ...;
)
...
}
//
Signed-off-by: Julia Lawall
---
This changes the semantics, with respect to the availability of the child
field, and has not been tested.
drivers/gpu/drm/imx/imx-ldb.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index 2c5bbe3..e31e263 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -643,8 +643,10 @@ static int imx_ldb_bind(struct device *dev, struct device
*master, void *data)
int bus_format;
ret = of_property_read_u32(child, "reg", &i);
- if (ret || i < 0 || i > 1)
- return -EINVAL;
+ if (ret || i < 0 || i > 1) {
+ ret = -EINVAL;
+ goto free_child;
+ }
if (!of_device_is_available(child))
continue;
@@ -657,7 +659,6 @@ static int imx_ldb_bind(struct device *dev, struct device
*master, void *data)
channel = &imx_ldb->channel[i];
channel->ldb = imx_ldb;
channel->chno = i;
- channel->child = child;
/*
* The output port is port@4 with an external 4-port mux or
@@ -667,13 +668,13 @@ static int imx_ldb_bind(struct device *dev, struct device
*master, void *data)
imx_ldb->lvds_mux ? 4 : 2, 0,
&channel->panel,
&channel->bridge);
if (ret && ret != -ENODEV)
- return ret;
+ goto free_child;
/* panel ddc only if there is no bridge */
if (!channel->bridge) {
ret = imx_ldb_panel_ddc(dev, channel, child);
if (ret)
- return ret;
+ goto free_child;
}
bus_format = of_get_bus_format(dev, child);
@@ -689,18 +690,26 @@ static int imx_ldb_bind(struct device *dev, struct device
*master, void *data)
if (bus_format < 0) {
dev_err(dev, "could not determine data mapping: %d\n",
bus_format);
- return bus_format;
+ ret = bus_format;
+ goto free_child;
}
channel->bus_format = bus_format;
+ channel->child = child;
ret = imx_ldb_register(drm, channel);
- if (ret)
- return ret;
+ if (ret) {
+ channel->child = NULL;
+ goto free_child;
+ }
}
dev_set_drvdata(dev, imx_ldb);
return 0;
+
+free_child:
+ of_node_put(child);
+ return ret;
}
static void imx_ldb_unbind(struct device *dev, struct device *master,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm/mediatek: add missing of_node_puts
The device node iterators perform an of_node_get on each iteration, so a
jump out of the loop requires an of_node_put.
The semantic patch that fixes this problem is as follows
(http://coccinelle.lip6.fr):
//
@@
local idexpression n;
expression e,e1;
identifier l;
@@
for_each_child_of_node(e1,n) {
...
(
of_node_put(n);
|
e = n
|
+ of_node_put(n);
? goto l;
)
...
}
...
l: ... when != n
//
Signed-off-by: Julia Lawall
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 6422e99..b9205bf 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -522,12 +522,15 @@ static int mtk_drm_probe(struct platform_device *pdev)
comp = devm_kzalloc(dev, sizeof(*comp), GFP_KERNEL);
if (!comp) {
ret = -ENOMEM;
+ of_node_put(node);
goto err_node;
}
ret = mtk_ddp_comp_init(dev, node, comp, comp_id, NULL);
- if (ret)
+ if (ret) {
+ of_node_put(node);
goto err_node;
+ }
private->ddp_comp[comp_id] = comp;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/sun4i: backend: add missing of_node_puts
The device node iterators perform an of_node_get on each
iteration, so a jump out of the loop requires an of_node_put.
Remote and port also have augmented reference counts, so drop them
on each iteration and at the end of the function, respectively.
Remote is only used for the address it contains, not for the
contents of that address, so the reference count can be dropped
immediately.
The semantic patch that fixes the first part of this problem is
as follows (http://coccinelle.lip6.fr):
//
@@
expression root,e;
local idexpression child;
iterator name for_each_child_of_node;
@@
for_each_available_child_of_node(root, child) {
... when != of_node_put(child)
when != e = child
+ of_node_put(child);
? break;
...
}
... when != child
//
Signed-off-by: Julia Lawall
---
Not tested.
drivers/gpu/drm/sun4i/sun4i_backend.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 9e9255e..a021bab 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -786,17 +786,18 @@ static struct sun4i_frontend
*sun4i_backend_find_frontend(struct sun4i_drv *drv,
remote = of_graph_get_remote_port_parent(ep);
if (!remote)
continue;
+ of_node_put(remote);
/* does this node match any registered engines? */
list_for_each_entry(frontend, &drv->frontend_list, list) {
if (remote == frontend->node) {
- of_node_put(remote);
of_node_put(port);
+ of_node_put(ep);
return frontend;
}
}
}
-
+ of_node_put(port);
return ERR_PTR(-EINVAL);
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm/rockchip: add missing of_node_put
The device node iterators perform an of_node_get on each iteration, so a
jump out of the loop requires an of_node_put.
The semantic patch that fixes this problem is as follows
(http://coccinelle.lip6.fr):
//
@@
expression root,e;
local idexpression child;
iterator name for_each_child_of_node;
@@
for_each_child_of_node(root, child) {
... when != of_node_put(child)
when != e = child
+ of_node_put(child);
? break;
...
}
... when != child
//
Signed-off-by: Julia Lawall
---
drivers/gpu/drm/rockchip/rockchip_rgb.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_rgb.c
b/drivers/gpu/drm/rockchip/rockchip_rgb.c
index 96ac145..37f9302 100644
--- a/drivers/gpu/drm/rockchip/rockchip_rgb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_rgb.c
@@ -113,8 +113,10 @@ struct rockchip_rgb *rockchip_rgb_init(struct device *dev,
child_count++;
ret = drm_of_find_panel_or_bridge(dev->of_node, 0, endpoint_id,
&panel, &bridge);
- if (!ret)
+ if (!ret) {
+ of_node_put(endpoint);
break;
+ }
}
of_node_put(port);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] add missing of_node_put
The result of of_graph_get_remote_port_parent needs an of_node_put, even if it is not available. --- drivers/gpu/drm/meson/meson_drv.c |9 +++-- drivers/gpu/drm/rcar-du/rcar_du_kms.c |1 + drivers/of/property.c |1 + 3 files changed, 9 insertions(+), 2 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm: rcar-du: add missing of_node_put
Add an of_node_put when the result of of_graph_get_remote_port_parent is not available. The semantic match that finds this problem is as follows (http://coccinelle.lip6.fr): // @r exists@ local idexpression e; expression x; @@ e = of_graph_get_remote_port_parent(...); ... when != x = e when != true e == NULL when != of_node_put(e) when != of_fwnode_handle(e) ( return e; | *return ...; ) // Signed-off-by: Julia Lawall --- drivers/gpu/drm/rcar-du/rcar_du_kms.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index 9c7007d..bc3fcb3 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c @@ -331,6 +331,7 @@ static int rcar_du_encoders_init_one(struct rcar_du_device *rcdu, dev_dbg(rcdu->dev, "connected entity %pOF is disabled, skipping\n", entity); + of_node_put(entity); return -ENODEV; } ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/meson: add missing of_node_put
Add an of_node_put when the result of of_graph_get_remote_port_parent is
not available.
An of_node_put is also needed when meson_probe_remote completes. This was
present at the recursive call, but not in the call from meson_drv_probe.
The semantic match that finds this problem is as follows
(http://coccinelle.lip6.fr):
//
@r exists@
local idexpression e;
expression x;
@@
e = of_graph_get_remote_port_parent(...);
... when != x = e
when != true e == NULL
when != of_node_put(e)
when != of_fwnode_handle(e)
(
return e;
|
*return ...;
)
//
Signed-off-by: Julia Lawall
---
drivers/gpu/drm/meson/meson_drv.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_drv.c
b/drivers/gpu/drm/meson/meson_drv.c
index 3ee4d4a4e..b59c757 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -388,8 +388,10 @@ static int meson_probe_remote(struct platform_device *pdev,
remote_node = of_graph_get_remote_port_parent(ep);
if (!remote_node ||
remote_node == parent || /* Ignore parent endpoint */
- !of_device_is_available(remote_node))
+ !of_device_is_available(remote_node)) {
+ of_node_put(remote_node);
continue;
+ }
count += meson_probe_remote(pdev, match, remote, remote_node);
@@ -408,10 +410,13 @@ static int meson_drv_probe(struct platform_device *pdev)
for_each_endpoint_of_node(np, ep) {
remote = of_graph_get_remote_port_parent(ep);
- if (!remote || !of_device_is_available(remote))
+ if (!remote || !of_device_is_available(remote)) {
+ of_node_put(remote);
continue;
+ }
count += meson_probe_remote(pdev, &match, np, remote);
+ of_node_put(remote);
}
if (count && !match)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109327] Wolfenstein II The New Colossus - black screen after the first cutscene of the game
https://bugs.freedesktop.org/show_bug.cgi?id=109327 Bas Nieuwenhuizen changed: What|Removed |Added QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Component|Drivers/Gallium/radeonsi|Drivers/Vulkan/radeon -- 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 109336] gma500_gfx misdetects LVDS-1 as connected causing black screen
https://bugs.freedesktop.org/show_bug.cgi?id=109336 Bug ID: 109336 Summary: gma500_gfx misdetects LVDS-1 as connected causing black screen Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: minor Priority: medium Component: DRM/other Assignee: dri-devel@lists.freedesktop.org Reporter: domi...@greysector.net On a Thecus N5550 NAS box (Intel Atom D2550/Cedarview platform), the gma500_gfx driver detects LVDS-1 output as connected (it's not): Jan 13 13:15:09 kernel: [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:36:LVDS-1] status updated from unknown to connected Only VGA-1 is connected, but that's detected correctly. This causes black screen after kernel loads the driver. Adding video=LVDS-1:d to the kernel command line works around the issue. The kernel version is 4.19.13-300.fc29.x86_64 (Fedora 29). Kernel output with drm.debug=0xe: Jan 13 13:15:08 kernel: [drm:psb_intel_opregion_setup [gma500_gfx]] Public ACPI methods supported Jan 13 13:15:08 kernel: [drm:psb_intel_opregion_setup [gma500_gfx]] ASLE supported Jan 13 13:15:08 kernel: [drm:psb_intel_init_bios [gma500_gfx]] Using VBT from OpRegion: $VBT CEDARVIEW d Jan 13 13:15:08 kernel: [drm:drm_mode_debug_printmodeline [drm]] Modeline 0:"1024x768" 0 65000 1024 1048 1184 1344 768 771 777 806 0x8 0xa Jan 13 13:15:08 kernel: [drm:psb_intel_init_bios [gma500_gfx]] No SDVO device info is found in VBT Jan 13 13:15:08 kernel: [drm:psb_intel_init_bios [gma500_gfx]] EDP timing in vbt t1_t3 2000 t8 10 t9 2000 t10 500 t11_t12 5000 Jan 13 13:15:08 kernel: [drm:psb_intel_init_bios [gma500_gfx]] VBT reports EDP: Lane_count 1, Lane_rate 6, Bpp 18 Jan 13 13:15:08 kernel: [drm:psb_intel_init_bios [gma500_gfx]] VBT reports EDP: VSwing 0, Preemph 0 Jan 13 13:15:08 kernel: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). Jan 13 13:15:08 kernel: [drm] No driver support for vblank timestamp query. Jan 13 13:15:08 kernel: [drm:drm_do_probe_ddc_edid [drm]] drm: skipping non-existent adapter intel drm LVDSDDC_C Jan 13 13:15:08 kernel: [drm:cdv_intel_dp_init [gma500_gfx]] i2c_init DPDDC-B Jan 13 13:15:08 kernel: [drm:cdv_intel_dp_aux_ch [gma500_gfx]] dp_aux_ch timeout status 0x51440064 Jan 13 13:15:08 kernel: [drm:cdv_intel_dp_i2c_aux_ch [gma500_gfx]] aux_ch failed -110 Jan 13 13:15:08 kernel: [drm:cdv_intel_dp_aux_ch [gma500_gfx]] dp_aux_ch timeout status 0x51440064 Jan 13 13:15:08 kernel: [drm:cdv_intel_dp_i2c_aux_ch [gma500_gfx]] aux_ch failed -110 Jan 13 13:15:08 kernel: [drm:drm_setup_crtcs [drm_kms_helper]] Jan 13 13:15:08 kernel: [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:34:VGA-1] Jan 13 13:15:08 kernel: [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:34:VGA-1] status updated from unknown to connected Jan 13 13:15:09 kernel: [drm:drm_add_display_info [drm]] non_desktop set to 0 Jan 13 13:15:09 kernel: [drm:drm_add_edid_modes [drm]] ELD: no CEA Extension found Jan 13 13:15:09 kernel: [drm:drm_add_display_info [drm]] non_desktop set to 0 Jan 13 13:15:09 kernel: [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:34:VGA-1] probed modes : Jan 13 13:15:09 kernel: [drm:drm_mode_debug_printmodeline [drm]] Modeline 46:"1920x1200" 60 154000 1920 1968 2000 2080 1200 1203 1209 1235 0x48 0x9 Jan 13 13:15:09 kernel: [drm:drm_mode_debug_printmodeline [drm]] Modeline 48:"1600x1200" 60 162000 1600 1664 1856 2160 1200 1201 1204 1250 0x40 0x5 Jan 13 13:15:09 kernel: [drm:drm_mode_debug_printmodeline [drm]] Modeline 50:"1680x1050" 60 146250 1680 1784 1960 2240 1050 1053 1059 1089 0x40 0x6 Jan 13 13:15:09 kernel: [drm:drm_mode_debug_printmodeline [drm]] Modeline 55:"1280x1024" 75 135000 1280 1296 1440 1688 1024 1025 1028 1066 0x40 0x5 Jan 13 13:15:09 kernel: [drm:drm_mode_debug_printmodeline [drm]] Modeline 47:"1280x1024" 60 108000 1280 1328 1440 1688 1024 1025 1028 1066 0x40 0x5 Jan 13 13:15:09 kernel: [drm:drm_mode_debug_printmodeline [drm]] Modeline 49:"1152x864" 75 108000 1152 1216 1344 1600 864 865 868 900 0x40 0x5 Jan 13 13:15:09 kernel: [drm:drm_mode_debug_printmodeline [drm]] Modeline 56:"1024x768" 75 78750 1024 1040 1136 1312 768 769 772 800 0x40 0x5 Jan 13 13:15:09 kernel: [drm:drm_mode_debug_printmodeline [drm]] Modeline 57:"1024x768" 60 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa Jan 13 13:15:09 kernel: [drm:drm_mode_debug_printmodeline [drm]] Modeline 58:"800x600" 75 49500 800 816 896 1056 600 601 604 625 0x40 0x5 Jan 13 13:15:09 kernel: [drm:drm_mode_debug_printmodeline [drm]] Modeline 51:"800x600" 60 4 800 840 968 1056 600 601 605 628 0x40 0x5 Jan 13 13:15:09 kernel: [drm:drm_mode_debug_printmodeline [drm]] Modeline 52:"640x480" 75 31500 640 656 720 840 480 481 484 500 0x40 0xa Jan 13 13:15:09 kernel: [drm:drm_mode_debug_printmodeline [drm]] Mode
[Bug 109331] Empire Total War - Graphical Corruption
https://bugs.freedesktop.org/show_bug.cgi?id=109331 --- Comment #2 from andrew.m.mcma...@gmail.com --- Created attachment 143084 --> https://bugs.freedesktop.org/attachment.cgi?id=143084&action=edit Xorg log -- 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 109331] Empire Total War - Graphical Corruption
https://bugs.freedesktop.org/show_bug.cgi?id=109331 --- Comment #4 from andrew.m.mcma...@gmail.com --- Created attachment 143086 --> https://bugs.freedesktop.org/attachment.cgi?id=143086&action=edit dmesg -w -- 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 109331] Empire Total War - Graphical Corruption
https://bugs.freedesktop.org/show_bug.cgi?id=109331 andrew.m.mcma...@gmail.com changed: What|Removed |Added Attachment #143084|0 |1 is obsolete|| --- Comment #3 from andrew.m.mcma...@gmail.com --- Created attachment 143085 --> https://bugs.freedesktop.org/attachment.cgi?id=143085&action=edit Xorg log -- 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 109331] Empire Total War - Graphical Corruption
https://bugs.freedesktop.org/show_bug.cgi?id=109331 --- Comment #5 from andrew.m.mcma...@gmail.com --- I've used apitrace (DEBUGGER="apitrace32 trace" steam steam://rungameid/10500) to capture some trace files. I'm able to replay them using apitrace replay [file] so I hope others are too. I've uploaded a 7z archive containing a "bugged" trace and a "workaround" trace with their corresponding terminal output: https://drive.google.com/file/d/1BAQFnrJqujU7dYGQTfheABTRjj-_a8Ys/view?usp=sharing By complete coincidence the archive happens to be 666MB. The bugged trace is several gigabytes in size whilst the workaround is a mere 90MB so there must be something funny happening there... -- 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 109338] hdmi/displayport audio is a semitone lower when amdgpu driver is used
https://bugs.freedesktop.org/show_bug.cgi?id=109338 Bug ID: 109338 Summary: hdmi/displayport audio is a semitone lower when amdgpu driver is used Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: thanosaposto...@outlook.com I have enabled amdgpu kernel driver for southern islands GPUs with kernel parameters `radeon.si_support=0 amdgpu.si_support=1`. When amdgpu is used, then the hdmi/displayport audio is a semitone lower. Audio works properly with radeon kernel driver. I uploaded a video in order to demonstrate the problem https://youtu.be/URhOlW5zCp0 Additional info: * linux kernel: 4.20 * GPU: Radeon HD 7750 * inxi info:https://pastebin.com/LeipSnQj -- 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 109331] Empire Total War - Graphical Corruption
https://bugs.freedesktop.org/show_bug.cgi?id=109331 --- Comment #6 from andrew.m.mcma...@gmail.com --- One last comment before I leave it to the experts. Another bug report with Unity 18.04: https://steamcommunity.com/app/10500/discussions/0/3441214221460524307/ If anyone wants to go above and beyond the call of duty then I've uploaded some traces for Medieval 2 here: https://drive.google.com/open?id=17LUb2EsS3oqYjEyZ-yxIB_C_DBnS0Wz8 I've used the same trick of disabling/enabling PBO surfaces. Finally what exactly are PBO surfaces? Do I need them? What's the penalty for not using them? The game seems to trace faster with them off than on. Are the Linux ports by Feral a bit wonky and/or prone to strange behaviour - or are they generally decent? -- 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 109182] [AMD][TAHITI XT] CSGO rendering artifact on dashboard human body
https://bugs.freedesktop.org/show_bug.cgi?id=109182 Sylvain BERTRAND changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Sylvain BERTRAND --- updated to latest git. rendering bug is 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
[Bug 105530] Stuttering on Raven Ridge when TearFree is on
https://bugs.freedesktop.org/show_bug.cgi?id=105530 --- Comment #19 from Tyson Tan --- I can confirm the screen stuttering with RX460 and RX550. It doesn't happen with R7 250E or Firepro W5100 which are GCN2 cards using radeon. Seems to be a Polaris/AMDGPU specific problem? This issue did not happen on Linux 4.14 if I recall correctly. Tested using Manjaro 18.0.2, Linux 4.20.1, Gnome 3.30, KDE Plasma 5.14. I'm using dual display, Dell U2417H via HDMI, Cintiq Pro 13 via Displayport. Stuttering happens even when U2417H is disabled using DE's control panel. amdgpu.dc=0 does not work for me. Anything I can do to help with the diagnose, please let me know. -- 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 109124] [AMD][TAHITI XT] csgo new battle royal mode bad performance
https://bugs.freedesktop.org/show_bug.cgi?id=109124 --- Comment #2 from Sylvain BERTRAND --- The actual main issue is while turning: since fps drops badly, it makes turning all blury, then makes it quite harder to spot anything. And in "open space" we turn all the time to check out if nobody is around (if you cannot know you are alone in your tile). I run the 3d engine at 1920x1080, video settings to minimal (native x11). I did investigate the update speed of my mouse, because I was suspicious, and I have above ~1000Hz update speed, using mouse-dpi-tool from libevdev. -- 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: [Bug 109124] [AMD][TAHITI XT] csgo new battle royal mode bad performance
The actual main issue is while turning: since fps drops badly, it makes turning all blury, then makes it quite harder to spot anything. And in "open space" we turn all the time to check out if nobody is around (if you cannot know you are alone in your tile). I run the 3d engine at 1920x1080, video settings to minimal (native x11). I did investigate the update speed of my mouse, because I was suspicious, and I have above ~1000Hz update speed, using mouse-dpi-tool from libevdev. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109331] Empire Total War - Graphical Corruption
https://bugs.freedesktop.org/show_bug.cgi?id=109331 --- Comment #7 from andrew.m.mcma...@gmail.com --- Created attachment 143088 --> https://bugs.freedesktop.org/attachment.cgi?id=143088&action=edit mesa-git glxinfo As a last ditch effort I thought I'd try the latest mesa/llvm that are provided by [llvm-git] and [mesa-git] unofficial repo's. Unfortunately the issue still occurs. -- 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 4/9] drm/rockchip/rockchip_drm_gem.c: Convert to use vm_insert_range
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
---
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 17 ++---
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index a8db758..c9e207f 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -221,26 +221,13 @@ static int rockchip_drm_gem_object_mmap_iommu(struct
drm_gem_object *obj,
struct vm_area_struct *vma)
{
struct rockchip_gem_object *rk_obj = to_rockchip_obj(obj);
- unsigned int i, count = obj->size >> PAGE_SHIFT;
+ unsigned int count = obj->size >> PAGE_SHIFT;
unsigned long user_count = vma_pages(vma);
- unsigned long uaddr = vma->vm_start;
- unsigned long offset = vma->vm_pgoff;
- unsigned long end = user_count + offset;
- int ret;
if (user_count == 0)
return -ENXIO;
- if (end > count)
- return -ENXIO;
- for (i = offset; i < end; i++) {
- ret = vm_insert_page(vma, uaddr, rk_obj->pages[i]);
- if (ret)
- return ret;
- uaddr += PAGE_SIZE;
- }
-
- return 0;
+ return vm_insert_range(vma, rk_obj->pages, count);
}
static int rockchip_drm_gem_object_mmap_dma(struct drm_gem_object *obj,
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/5] dt-bindings: display: bridge: lvds-transmitter: cleanup example
Drop #address-cells and #size-cells from the root node in the
example, they are unused.
Reviewed-by: Rob Herring
Signed-off-by: Peter Rosin
---
Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt | 2 --
1 file changed, 2 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
index bc6960741cb5..60091db5dfa5 100644
--- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
@@ -42,8 +42,6 @@ Example
lvds-encoder {
compatible = "lvds-encoder";
- #address-cells = <1>;
- #size-cells = <0>;
ports {
#address-cells = <1>;
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/atmel-hlcdc: do not immediately disable planes, wait for next frame
On 2019-01-10 20:25, Boris Brezillon wrote:
> On Thu, 10 Jan 2019 18:51:21 +
> Peter Rosin wrote:
>
>> On 2019-01-10 18:29, Boris Brezillon wrote:
>>> On Thu, 10 Jan 2019 15:10:48 +
>>> Peter Rosin wrote:
>>>
The A2Q and UPDATE bits have no effect in the channel disable registers.
However, since they are present, assume that the intention is to disable
planes, not immediately as indicated by the RST bit, but on the next
frame shift since that is what A2Q and UPDATE means in the channel enable
registers.
Disabling the plane on the next frame shift is done with the EN bit,
so use that.
>>>
>>> It's been a long time, but I think I had a good reason for forcing a
>>> reset. IIRC, when you don't do that and the CRTC is disabled before the
>>> plane, the EN bit stays around, and next time you queue a plane update,
>>> you'll start with an invalid buf pointer.
>>
>> It might be possible to clear the EN bit in ...CHDR before enabling the
>> plane in ...CHER. Or is that too late?
>
> I think I tried that, but I'm not sure (BTW, this change was done in
> bd4248bb5e8b ("drm: atmel-hlcdc: reset layer A2Q and UPDATE bits when
That patch is a big fat NOP if you read the documentation. Those bits
are marked with a '-' for all LCDC channel disable registers, for all
supported chips IIUC. Are the effects of those bits mentioned in any
errata?
It would be good with a comment that the present undocumented disable
method is intentional. That would have kept me from assuming the whole
thing was just copy-paste junk from ..._enable that happened to work.
>> disabling it")). Anyway, I'm not even sure this is still needed now
>> that atomic updates have a wait_for_flip_done/vblank() in the commit
>> path.
The documentation for the RST bit states "Resets the layer immediately.
The frame is aborted." which sounds a bit scary and heavy-handed. But
again, I don't know what that actually means and what the effects are
but that was the reason for me wanting to avoid the RST bit.
Cheers,
Peter
>> But this patch is not overly
>> important, I just wanted to avoid the resulting "black hole" when the
>> plane DMA is disabled mid-frame. But disabling planes is probably not
>> something that happens frequently and will perhaps not be noticed at
>> all...
>
> Okay. Other patches look good to me, I'm just waiting for Nicolas
> feedback before applying them.
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107296] WARNING: CPU: 0 PID: 370 at drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:1355 dcn_bw_update_from_pplib+0x16b/0x280 [amdgpu]
https://bugs.freedesktop.org/show_bug.cgi?id=107296 --- Comment #7 from Paul Menzel --- I am still getting this error with Linux 5.0-rc1+. [ 19.518149] WARNING: CPU: 2 PID: 359 at drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:1380 dcn_bw_update_from_pplib+0x158/0x 290 [amdgpu] -- 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 5/9] drm/xen/xen_drm_front_gem.c: Convert to use vm_insert_range
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
---
drivers/gpu/drm/xen/xen_drm_front_gem.c | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c
b/drivers/gpu/drm/xen/xen_drm_front_gem.c
index 47ff019..9990c2f 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
@@ -225,8 +225,7 @@ struct drm_gem_object *
static int gem_mmap_obj(struct xen_gem_object *xen_obj,
struct vm_area_struct *vma)
{
- unsigned long addr = vma->vm_start;
- int i;
+ int ret;
/*
* clear the VM_PFNMAP flag that was set by drm_gem_mmap(), and set the
@@ -247,18 +246,11 @@ static int gem_mmap_obj(struct xen_gem_object *xen_obj,
* FIXME: as we insert all the pages now then no .fault handler must
* be called, so don't provide one
*/
- for (i = 0; i < xen_obj->num_pages; i++) {
- int ret;
-
- ret = vm_insert_page(vma, addr, xen_obj->pages[i]);
- if (ret < 0) {
- DRM_ERROR("Failed to insert pages into vma: %d\n", ret);
- return ret;
- }
+ ret = vm_insert_range(vma, xen_obj->pages, xen_obj->num_pages);
+ if (ret < 0)
+ DRM_ERROR("Failed to insert pages into vma: %d\n", ret);
- addr += PAGE_SIZE;
- }
- return 0;
+ return ret;
}
int xen_drm_front_gem_mmap(struct file *filp, struct vm_area_struct *vma)
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/5] dt-bindings: display: bridge: fork out ti,ds90c185 from lvds-transmitter
DS90C185 has a shutdown pin which does not fit in the lvds-transmitter
binding, which is meant to be generic.
The sister chip DS90C187 is similar to DS90C185, describe it here as well.
Signed-off-by: Peter Rosin
---
.../bindings/display/bridge/lvds-transmitter.txt | 10 ++--
.../bindings/display/bridge/ti,ds90c185.txt| 55 ++
2 files changed, 59 insertions(+), 6 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt
diff --git
a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
index 50220190c203..bc6960741cb5 100644
--- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
@@ -22,13 +22,11 @@ among others.
Required properties:
-- compatible: Must be one or more of the following
- - "ti,ds90c185" for the TI DS90C185 FPD-Link Serializer
- - "lvds-encoder" for a generic LVDS encoder device
+- compatible: Must be "lvds-encoder"
- When compatible with the generic version, nodes must list the
- device-specific version corresponding to the device first
- followed by the generic version.
+ Any encoder compatible with this generic binding, but with additional
+ properties not listed here, must list a device specific compatible first
+ followed by this generic compatible.
Required nodes:
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt
b/Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt
new file mode 100644
index ..e575f996959a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt
@@ -0,0 +1,55 @@
+Texas Instruments FPD-Link (LVDS) Serializer
+
+
+The DS90C185 and DS90C187 are low-power serializers for portable
+battery-powered applications that reduces the size of the RGB
+interface between the host GPU and the display.
+
+Required properties:
+
+- compatible: Should be
+ "ti,ds90c185", "lvds-encoder" for the TI DS90C185 FPD-Link Serializer
+ "ti,ds90c187", "lvds-encoder" for the TI DS90C187 FPD-Link Serializer
+
+Optional properties:
+
+- powerdown-gpios: Power down control GPIO (the PDB pin, active-low)
+
+Required nodes:
+
+The devices have two video ports. Their connections are modeled using the OF
+graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 for parallel input
+- Video port 1 for LVDS output
+
+
+Example
+---
+
+lvds-encoder {
+ compatible = "ti,ds90c185", "lvds-encoder";
+
+ powerdown-gpios = <&gpio 17 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ lvds_enc_in: endpoint {
+ remote-endpoint = <&lcdc_out_rgb>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ lvds_enc_out: endpoint {
+ remote-endpoint = <&lvds_panel_in>;
+ };
+ };
+ };
+};
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/5] drm/bridge: various small lvds-encoder things
Hi! I'm not sure if I should have added the texas chips to the lvds_encoder_match list in the driver, right next to the thine,thc63lvdm83d entry, but ended up not doing that. That can always be added later, if needed... Changes since v3: - retained a (modified) note in lvds-transmitter.txt about encoders with additional device-specific properties - added tag from Rob on patch 3/5 Changes since v2: - changed from pwdn-gpios to powerdown-gpios after discussion with Rob with new patch 3/5 updating the thine,thc63lvdm83d binding as well as a consequence - added patch 4/5 which helps keep lines shorter in the lvds-encoder driver - added tag from Rob on patch 2/5 Changes since v1: - fork out the bindings for the texas chips into their own file in order to avoid clutter in the generic lvds-transmitter binding. - added a patch to remove some surplus stuff in the generic lvds-transmitter binding. Cheers, Peter Peter Rosin (5): dt-bindings: display: bridge: fork out ti,ds90c185 from lvds-transmitter dt-bindings: display: bridge: lvds-transmitter: cleanup example dt-bindings: display: bridge: thc63lvdm83d: use standard powerdown-gpios drm/bridge: lvds-encoder: add dev helper variable in .probe() drm/bridge: lvds-encoder: add powerdown-gpios support .../bindings/display/bridge/lvds-transmitter.txt | 12 ++--- .../bindings/display/bridge/thine,thc63lvdm83d.txt | 2 +- .../bindings/display/bridge/ti,ds90c185.txt| 55 ++ drivers/gpu/drm/bridge/lvds-encoder.c | 53 + 4 files changed, 103 insertions(+), 19 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] lib/scatterlist: Provide a DMA page iterator
On Sat, Jan 12, 2019 at 12:27:05PM -0600, Shiraz Saleem wrote:
> On Fri, Jan 04, 2019 at 10:35:43PM +, Jason Gunthorpe wrote:
> > Commit 2db76d7c3c6d ("lib/scatterlist: sg_page_iter: support sg lists w/o
> > backing pages") introduced the sg_page_iter_dma_address() function without
> > providing a way to use it in the general case. If the sg_dma_len is not
> > equal to the dma_length callers cannot safely use the
> > for_each_sg_page/sg_page_iter_dma_address combination.
> >
> > Resolve this API mistake by providing a DMA specific iterator,
> > for_each_sg_dma_page(), that uses the right length so
> > sg_page_iter_dma_address() works as expected with all sglists. A new
> > iterator type is introduced to provide compile-time safety against wrongly
> > mixing accessors and iterators.
> [..]
>
> >
> > +/*
> > + * sg page iterator for DMA addresses
> > + *
> > + * This is the same as sg_page_iter however you can call
> > + * sg_page_iter_dma_address(@dma_iter) to get the page's DMA
> > + * address. sg_page_iter_page() cannot be called on this iterator.
> > + */
> Does it make sense to have a variant of sg_page_iter_page() to get the
> page descriptor with this dma_iter? This can be used when walking DMA-mapped
> SG lists with for_each_sg_dma_page.
I think that would be a complicated cacluation to find the right
offset into the page sg list to get the page pointer back. We can't
just naively use the existing iterator location.
Probably places that need this are better to run with two iterators,
less computationally expensive.
Did you find a need for this?
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/5] dt-bindings: display: bridge: thc63lvdm83d: use standard powerdown-gpios
The name powerdown-gpios is the standard property name for the functionality covered by the previous pwdn-gpios name. This rename should be safe to do since the linux driver supporting the binding (lvds-encoder.c) never implemented the property, and no dts file names it. At least not upstream. Reviewed-by: Rob Herring Signed-off-by: Peter Rosin --- Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt index 527e236e9a2a..fee3c88e1a17 100644 --- a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt +++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt @@ -10,7 +10,7 @@ Required properties: Optional properties: -- pwdn-gpios: Power down control GPIO +- powerdown-gpios: Power down control GPIO (the /PWDN pin, active low). Required nodes: -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Aw: Re: Re: [PATCH] drm/mediatek: Add MTK Framebuffer-Device (mt7623)
like Daniel guessed, fb-console does not work with this Patch. i tried your Patch (additional patch for headerfile): https://github.com/frank-w/BPI-R2-4.14/commits/4.20-fbdev and R2 hangs (no crash and no further boot) [5.435075] mediatek-drm 1400.dispsys: bound 14012000.rdma (ops mtk_disp) [5.435134] mediatek-drm 1400.dispsys: bound 14014000.dpi (ops mtk_dpi_c) [5.459277] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [5.465863] [drm] No driver support for vblank timestamp query. [5.472331] [drm] Initialized mediatek 1.0.0 20150513 for 1400.dispsys o0 my monitor is switched on, but no outputwe had added fbdev-driver to get FB-console over hdmi, so it's currently useless regards Frank ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] drm/atmel-hlcdc: do not swap w/h of the crtc when a plane is rotated
On 11/01/2019 at 14:29, Peter Rosin wrote:
> On 2019-01-10 18:48, Boris Brezillon wrote:
>> On Thu, 10 Jan 2019 15:10:39 +
>> Peter Rosin wrote:
>>
>>> The destination crtc rectangle is independent of source plane rotation.
>>>
>>> Signed-off-by: Peter Rosin
>>> ---
>>> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 3 ---
>>> 1 file changed, 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
>>> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
>>> index ea8fc0deb814..d6f93f029020 100644
>>> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
>>> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
>>> @@ -642,9 +642,6 @@ 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->crtc_w;
>>> - state->crtc_w = state->crtc_h;
>>> - state->crtc_h = tmp;
>>
>> Again, I guess I assumed ->crtc_h/w were the width and height before
>> rotation when I initially added rotation support.
>
> And I thought so too, possibly since I have only been doing drm-stuff
> with this driver, but I also suspect that the incompleteness of the
> libdrm modetest program is to blame. I don't think it's possible to
> specify individual src and dst rectangles with it, and that seems
> rather limiting when dealing with rotated planes. I can easily see
> why someone using modetest thinks the crtc rect should be rotated by
> the driver...
>
>> This change might break users too.
>
> Right you are, and the same impossible scenario. Fix things to do the
> right thing and risk breaking users, or don't and preserve the buggy
> non-portable issues of the driver making it unusable for others.
I understand that we are the only ones to be different here. My
colleague Josh also helped me grasp the implications of this issue.
I would say that we mustn't be different. So please consider fixing
this. Some users might have started something with rotations but we'll
make sure to help them with the issue encountered and our additional DRM
libraries (like libplanes) can be fixed easily to make this change
transparent.
> I don't care either way, because rotating planes with this stride-
> method is practically useless here. It simply requires to much
> memory bandwidth. I might work ok for smaller panels with lower
> pixel clock frequencies though?
Rotation works for our use cases.
> I think the LCDC might read the same
> data more than once when data is not in the "natural" order? (no,
> I do not need an answer to this question, and I do not have time to
> dig in this area at the moment...)
>
> However, if you can't do both patch 1 and 2 (because users regress),
> then patch 3 is no good either. The reason is that
> drm_atomic_helper_check_plane_state assumes the rotational
> properties fixed by patch 1 and 2, and the behavior is "odd" if you
> have that wrong.
Thanks for continuing the discussion Boris and thanks to Peter for this
work. You have my opinion: please go-on with the fix.
Best regards,
Nicolas
>>> tmp = state->src_w;
>>> state->src_w = state->src_h;
>>> state->src_h = tmp;
>>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
Nicolas Ferre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] drm/atmel-hlcdc: fix plane clipping/rotation issues
On 2019-01-10 21:16, Sam Ravnborg wrote: > Hi Peter. > > (Hijacking this thread as I lost the orginal mails) Assuming you wanted to reply to this patch? https://patchwork.kernel.org/patch/10753571/ >>> I found an unfortunate issue while recoding plane handling to use >>> drm_atomic_helper_check_plane_state(). The driver rotates clockwise, >>> which is not correct. I simply fixed it (patch 1/4), but maybe that >>> will cause regressions for unsuspecting users who simply assumed >>> that the clockwise rotation was correct? I don't know what to do >>> about that? Adding an option to get the old broken behavior seems >>> useless, wouldn't it be just as easy to just fix whatever app to >>> rotate the other way instead of adding an option somewhere? >> >> Hm, rotation support has been added before the standard rotation >> property was created, and at that time I assumed rotation was clockwise >> (which apparently was an unwise choice). Anyway, I don't have a >> solution for this problem, so I'll let Nicolas decide if it's >> acceptable to change the rotation behavior. >> >>> I have only tested this series on sama5d3, but I did check the docs >>> for various other chips (sama5d2, sama5d4, sam9n12, sam9g15, sam9g35 >>> and sam9x35) supported by the driver (relevant to patch 4/4). > > I wonder if, when this code path is anyway touched, could benefit > from drm_rect_rotate(). > > It is obviously not a simple replacement, but could it be used then > I hope the resulting code is simpler. What are you referring to that goes beyond what is done in patch 3/4 in this series? After setting up the strides, the only use of src_[xywh] are to calculate the scaling factors, and for that the position is irrelevant. I.e. src_x and src_y are not used. Sure, in some theoretical sense it might be good if src_[xy] are also transformed into the rotated coordinate system along with src_[wh], but it seems a bit backwards to switch over to struct drm_rect when the interesting properties are the width and height, not the coordinates of the corners. No strong feelings on the issue though... Cheers, Peter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] drm/atmel-hlcdc: fix plane clipping/rotation issues
On 10/01/2019 at 18:45, Boris Brezillon wrote: > On Thu, 10 Jan 2019 15:10:28 + > Peter Rosin wrote: > >> Hi! >> >> I found an unfortunate issue while recoding plane handling to use >> drm_atomic_helper_check_plane_state(). The driver rotates clockwise, >> which is not correct. I simply fixed it (patch 1/4), but maybe that >> will cause regressions for unsuspecting users who simply assumed >> that the clockwise rotation was correct? I don't know what to do >> about that? Adding an option to get the old broken behavior seems >> useless, wouldn't it be just as easy to just fix whatever app to >> rotate the other way instead of adding an option somewhere? > > Hm, rotation support has been added before the standard rotation > property was created, and at that time I assumed rotation was clockwise > (which apparently was an unwise choice). Anyway, I don't have a > solution for this problem, so I'll let Nicolas decide if it's > acceptable to change the rotation behavior. Yes, being consistent with standard DRM sub-system is far more important in my opinion. Best regards, Nicolas >> I have only tested this series on sama5d3, but I did check the docs >> for various other chips (sama5d2, sama5d4, sam9n12, sam9g15, sam9g35 >> and sam9x35) supported by the driver (relevant to patch 4/4). > > Thanks for addressing those problems. > >> >> Cheers, >> Peter >> >> Peter Rosin (4): >>drm/atmel-hlcdc: rotate planes counterclockwise >>drm/atmel-hlcdc: do not swap w/h of the crtc when a plane is rotated >>drm/atmel-hlcdc: fix clipping of planes >>drm/atmel-hlcdc: do not immediately disable planes, wait for next >> frame >> >> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 179 >> +--- >> 1 file changed, 67 insertions(+), 112 deletions(-) >> > > -- Nicolas Ferre ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 4/5] drm/bridge: lvds-encoder: add dev helper variable in .probe()
Make the code easier to read and modify.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/bridge/lvds-encoder.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c
b/drivers/gpu/drm/bridge/lvds-encoder.c
index 75b0d3f6e4de..f6770e83d49d 100644
--- a/drivers/gpu/drm/bridge/lvds-encoder.c
+++ b/drivers/gpu/drm/bridge/lvds-encoder.c
@@ -34,48 +34,47 @@ static struct drm_bridge_funcs funcs = {
static int lvds_encoder_probe(struct platform_device *pdev)
{
+ struct device *dev = &pdev->dev;
struct device_node *port;
struct device_node *endpoint;
struct device_node *panel_node;
struct drm_panel *panel;
struct lvds_encoder *lvds_encoder;
- lvds_encoder = devm_kzalloc(&pdev->dev, sizeof(*lvds_encoder),
- GFP_KERNEL);
+ lvds_encoder = devm_kzalloc(dev, sizeof(*lvds_encoder), GFP_KERNEL);
if (!lvds_encoder)
return -ENOMEM;
/* Locate the panel DT node. */
- port = of_graph_get_port_by_id(pdev->dev.of_node, 1);
+ port = of_graph_get_port_by_id(dev->of_node, 1);
if (!port) {
- dev_dbg(&pdev->dev, "port 1 not found\n");
+ dev_dbg(dev, "port 1 not found\n");
return -ENXIO;
}
endpoint = of_get_child_by_name(port, "endpoint");
of_node_put(port);
if (!endpoint) {
- dev_dbg(&pdev->dev, "no endpoint for port 1\n");
+ dev_dbg(dev, "no endpoint for port 1\n");
return -ENXIO;
}
panel_node = of_graph_get_remote_port_parent(endpoint);
of_node_put(endpoint);
if (!panel_node) {
- dev_dbg(&pdev->dev, "no remote endpoint for port 1\n");
+ dev_dbg(dev, "no remote endpoint for port 1\n");
return -ENXIO;
}
panel = of_drm_find_panel(panel_node);
of_node_put(panel_node);
if (!panel) {
- dev_dbg(&pdev->dev, "panel not found, deferring probe\n");
+ dev_dbg(dev, "panel not found, deferring probe\n");
return -EPROBE_DEFER;
}
lvds_encoder->panel_bridge =
- devm_drm_panel_bridge_add(&pdev->dev,
- panel, DRM_MODE_CONNECTOR_LVDS);
+ devm_drm_panel_bridge_add(dev, panel, DRM_MODE_CONNECTOR_LVDS);
if (IS_ERR(lvds_encoder->panel_bridge))
return PTR_ERR(lvds_encoder->panel_bridge);
@@ -83,7 +82,7 @@ static int lvds_encoder_probe(struct platform_device *pdev)
* but we need a bridge attached to our of_node for our user
* to look up.
*/
- lvds_encoder->bridge.of_node = pdev->dev.of_node;
+ lvds_encoder->bridge.of_node = dev->of_node;
lvds_encoder->bridge.funcs = &funcs;
drm_bridge_add(&lvds_encoder->bridge);
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 5/5] drm/bridge: lvds-encoder: add powerdown-gpios support
Optionally power down the LVDS-encoder when it is not in use.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/bridge/lvds-encoder.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c
b/drivers/gpu/drm/bridge/lvds-encoder.c
index f6770e83d49d..36d8557bc097 100644
--- a/drivers/gpu/drm/bridge/lvds-encoder.c
+++ b/drivers/gpu/drm/bridge/lvds-encoder.c
@@ -11,11 +11,13 @@
#include
#include
+#include
#include
struct lvds_encoder {
struct drm_bridge bridge;
struct drm_bridge *panel_bridge;
+ struct gpio_desc *powerdown_gpio;
};
static int lvds_encoder_attach(struct drm_bridge *bridge)
@@ -28,8 +30,30 @@ static int lvds_encoder_attach(struct drm_bridge *bridge)
bridge);
}
+static void lvds_encoder_enable(struct drm_bridge *bridge)
+{
+ struct lvds_encoder *lvds_encoder = container_of(bridge,
+struct lvds_encoder,
+bridge);
+
+ if (lvds_encoder->powerdown_gpio)
+ gpiod_set_value_cansleep(lvds_encoder->powerdown_gpio, 0);
+}
+
+static void lvds_encoder_disable(struct drm_bridge *bridge)
+{
+ struct lvds_encoder *lvds_encoder = container_of(bridge,
+struct lvds_encoder,
+bridge);
+
+ if (lvds_encoder->powerdown_gpio)
+ gpiod_set_value_cansleep(lvds_encoder->powerdown_gpio, 1);
+}
+
static struct drm_bridge_funcs funcs = {
.attach = lvds_encoder_attach,
+ .enable = lvds_encoder_enable,
+ .disable = lvds_encoder_disable,
};
static int lvds_encoder_probe(struct platform_device *pdev)
@@ -45,6 +69,16 @@ static int lvds_encoder_probe(struct platform_device *pdev)
if (!lvds_encoder)
return -ENOMEM;
+ lvds_encoder->powerdown_gpio = devm_gpiod_get_optional(dev, "powerdown",
+ GPIOD_OUT_HIGH);
+ if (IS_ERR(lvds_encoder->powerdown_gpio)) {
+ int err = PTR_ERR(lvds_encoder->powerdown_gpio);
+
+ if (err != -EPROBE_DEFER)
+ dev_err(dev, "powerdown GPIO failure: %d\n", err);
+ return err;
+ }
+
/* Locate the panel DT node. */
port = of_graph_get_port_by_id(dev->of_node, 1);
if (!port) {
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [BUG] virtio-gpu hung when booting ARM64 virtual machine
Sorry for that I missed typing 'd' in the email addreslist. On 2019/1/10 20:52, Zheng Xiang wrote: > Hi all, > > Recently I encountered a problem that virtio-gpu driver would have a very low > chance of getting hung > when I boot VM from linux kernel 4.19 on ARM64 server by using qemu. The > dmesg log shows bellow: > > [ 242.782731] INFO: task systemd:1 blocked for more than 120 seconds. > [ 242.782738] Tainted: GE 4.19.5-1.2.32.aarch64 #1 > [ 242.782739] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > disables this message. > [ 242.782743] systemd D0 1 0 0x > [ 242.782748] Call trace: > [ 242.782767] __switch_to+0x94/0xd8 > [ 242.782779] __schedule+0x228/0x8a8 > [ 242.782782] schedule+0x2c/0x88 > [ 242.782785] schedule_timeout+0x234/0x470 > [ 242.782787] __down+0x88/0x108 > [ 242.782792] down+0x88/0xa0 > [ 242.782798] console_lock+0x24/0x48 > [ 242.782799] console_device+0x1c/0x88 > [ 242.782806] tty_lookup_driver+0xa8/0x128 > [ 242.782808] tty_open+0x1f4/0x418 > [ 242.782813] chrdev_open+0xd4/0x248 > [ 242.782816] do_dentry_open+0x1b0/0x380 > [ 242.782818] vfs_open+0x38/0x48 > [ 242.782822] do_last+0x294/0xf58 > [ 242.782824] path_openat+0x88/0x2a0 > [ 242.782827] do_filp_open+0x88/0x108 > [ 242.782829] do_sys_open+0x1a8/0x238 > [ 242.782831] __arm64_sys_openat+0x2c/0x38 > [ 242.782834] el0_svc_common+0x78/0x100 > [ 242.782836] el0_svc_handler+0x38/0x88 > [ 242.782839] el0_svc+0x8/0xc > [ 242.782850] INFO: task kworker/0:1:13 blocked for more than 120 > seconds. > [ 242.782851] Tainted: GE 4.19.5-1.2.32.aarch64 #1 > [ 242.782853] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > disables this message. > [ 242.782855] kworker/0:1 D013 2 0x0028 > [ 242.782872] Workqueue: events drm_fb_helper_dirty_work > [ 242.782875] Call trace: > [ 242.782877] __switch_to+0x94/0xd8 > [ 242.782880] __schedule+0x228/0x8a8 > [ 242.782882] schedule+0x2c/0x88 > [ 242.782902] virtio_gpu_queue_ctrl_buffer_locked+0x12c/0x220 > [virtio_gpu] > [ 242.782906] virtio_gpu_queue_ctrl_buffer+0x58/0x80 [virtio_gpu] > [ 242.782911] virtio_gpu_cmd_resource_flush+0x8c/0xb0 [virtio_gpu] > [ 242.782915] virtio_gpu_surface_dirty+0x60/0x110 [virtio_gpu] > [ 242.782920] virtio_gpu_framebuffer_surface_dirty+0x34/0x48 > [virtio_gpu] > [ 242.782922] drm_fb_helper_dirty_work+0x170/0x1b0 > [ 242.782928] process_one_work+0x1f4/0x458 > [ 242.782930] worker_thread+0x50/0x4c8 > [ 242.782932] kthread+0x134/0x138 > [ 242.782934] ret_from_fork+0x10/0x1c > [ 242.782946] INFO: task kworker/1:1:34 blocked for more than 120 > seconds. > [ 242.782948] Tainted: GE 4.19.5-1.2.32.aarch64 #1 > [ 242.782949] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > disables this message. > [ 242.782950] kworker/1:1 D034 2 0x0028 > [ 242.782960] Workqueue: events virtio_gpu_fb_dirty_work [virtio_gpu] > [ 242.782963] Call trace: > [ 242.782965] __switch_to+0x94/0xd8 > [ 242.782967] __schedule+0x228/0x8a8 > [ 242.782969] schedule+0x2c/0x88 > [ 242.782974] virtio_gpu_queue_fenced_ctrl_buffer+0x12c/0x160 > [virtio_gpu] > [ 242.782978] virtio_gpu_cmd_transfer_to_host_2d+0xa4/0xd0 [virtio_gpu] > [ 242.782981] virtio_gpu_dirty_update+0x184/0x200 [virtio_gpu] > [ 242.782986] virtio_gpu_fb_dirty_work+0x3c/0x48 [virtio_gpu] > [ 242.782988] process_one_work+0x1f4/0x458 > [ 242.782990] worker_thread+0x50/0x4c8 > [ 242.782991] kthread+0x134/0x138 > [ 242.782993] ret_from_fork+0x10/0x1c > [ 242.783033] INFO: task kworker/0:3:3706 blocked for more than 120 > seconds. > [ 242.783034] Tainted: GE 4.19.5-1.2.32.aarch64 #1 > [ 242.783035] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > disables this message. > [ 242.783037] kworker/0:3 D0 3706 2 0x0028 > [ 242.783046] Workqueue: events console_callback > [ 242.783048] Call trace: > [ 242.783050] __switch_to+0x94/0xd8 > [ 242.783053] __schedule+0x228/0x8a8 > [ 242.783055] schedule+0x2c/0x88 > [ 242.783057] schedule_timeout+0x234/0x470 > [ 242.783059] __down+0x88/0x108 > [ 242.783061] down+0x88/0xa0 > [ 242.783063] console_lock+0x24/0x48 > [ 242.783065] console_callback+0x40/0x198 > [ 242.783067] process_one_work+0x1f4/0x458 > [ 242.783068] worker_thread+0x50/0x4c8 > [ 242.783070] kthread+0x134/0x138 > [ 242.783072] ret_from_fork+0x10/0x1c > [ 242.783075] INFO: task kworker/u8:6:4901 blocked for more than 120 > seconds. > [ 242.783077] Tainted: GE 4.19.5-1.2.32.
[PATCH 0/9] Use vm_insert_range and vm_insert_range_buggy
Previouly drivers have their own way of mapping range of kernel pages/memory into user vma and this was done by invoking vm_insert_page() within a loop. As this pattern is common across different drivers, it can be generalized by creating new functions and use it across the drivers. vm_insert_range() is the API which could be used to mapped kernel memory/pages in drivers which has considered vm_pgoff vm_insert_range_buggy() is the API which could be used to map range of kernel memory/pages in drivers which has not considered vm_pgoff. vm_pgoff is passed default as 0 for those drivers. We _could_ then at a later "fix" these drivers which are using vm_insert_range_buggy() to behave according to the normal vm_pgoff offsetting simply by removing the _buggy suffix on the function name and if that causes regressions, it gives us an easy way to revert. There is an existing bug in [7/9], where user passed length is not verified against object_count. For any value of length > object_count it will end up overrun page array which could lead to a potential bug. This is fixed as part of these conversion. Souptick Joarder (9): mm: Introduce new vm_insert_range and vm_insert_range_buggy API arch/arm/mm/dma-mapping.c: Convert to use vm_insert_range drivers/firewire/core-iso.c: Convert to use vm_insert_range_buggy drm/rockchip/rockchip_drm_gem.c: Convert to use vm_insert_range drm/xen/xen_drm_front_gem.c: Convert to use vm_insert_range iommu/dma-iommu.c: Convert to use vm_insert_range videobuf2/videobuf2-dma-sg.c: Convert to use vm_insert_range_buggy xen/gntdev.c: Convert to use vm_insert_range xen/privcmd-buf.c: Convert to use vm_insert_range_buggy arch/arm/mm/dma-mapping.c | 22 ++ drivers/firewire/core-iso.c | 15 + drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 17 + drivers/gpu/drm/xen/xen_drm_front_gem.c | 18 ++--- drivers/iommu/dma-iommu.c | 12 +--- drivers/media/common/videobuf2/videobuf2-dma-sg.c | 22 ++ drivers/xen/gntdev.c | 16 ++--- drivers/xen/privcmd-buf.c | 8 +-- include/linux/mm.h| 4 ++ mm/memory.c | 81 +++ mm/nommu.c| 14 11 files changed, 129 insertions(+), 100 deletions(-) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] MAINTAINERS: unify reference to xen-devel list
In the linux kernel MAINTAINERS file, largely "xen-de...@lists.xenproject.org (moderated for non-subscribers)" is used to refer to the xen-devel mailing list. The DRM DRIVERS FOR XEN section entry mentions xen-de...@lists.xen.org instead, but that is just the same mailing list as the mailing list above. Signed-off-by: Lukas Bulwahn --- Juergen, please include this in the xen tree. MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 14b991ebf2c1..d9d088e0677f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5179,11 +5179,11 @@ F: include/drm/tinydrm/ DRM DRIVERS FOR XEN M: Oleksandr Andrushchenko T: git git://anongit.freedesktop.org/drm/drm-misc L: dri-devel@lists.freedesktop.org -L: xen-de...@lists.xen.org +L: xen-de...@lists.xenproject.org (moderated for non-subscribers) S: Supported F: drivers/gpu/drm/xen/ F: Documentation/gpu/xen-front.rst DRM TTM SUBSYSTEM -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/9] mm: Introduce new vm_insert_range and vm_insert_range_buggy API
Previouly drivers have their own way of mapping range of
kernel pages/memory into user vma and this was done by
invoking vm_insert_page() within a loop.
As this pattern is common across different drivers, it can
be generalized by creating new functions and use it across
the drivers.
vm_insert_range() is the API which could be used to mapped
kernel memory/pages in drivers which has considered vm_pgoff
vm_insert_range_buggy() is the API which could be used to map
range of kernel memory/pages in drivers which has not considered
vm_pgoff. vm_pgoff is passed default as 0 for those drivers.
We _could_ then at a later "fix" these drivers which are using
vm_insert_range_buggy() to behave according to the normal vm_pgoff
offsetting simply by removing the _buggy suffix on the function
name and if that causes regressions, it gives us an easy way to revert.
Signed-off-by: Souptick Joarder
Suggested-by: Russell King
Suggested-by: Matthew Wilcox
---
include/linux/mm.h | 4 +++
mm/memory.c| 81 ++
mm/nommu.c | 14 ++
3 files changed, 99 insertions(+)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 5411de9..9d1dff6 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2514,6 +2514,10 @@ unsigned long change_prot_numa(struct vm_area_struct
*vma,
int remap_pfn_range(struct vm_area_struct *, unsigned long addr,
unsigned long pfn, unsigned long size, pgprot_t);
int vm_insert_page(struct vm_area_struct *, unsigned long addr, struct page *);
+int vm_insert_range(struct vm_area_struct *vma, struct page **pages,
+ unsigned long num);
+int vm_insert_range_buggy(struct vm_area_struct *vma, struct page **pages,
+ unsigned long num);
vm_fault_t vmf_insert_pfn(struct vm_area_struct *vma, unsigned long addr,
unsigned long pfn);
vm_fault_t vmf_insert_pfn_prot(struct vm_area_struct *vma, unsigned long addr,
diff --git a/mm/memory.c b/mm/memory.c
index 4ad2d29..00e66df 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1520,6 +1520,87 @@ int vm_insert_page(struct vm_area_struct *vma, unsigned
long addr,
}
EXPORT_SYMBOL(vm_insert_page);
+/**
+ * __vm_insert_range - insert range of kernel pages into user vma
+ * @vma: user vma to map to
+ * @pages: pointer to array of source kernel pages
+ * @num: number of pages in page array
+ * @offset: user's requested vm_pgoff
+ *
+ * This allows drivers to insert range of kernel pages they've allocated
+ * into a user vma.
+ *
+ * If we fail to insert any page into the vma, the function will return
+ * immediately leaving any previously inserted pages present. Callers
+ * from the mmap handler may immediately return the error as their caller
+ * will destroy the vma, removing any successfully inserted pages. Other
+ * callers should make their own arrangements for calling unmap_region().
+ *
+ * Context: Process context.
+ * Return: 0 on success and error code otherwise.
+ */
+static int __vm_insert_range(struct vm_area_struct *vma, struct page **pages,
+ unsigned long num, unsigned long offset)
+{
+ unsigned long count = vma_pages(vma);
+ unsigned long uaddr = vma->vm_start;
+ int ret, i;
+
+ /* Fail if the user requested offset is beyond the end of the object */
+ if (offset > num)
+ return -ENXIO;
+
+ /* Fail if the user requested size exceeds available object size */
+ if (count > num - offset)
+ return -ENXIO;
+
+ for (i = 0; i < count; i++) {
+ ret = vm_insert_page(vma, uaddr, pages[offset + i]);
+ if (ret < 0)
+ return ret;
+ uaddr += PAGE_SIZE;
+ }
+
+ return 0;
+}
+
+/**
+ * vm_insert_range - insert range of kernel pages starts with non zero offset
+ * @vma: user vma to map to
+ * @pages: pointer to array of source kernel pages
+ * @num: number of pages in page array
+ *
+ * Maps an object consisting of `num' `pages', catering for the user's
+ * requested vm_pgoff
+ *
+ * Context: Process context. Called by mmap handlers.
+ * Return: 0 on success and error code otherwise.
+ */
+int vm_insert_range(struct vm_area_struct *vma, struct page **pages,
+ unsigned long num)
+{
+ return __vm_insert_range(vma, pages, num, vma->vm_pgoff);
+}
+EXPORT_SYMBOL(vm_insert_range);
+
+/**
+ * vm_insert_range_buggy - insert range of kernel pages starts with zero offset
+ * @vma: user vma to map to
+ * @pages: pointer to array of source kernel pages
+ * @num: number of pages in page array
+ *
+ * Maps a set of pages, always starting at page[0]
+ *
+ * Context: Process context. Called by mmap handlers.
+ * Return: 0 on success and error code otherwise.
+ */
+int vm_insert_range_buggy(struct vm_area_struct *vma, struct page **pages,
+ unsigned long num)
+{
Re: [PATCH 2/4] drm/atmel-hlcdc: do not swap w/h of the crtc when a plane is rotated
On 2019-01-10 18:48, Boris Brezillon wrote:
> On Thu, 10 Jan 2019 15:10:39 +
> Peter Rosin wrote:
>
>> The destination crtc rectangle is independent of source plane rotation.
>>
>> Signed-off-by: Peter Rosin
>> ---
>> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 3 ---
>> 1 file changed, 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
>> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
>> index ea8fc0deb814..d6f93f029020 100644
>> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
>> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
>> @@ -642,9 +642,6 @@ 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->crtc_w;
>> -state->crtc_w = state->crtc_h;
>> -state->crtc_h = tmp;
>
> Again, I guess I assumed ->crtc_h/w were the width and height before
> rotation when I initially added rotation support.
And I thought so too, possibly since I have only been doing drm-stuff
with this driver, but I also suspect that the incompleteness of the
libdrm modetest program is to blame. I don't think it's possible to
specify individual src and dst rectangles with it, and that seems
rather limiting when dealing with rotated planes. I can easily see
why someone using modetest thinks the crtc rect should be rotated by
the driver...
> This change might break users too.
Right you are, and the same impossible scenario. Fix things to do the
right thing and risk breaking users, or don't and preserve the buggy
non-portable issues of the driver making it unusable for others.
I don't care either way, because rotating planes with this stride-
method is practically useless here. It simply requires to much
memory bandwidth. I might work ok for smaller panels with lower
pixel clock frequencies though? I think the LCDC might read the same
data more than once when data is not in the "natural" order? (no,
I do not need an answer to this question, and I do not have time to
dig in this area at the moment...)
However, if you can't do both patch 1 and 2 (because users regress),
then patch 3 is no good either. The reason is that
drm_atomic_helper_check_plane_state assumes the rotational
properties fixed by patch 1 and 2, and the behavior is "odd" if you
have that wrong.
Cheers,
Peter
>> tmp = state->src_w;
>> state->src_w = state->src_h;
>> state->src_h = tmp;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm/rockchip: add missing of_node_put
Am Sonntag, 13. Januar 2019, 09:47:43 CET schrieb Julia Lawall:
> The device node iterators perform an of_node_get on each iteration, so a
> jump out of the loop requires an of_node_put.
>
> The semantic patch that fixes this problem is as follows
> (http://coccinelle.lip6.fr):
>
> //
> @@
> expression root,e;
> local idexpression child;
> iterator name for_each_child_of_node;
> @@
>
> for_each_child_of_node(root, child) {
>... when != of_node_put(child)
>when != e = child
> + of_node_put(child);
> ? break;
>...
> }
> ... when != child
> //
>
> Signed-off-by: Julia Lawall
I've added a fixes+stable tag and applied it to drm-misc-fixes
Thanks for catching that
Heiko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 200695] Blank screen on RX 580 with amdgpu.dc=1 enabled (no displays detected)
https://bugzilla.kernel.org/show_bug.cgi?id=200695 Claude Heiland-Allen (cla...@mathr.co.uk) changed: What|Removed |Added Kernel Version|4.17.19, 4.18.5 through |4.17.19, 4.18.5 through |4.18.20, 4.19-rc1 through |4.18.20, 4.19-rc1 through |4.19.6, 4.20-rc1 through|4.19.15, 4.20-rc1 through |4.20-rc5|4.20.2, 5.0-rc1 --- Comment #24 from Claude Heiland-Allen (cla...@mathr.co.uk) --- still an issue in 4.19.15 4.20.2 5.0-rc1 (I didn't check intermediate versions since comment 21 above https://bugzilla.kernel.org/show_bug.cgi?id=200695#c21 ) [drm] Cannot find any crtc or sizes followed by screen going blank, monitor turning off, no display detected -- 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 109124] [AMD][TAHITI XT] csgo new battle royal mode bad performance
https://bugs.freedesktop.org/show_bug.cgi?id=109124 --- Comment #3 from Sylvain BERTRAND --- You can increase significantly the performance issue while taking some height: climb to the top of the "water station", turn to look anywhere, the fps drops below 30fps. Seems to be significantly linked to the 3d engine performance. -- 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: [Bug 109124] [AMD][TAHITI XT] csgo new battle royal mode bad performance
You can increase significantly the performance issue while taking some height: climb to the top of the "water station", turn to look anywhere, the fps drops below 30fps. Seems to be significantly linked to the 3d engine performance. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/drm_vblank: Change EINVAL by the correct errno
Hi, I resend this patch for CI via “intel-...@lists.freedesktop.org” as Daniel suggested, and I got a feedback that reported an issue as can be seen here: https://patchwork.freedesktop.org/series/51147/ After a careful analysis of what happened, I concluded that the problem is related to the function “igt_wait_for_vblank_count()” in “igt_kms.c”. This function has the following assert: igt_assert(drmWaitVBlank(drm_fd, &wait_vbl) == 0) This function only checks if everything went well with the drmWaitVBlank() operation and does not make any other validation. IMHO the patch is correct, and the problem pointed out by CI is not related to this change. Make sense? Best Regards On 10/17, Daniel Vetter wrote: > On Wed, Oct 17, 2018 at 2:43 PM Rodrigo Siqueira > wrote: > > > > Hi, > > > > First of all, thanks to all for the reviewers and feedbacks. > > > > On 10/16, Daniel Vetter wrote: > > > On Mon, Oct 15, 2018 at 02:05:29PM -0300, Rodrigo Siqueira wrote: > > > > For historical reason, the function drm_wait_vblank_ioctl always return > > > > -EINVAL if something gets wrong. This scenario limits the flexibility > > > > for the userspace make detailed verification of the problem and take > > > > some action. In particular, the validation of “if (!dev->irq_enabled)” > > > > in the drm_wait_vblank_ioctl is responsible for checking if the driver > > > > support vblank or not. If the driver does not support VBlank, the > > > > function drm_wait_vblank_ioctl returns EINVAL which does not represent > > > > the real issue; this patch changes this behavior by return EOPNOTSUPP. > > > > Additionally, some operations are unsupported by this function, and > > > > returns EINVAL; this patch also changes the return value to EOPNOTSUPP > > > > in this case. Lastly, the function drm_wait_vblank_ioctl is invoked by > > > > libdrm, which is used by many compositors; because of this, it is > > > > important to check if this change breaks any compositor. In this sense, > > > > the following projects were examined: > > > > > > > > * Drm-hwcomposer > > > > * Kwin > > > > * Sway > > > > * Wlroots > > > > * Wayland-core > > > > * Weston > > > > * Xorg (67 different drivers) > > > > > > > > For each repository the verification happened in three steps: > > > > > > > > * Update the main branch > > > > * Look for any occurrence "drmWaitVBlank" with the command: > > > > git grep -n "drmWaitVBlank" > > > > * Look in the git history of the project with the command: > > > > git log -SdrmWaitVBlank > > > > > > > > Finally, none of the above projects validate the use of EINVAL which > > > > make safe, at least for these projects, to change the return values. > > > > > > > > Change since V1: > > > > Daniel Vetter and Chris Wilson > > > > - Replace ENOTTY by EOPNOTSUPP > > > > - Return EINVAL if the parameters are wrong > > > > > > > > Signed-off-by: Rodrigo Siqueira > > > > > > Reviewed-by: Daniel Vetter > > > > > > Can you pls also let intel-gfx-ci test this patch? You just need to > > > include intel-...@lists.freedesktop.org in your recipient list. > > > > I did know about intel-gfx-ci, really nice:) > > > > Should I CC this mailing list if I send patches to the DRM core, amdgpu, > > i915, vc4, vgem, and virtio-gpu? I suppose that IGT is running on the > > CI, right? > > It's only intel gpus (well and one special amd one) running igt on a > _lot_ of different machines. > > > Another question, do I need to send a V3 with intel-gfx-ci? > > If the patch-set is unchanged people use the "FOR CI" subject prefix > when resending, instead of incrementing the version number. > > > > For merging, since you plan to stick around doing kms stuff a bit: Want > > > commit rights for drm-misc? > > > > > > https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html > > > > Yes, I want :) > > I will need some guidance, in the beginning, to get confident about the > > processes. If you can help me with this, I will be glad to play around > > with 'dim' and the merging tasks. > > Sure, just ping me on irc. First you need a freedesktop.org ssh account: > > https://www.freedesktop.org/wiki/AccountRequests/ > > You need to request access to the drm-misc group. Once you have the > bugzilla, pls ping me so I can ack it. > > Thanks, Daniel > > > > > Best Regards > > > > > Cheers, Daniel > > > > > > > --- > > > > drivers/gpu/drm/drm_vblank.c | 4 ++-- > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c > > > > index 98e091175921..80f5a3bb427e 100644 > > > > --- a/drivers/gpu/drm/drm_vblank.c > > > > +++ b/drivers/gpu/drm/drm_vblank.c > > > > @@ -1533,10 +1533,10 @@ int drm_wait_vblank_ioctl(struct drm_device > > > > *dev, void *data, > > > > unsigned int flags, pipe, high_pipe; > > > > > > > > if (!dev->irq_enabled) > > > > - return -EINVAL; > > > > + return -EOPNOTSUPP; > > > > > > > > if (vblwait->req
[RESEND] MAINTAINERS: Add entry for VKMS
Add maintainers and reviewers for VKMS driver Signed-off-by: Rodrigo Siqueira --- Changes in v2: - Insert the section in alphabetical order Resend: - Update patch due to changes in MAINTAINER file MAINTAINERS | 10 ++ 1 file changed, 10 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 163c8f76a1c8..6e1cef2f21d9 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4925,6 +4925,16 @@ S: Odd Fixes F: drivers/gpu/drm/udl/ T: git git://anongit.freedesktop.org/drm/drm-misc +DRM DRIVER FOR VIRTUAL KERNEL MODESETTING (VKMS) +M: Rodrigo Siqueira +R: Haneen Mohammed +R: Daniel Vetter +T: git git://anongit.freedesktop.org/drm/drm-misc +S: Maintained +L: dri-devel@lists.freedesktop.org +F: drivers/gpu/drm/vkms/ +F: Documentation/gpu/vkms.rst + DRM DRIVER FOR VMWARE VIRTUAL GPU M: "VMware Graphics" M: Thomas Hellstrom -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm: Fix A6XX support for opp-level
Hi Douglas,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robclark/msm-next]
[also build test ERROR on v5.0-rc1 next-20190111]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Douglas-Anderson/drm-msm-Fix-A6XX-support-for-opp-level/20190114-004951
base: git://people.freedesktop.org/~robclark/linux msm-next
config: arm-defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm
All errors (new ones prefixed by >>):
drivers/gpu/drm/msm/adreno/a6xx_gmu.c: In function 'a6xx_gmu_get_arc_level':
>> drivers/gpu/drm/msm/adreno/a6xx_gmu.c:964:8: error: implicit declaration of
>> function 'dev_pm_opp_get_level'; did you mean 'dev_pm_opp_get_freq'?
>> [-Werror=implicit-function-declaration]
val = dev_pm_opp_get_level(opp);
^~~~
dev_pm_opp_get_freq
cc1: some warnings being treated as errors
vim +964 drivers/gpu/drm/msm/adreno/a6xx_gmu.c
949
950 /* Return the 'arc-level' for the given frequency */
951 static unsigned int a6xx_gmu_get_arc_level(struct device *dev,
952 unsigned long freq)
953 {
954 struct dev_pm_opp *opp;
955 unsigned int val;
956
957 if (!freq)
958 return 0;
959
960 opp = dev_pm_opp_find_freq_exact(dev, freq, true);
961 if (IS_ERR(opp))
962 return 0;
963
> 964 val = dev_pm_opp_get_level(opp);
965
966 dev_pm_opp_put(opp);
967
968 return val;
969 }
970
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] drm/tinydrm: Use damage helper for dirtyfb
On 1/11/19 2:12 PM, Noralf Trønnes wrote: This switches to drm_atomic_helper_dirtyfb() as the framebuffer dirty handler. All flushing will now happen in the pipe functions. Also enable the damage plane property for all except repaper which can only do full updates. ili9225: This change made ili9225_init() equal to mipi_dbi_init() so use it. v2: Remove fb check in mipi_dbi_enable_flush() it can't be NULL (kbuild test robot) Cc: David Lechner Cc: Eric Anholt Signed-off-by: Noralf Trønnes Acked-by: Sam Ravnborg Acked-by: Daniel Vetter --- Tested-by: David Lechner Reviewed-by: David Lechner Tested with ST7586 on LEGO MINDSTORMS EV3 and ILI9225 on BeagleBone Green. (FWIW, I encounter other issues that had to be fixed to make things work on both of these, but none were actually related to this series.) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109336] gma500_gfx misdetects LVDS-1 as connected causing black screen
https://bugs.freedesktop.org/show_bug.cgi?id=109336 --- Comment #1 from Dominik 'Rathann' Mierzejewski --- Downstream (Fedora) bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1665766 . -- 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 109340] HDMI output (DisplayPort-0) stops listing modes after using docking station DP output
https://bugs.freedesktop.org/show_bug.cgi?id=109340 Bug ID: 109340 Summary: HDMI output (DisplayPort-0) stops listing modes after using docking station DP output Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: zaj...@gmail.com Created attachment 143092 --> https://bugs.freedesktop.org/attachment.cgi?id=143092&action=edit dmesg I use following setup: 1) HP EliteBook 745 G5 with Ryzen 5 PRO 2500U 2) Docking station HP HSTNN-I11X 3) Monitor BenQ GW2260 (HDMI and no DisplayPort) 4) openSUSE Tumbleweed 5) Self compiled kernel 4.20-rc3 from amd-staging-drm-next with patches: drm/amd/display: Include names of all PP clock types x86/MCE/AMD: Fix the thresholding machinery initialization order My problem is that I can't use notebook's HDMI port (visible as DisplayPort-0) after using DisplayPort output of docking station. HDMI detects monitor & gets EDID but xrandr doesn't list any modes. After booting without docking station & connecting monitor using HDMI port: DisplayPort-0 connected (normal left inverted right x axis y axis) 1920x1080 60.00 + 50.0059.94 1680x1050 59.88 1600x900 60.00 1280x1024 60.02 1440x900 60.00 1280x800 59.91 1280x720 60.0050.0059.94 1024x768 60.00 800x600 60.32 720x576 50.00 720x480 60.0059.94 640x480 60.0059.94 After connecting docking station & monitor using DP port + HDMI adapter: [drm] DM_MST: starting TM on aconnector: 651bd996 [id: 57] [drm] DM_MST: added connector: e1b7686d [id: 90] [master: 651bd996] [drm] DM_MST: added connector: 78869ed2 [id: 94] [master: 651bd996] [drm] DM_MST: added connector: af4e5879 [id: 98] [master: 651bd996] [drm] amdgpu_dm_irq_schedule_work FAILED src 8 [drm] amdgpu_dm_irq_schedule_work FAILED src 8 [drm] amdgpu_dm_irq_schedule_work FAILED src 8 After disconnecting monitor & docking station: [drm] DM_MST: stopping TM on aconnector: 651bd996 [id: 57] [drm] DM_MST: Disabling connector: e1b7686d [id: 90] [master: 651bd996] [drm] DM_MST: Disabling connector: 78869ed2 [id: 94] [master: 651bd996] [drm] DM_MST: Disabling connector: af4e5879 [id: 98] [master: 651bd996] After connecting monitor using HDMI port: xrandr: Output DisplayPort-0 is not disconnected but has no modes (...) DisplayPort-0 connected (normal left inverted right x axis y axis) It's a bit weird since HDMI port (DisplayPort-0) seems to detect monitor being connected & can get EDID. Is there some bug with enumerating available models caused by DM_MST / TM? -- 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 109340] HDMI output (DisplayPort-0) stops listing modes after using docking station DP output
https://bugs.freedesktop.org/show_bug.cgi?id=109340 --- Comment #1 from Rafał Miłecki --- Created attachment 143093 --> https://bugs.freedesktop.org/attachment.cgi?id=143093&action=edit Detailed logs of all connecting/disconnecting operations -- 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 109340] HDMI output (DisplayPort-0) stops listing modes after using docking station DP output
https://bugs.freedesktop.org/show_bug.cgi?id=109340 --- Comment #2 from Rafał Miłecki --- I've noticed that: 1) After connecting monitor to the docking station's DP output following outputs appear: DisplayPort-3, DisplayPort-4 and DisplayPort-5. 2) After disconnecting monitor from docking stating I can see: [drm] DM_MST: stopping TM on aconnector: 651bd996 [id: 57] [drm] DM_MST: Disabling connector: e1b7686d [id: 90] [master: 651bd996] [drm] DM_MST: Disabling connector: 78869ed2 [id: 94] [master: 651bd996] [drm] DM_MST: Disabling connector: af4e5879 [id: 98] [master: 651bd996] 3) After disconnecting whole docking station I can still see DisplayPort-3, DisplayPort-4 and DisplayPort-5 in the "xrandr" output. Is that expected? Is that a possible hint for some problem with output management that also causes the original problem? -- 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 109234] amdgpu random hangs with 5.0-rc2/4.21+
https://bugs.freedesktop.org/show_bug.cgi?id=109234 Sibren Vasse changed: What|Removed |Added Summary|amdgpu random hangs with|amdgpu random hangs with |5.0-rc1/4.21+ |5.0-rc2/4.21+ -- 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 107978] [amdgpu] Switching to tty fails with DisplayPort 1.2 monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)
https://bugs.freedesktop.org/show_bug.cgi?id=107978 --- Comment #41 from Shmerl --- Same thing still happen with 5.0-rc2. Does anyone else experience this race condition when the monitor goes to sleep right after boot? It is related to the same setup (DisplayPort 1.2), since it's not happening with it disabled. -- 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/mediatek: Add MTK Framebuffer-Device (mt7623)
On Fri, 2019-01-11 at 17:07 +0100, Noralf Trønnes wrote:
>
> Den 11.01.2019 11.25, skrev Daniel Vetter:
> > On Fri, Jan 11, 2019 at 05:49:15PM +0800, CK Hu wrote:
> >> Hi, Daniel:
> >>
> >> On Fri, 2019-01-11 at 10:20 +0100, Daniel Vetter wrote:
> >>> On Fri, Jan 11, 2019 at 11:20:09AM +0800, CK Hu wrote:
> Hi, Daniel:
>
> On Thu, 2019-01-10 at 21:02 +0100, Daniel Vetter wrote:
> > On Thu, Jan 10, 2019 at 08:01:37PM +0100, Frank Wunderlich wrote:
> >> Hi Daniel,
> >>
> Would be good to use the new generic fbdev emulation code here, for
> even
> less code. Or at least know why this isn't possible to use for mtk
> (and
> maybe address that in the core code). Hand-rolling fbdev code
> shouldn't be
> needed anymore.
> >>>
> >>> Back on the mailing list, no private replies please:
> >>
> >> i don't wanted to spam all people with dumb questions ;)
> >
> > There's no dumb questions, only insufficient documentation :-)
> >
> >>> For examples please grep for drm_fbdev_generic_setup(). There's also a
> >>> still in-flight series from Gerd Hoffmann to convert over bochs. That,
> >>> plus all the kerneldoc linked from there should get you started.
> >>> -Daniel
> >>
> >> this is one of google best founds if i search for
> >> drm_fbdev_generic_setup:
> >>
> >> https://lkml.org/lkml/2018/12/19/305
> >>
> >> not very helpful...
> >>
> >> so i tried kernel-doc
> >>
> >> https://www.kernel.org/doc/html/latest/gpu/drm-kms-helpers.html?highlight=drm_fbdev_generic_setup#c.drm_fbdev_generic_setup
> >>
> >> which is nice function-reference but i've found no generic workflow
> >>
> >> as the posted driver is "only" a driver ported from kernel 4.4 by
> >> Alexander, i don't know if this new framework can be used and which
> >> parts need to be changed. I only try to bring his code Mainline
> >> Maybe CK Hu can help here because driver is originally from him and he
> >> knows internals. Or maybe you can help here?
> >>
> >> i personally make my first steps as spare-time kernel-developer :)
> >
> > There's a ton of in-kernel users of that function already, I meant you
> > can
> > use those to serve as examples ... If those + the kerneldoc aren't
> > good enough, then we need to improve them.
> > -Daniel
>
> I've tried with drm_fbdev_generic_setup() and it works fine with simple
> modification. The patch is
>
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -379,6 +380,7 @@ static void mtk_drm_kms_deinit(struct drm_device
> *drm)
> .gem_prime_get_sg_table = mtk_gem_prime_get_sg_table,
> .gem_prime_import_sg_table = mtk_gem_prime_import_sg_table,
> .gem_prime_mmap = mtk_drm_gem_mmap_buf,
> + .gem_prime_vmap = mtk_drm_gem_prime_vmap,
> .ioctls = mtk_ioctls,
> .num_ioctls = ARRAY_SIZE(mtk_ioctls),
> .fops = &mtk_drm_fops,
> @@ -416,6 +418,8 @@ static int mtk_drm_bind(struct device *dev)
> if (ret < 0)
> goto err_deinit;
>
> + drm_fbdev_generic_setup(drm, 32);
> +
> return 0;
>
>
> But I implement .gem_prime_vmap with a workaround,
>
>
> --- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> @@ -280,3 +280,8 @@ int mtk_gem_create_ioctl(struct drm_device *dev,
> void *data,
> mtk_drm_gem_free_object(&mtk_gem->base);
> return ret;
> }
> +
> +void *mtk_drm_gem_prime_vmap(struct drm_gem_object *obj)
> +{
> + return (void *)1;
> +}
>
> Current drm_fb_helper depends on drm_client to create fbdev. When
> drm_client create drm_client_buffer, it need to vmap to get kernel
> vaddr. But I think for fbdev, the vaddr is useless. Do you agree that I
> temporarily implement .gem_prime_vmap in such way?
> >>>
> >>> The vmap is used by fbcon, without that fbdev won't really work I think.
> >>> So I'm rather confused on what you tested ...
> >>>
> >>> Adding Noralf, he's the expert here.
> >>> -Daniel
> >>
> >> I test with fb_test [1], it is a user space program just open /dev/fb0
> >> and mmap it to user space. I does not turn on fbcon so everything looks
> >> well. If support fbcon is essential, I would implement vmap correctly.
> >> If it's not essential, I think I could return 0 when
> >> CONFIG_FRAMBUFFER_CONSOLE is defined.
> >
> > I think fbdev emulation without working fbcon is fairly useless. And it
> > shouldn't be that much work
Re: [PATCH v2 4/5] drm/tinydrm: Use damage helper for dirtyfb
On 1/13/19 3:19 PM, David Lechner wrote: On 1/11/19 2:12 PM, Noralf Trønnes wrote: This switches to drm_atomic_helper_dirtyfb() as the framebuffer dirty handler. All flushing will now happen in the pipe functions. Also enable the damage plane property for all except repaper which can only do full updates. ili9225: This change made ili9225_init() equal to mipi_dbi_init() so use it. v2: Remove fb check in mipi_dbi_enable_flush() it can't be NULL (kbuild test robot) Cc: David Lechner Cc: Eric Anholt Signed-off-by: Noralf Trønnes Acked-by: Sam Ravnborg Acked-by: Daniel Vetter --- Tested-by: David Lechner Reviewed-by: David Lechner Tested with ST7586 on LEGO MINDSTORMS EV3 and ILI9225 on BeagleBone Green. (FWIW, I encounter other issues that had to be fixed to make things work on both of these, but none were actually related to this series.) Actually, I have to take this back. It appears that the problems that I had on LEGO MINDSTORMS EV3 are actually caused by this series. I did a git bisect to be sure and ended up with this patch as the bad commit. I'm guessing that the damage helper must be causing some kind of memory corruption. Here is the crash I am getting: Unable to handle kernel NULL pointer dereference at virtual address 0004 pgd = (ptrval) [0004] *pgd= Internal error: Oops: 5 [#1] PREEMPT ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 5.0.0-rc1-00125-ge9acadba5409 #1389 Hardware name: Generic DA850/OMAP-L138/AM18x PC is at rb_insert_color+0x1c/0x1a4 LR is at kernfs_link_sibling+0x94/0xcc pc : []lr : []psr: 6013 sp : c2831b38 ip : fp : c06b762c r10: r9 : c06b835c r8 : r7 : c2963f00 r6 : c066b028 r5 : c2016cc0 r4 : r3 : r2 : c2983010 r1 : c2963f2c r0 : c2016cd0 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 0005317f Table: c0004000 DAC: 0053 Process swapper (pid: 1, stack limit = 0x(ptrval)) Stack: (0xc2831b38 to 0xc2832000) 1b20: c2016cc0 1b40: c066b028 c014bfdc c2016cc0 c2963f00 c066b028 c014c768 c2963f00 c014c448 1b60: c2016cc0 c2963f00 c066b028 c2963f00 c014c860 0001 1b80: c0589938 c2b4b408 c014ec70 c2b4b408 c04c4cb0 1ba0: 070f 9fd04dd9 c2b4b408 c066b028 1bc0: c293ac98 c04b58f8 c059081c c2b4b408 c066b028 1be0: c04b5d64 c2831c08 9fd04dd9 c2b4b3c0 c293ac80 c2bd16c0 c2b4b408 1c00: c00d650c c059081c c2bd16c0 c28e3a80 c2b4b3c0 c2b4b3c0 1c20: c06b7634 0002 c06b835c c00d72f8 c00b0c24 0074 1c40: c0590728 c0590728 c2b4b3c0 0074 c0590728 0002 1c60: c06b762c c00b0958 00380bc6 c06bbf1c c2bd9c00 c2bfe000 1c80: c06bbf14 000c c2831e0c c00b0a90 1ca0: 003b2580 c017d6e4 c2bfe000 1cc0: c2bd9c00 003b2580 c01971a0 1103 1ce0: c2bd8400 0400 0400 9fd04dd9 000a 0002 1d00: 0001 0a04 0032 1d20: 000c 0004 c00af550 c2bd9ecc 9fd04dd9 c2404480 c2bd9eb4 1d40: c2bd8400 c2404480 0002 0001 0001 1d60: 0001 1d80: 00380bc6 003b257f 0077 0200 0002 1da0: 0001 0401 c2bfe22c 1dc0: c2012400 c24be100 1000 c2404480 1de0: 4003 9fd04dd9 c2bd9c00 c2404480 0083 c24044fc 8000 1e00: 0020 8000 c00e4d88 c2404480 c0190afc 1e20: c2bd0be0 c0692898 c0692898 0020 c0190b10 c0194f48 c2bd0be0 1e40: c066b370 c00e568c c29f5380 c01002d4 c29f5380 c2bd0be0 8000 c0100488 1e60: c0692898 c066b028 c2bd0be0 c2bd0bc0 c01033ec ff00 1e80: 0a00 c0575ff4 c2bd0be0 c281a010 c2417098 c2bd0be0 000a 1ea0: 000a 9fd04dd9 000a c2bd0be0 c2bd0bc0 c0575ff8 8000 1ec0: c066b028 8000 c0575ff4 c0104178 c2014000 c2014005 1ee0: c0575ff8 c3fb1280 c0652868 c062b1ec c01013d8 c24c3558 1f00: 6180 c24c3558 c00f17c4 e10c76ac 0b32 c2858015 c281a010 1f20: c2415da8 9fd04dd9 0002 c06ad310 c066b028 c066da68 1f40: c062b478 c0037200 00306b6c 9fd0 1f60: c0576098 9fd04dd9 0002 c06ad310 c0652878 1f80: c062b5e4 1fa0: c04c7860 c04c7868 c00090e0 1fc0: 1fe0:
[GIT PULL FOR v5.1] Renesas display drivers changes
Hi Dave, The following changes since commit e3d093070eb0b5e3df668d3eb04100ea79343c65: Merge tag 'tilcdc-4.22' of https://github.com/jsarha/linux into drm-next (2019-01-11 06:29:31 +1000) are available in the Git repository at: git://linuxtv.org/pinchartl/media.git tags/du-next-20190114 for you to fetch changes up to 9a47db8e7a9dabe0b88a0071f1677722be167e68: drm: rcar-du: Remove inclusion of drmP.h (2019-01-14 03:51:33 +0200) Renesas display drivers changes for v5.1: - R8A774C0 support - D3/E3 RGB output routing fixes - Miscellaneous fixes - Constify drm_bridge .mode_set() arguments Fabrizio Castro (4): dt-bindings: display: renesas: du: Document r8a774c0 bindings dt-bindings: display: renesas: lvds: Document r8a774c0 bindings drm: rcar-du: Add r8a774c0 device support drm: rcar-du: lvds: add R8A774C0 support Geert Uytterhoeven (1): drm: rcar-du: Convert live DT patches to sugar syntax Laurent Pinchart (6): drm: bridge: Constify mode arguments to bridge .mode_set() operation drm: rcar-du: dw-hdmi: Reject modes with a too high clock frequency drm: rcar-du: Replace EXT_CTRL_REGS feature flag with generation check drm: rcar-du: Move CRTC outputs bitmask to private CRTC state drm: rcar-du: Disable unused DPAD outputs drm: rcar-du: Remove inclusion of drmP.h YueHaibing (1): drm/shmob: Fix return value check in shmob_drm_probe .../bindings/display/bridge/renesas,lvds.txt | 3 +- .../devicetree/bindings/display/renesas,du.txt| 2 + drivers/gpu/drm/bridge/adv7511/adv7511.h | 4 +- drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 8 +- drivers/gpu/drm/bridge/adv7511/adv7533.c | 2 +- drivers/gpu/drm/bridge/analogix-anx78xx.c | 4 +- .../gpu/drm/bridge/analogix/analogix_dp_core.c| 4 +- drivers/gpu/drm/bridge/sii902x.c | 4 +- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 +- drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 18 ++-- drivers/gpu/drm/bridge/tc358767.c | 9 +- drivers/gpu/drm/drm_bridge.c | 4 +- drivers/gpu/drm/exynos/exynos_drm_mic.c | 4 +- drivers/gpu/drm/i2c/tda998x_drv.c | 6 +- drivers/gpu/drm/mediatek/mtk_hdmi.c | 4 +- drivers/gpu/drm/msm/dsi/dsi.h | 2 +- drivers/gpu/drm/msm/dsi/dsi_host.c| 2 +- drivers/gpu/drm/msm/dsi/dsi_manager.c | 4 +- drivers/gpu/drm/msm/edp/edp_bridge.c | 4 +- drivers/gpu/drm/msm/hdmi/hdmi_bridge.c| 4 +- drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 43 +- drivers/gpu/drm/rcar-du/rcar_du_crtc.h| 8 +- drivers/gpu/drm/rcar-du/rcar_du_drv.c | 42 ++ drivers/gpu/drm/rcar-du/rcar_du_drv.h | 9 +- drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 11 --- drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 2 - drivers/gpu/drm/rcar-du/rcar_du_group.c | 51 ++- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 23 - .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts | 93 ++--- .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dts | 53 +--- .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dts | 53 +--- .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dts | 53 +--- .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dts | 53 +--- drivers/gpu/drm/rcar-du/rcar_du_plane.c | 1 - drivers/gpu/drm/rcar-du/rcar_du_plane.h | 3 +- drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 1 - drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 3 +- drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c| 15 drivers/gpu/drm/rcar-du/rcar_lvds.c | 5 +- drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 2 +- drivers/gpu/drm/shmobile/shmob_drm_drv.c | 4 +- drivers/gpu/drm/sti/sti_dvo.c | 4 +- drivers/gpu/drm/sti/sti_hda.c | 4 +- drivers/gpu/drm/sti/sti_hdmi.c| 4 +- drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 2 +- include/drm/bridge/dw_mipi_dsi.h | 3 +- include/drm/drm_bridge.h | 8 +- 47 files changed, 345 insertions(+), 304 deletions(-) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109234] amdgpu random hangs with 5.0-rc2/4.21+
https://bugs.freedesktop.org/show_bug.cgi?id=109234 --- Comment #15 from bmil...@gmail.com --- @Sibren Vasse Have you forwarded this to dma devs yet? -- 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 109342] Display is frozen in X, but mouse cursor moves when using fcitx with nouveau.
https://bugs.freedesktop.org/show_bug.cgi?id=109342 Bug ID: 109342 Summary: Display is frozen in X, but mouse cursor moves when using fcitx with nouveau. Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: All Status: NEW Severity: normal Priority: medium Component: DRM/other Assignee: dri-devel@lists.freedesktop.org Reporter: ihc...@gmail.com Created attachment 143097 --> https://bugs.freedesktop.org/attachment.cgi?id=143097&action=edit dmesg > dmesg.0114 I am not sure where to post nouveau problem. The attched is the output of dmesg command. -- 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 109342] Display is frozen in X, but mouse cursor moves when using fcitx with nouveau.
https://bugs.freedesktop.org/show_bug.cgi?id=109342 Sih Sîng-hông changed: What|Removed |Added CC||ihc...@gmail.com --- Comment #1 from Sih Sîng-hông --- Created attachment 143098 --> https://bugs.freedesktop.org/attachment.cgi?id=143098&action=edit /var/log/Xorg.0.log -- 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 109265] [regression, bisected] arb_texture_multisample texelfetch piglit test failing on NIR backend
https://bugs.freedesktop.org/show_bug.cgi?id=109265
--- Comment #4 from Timothy Arceri ---
This is odd. As far as I can tell the shader variant produced after loading
from the case is the same as the one produced when the cache is disabled.
Its also a fairly simple program. From tests/texturing/shaders/texelFetch.c the
offending program is:
int vs = piglit_compile_shader_text(GL_VERTEX_SHADER,
"#version 130\n"
"#extension GL_ARB_explicit_attrib_location: require\n"
"layout(location=0) in vec4 pos;\n"
"void main() {\n"
" gl_Position = pos;\n"
"}\n");
(void)!asprintf(&fs_code,
"#version 130\n"
"#extension GL_ARB_explicit_attrib_location: require\n"
"#extension GL_ARB_fragment_coord_conventions: require\n"
"uniform int layer;\n"
"uniform int si;\n"
"layout(pixel_center_integer) in vec4 gl_FragCoord;\n"
"layout(location=0) out %s o;\n"
"void main() {\n"
" o = %s(%sgl_FragCoord.x, gl_FragCoord.y, layer, si);\n"
"}\n",
sampler.return_type,
sampler.return_type,
sampler.data_type == GL_UNSIGNED_INT ? "" : "-");
We must not be setting a flag somewhere, but I've looked over the code that
handles the cache multiple time now and can't spot any real difference between
tgsi and nir.
--
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 2/2] drm/amdgpu: set bulk_moveable to false when lru changed v2
if lru is changed, we cannot do bulk moving.
v2:
root bo isn't bulk moving, skip its change.
Change-Id: Ide0fe920295cc25f7cabcf41a6400519e5783f2a
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 22 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 2 ++
3 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index c91ec3101d00..b852abb9db0f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1546,7 +1546,8 @@ static struct ttm_bo_driver amdgpu_bo_driver = {
.io_mem_reserve = &amdgpu_ttm_io_mem_reserve,
.io_mem_free = &amdgpu_ttm_io_mem_free,
.io_mem_pfn = amdgpu_ttm_io_mem_pfn,
- .access_memory = &amdgpu_ttm_access_memory
+ .access_memory = &amdgpu_ttm_access_memory,
+ .del_from_lru_notify = &amdgpu_vm_del_from_lru_notify
};
/*
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index e73d152659a2..ef012d47cbeb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -623,6 +623,28 @@ void amdgpu_vm_get_pd_bo(struct amdgpu_vm *vm,
list_add(&entry->tv.head, validated);
}
+void amdgpu_vm_del_from_lru_notify(struct ttm_buffer_object *bo)
+{
+ struct amdgpu_bo *abo;
+ struct amdgpu_vm_bo_base *bo_base;
+
+ if (!amdgpu_bo_is_amdgpu_bo(bo))
+ return;
+
+ if (bo->mem.placement & TTM_PL_FLAG_NO_EVICT)
+ return;
+
+ abo = ttm_to_amdgpu_bo(bo);
+ if (!abo->parent)
+ return;
+ for (bo_base = abo->vm_bo; bo_base; bo_base = bo_base->next) {
+ struct amdgpu_vm *vm = bo_base->vm;
+
+ if (abo->tbo.resv == vm->root.base.bo->tbo.resv)
+ vm->bulk_moveable = false;
+ }
+
+}
/**
* amdgpu_vm_move_to_lru_tail - move all BOs to the end of LRU
*
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
index e8dcfd59fc93..81ff8177f092 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
@@ -363,4 +363,6 @@ int amdgpu_vm_add_fault(struct amdgpu_retryfault_hashtable
*fault_hash, u64 key)
void amdgpu_vm_clear_fault(struct amdgpu_retryfault_hashtable *fault_hash, u64
key);
+void amdgpu_vm_del_from_lru_notify(struct ttm_buffer_object *bo);
+
#endif
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/ttm: add lru notify to bo driver v2
allow driver do somethings when lru changed.
v2:
address Michel's comments.
Change-Id: Ie82053da49272881d4b52b1c406f7c221a3fcadf
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/ttm/ttm_bo.c| 11 +++
include/drm/ttm/ttm_bo_driver.h | 9 +
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 0ec08394e17a..de088c8070fb 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -198,19 +198,22 @@ static void ttm_bo_ref_bug(struct kref *list_kref)
void ttm_bo_del_from_lru(struct ttm_buffer_object *bo)
{
+ struct ttm_bo_device *bdev = bo->bdev;
+ bool notify = false;
+
if (!list_empty(&bo->swap)) {
list_del_init(&bo->swap);
kref_put(&bo->list_kref, ttm_bo_ref_bug);
+ notify = true;
}
if (!list_empty(&bo->lru)) {
list_del_init(&bo->lru);
kref_put(&bo->list_kref, ttm_bo_ref_bug);
+ notify = true;
}
- /*
-* TODO: Add a driver hook to delete from
-* driver-specific LRU's here.
-*/
+ if (notify && bdev->driver->del_from_lru_notify)
+ bdev->driver->del_from_lru_notify(bo);
}
void ttm_bo_del_sub_from_lru(struct ttm_buffer_object *bo)
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 1021106438b2..15829b24277c 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -381,6 +381,15 @@ struct ttm_bo_driver {
*/
int (*access_memory)(struct ttm_buffer_object *bo, unsigned long offset,
void *buf, int len, int write);
+
+ /**
+* struct ttm_bo_driver member del_from_lru_notify
+*
+* @bo: the buffer object deleted from lru
+*
+* notify driver that a BO was deleted from LRU.
+*/
+ void (*del_from_lru_notify)(struct ttm_buffer_object *bo);
};
/**
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: stop always moving BOs on the LRU on page fault
On 2019年01月11日 21:15, Christian König wrote:
Move the BO on the LRU only when it is actually moved by a DMA
operation.
Signed-off-by: Christian König
Tested-And-Reviewed-by: Chunming Zhou
I just sent lru_notify v2 patches, please review them. With yours and
mine, the OOM issue is fixed without negative effect.
-David
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index a1d977fbade5..e86a29a1e51f 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -71,7 +71,7 @@ static vm_fault_t ttm_bo_vm_fault_idle(struct
ttm_buffer_object *bo,
ttm_bo_get(bo);
up_read(&vmf->vma->vm_mm->mmap_sem);
(void) dma_fence_wait(bo->moving, true);
- ttm_bo_unreserve(bo);
+ reservation_object_unlock(bo->resv);
ttm_bo_put(bo);
goto out_unlock;
}
@@ -131,11 +131,7 @@ static vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
* for reserve, and if it fails, retry the fault after waiting
* for the buffer to become unreserved.
*/
- err = ttm_bo_reserve(bo, true, true, NULL);
- if (unlikely(err != 0)) {
- if (err != -EBUSY)
- return VM_FAULT_NOPAGE;
-
+ if (unlikely(!reservation_object_trylock(bo->resv))) {
if (vmf->flags & FAULT_FLAG_ALLOW_RETRY) {
if (!(vmf->flags & FAULT_FLAG_RETRY_NOWAIT)) {
ttm_bo_get(bo);
@@ -165,6 +161,8 @@ static vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
}
if (bdev->driver->fault_reserve_notify) {
+ struct dma_fence *moving = dma_fence_get(bo->moving);
+
err = bdev->driver->fault_reserve_notify(bo);
switch (err) {
case 0:
@@ -177,6 +175,13 @@ static vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
ret = VM_FAULT_SIGBUS;
goto out_unlock;
}
+
+ if (bo->moving != moving) {
+ spin_lock(&bdev->glob->lru_lock);
+ ttm_bo_move_to_lru_tail(bo, NULL);
+ spin_unlock(&bdev->glob->lru_lock);
+ }
+ dma_fence_put(moving);
}
/*
@@ -291,7 +296,7 @@ static vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
out_io_unlock:
ttm_mem_io_unlock(man);
out_unlock:
- ttm_bo_unreserve(bo);
+ reservation_object_unlock(bo->resv);
return ret;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109345] drm-next-2018-12-14 -Linux PPC
https://bugs.freedesktop.org/show_bug.cgi?id=109345 Bug ID: 109345 Summary: drm-next-2018-12-14 -Linux PPC Product: DRI Version: XOrg git Hardware: PowerPC OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel@lists.freedesktop.org Reporter: ace...@gmail.com Initialization and use of secondary graphics card (Firepro2600) does not work with new kernels using update drm-next-2018-12-14. Situation Amigaone x5000 with Radeon R7 250E in 16x PCIE slot, and Firepro 2260 in 1 x PCIE slot. Previously using the following commands would allow the Firepro 2260 to be used instead of the 250E. "sudo mv '/usr/lib/xorg/modules/libglamoregl.so' '/usr/lib/xorg/modules/libglamoregl.so.bak' sudo mv /etc/X11/xorg.conf /etc/X11/xorg.conf.bak" Since the incorporation of update drm-next-2018-12-14, initialization of the Firepro fails and the 250E is used. If I remove the 250E and place the Firepro 2260 in the 16x PCIE slot it is initialized and works fine. The issue is I need to use the 250E for Amiga 4.1 OS. I have kept various logs but I am not sure this is actually a bug or consistent with what developers wish to happen. -- 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/cirrus: fix connector leak at unload
On Fri, Jan 11, 2019 at 11:16:38PM +0100, Daniel Vetter wrote: > On Fri, Jan 11, 2019 at 11:06:20PM +0100, Daniel Vetter wrote: > > On Fri, Jan 11, 2019 at 09:02:34AM -0500, Rob Clark wrote: > > > This fixes an '*ERROR* connector VGA-2 leaked!' splat at driver unload. > > > > > > Signed-off-by: Rob Clark > > > --- > > > Similar case to the issue that was fixed recently in drm/ast > > > > Reviewed-by: Daniel Vetter > > Actually I just pushed a patch to drm-misc-next to rename this function to > drm_helper_force_disable_all(), so you need to respin ... My r-b still > holds. Fixed and queued up. thanks, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
