[Bug 110457] System resumes failed and hits [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout on Acer Squirtle_SR laptop
https://bugs.freedesktop.org/show_bug.cgi?id=110457 Bug ID: 110457 Summary: System resumes failed and hits [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout on Acer Squirtle_SR laptop Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: jian-h...@endlessm.com Created attachment 144006 --> https://bugs.freedesktop.org/attachment.cgi?id=144006=edit dmesg with amdgpu.dc=1 drm.debug=7 in boot command We have an Acer Squirtle_SR laptop equipped with AMD A9-9420e RADEON R5, 5 COMPUTE CORES 2C+3G and [AMD/ATI] Topaz XT [Radeon R7 M260/M265 / M340/M360 / M440/M445] [1002:6900]. We test it with Linux kernel 5.1.0-rc5+. The kernel includes the patch [1] mentioned in comment 110360#c9 [2]. System keeps screen black after system resumes from suspending. The error keeps showing on dmesg: [ 177.401716] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=290, emitted seq=294 [ 177.401848] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process Xorg pid 569 thread Xorg:cs0 pid 571 [ 177.401855] [drm] IP block:gfx_v8_0 is hung! [ 177.401932] [drm] GPU recovery disabled. 01:00.0 Display controller [0380]: Advanced Micro Devices, Inc. [AMD/ATI] Topaz XT [Radeon R7 M260/M265 / M340/M360 / M440/M445] [1002:6900] (rev c3) Subsystem: Acer Incorporated [ALI] Topaz XT [Radeon R7 M260/M265 / M340/M360 / M440/M445] [1025:1217] Flags: bus master, fast devsel, latency 0, IRQ 40 Memory at c000 (64-bit, prefetchable) [size=256M] Memory at d000 (64-bit, prefetchable) [size=2M] I/O ports at 3000 [size=256] Memory at d140 (32-bit, non-prefetchable) [size=256K] Expansion ROM at d144 [disabled] [size=128K] Capabilities: [48] Vendor Specific Information: Len=08 Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint, MSI 00 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 Capabilities: [150] Advanced Error Reporting Capabilities: [270] #19 Capabilities: [2b0] Address Translation Service (ATS) Capabilities: [2c0] Page Request Interface (PRI) Capabilities: [2d0] Process Address Space ID (PASID) Kernel driver in use: amdgpu Kernel modules: amdgpu [1] https://patchwork.kernel.org/patch/10889269/ [2] https://bugzilla.freedesktop.org/show_bug.cgi?id=110360#c9 -- 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 v1 3/4] drm/mediatek: fix boot up for 720 and 480 but 1080
Hi, Frank:
On Tue, 2019-04-16 at 16:58 +0200, Frank Wunderlich wrote:
> From: chunhui dai
>
> - 1080 plg in/out with ng/ok
> - support other resolutions like 1280x1024
The description is so simple and I could not understand why
pll_default_off could fix this problem. And why only MT2701 has this
problem? Please describe more clear about this patch.
Regards,
CK
>
> Signed-off-by: chunhui dai
> Signed-off-by: Frank Wunderlich
> Tested-by: Frank Wunderlich
> ---
> drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 3 +++
> drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 1 +
> drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 1 +
> 3 files changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> index 5223498502c4..edadb7a700f1 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> @@ -184,6 +184,9 @@ static int mtk_hdmi_phy_probe(struct platform_device
> *pdev)
> return PTR_ERR(phy_provider);
> }
>
> + if (hdmi_phy->conf->pll_default_off)
> + hdmi_phy->conf->hdmi_phy_disable_tmds(hdmi_phy);
> +
> return of_clk_add_provider(dev->of_node, of_clk_src_simple_get,
> hdmi_phy->pll);
> }
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> index 2d8b3182470d..f472fdeb63dc 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> @@ -22,6 +22,7 @@ struct mtk_hdmi_phy;
> struct mtk_hdmi_phy_conf {
> bool tz_disabled;
> unsigned long flags;
> + bool pll_default_off;
> const struct clk_ops *hdmi_phy_clk_ops;
> void (*hdmi_phy_enable_tmds)(struct mtk_hdmi_phy *hdmi_phy);
> void (*hdmi_phy_disable_tmds)(struct mtk_hdmi_phy *hdmi_phy);
> diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> index d3cc4022e988..6fbedacfc1e8 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> @@ -239,6 +239,7 @@ static void mtk_hdmi_phy_disable_tmds(struct mtk_hdmi_phy
> *hdmi_phy)
> struct mtk_hdmi_phy_conf mtk_hdmi_phy_2701_conf = {
> .tz_disabled = true,
> .flags = CLK_SET_RATE_GATE,
> + .pll_default_off = true,
> .hdmi_phy_clk_ops = _hdmi_phy_pll_ops,
> .hdmi_phy_enable_tmds = mtk_hdmi_phy_enable_tmds,
> .hdmi_phy_disable_tmds = mtk_hdmi_phy_disable_tmds,
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Aw: Re: [PATCH v1 0/4] make hdmi work on bananapi-r2
Hi, Frank: On Wed, 2019-04-17 at 07:30 +0200, Frank Wunderlich wrote: > Hi CK Hu, > > you mean the problematic patch is fix possible_crtcs (4/4) and the others are > ok? > > can you push the first 3 while working on the last one? I think 3 patches is related to possible crtc problem: (1/4), (2/4), and (4/4). And I have comment on (3/4) also. Regards, CK > > regards Frank ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v2 2/5] drm/mediatek: CMDQ reg address of mt8173 is different with mt2701
Hi Jitao,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.1-rc5 next-20190416]
[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/Jitao-Shi/drm-mediatek-move-mipi_dsi_host_register-to-probe/20190417-100619
config: arm-allmodconfig (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 warnings (new ones prefixed by >>):
drivers/gpu//drm/mediatek/mtk_dsi.c: In function 'mtk_dsi_probe':
>> drivers/gpu//drm/mediatek/mtk_dsi.c:1129:19: warning: assignment discards
>> 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
dsi->driver_data = of_id->data;
^
vim +/const +1129 drivers/gpu//drm/mediatek/mtk_dsi.c
1099
1100 static int mtk_dsi_probe(struct platform_device *pdev)
1101 {
1102 struct mtk_dsi *dsi;
1103 struct device *dev = >dev;
1104 const struct of_device_id *of_id;
1105 struct resource *regs;
1106 int irq_num;
1107 int comp_id;
1108 int ret;
1109
1110 dsi = devm_kzalloc(dev, sizeof(*dsi), GFP_KERNEL);
if (!dsi)
1112 return -ENOMEM;
1113
1114 dsi->host.ops = _dsi_ops;
1115 dsi->host.dev = dev;
1116 dsi->dev = dev;
1117 ret = mipi_dsi_host_register(>host);
1118 if (ret < 0) {
1119 dev_err(dev, "failed to register DSI host: %d\n", ret);
1120 return ret;
1121 }
1122
1123 ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
1124>panel, >bridge);
1125 if (ret)
1126 goto err_unregister_host;
1127
1128 of_id = of_match_device(mtk_dsi_of_match, >dev);
> 1129 dsi->driver_data = of_id->data;
1130
1131 dsi->engine_clk = devm_clk_get(dev, "engine");
1132 if (IS_ERR(dsi->engine_clk)) {
1133 ret = PTR_ERR(dsi->engine_clk);
1134 dev_err(dev, "Failed to get engine clock: %d\n", ret);
1135 goto err_unregister_host;
1136 }
1137
1138 dsi->digital_clk = devm_clk_get(dev, "digital");
1139 if (IS_ERR(dsi->digital_clk)) {
1140 ret = PTR_ERR(dsi->digital_clk);
1141 dev_err(dev, "Failed to get digital clock: %d\n", ret);
1142 goto err_unregister_host;
1143 }
1144
1145 dsi->hs_clk = devm_clk_get(dev, "hs");
1146 if (IS_ERR(dsi->hs_clk)) {
1147 ret = PTR_ERR(dsi->hs_clk);
1148 dev_err(dev, "Failed to get hs clock: %d\n", ret);
1149 goto err_unregister_host;
1150 }
1151
1152 regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
1153 dsi->regs = devm_ioremap_resource(dev, regs);
1154 if (IS_ERR(dsi->regs)) {
1155 ret = PTR_ERR(dsi->regs);
1156 dev_err(dev, "Failed to ioremap memory: %d\n", ret);
1157 goto err_unregister_host;
1158 }
1159
1160 dsi->phy = devm_phy_get(dev, "dphy");
1161 if (IS_ERR(dsi->phy)) {
1162 ret = PTR_ERR(dsi->phy);
1163 dev_err(dev, "Failed to get MIPI-DPHY: %d\n", ret);
1164 goto err_unregister_host;
1165 }
1166
1167 comp_id = mtk_ddp_comp_get_id(dev->of_node, MTK_DSI);
1168 if (comp_id < 0) {
1169 dev_err(dev, "Failed to identify by alias: %d\n",
comp_id);
1170 ret = comp_id;
1171 goto err_unregister_host;
1172 }
1173
1174 ret = mtk_ddp_comp_init(dev, dev->of_node, >ddp_comp,
comp_id,
1175 _dsi_funcs);
1176 if (ret) {
1177 dev_err(dev, "Failed to initialize component: %d\n",
ret);
1178 goto err_unregister_host;
1179 }
1180
1181 irq_num = platform_get_irq(pdev, 0);
1182 if (irq_num < 0) {
1183 dev_err(>dev, "failed to get dsi irq_num: %d\n",
irq_num);
[Bug 203339] AMDGPU: virtual_display disables physical outputs
https://bugzilla.kernel.org/show_bug.cgi?id=203339 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) --- (In reply to Parker Reed from comment #0) > > I have a monitor connected via HDMI. When I use the virtual_display kernel > parameter, only the virtual displays show up. When you enable the virtual display option the real displays are disabled. That is the intended behavior. It's not a crash just a warning. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 0/4] make hdmi work on bananapi-r2
Hi, Frank: On Tue, 2019-04-16 at 16:58 +0200, Frank Wunderlich wrote: > This Patch-Series adds missing Patches/Bugfixes to get hdmi working on BPI-R2 > > first 2 Patches were already posted, but not yet merged into mainline > i found no hint why > - config component output by device node port > https://patchwork.kernel.org/patch/10609007/ > - add display subsystem related device nodes (resend) > https://patchwork.kernel.org/patch/10588951/ > These patches need to modify binding document and need long term discuss. I have an idea not to modify binding document so you could be quicker to merge these patches. The idea is: 1. Keep the patch 'drm/mediatek: fix possible_crtcs', let DPI encoder support both crtc0 and crtc1. 2. For encoder and crtc, it could find each other by encoder->crtc and crtc->encoder_mask to configure hardware correctly. Regards, CK > Bibby Hsieh (1): > drm/mediatek: config component output by device node port > > Ryder Lee (2): > arm: dts: mt7623: add display subsystem related device nodes > drm/mediatek: fix possible_crtcs > > chunhui dai (1): > drm/mediatek: fix boot up for 720 and 480 but 1080 > > arch/arm/boot/dts/mt7623.dtsi | 177 ++ > arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 85 + > arch/arm/boot/dts/mt7623n-rfb-emmc.dts| 85 + > drivers/gpu/drm/mediatek/mtk_dpi.c| 2 +- > drivers/gpu/drm/mediatek/mtk_drm_drv.c| 41 +++- > drivers/gpu/drm/mediatek/mtk_drm_drv.h| 4 +- > drivers/gpu/drm/mediatek/mtk_hdmi_phy.c | 3 + > drivers/gpu/drm/mediatek/mtk_hdmi_phy.h | 1 + > .../gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c| 1 + > 9 files changed, 390 insertions(+), 9 deletions(-) > > -- > 2.17.1 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/lima: Make lima_sched_ops static
Thanks, patch is:
Reviewed-by: Qiang Yu
I'll add a "Fix" tag and push it to drm-misc-next.
Regards,
Qiang
On Tue, Apr 16, 2019 at 10:44 PM Yue Haibing wrote:
>
> From: YueHaibing
>
> Fix sparse warning:
>
> drivers/gpu/drm/lima/lima_sched.c:356:36: warning:
> symbol 'lima_sched_ops' was not declared. Should it be static?
>
> Reported-by: Hulk Robot
> Signed-off-by: YueHaibing
> ---
> drivers/gpu/drm/lima/lima_sched.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/lima/lima_sched.c
> b/drivers/gpu/drm/lima/lima_sched.c
> index 97bd9c1..569f0a95 100644
> --- a/drivers/gpu/drm/lima/lima_sched.c
> +++ b/drivers/gpu/drm/lima/lima_sched.c
> @@ -353,7 +353,7 @@ static void lima_sched_free_job(struct drm_sched_job *job)
> kmem_cache_free(pipe->task_slab, task);
> }
>
> -const struct drm_sched_backend_ops lima_sched_ops = {
> +static const struct drm_sched_backend_ops lima_sched_ops = {
> .dependency = lima_sched_dependency,
> .run_job = lima_sched_run_job,
> .timedout_job = lima_sched_timedout_job,
> --
> 2.7.4
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108361] Radeon/Xorg crash during boot with Radeon R5 M230
https://bugs.freedesktop.org/show_bug.cgi?id=108361 --- Comment #1 from jian-h...@endlessm.com --- Created attachment 144004 --> https://bugs.freedesktop.org/attachment.cgi?id=144004=edit dmesg with Linux kernel 5.1.0-rc5 Tested with Linux kernel 5.1.0-rc5 on this model again. This issue still can be reproduced. cat /sys/module/radeon/parameters/runpm -1 [ 36.906374] [drm] PCIE GART of 2048M enabled (table at 0x0004). [ 36.906474] radeon :01:00.0: WB enabled [ 36.906475] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x8c00 and cpu addr 0x7764e5ef [ 36.906476] radeon :01:00.0: fence driver on ring 1 use gpu addr 0x8c04 and cpu addr 0xacdd696b [ 36.906476] radeon :01:00.0: fence driver on ring 2 use gpu addr 0x8c08 and cpu addr 0x94afed91 [ 36.906477] radeon :01:00.0: fence driver on ring 3 use gpu addr 0x8c0c and cpu addr 0xb67dc661 [ 36.906477] radeon :01:00.0: fence driver on ring 4 use gpu addr 0x8c10 and cpu addr 0xa1f607b2 [ 37.438936] [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x850C)=0xCAFEDEAD) [ 37.438947] [drm:si_resume [radeon]] *ERROR* si startup failed on resume [ 49.387494] [drm:atom_op_jump [radeon]] *ERROR* atombios stuck in loop for more than 5secs aborting [ 49.387514] [drm:atom_execute_table_locked [radeon]] *ERROR* atombios stuck executing 67C0 (len 254, WS 0, PS 4) @ 0x67CE [ 49.387521] [drm:atom_execute_table_locked [radeon]] *ERROR* atombios stuck executing 612C (len 78, WS 12, PS 8) @ 0x6165 [ 49.393021] [drm] PCIE gen 3 link speeds already enabled [ 49.736418] radeon :01:00.0: Wait for MC idle timedout ! [ 49.907902] radeon :01:00.0: Wait for MC idle timedout ! -- 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/3] drm/msm: add param to retrieve # of GPU faults (global)
From: Rob Clark
For KHR_robustness, userspace wants to know two things, the count of GPU
faults globally, and the count of faults attributed to a given context.
This patch providees the former, and the next patch provides the latter.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 3 +++
drivers/gpu/drm/msm/msm_gpu.c | 3 +++
drivers/gpu/drm/msm/msm_gpu.h | 3 +++
include/uapi/drm/msm_drm.h | 1 +
4 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index fbdf6f1c247e..8436caa4547f 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -65,6 +65,9 @@ int adreno_get_param(struct msm_gpu *gpu, uint32_t param,
uint64_t *value)
case MSM_PARAM_PP_PGTABLE:
*value = 0;
return 0;
+ case MSM_PARAM_FAULTS:
+ *value = gpu->global_faults;
+ return 0;
default:
DBG("%s: invalid param: %u", gpu->name, param);
return -EINVAL;
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 10babd18e286..194847a220b6 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -443,6 +443,9 @@ static void recover_worker(struct work_struct *work)
if (submit) {
struct task_struct *task;
+ /* Increment the fault count */
+ gpu->global_faults++;
+
task = get_pid_task(submit->pid, PIDTYPE_PID);
if (task) {
comm = kstrdup(task->comm, GFP_KERNEL);
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index ca17086f72c9..3e9078ec3023 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -103,6 +103,9 @@ struct msm_gpu {
/* does gpu need hw_init? */
bool needs_hw_init;
+ /* number of GPU hangs (for all contexts) */
+ int global_faults;
+
/* worker for handling active-list retiring: */
struct work_struct retire_work;
diff --git a/include/uapi/drm/msm_drm.h b/include/uapi/drm/msm_drm.h
index a9fdcf1689ce..178d7b407f3a 100644
--- a/include/uapi/drm/msm_drm.h
+++ b/include/uapi/drm/msm_drm.h
@@ -75,6 +75,7 @@ struct drm_msm_timespec {
#define MSM_PARAM_GMEM_BASE 0x06
#define MSM_PARAM_NR_RINGS 0x07
#define MSM_PARAM_PP_PGTABLE 0x08 /* => 1 for per-process pagetables, else 0
*/
+#define MSM_PARAM_FAULTS 0x09
struct drm_msm_param {
__u32 pipe; /* in, MSM_PIPE_x */
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/msm/gpu: Add submit queue queries
From: Jordan Crouse
Add the capability to query information from a submit queue.
The first available parameter is for querying the number of GPU faults
(hangs) that can be attributed to the queue.
This is useful for implementing context robustness. A user context can
regularly query the number of faults to see if it is responsible for any
and if so it can invalidate itself.
This is also helpful for testing by confirming to the user driver if a
particular command stream caused a fault (or not as the case may be).
Signed-off-by: Jordan Crouse
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c | 9 +-
drivers/gpu/drm/msm/msm_drv.h | 2 ++
drivers/gpu/drm/msm/msm_gpu.c | 3 +-
drivers/gpu/drm/msm/msm_submitqueue.c | 41 +++
include/uapi/drm/msm_drm.h| 12
5 files changed, 65 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 906b2bb79f6a..b8671bdc12ab 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -39,9 +39,10 @@
* MSM_GEM_INFO ioctl.
* - 1.4.0 - softpin, MSM_RELOC_BO_DUMP, and GEM_INFO support to set/get
* GEM object's debug name
+ * - 1.5.0 - Add SUBMITQUERY_QUERY ioctl
*/
#define MSM_VERSION_MAJOR 1
-#define MSM_VERSION_MINOR 4
+#define MSM_VERSION_MINOR 5
#define MSM_VERSION_PATCHLEVEL 0
static const struct drm_mode_config_funcs mode_config_funcs = {
@@ -964,6 +965,11 @@ static int msm_ioctl_submitqueue_new(struct drm_device
*dev, void *data,
args->flags, >id);
}
+static int msm_ioctl_submitqueue_query(struct drm_device *dev, void *data,
+ struct drm_file *file)
+{
+ return msm_submitqueue_query(dev, file->driver_priv, data);
+}
static int msm_ioctl_submitqueue_close(struct drm_device *dev, void *data,
struct drm_file *file)
@@ -984,6 +990,7 @@ static const struct drm_ioctl_desc msm_ioctls[] = {
DRM_IOCTL_DEF_DRV(MSM_GEM_MADVISE, msm_ioctl_gem_madvise,
DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_NEW, msm_ioctl_submitqueue_new,
DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_CLOSE, msm_ioctl_submitqueue_close,
DRM_AUTH|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_QUERY, msm_ioctl_submitqueue_query,
DRM_AUTH|DRM_RENDER_ALLOW),
};
static const struct vm_operations_struct vm_ops = {
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index cb642fefbd2f..afb91712acd6 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -420,6 +420,8 @@ struct msm_gpu_submitqueue *msm_submitqueue_get(struct
msm_file_private *ctx,
u32 id);
int msm_submitqueue_create(struct drm_device *drm, struct msm_file_private
*ctx,
u32 prio, u32 flags, u32 *id);
+int msm_submitqueue_query(struct drm_device *drm, struct msm_file_private *ctx,
+ struct drm_msm_submitqueue_query *args);
int msm_submitqueue_remove(struct msm_file_private *ctx, u32 id);
void msm_submitqueue_close(struct msm_file_private *ctx);
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 194847a220b6..2b76657badd5 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -443,8 +443,9 @@ static void recover_worker(struct work_struct *work)
if (submit) {
struct task_struct *task;
- /* Increment the fault count */
+ /* Increment the fault counts */
gpu->global_faults++;
+ submit->queue->faults++;
task = get_pid_task(submit->pid, PIDTYPE_PID);
if (task) {
diff --git a/drivers/gpu/drm/msm/msm_submitqueue.c
b/drivers/gpu/drm/msm/msm_submitqueue.c
index 5115f75b5b7f..f160ec40a39b 100644
--- a/drivers/gpu/drm/msm/msm_submitqueue.c
+++ b/drivers/gpu/drm/msm/msm_submitqueue.c
@@ -120,6 +120,47 @@ int msm_submitqueue_init(struct drm_device *drm, struct
msm_file_private *ctx)
return msm_submitqueue_create(drm, ctx, default_prio, 0, NULL);
}
+static int msm_submitqueue_query_faults(struct msm_gpu_submitqueue *queue,
+ struct drm_msm_submitqueue_query *args)
+{
+ size_t size = min_t(size_t, args->len, sizeof(queue->faults));
+ int ret;
+
+ /* If a zero length was passed in, return the data size we expect */
+ if (!args->len) {
+ args->len = sizeof(queue->faults);
+ return 0;
+ }
+
+ /* Set the length to the actual size of the data */
+ args->len = size;
+
+ ret = copy_to_user(u64_to_user_ptr(args->data), >faults, size);
+
+ return ret ? -EFAULT : 0;
+}
+
+int msm_submitqueue_query(struct drm_device *drm, struct msm_file_private *ctx,
+ struct drm_msm_submitqueue_query *args)
+{
+ struct msm_gpu_submitqueue *queue;
[PATCH 1/3] drm/msm/gpu: add per-process pagetables param
From: Rob Clark
For now it always returns '0' (false), but once the iommu work is in
place to enable per-process pagetables we can update the value returned.
Userspace needs to know this to make an informed decision about exposing
KHR_robustness.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 3 +++
include/uapi/drm/msm_drm.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 2cfee1a4fe0b..fbdf6f1c247e 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -62,6 +62,9 @@ int adreno_get_param(struct msm_gpu *gpu, uint32_t param,
uint64_t *value)
case MSM_PARAM_NR_RINGS:
*value = gpu->nr_rings;
return 0;
+ case MSM_PARAM_PP_PGTABLE:
+ *value = 0;
+ return 0;
default:
DBG("%s: invalid param: %u", gpu->name, param);
return -EINVAL;
diff --git a/include/uapi/drm/msm_drm.h b/include/uapi/drm/msm_drm.h
index 91a16b333c69..a9fdcf1689ce 100644
--- a/include/uapi/drm/msm_drm.h
+++ b/include/uapi/drm/msm_drm.h
@@ -74,6 +74,7 @@ struct drm_msm_timespec {
#define MSM_PARAM_TIMESTAMP 0x05
#define MSM_PARAM_GMEM_BASE 0x06
#define MSM_PARAM_NR_RINGS 0x07
+#define MSM_PARAM_PP_PGTABLE 0x08 /* => 1 for per-process pagetables, else 0
*/
struct drm_msm_param {
__u32 pipe; /* in, MSM_PIPE_x */
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] drm/msm: uabi updates for KHR_robustness
Collection of a few small UABI updates from Jordan and myself to enable userspace support for robustness[1]. The userspace side of this is at: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/673/commits [1] it doesn't *quite* enable it yet, since we don't have per-context pagetables yet without some iommu work landing first. But it can otherwise be tested for the fault detection part of things with a small hack. Jordan Crouse (1): drm/msm/gpu: Add submit queue queries Rob Clark (2): drm/msm/gpu: add per-process pagetables param drm/msm: add param to retrieve # of GPU faults (global) drivers/gpu/drm/msm/adreno/adreno_gpu.c | 6 drivers/gpu/drm/msm/msm_drv.c | 9 +- drivers/gpu/drm/msm/msm_drv.h | 2 ++ drivers/gpu/drm/msm/msm_gpu.c | 4 +++ drivers/gpu/drm/msm/msm_gpu.h | 3 ++ drivers/gpu/drm/msm/msm_submitqueue.c | 41 + include/uapi/drm/msm_drm.h | 14 + 7 files changed, 78 insertions(+), 1 deletion(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/6] Fix crash after reloading a driver using ttm
On Wed, Apr 17, 2019 at 1:09 AM Eric Anholt wrote: > > Christian König writes: > > > Am 16.04.19 um 02:35 schrieb Karol Herbst: > >> Kobjects are supposed to be dynamically allocated, but with recent changes > >> this rule was violated. Reverting those commits fixes crashes when a drm > >> driver using TTM gets loaded again. > >> > >> The object in question is "ttm_mem_glob" declared inside > >> "include/drm/ttm/ttm_memory.h" and instatiated inside > >> "drivers/gpu/drm/ttm/ttm_memory.c". > >> > >> from "Documentation/kobject.txt": > >> "Because kobjects are dynamic, they must not be declared statically or on > >> the stack, but instead, always allocated dynamically. Future versions of > >> the kernel will contain a run-time check for kobjects that are created > >> statically and will warn the developer of this improper usage." > >> > >> Unloading ttm before reloading the driver workarounds that crash, because > >> the memory backing the kobject member "kobj" is cleaned up. The kobject_del > >> and kobject_put function never free or clean up the kobject object leaving > >> it in an undefined state. > >> > >> I reverted a few more commits to make it less painful for me to rever this > >> rather big change. > > > > Well, NAK. By reverting those change you also re-introduced the problems > > we originally fixed with those patches. > > > > Please work on a proper fix instead, > > That's not Karol's responsibility, that's yours as the author. I would > like to remind about Linux's regressions policy, quoting from > Documentation/process/4.Coding.rst: > > "One final hazard worth mentioning is this: it can be tempting to make a > change (which may bring big improvements) which causes something to break > for existing users. This kind of change is called a "regression," and > regressions have become most unwelcome in the mainline kernel. With few > exceptions, changes which cause regressions will be backed out if the > regression cannot be fixed in a timely manner. Far better to avoid the > regression in the first place. > > It is often argued that a regression can be justified if it causes things > to work for more people than it creates problems for. Why not make a > change if it brings new functionality to ten systems for each one it > breaks? The best answer to this question was expressed by Linus in July, > 2007: > > :: > > So we don't fix bugs by introducing new problems. That way lies > madness, and nobody ever knows if you actually make any real > progress at all. Is it two steps forwards, one step back, or one > step forward and two steps back?" he already wrote a fix. Search for "[PATCH 1/2] drm/ttm: fix re-init of global structures" ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110443] vaapi/vpp: wrong output for non 64-bytes align width (ex: 1200)
https://bugs.freedesktop.org/show_bug.cgi?id=110443 --- Comment #3 from Marek Olšák --- That's incorrect. The only way to get the stride is through winsys_handle. We could add a separate query function though. -- 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 0/6] Fix crash after reloading a driver using ttm
Christian König writes: > Am 16.04.19 um 02:35 schrieb Karol Herbst: >> Kobjects are supposed to be dynamically allocated, but with recent changes >> this rule was violated. Reverting those commits fixes crashes when a drm >> driver using TTM gets loaded again. >> >> The object in question is "ttm_mem_glob" declared inside >> "include/drm/ttm/ttm_memory.h" and instatiated inside >> "drivers/gpu/drm/ttm/ttm_memory.c". >> >> from "Documentation/kobject.txt": >> "Because kobjects are dynamic, they must not be declared statically or on >> the stack, but instead, always allocated dynamically. Future versions of >> the kernel will contain a run-time check for kobjects that are created >> statically and will warn the developer of this improper usage." >> >> Unloading ttm before reloading the driver workarounds that crash, because >> the memory backing the kobject member "kobj" is cleaned up. The kobject_del >> and kobject_put function never free or clean up the kobject object leaving >> it in an undefined state. >> >> I reverted a few more commits to make it less painful for me to rever this >> rather big change. > > Well, NAK. By reverting those change you also re-introduced the problems > we originally fixed with those patches. > > Please work on a proper fix instead, That's not Karol's responsibility, that's yours as the author. I would like to remind about Linux's regressions policy, quoting from Documentation/process/4.Coding.rst: "One final hazard worth mentioning is this: it can be tempting to make a change (which may bring big improvements) which causes something to break for existing users. This kind of change is called a "regression," and regressions have become most unwelcome in the mainline kernel. With few exceptions, changes which cause regressions will be backed out if the regression cannot be fixed in a timely manner. Far better to avoid the regression in the first place. It is often argued that a regression can be justified if it causes things to work for more people than it creates problems for. Why not make a change if it brings new functionality to ten systems for each one it breaks? The best answer to this question was expressed by Linus in July, 2007: :: So we don't fix bugs by introducing new problems. That way lies madness, and nobody ever knows if you actually make any real progress at all. Is it two steps forwards, one step back, or one step forward and two steps back?" signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/5] drm/v3d: Add support for compute shader dispatch.
The compute shader dispatch interface is pretty simple -- just pass in
the regs that userspace has passed us, with no CLs to run. However,
with no CL to run it means that we need to do manual cache flushing of
the L2 after the HW execution completes (for SSBO, atomic, and
image_load_store writes that are the output of compute shaders).
This doesn't yet expose the L2 cache's ability to have a region of the
address space not write back to memory (which could be used for
shared_var storage).
So far, the Mesa side has been tested on V3D v4.2 simpenrose (passing
the ES31 tests), and on the kernel side on 7278 (failing atomic
compswap tests in a way that doesn't reproduce on simpenrose).
v2: Fix excessive allocation for the clean_job (reported by Dan
Carpenter). Keep refs on jobs until clean_job is finished, to
avoid spurious MMU errors if the output BOs are freed by userspace
before L2 cleaning is finished.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/v3d/v3d_debugfs.c | 22 +
drivers/gpu/drm/v3d/v3d_drv.c | 10 +-
drivers/gpu/drm/v3d/v3d_drv.h | 28 +-
drivers/gpu/drm/v3d/v3d_fence.c | 2 +
drivers/gpu/drm/v3d/v3d_gem.c | 156 +-
drivers/gpu/drm/v3d/v3d_irq.c | 16 ++-
drivers/gpu/drm/v3d/v3d_regs.h| 73 ++
drivers/gpu/drm/v3d/v3d_sched.c | 121 +--
drivers/gpu/drm/v3d/v3d_trace.h | 94 ++
include/uapi/drm/v3d_drm.h| 28 ++
10 files changed, 531 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_debugfs.c
b/drivers/gpu/drm/v3d/v3d_debugfs.c
index a24af2d2f574..a2dc4262955e 100644
--- a/drivers/gpu/drm/v3d/v3d_debugfs.c
+++ b/drivers/gpu/drm/v3d/v3d_debugfs.c
@@ -58,6 +58,17 @@ static const struct v3d_reg_def v3d_core_reg_defs[] = {
REGDEF(V3D_GMP_VIO_ADDR),
};
+static const struct v3d_reg_def v3d_csd_reg_defs[] = {
+ REGDEF(V3D_CSD_STATUS),
+ REGDEF(V3D_CSD_CURRENT_CFG0),
+ REGDEF(V3D_CSD_CURRENT_CFG1),
+ REGDEF(V3D_CSD_CURRENT_CFG2),
+ REGDEF(V3D_CSD_CURRENT_CFG3),
+ REGDEF(V3D_CSD_CURRENT_CFG4),
+ REGDEF(V3D_CSD_CURRENT_CFG5),
+ REGDEF(V3D_CSD_CURRENT_CFG6),
+};
+
static int v3d_v3d_debugfs_regs(struct seq_file *m, void *unused)
{
struct drm_info_node *node = (struct drm_info_node *)m->private;
@@ -89,6 +100,17 @@ static int v3d_v3d_debugfs_regs(struct seq_file *m, void
*unused)
V3D_CORE_READ(core,
v3d_core_reg_defs[i].reg));
}
+
+ if (v3d_has_csd(v3d)) {
+ for (i = 0; i < ARRAY_SIZE(v3d_csd_reg_defs); i++) {
+ seq_printf(m, "core %d %s (0x%04x): 0x%08x\n",
+ core,
+ v3d_csd_reg_defs[i].name,
+ v3d_csd_reg_defs[i].reg,
+ V3D_CORE_READ(core,
+
v3d_csd_reg_defs[i].reg));
+ }
+ }
}
return 0;
diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c
index 1558178187f6..f8d1d2569c1f 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.c
+++ b/drivers/gpu/drm/v3d/v3d_drv.c
@@ -7,9 +7,9 @@
* This driver supports the Broadcom V3D 3.3 and 4.1 OpenGL ES GPUs.
* For V3D 2.x support, see the VC4 driver.
*
- * Currently only single-core rendering using the binner and renderer,
- * along with TFU (texture formatting unit) rendering is supported.
- * V3D 4.x's CSD (compute shader dispatch) is not yet supported.
+ * The V3D GPU includes a tiled render (composed of a bin and render
+ * pipelines), the TFU (texture formatting unit), and the CSD (compute
+ * shader dispatch).
*/
#include
@@ -193,6 +193,9 @@ static int v3d_get_param_ioctl(struct drm_device *dev, void
*data,
case DRM_V3D_PARAM_SUPPORTS_TFU:
args->value = 1;
return 0;
+ case DRM_V3D_PARAM_SUPPORTS_CSD:
+ args->value = v3d_has_csd(v3d);
+ return 0;
default:
DRM_DEBUG("Unknown parameter %d\n", args->param);
return -EINVAL;
@@ -252,6 +255,7 @@ static const struct drm_ioctl_desc v3d_drm_ioctls[] = {
DRM_IOCTL_DEF_DRV(V3D_GET_PARAM, v3d_get_param_ioctl, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(V3D_GET_BO_OFFSET, v3d_get_bo_offset_ioctl,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(V3D_SUBMIT_TFU, v3d_submit_tfu_ioctl,
DRM_RENDER_ALLOW | DRM_AUTH),
+ DRM_IOCTL_DEF_DRV(V3D_SUBMIT_CSD, v3d_submit_csd_ioctl,
DRM_RENDER_ALLOW | DRM_AUTH),
};
static int v3d_dumb_create(struct drm_file *file_priv,
diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index aa21a70e6879..c4ef640effc2 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++
[PATCH v2 0/5] V3D CSD support, implicit sync fix.
This is a resend of my April 1st series, rebased on the merge of the fence array helpers, and with little fixes for bugs reported by static analysis and one minor race fix I noticed while re-reviewing. Eric Anholt (5): drm/v3d: Switch the type of job-> to reduce casting. drm/v3d: Refactor job management. drm/v3d: Add support for compute shader dispatch. drm/v3d: Drop reservation of a shared slot in the dma-buf reservations. drm/v3d: Add missing implicit synchronization. drivers/gpu/drm/v3d/v3d_debugfs.c | 22 ++ drivers/gpu/drm/v3d/v3d_drv.c | 10 +- drivers/gpu/drm/v3d/v3d_drv.h | 104 +++--- drivers/gpu/drm/v3d/v3d_fence.c | 2 + drivers/gpu/drm/v3d/v3d_gem.c | 548 +++--- drivers/gpu/drm/v3d/v3d_irq.c | 24 +- drivers/gpu/drm/v3d/v3d_regs.h| 73 drivers/gpu/drm/v3d/v3d_sched.c | 380 ++--- drivers/gpu/drm/v3d/v3d_trace.h | 94 + include/uapi/drm/v3d_drm.h| 28 ++ 10 files changed, 908 insertions(+), 377 deletions(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/5] drm/v3d: Add missing implicit synchronization.
It is the expectation of existing userspace (X11 + Mesa, in
particular) that jobs submitted to the kernel against a shared BO will
get implicitly synchronized by their submission order. If we want to
allow clever userspace to disable implicit synchronization, we should
do that under its own submit flag (as amdgpu and lima do).
Note that we currently only implicitly sync for the rendering pass,
not binning -- if you texture-from-pixmap in the binning vertex shader
(vertex coordinate generation), you'll miss out on synchronization.
Fixes flickering when multiple clients are running in parallel,
particularly GL apps and compositors.
v2: Fix a missing refcount on the CSD done fence for L2 cleaning.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/v3d/v3d_drv.h | 11 +++---
drivers/gpu/drm/v3d/v3d_gem.c | 63 +++--
drivers/gpu/drm/v3d/v3d_sched.c | 40 +++--
3 files changed, 53 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index c4ef640effc2..6d31a6a5a08e 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -188,8 +188,10 @@ struct v3d_job {
struct drm_gem_object **bo;
u32 bo_count;
- /* An optional fence userspace can pass in for the job to depend on. */
- struct dma_fence *in_fence;
+ /* Array of struct dma_fence * to block on before submitting this job.
+*/
+ struct xarray deps;
+ unsigned long last_dep;
/* v3d fence to be signaled by IRQ handler when the job is complete. */
struct dma_fence *irq_fence;
@@ -221,11 +223,6 @@ struct v3d_bin_job {
struct v3d_render_job {
struct v3d_job base;
- /* Optional fence for the binner, to depend on before starting
-* our job.
-*/
- struct dma_fence *bin_done_fence;
-
/* GPU virtual addresses of the start/end of the CL job. */
u32 start, end;
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index 6873b14a0d38..f736e021467a 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -243,16 +243,25 @@ v3d_invalidate_caches(struct v3d_dev *v3d)
* to v3d, so we don't attach dma-buf fences to them.
*/
static int
-v3d_lock_bo_reservations(struct drm_gem_object **bos,
-int bo_count,
+v3d_lock_bo_reservations(struct v3d_job *job,
struct ww_acquire_ctx *acquire_ctx)
{
int i, ret;
- ret = drm_gem_lock_reservations(bos, bo_count, acquire_ctx);
+ ret = drm_gem_lock_reservations(job->bo, job->bo_count, acquire_ctx);
if (ret)
return ret;
+ for (i = 0; i < job->bo_count; i++) {
+ ret = drm_gem_fence_array_add_implicit(>deps,
+ job->bo[i], true);
+ if (ret) {
+ drm_gem_unlock_reservations(job->bo, job->bo_count,
+ acquire_ctx);
+ return ret;
+ }
+ }
+
return 0;
}
@@ -339,6 +348,8 @@ static void
v3d_job_free(struct kref *ref)
{
struct v3d_job *job = container_of(ref, struct v3d_job, refcount);
+ unsigned long index;
+ struct dma_fence *fence;
int i;
for (i = 0; i < job->bo_count; i++) {
@@ -347,7 +358,11 @@ v3d_job_free(struct kref *ref)
}
kvfree(job->bo);
- dma_fence_put(job->in_fence);
+ xa_for_each(>deps, index, fence) {
+ dma_fence_put(fence);
+ }
+ xa_destroy(>deps);
+
dma_fence_put(job->irq_fence);
dma_fence_put(job->done_fence);
@@ -414,6 +429,7 @@ v3d_job_init(struct v3d_dev *v3d, struct drm_file
*file_priv,
struct v3d_job *job, void (*free)(struct kref *ref),
u32 in_sync)
{
+ struct dma_fence *in_fence = NULL;
int ret;
job->v3d = v3d;
@@ -423,15 +439,23 @@ v3d_job_init(struct v3d_dev *v3d, struct drm_file
*file_priv,
if (ret < 0)
return ret;
- ret = drm_syncobj_find_fence(file_priv, in_sync, 0, 0, >in_fence);
- if (ret == -EINVAL) {
- pm_runtime_put_autosuspend(v3d->dev);
- return ret;
- }
+ xa_init_flags(>deps, XA_FLAGS_ALLOC);
+
+ ret = drm_syncobj_find_fence(file_priv, in_sync, 0, 0, _fence);
+ if (ret == -EINVAL)
+ goto fail;
+
+ ret = drm_gem_fence_array_add(>deps, in_fence);
+ if (ret)
+ goto fail;
kref_init(>refcount);
return 0;
+fail:
+ xa_destroy(>deps);
+ pm_runtime_put_autosuspend(v3d->dev);
+ return ret;
}
static int
@@ -552,8 +576,7 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
if (ret)
goto fail;
- ret = v3d_lock_bo_reservations(render->base.bo,
[PATCH v2 4/5] drm/v3d: Drop reservation of a shared slot in the dma-buf reservations.
We only set the excl (possible-writing) fence pointer and never add a
shared (read-only) fence.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/v3d/v3d_gem.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index 8bd6fa69f566..6873b14a0d38 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -253,18 +253,6 @@ v3d_lock_bo_reservations(struct drm_gem_object **bos,
if (ret)
return ret;
- /* Reserve space for our shared (read-only) fence references,
-* before we commit the CL to the hardware.
-*/
- for (i = 0; i < bo_count; i++) {
- ret = reservation_object_reserve_shared(bos[i]->resv, 1);
- if (ret) {
- drm_gem_unlock_reservations(bos, bo_count,
- acquire_ctx);
- return ret;
- }
- }
-
return 0;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/5] drm/v3d: Refactor job management.
The CL submission had two jobs embedded in an exec struct. When I
added TFU support, I had to replicate some of the exec stuff and some
of the job stuff. As I went to add CSD, it became clear that actually
what was in exec should just be in the two CL jobs, and it would let
us share a lot more code between the 4 queues.
v2: Fix missing error path in TFU ioctl's bo[] allocation.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/v3d/v3d_drv.h | 77 +++
drivers/gpu/drm/v3d/v3d_gem.c | 365
drivers/gpu/drm/v3d/v3d_irq.c | 8 +-
drivers/gpu/drm/v3d/v3d_sched.c | 259 --
4 files changed, 380 insertions(+), 329 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index 238486925096..aa21a70e6879 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -73,8 +73,8 @@ struct v3d_dev {
struct work_struct overflow_mem_work;
- struct v3d_exec_info *bin_job;
- struct v3d_exec_info *render_job;
+ struct v3d_bin_job *bin_job;
+ struct v3d_render_job *render_job;
struct v3d_tfu_job *tfu_job;
struct v3d_queue_state queue[V3D_MAX_QUEUES];
@@ -123,7 +123,7 @@ struct v3d_bo {
struct drm_mm_node node;
/* List entry for the BO's position in
-* v3d_exec_info->unref_list
+* v3d_render_job->unref_list
*/
struct list_head unref_head;
};
@@ -163,7 +163,15 @@ to_v3d_fence(struct dma_fence *fence)
struct v3d_job {
struct drm_sched_job base;
- struct v3d_exec_info *exec;
+ struct kref refcount;
+
+ struct v3d_dev *v3d;
+
+ /* This is the array of BOs that were looked up at the start
+* of submission.
+*/
+ struct drm_gem_object **bo;
+ u32 bo_count;
/* An optional fence userspace can pass in for the job to depend on. */
struct dma_fence *in_fence;
@@ -171,59 +179,53 @@ struct v3d_job {
/* v3d fence to be signaled by IRQ handler when the job is complete. */
struct dma_fence *irq_fence;
+ /* scheduler fence for when the job is considered complete and
+* the BO reservations can be released.
+*/
+ struct dma_fence *done_fence;
+
+ /* Callback for the freeing of the job on refcount going to 0. */
+ void (*free)(struct kref *ref);
+};
+
+struct v3d_bin_job {
+ struct v3d_job base;
+
/* GPU virtual addresses of the start/end of the CL job. */
u32 start, end;
u32 timedout_ctca, timedout_ctra;
-};
-struct v3d_exec_info {
- struct v3d_dev *v3d;
+ /* Corresponding render job, for attaching our overflow memory. */
+ struct v3d_render_job *render;
+
+ /* Submitted tile memory allocation start/size, tile state. */
+ u32 qma, qms, qts;
+};
- struct v3d_job bin, render;
+struct v3d_render_job {
+ struct v3d_job base;
- /* Fence for when the scheduler considers the binner to be
-* done, for render to depend on.
+ /* Optional fence for the binner, to depend on before starting
+* our job.
*/
struct dma_fence *bin_done_fence;
- /* Fence for when the scheduler considers the render to be
-* done, for when the BOs reservations should be complete.
-*/
- struct dma_fence *render_done_fence;
-
- struct kref refcount;
+ /* GPU virtual addresses of the start/end of the CL job. */
+ u32 start, end;
- /* This is the array of BOs that were looked up at the start of exec. */
- struct drm_gem_object **bo;
- u32 bo_count;
+ u32 timedout_ctca, timedout_ctra;
/* List of overflow BOs used in the job that need to be
* released once the job is complete.
*/
struct list_head unref_list;
-
- /* Submitted tile memory allocation start/size, tile state. */
- u32 qma, qms, qts;
};
struct v3d_tfu_job {
- struct drm_sched_job base;
+ struct v3d_job base;
struct drm_v3d_submit_tfu args;
-
- /* An optional fence userspace can pass in for the job to depend on. */
- struct dma_fence *in_fence;
-
- /* v3d fence to be signaled by IRQ handler when the job is complete. */
- struct dma_fence *irq_fence;
-
- struct v3d_dev *v3d;
-
- struct kref refcount;
-
- /* This is the array of BOs that were looked up at the start of exec. */
- struct drm_gem_object *bo[4];
};
/**
@@ -289,8 +291,7 @@ int v3d_submit_tfu_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
int v3d_wait_bo_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
-void v3d_exec_put(struct v3d_exec_info *exec);
-void v3d_tfu_job_put(struct v3d_tfu_job *exec);
+void v3d_job_put(struct v3d_job *job);
void v3d_reset(struct v3d_dev *v3d);
void
[PATCH v2 1/5] drm/v3d: Switch the type of job-> to reduce casting.
All consumers wanted drm_gem_object * now.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/v3d/v3d_drv.h | 4 ++--
drivers/gpu/drm/v3d/v3d_gem.c | 42 +--
2 files changed, 17 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index 89e5b9852c4d..238486925096 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -195,7 +195,7 @@ struct v3d_exec_info {
struct kref refcount;
/* This is the array of BOs that were looked up at the start of exec. */
- struct v3d_bo **bo;
+ struct drm_gem_object **bo;
u32 bo_count;
/* List of overflow BOs used in the job that need to be
@@ -223,7 +223,7 @@ struct v3d_tfu_job {
struct kref refcount;
/* This is the array of BOs that were looked up at the start of exec. */
- struct v3d_bo *bo[4];
+ struct drm_gem_object *bo[4];
};
/**
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index 93ff8fcbe475..aa0397d12847 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -194,27 +194,17 @@ v3d_invalidate_caches(struct v3d_dev *v3d)
}
static void
-v3d_attach_object_fences(struct v3d_bo **bos, int bo_count,
+v3d_attach_object_fences(struct drm_gem_object **bos, int bo_count,
struct dma_fence *fence)
{
int i;
for (i = 0; i < bo_count; i++) {
/* XXX: Use shared fences for read-only objects. */
- reservation_object_add_excl_fence(bos[i]->base.base.resv,
- fence);
+ reservation_object_add_excl_fence(bos[i]->resv, fence);
}
}
-static void
-v3d_unlock_bo_reservations(struct v3d_bo **bos,
- int bo_count,
- struct ww_acquire_ctx *acquire_ctx)
-{
- drm_gem_unlock_reservations((struct drm_gem_object **)bos, bo_count,
- acquire_ctx);
-}
-
/* Takes the reservation lock on all the BOs being referenced, so that
* at queue submit time we can update the reservations.
*
@@ -223,14 +213,13 @@ v3d_unlock_bo_reservations(struct v3d_bo **bos,
* to v3d, so we don't attach dma-buf fences to them.
*/
static int
-v3d_lock_bo_reservations(struct v3d_bo **bos,
+v3d_lock_bo_reservations(struct drm_gem_object **bos,
int bo_count,
struct ww_acquire_ctx *acquire_ctx)
{
int i, ret;
- ret = drm_gem_lock_reservations((struct drm_gem_object **)bos,
- bo_count, acquire_ctx);
+ ret = drm_gem_lock_reservations(bos, bo_count, acquire_ctx);
if (ret)
return ret;
@@ -238,11 +227,10 @@ v3d_lock_bo_reservations(struct v3d_bo **bos,
* before we commit the CL to the hardware.
*/
for (i = 0; i < bo_count; i++) {
- ret = reservation_object_reserve_shared(bos[i]->base.base.resv,
- 1);
+ ret = reservation_object_reserve_shared(bos[i]->resv, 1);
if (ret) {
- v3d_unlock_bo_reservations(bos, bo_count,
- acquire_ctx);
+ drm_gem_unlock_reservations(bos, bo_count,
+ acquire_ctx);
return ret;
}
}
@@ -319,7 +307,7 @@ v3d_cl_lookup_bos(struct drm_device *dev,
goto fail;
}
drm_gem_object_get(bo);
- exec->bo[i] = to_v3d_bo(bo);
+ exec->bo[i] = bo;
}
spin_unlock(_priv->table_lock);
@@ -347,7 +335,7 @@ v3d_exec_cleanup(struct kref *ref)
dma_fence_put(exec->render_done_fence);
for (i = 0; i < exec->bo_count; i++)
- drm_gem_object_put_unlocked(>bo[i]->base.base);
+ drm_gem_object_put_unlocked(exec->bo[i]);
kvfree(exec->bo);
list_for_each_entry_safe(bo, save, >unref_list, unref_head) {
@@ -378,7 +366,7 @@ v3d_tfu_job_cleanup(struct kref *ref)
for (i = 0; i < ARRAY_SIZE(job->bo); i++) {
if (job->bo[i])
- drm_gem_object_put_unlocked(>bo[i]->base.base);
+ drm_gem_object_put_unlocked(job->bo[i]);
}
pm_runtime_mark_last_busy(v3d->dev);
@@ -532,7 +520,7 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
v3d_attach_object_fences(exec->bo, exec->bo_count,
exec->render_done_fence);
- v3d_unlock_bo_reservations(exec->bo, exec->bo_count, _ctx);
+ drm_gem_unlock_reservations(exec->bo, exec->bo_count, _ctx);
/* Update the return sync object for the */
sync_out = drm_syncobj_find(file_priv,
Re: [PATCH 7/7] drm/lima: Use the drm_gem_fence_array_add helpers for our deps.
Qiang Yu writes: > Indeed not that important, so patch 5&7 is: > Reviewed-and-tested-by: Qiang Yu Merged these two. Thanks for trying it out! signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 203339] New: AMDGPU: virtual_display disables physical outputs
https://bugzilla.kernel.org/show_bug.cgi?id=203339 Bug ID: 203339 Summary: AMDGPU: virtual_display disables physical outputs Product: Drivers Version: 2.5 Kernel Version: 5.0.7 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: parker.l.r...@gmail.com Regression: No Created attachment 282351 --> https://bugzilla.kernel.org/attachment.cgi?id=282351=edit Kernel log Unable to tell if this is intended or if caused by a crash. I have a monitor connected via HDMI. When I use the virtual_display kernel parameter, only the virtual displays show up. amdgpu.virtual_display=:07:00.0,2 Original patchset doesn't mention this usecase. https://lists.freedesktop.org/archives/amd-gfx/2016-August/001058.html Kernel log attached shows some crashes related to dce_virtual_crtc -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Expose "FB_DAMAGE_CLIPS" property to atomic aware user-space only
> > > > If you mean ssh on annarchy.freedesktop.org, I already have one > > with > > username - drawat > > You're added. Please check out the dim toturial and pls ask any > questions here or on irc or wherever - drm(-misc) maintainers are > happy to help out. > -Daniel > Hi I followed the instruction at https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html and submitted my patch, I see that drm-tip has a lot of commits with myself as author(https://cgit.freedesktop.org/drm/drm-tip/log/). Is this expected? Or did I messed up something. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/dp_mst: Register aux-dev nodes for MST ports
On Fri, 2019-04-12 at 12:05 -0400, sunpeng...@amd.com wrote:
> From: Ville Syrjälä
>
> Expose AUX devices for MST ports, similar to how they are exposed for
> SST.
>
> The registered device will have it's MST port path appended in order to
> identify it. i.e. /dev/drm_dp_aux4_mst:0-2-1
>
> So for a MST topology like so:
>
>+-+
>| ASIC |
>+-+
> Conn-0|
> |
>+v+
> +| MST HUB |+
> |+-+|
> | |
> |Port-1 Port-2|
> +-v-+ +-v-+
> | MST | | SST |
> | Display | | Display |
> +---+ +---+
> |Port-1
> x
>
> The list of AUX device names will look like:
>
> AUX Device Name | MST Device
> --+--
> drm_dp_aux0 | MST Hub
> drm_dp_aux1_mst:0-1-1 | MST Display's disconnected DP out
> drm_dp_aux2_mst:0-1 | MST Display
> drm_dp_aux3_mst:0-2 | SST Display
>
> Note that aux devices are only created for Physical Ports. Logical Ports
> are left out, since they are internally connected within the MST device
> (not connected to a DP RX or TX).
>
> Leo Li:
> * Add missing drm_crtc_helper_internal.h include
> * Fix hard-coded offset and size in drm_dp_send_dpcd_read()
> * Only create aux devices for physical ports.
>
> Signed-off-by: Ville Syrjälä
> Signed-off-by: Leo Li
> ---
> drivers/gpu/drm/drm_dp_aux_dev.c | 13 +++-
> drivers/gpu/drm/drm_dp_mst_topology.c | 109 ++-
> ---
> include/drm/drm_dp_helper.h | 4 ++
> include/drm/drm_dp_mst_helper.h | 6 ++
> 4 files changed, 117 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_aux_dev.c
> b/drivers/gpu/drm/drm_dp_aux_dev.c
> index 2310a67..f1241d1 100644
> --- a/drivers/gpu/drm/drm_dp_aux_dev.c
> +++ b/drivers/gpu/drm/drm_dp_aux_dev.c
> @@ -34,6 +34,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -160,7 +161,11 @@ static ssize_t auxdev_read_iter(struct kiocb *iocb,
> struct iov_iter *to)
> break;
> }
>
> - res = drm_dp_dpcd_read(aux_dev->aux, pos, buf, todo);
> + if (aux_dev->aux->is_remote)
> + res = drm_dp_mst_dpcd_read(aux_dev->aux, pos, buf,
> todo);
> + else
> + res = drm_dp_dpcd_read(aux_dev->aux, pos, buf, todo);
> +
m, is there a reason we can't just use the normal ->read and ->write
auxdev callbacks for this instead of mixing layers like this?
> if (res <= 0)
> break;
>
> @@ -207,7 +212,11 @@ static ssize_t auxdev_write_iter(struct kiocb *iocb,
> struct iov_iter *from)
> break;
> }
>
> - res = drm_dp_dpcd_write(aux_dev->aux, pos, buf, todo);
> + if (aux_dev->aux->is_remote)
> + res = drm_dp_mst_dpcd_write(aux_dev->aux, pos, buf,
> todo);
> + else
> + res = drm_dp_dpcd_write(aux_dev->aux, pos, buf, todo);
> +
> if (res <= 0)
> break;
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 2ab16c9..d5282db 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -35,6 +35,8 @@
> #include
> #include
>
> +#include "drm_crtc_helper_internal.h"
> +
> /**
> * DOC: dp mst helper
> *
> @@ -52,6 +54,9 @@ static int drm_dp_dpcd_write_payload(struct
> drm_dp_mst_topology_mgr *mgr,
>int id,
>struct drm_dp_payload *payload);
>
> +static int drm_dp_send_dpcd_read(struct drm_dp_mst_topology_mgr *mgr,
> + struct drm_dp_mst_port *port,
> + int offset, int size, u8 *bytes);
> static int drm_dp_send_dpcd_write(struct drm_dp_mst_topology_mgr *mgr,
> struct drm_dp_mst_port *port,
> int offset, int size, u8 *bytes);
> @@ -941,6 +946,8 @@ static void drm_dp_destroy_port(struct kref *kref)
> struct drm_dp_mst_topology_mgr *mgr = port->mgr;
>
> if (!port->input) {
> + drm_dp_aux_unregister_devnode(>aux);
> +
> port->vcpi.num_slots = 0;
>
> kfree(port->cached_edid);
> @@ -1095,6 +1102,46 @@ static bool drm_dp_port_setup_pdt(struct
> drm_dp_mst_port *port)
> return send_link;
> }
>
> +/**
> + * drm_dp_mst_dpcd_read() - read a series of bytes from the DPCD via
> sideband
> + * @aux: Fake sideband AUX CH
> + * @offset: address of the (first) register to read
> + * @buffer: buffer to store the register values
> + * @size:
Re: [PATCH 1/2] drm/dp_aux: Use non-cyclic idr, add suffix option for aux device
Sorry for the slow response, I've been really busy ;_;
On Fri, 2019-04-12 at 12:05 -0400, sunpeng...@amd.com wrote:
> From: Leo Li
>
> In preparation for adding aux devices for DP MST:
>
> 1. A non-cyclic idr is used for the device minor version. That way,
>hotplug cycling MST devices won't needlessly increment the minor
>version index.
I really like this btw, cyclic idrs are really annoying for drm_dp_aux_dev,
even outside of MST (try reloading a drm driver a couple of times and you'll
understand ;). I think we should split this into another commit though
> 2. A suffix option is added to the aux device file name. It can be used
>to identify the corresponding MST device.
I like this idea, but I think there may be a better way that we can do this.
Using /dev/nvme* as an example, we have the standard dev paths (/dev/nvme0,
/dev/nvme0n1, etc.). But we can also access them through /dev/disk/by-
{id,label,partlabel,partuuid,path,uuid}.
So what if we added something similar for aux devices? We start off with the
standard /dev/drm_dp_aux*, then provide more descriptive symlinks and
directories:
(feel free to come up with better naming then this if you can)
/dev/drm_dp_aux/card0-DP-1 -> /dev/drm_dp_aux1
/dev/drm_dp_aux/card0-DP-2 -> /dev/drm_dp_aux2
etc.
>
> Signed-off-by: Leo Li
> ---
> drivers/gpu/drm/drm_crtc_helper_internal.h | 5 +++--
> drivers/gpu/drm/drm_dp_aux_dev.c | 8
> drivers/gpu/drm/drm_dp_helper.c| 2 +-
> 3 files changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc_helper_internal.h
> b/drivers/gpu/drm/drm_crtc_helper_internal.h
> index b5ac158..9f0907b 100644
> --- a/drivers/gpu/drm/drm_crtc_helper_internal.h
> +++ b/drivers/gpu/drm/drm_crtc_helper_internal.h
> @@ -46,7 +46,7 @@ static inline int drm_fb_helper_modinit(void)
> #ifdef CONFIG_DRM_DP_AUX_CHARDEV
> int drm_dp_aux_dev_init(void);
> void drm_dp_aux_dev_exit(void);
> -int drm_dp_aux_register_devnode(struct drm_dp_aux *aux);
> +int drm_dp_aux_register_devnode(struct drm_dp_aux *aux, const char
> *suffix);
> void drm_dp_aux_unregister_devnode(struct drm_dp_aux *aux);
> #else
> static inline int drm_dp_aux_dev_init(void)
> @@ -58,7 +58,8 @@ static inline void drm_dp_aux_dev_exit(void)
> {
> }
>
> -static inline int drm_dp_aux_register_devnode(struct drm_dp_aux *aux)
> +static inline int drm_dp_aux_register_devnode(struct drm_dp_aux *aux,
> + const char *suffix)
> {
> return 0;
> }
> diff --git a/drivers/gpu/drm/drm_dp_aux_dev.c
> b/drivers/gpu/drm/drm_dp_aux_dev.c
> index 0e4f25d..2310a67 100644
> --- a/drivers/gpu/drm/drm_dp_aux_dev.c
> +++ b/drivers/gpu/drm/drm_dp_aux_dev.c
> @@ -80,8 +80,7 @@ static struct drm_dp_aux_dev *alloc_drm_dp_aux_dev(struct
> drm_dp_aux *aux)
> kref_init(_dev->refcount);
>
> mutex_lock(_idr_mutex);
> - index = idr_alloc_cyclic(_idr, aux_dev, 0, DRM_AUX_MINORS,
> - GFP_KERNEL);
> + index = idr_alloc(_idr, aux_dev, 0, DRM_AUX_MINORS, GFP_KERNEL);
> mutex_unlock(_idr_mutex);
> if (index < 0) {
> kfree(aux_dev);
> @@ -290,7 +289,7 @@ void drm_dp_aux_unregister_devnode(struct drm_dp_aux
> *aux)
> kref_put(_dev->refcount, release_drm_dp_aux_dev);
> }
>
> -int drm_dp_aux_register_devnode(struct drm_dp_aux *aux)
> +int drm_dp_aux_register_devnode(struct drm_dp_aux *aux, const char *suffix)
> {
> struct drm_dp_aux_dev *aux_dev;
> int res;
> @@ -301,7 +300,8 @@ int drm_dp_aux_register_devnode(struct drm_dp_aux *aux)
>
> aux_dev->dev = device_create(drm_dp_aux_dev_class, aux->dev,
>MKDEV(drm_dev_major, aux_dev->index),
> NULL,
> - "drm_dp_aux%d", aux_dev->index);
> + "drm_dp_aux%d%s", aux_dev->index,
> + suffix ? suffix : "");
> if (IS_ERR(aux_dev->dev)) {
> res = PTR_ERR(aux_dev->dev);
> aux_dev->dev = NULL;
> diff --git a/drivers/gpu/drm/drm_dp_helper.c
> b/drivers/gpu/drm/drm_dp_helper.c
> index e2266ac..13f1005 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -1143,7 +1143,7 @@ int drm_dp_aux_register(struct drm_dp_aux *aux)
> strlcpy(aux->ddc.name, aux->name ? aux->name : dev_name(aux->dev),
> sizeof(aux->ddc.name));
>
> - ret = drm_dp_aux_register_devnode(aux);
> + ret = drm_dp_aux_register_devnode(aux, NULL);
> if (ret)
> return ret;
>
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amdgpu: fix drm leases being broken on radv
After a recent commit, access to the DRM_AUTH ioctls become more
permissive. This resulted in a buggy check for drm_master capabilities
inside radv stop working.
This commit adds a backwards compatibility workaround so that the radv
drm_master check keeps working as previously expected.
This fixes SteamVR and other drm lease based apps being broken since
v5.1-rc1
From the usermode side, radv will also be fixed to properly test for
master capabilities:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/669
Fixes: 8059add0478e ("drm: allow render capable master with DRM_AUTH ioctls")
Signed-off-by: Andres Rodriguez
Cc: Daniel Vetter
Cc: David Airlie
Cc: Emil Velikov
Cc: Alex Deucher
Cc: Keith Packard
Reviewed-by: Keith Packard
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 3 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 22 ++
3 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 8d0d7f3dd5fb..e67bfee8d411 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -409,6 +409,9 @@ struct amdgpu_fpriv {
struct mutexbo_list_lock;
struct idr bo_list_handles;
struct amdgpu_ctx_mgr ctx_mgr;
+
+ /* Part of a backwards compatibility hack */
+ boolis_first_ioctl;
};
int amdgpu_file_to_fpriv(struct file *filp, struct amdgpu_fpriv **fpriv);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 7419ea8a388b..cd438afa7092 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1128,6 +1128,7 @@ long amdgpu_drm_ioctl(struct file *filp,
unsigned int cmd, unsigned long arg)
{
struct drm_file *file_priv = filp->private_data;
+ struct amdgpu_fpriv *fpriv = file_priv->driver_priv;
struct drm_device *dev;
long ret;
dev = file_priv->minor->dev;
@@ -1136,6 +1137,7 @@ long amdgpu_drm_ioctl(struct file *filp,
return ret;
ret = drm_ioctl(filp, cmd, arg);
+ fpriv->is_first_ioctl = false;
pm_runtime_mark_last_busy(dev->dev);
pm_runtime_put_autosuspend(dev->dev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index e860412043bb..00c0a2fb2a69 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -455,6 +455,7 @@ static int amdgpu_hw_ip_info(struct amdgpu_device *adev,
static int amdgpu_info_ioctl(struct drm_device *dev, void *data, struct
drm_file *filp)
{
struct amdgpu_device *adev = dev->dev_private;
+ struct amdgpu_fpriv *fpriv = filp->driver_priv;
struct drm_amdgpu_info *info = data;
struct amdgpu_mode_info *minfo = >mode_info;
void __user *out = (void __user *)(uintptr_t)info->return_pointer;
@@ -470,6 +471,26 @@ static int amdgpu_info_ioctl(struct drm_device *dev, void
*data, struct drm_file
switch (info->query) {
case AMDGPU_INFO_ACCEL_WORKING:
+ /* HACK: radv has a fragile open-coded check for drm master
+* The pattern for the call is:
+* open(DRM_NODE_PRIMARY)
+* drmModeCommandWrite( query=AMDGPU_INFO_ACCEL_WORKING )
+*
+* After commit 8059add04 this check stopped working due to
+* operations on a primary node from non-master clients becoming
+* more permissive.
+*
+* This backwards compatibility hack targets the calling pattern
+* above to fail radv from thinking it has master access to the
+* display system ( without reverting 8059add04 ).
+*
+* Users of libdrm will not be affected as some other ioctls are
+* performed between open() and the AMDGPU_INFO_ACCEL_WORKING
+* query.
+*/
+ if (fpriv->is_first_ioctl && !filp->is_master)
+ return -EACCES;
+
ui32 = adev->accel_working;
return copy_to_user(out, , min(size, 4u)) ? -EFAULT : 0;
case AMDGPU_INFO_CRTC_FROM_ID:
@@ -987,6 +1008,7 @@ int amdgpu_driver_open_kms(struct drm_device *dev, struct
drm_file *file_priv)
goto error_vm;
}
+ fpriv->is_first_ioctl = true;
mutex_init(>bo_list_lock);
idr_init(>bo_list_handles);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 14/26] compat_ioctl: move ATYFB_CLK handling to atyfb driver
These are two obscure ioctl commands, in a driver that only
has compatible commands, so just let the driver handle this
itself.
Signed-off-by: Arnd Bergmann
---
drivers/video/fbdev/aty/atyfb_base.c | 12 +++-
fs/compat_ioctl.c| 2 --
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/aty/atyfb_base.c
b/drivers/video/fbdev/aty/atyfb_base.c
index b6fe103df145..1bc4b6672fdc 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -48,7 +48,7 @@
**/
-
+#include
#include
#include
#include
@@ -235,6 +235,13 @@ static int atyfb_pan_display(struct fb_var_screeninfo *var,
struct fb_info *info);
static int atyfb_blank(int blank, struct fb_info *info);
static int atyfb_ioctl(struct fb_info *info, u_int cmd, u_long arg);
+#ifdef CONFIG_COMPAT
+static int atyfb_compat_ioctl(struct fb_info *info, u_int cmd, u_long arg)
+{
+ return atyfb_ioctl(info, cmd, (u_long)compat_ptr(arg));
+}
+#endif
+
#ifdef __sparc__
static int atyfb_mmap(struct fb_info *info, struct vm_area_struct *vma);
#endif
@@ -290,6 +297,9 @@ static struct fb_ops atyfb_ops = {
.fb_pan_display = atyfb_pan_display,
.fb_blank = atyfb_blank,
.fb_ioctl = atyfb_ioctl,
+#ifdef CONFIG_COMPAT
+ .fb_compat_ioctl = atyfb_compat_ioctl,
+#endif
.fb_fillrect= atyfb_fillrect,
.fb_copyarea= atyfb_copyarea,
.fb_imageblit = atyfb_imageblit,
diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index 6eb7a3f51702..a0f230650de2 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -637,8 +637,6 @@ COMPATIBLE_IOCTL(CAPI_CLR_FLAGS)
COMPATIBLE_IOCTL(CAPI_NCCI_OPENCOUNT)
COMPATIBLE_IOCTL(CAPI_NCCI_GETUNIT)
/* Misc. */
-COMPATIBLE_IOCTL(0x41545900) /* ATYIO_CLKR */
-COMPATIBLE_IOCTL(0x41545901) /* ATYIO_CLKW */
COMPATIBLE_IOCTL(PCIIOC_CONTROLLER)
COMPATIBLE_IOCTL(PCIIOC_MMAP_IS_IO)
COMPATIBLE_IOCTL(PCIIOC_MMAP_IS_MEM)
--
2.20.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl
The .ioctl and .compat_ioctl file operations have the same prototype so
they can both point to the same function, which works great almost all
the time when all the commands are compatible.
One exception is the s390 architecture, where a compat pointer is only
31 bit wide, and converting it into a 64-bit pointer requires calling
compat_ptr(). Most drivers here will ever run in s390, but since we now
have a generic helper for it, it's easy enough to use it consistently.
I double-checked all these drivers to ensure that all ioctl arguments
are used as pointers or are ignored, but are not interpreted as integer
values.
Acked-by: Jason Gunthorpe
Acked-by: Daniel Vetter
Acked-by: Mauro Carvalho Chehab
Acked-by: Greg Kroah-Hartman
Acked-by: David Sterba
Acked-by: Darren Hart (VMware)
Acked-by: Jonathan Cameron
Acked-by: Bjorn Andersson
Signed-off-by: Arnd Bergmann
---
drivers/android/binder.c| 2 +-
drivers/crypto/qat/qat_common/adf_ctl_drv.c | 2 +-
drivers/dma-buf/dma-buf.c | 4 +---
drivers/dma-buf/sw_sync.c | 2 +-
drivers/dma-buf/sync_file.c | 2 +-
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c| 2 +-
drivers/hid/hidraw.c| 4 +---
drivers/iio/industrialio-core.c | 2 +-
drivers/infiniband/core/uverbs_main.c | 4 ++--
drivers/media/rc/lirc_dev.c | 4 +---
drivers/mfd/cros_ec_dev.c | 4 +---
drivers/misc/vmw_vmci/vmci_host.c | 2 +-
drivers/nvdimm/bus.c| 4 ++--
drivers/nvme/host/core.c| 2 +-
drivers/pci/switch/switchtec.c | 2 +-
drivers/platform/x86/wmi.c | 2 +-
drivers/rpmsg/rpmsg_char.c | 4 ++--
drivers/sbus/char/display7seg.c | 2 +-
drivers/sbus/char/envctrl.c | 4 +---
drivers/scsi/3w-.c | 4 +---
drivers/scsi/cxlflash/main.c| 2 +-
drivers/scsi/esas2r/esas2r_main.c | 2 +-
drivers/scsi/pmcraid.c | 4 +---
drivers/staging/android/ion/ion.c | 4 +---
drivers/staging/vme/devices/vme_user.c | 2 +-
drivers/tee/tee_core.c | 2 +-
drivers/usb/class/cdc-wdm.c | 2 +-
drivers/usb/class/usbtmc.c | 4 +---
drivers/virt/fsl_hypervisor.c | 2 +-
fs/btrfs/super.c| 2 +-
fs/ceph/dir.c | 2 +-
fs/ceph/file.c | 2 +-
fs/fuse/dev.c | 2 +-
fs/notify/fanotify/fanotify_user.c | 2 +-
fs/userfaultfd.c| 2 +-
net/rfkill/core.c | 2 +-
36 files changed, 39 insertions(+), 57 deletions(-)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index 4b9c7ca492e6..48109ade7234 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -5998,7 +5998,7 @@ const struct file_operations binder_fops = {
.owner = THIS_MODULE,
.poll = binder_poll,
.unlocked_ioctl = binder_ioctl,
- .compat_ioctl = binder_ioctl,
+ .compat_ioctl = compat_ptr_ioctl,
.mmap = binder_mmap,
.open = binder_open,
.flush = binder_flush,
diff --git a/drivers/crypto/qat/qat_common/adf_ctl_drv.c
b/drivers/crypto/qat/qat_common/adf_ctl_drv.c
index abc7a7f64d64..ef0e482ee04f 100644
--- a/drivers/crypto/qat/qat_common/adf_ctl_drv.c
+++ b/drivers/crypto/qat/qat_common/adf_ctl_drv.c
@@ -68,7 +68,7 @@ static long adf_ctl_ioctl(struct file *fp, unsigned int cmd,
unsigned long arg);
static const struct file_operations adf_ctl_ops = {
.owner = THIS_MODULE,
.unlocked_ioctl = adf_ctl_ioctl,
- .compat_ioctl = adf_ctl_ioctl,
+ .compat_ioctl = compat_ptr_ioctl,
};
struct adf_ctl_drv_info {
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 7c858020d14b..0cb336fe6324 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -325,9 +325,7 @@ static const struct file_operations dma_buf_fops = {
.llseek = dma_buf_llseek,
.poll = dma_buf_poll,
.unlocked_ioctl = dma_buf_ioctl,
-#ifdef CONFIG_COMPAT
- .compat_ioctl = dma_buf_ioctl,
-#endif
+ .compat_ioctl = compat_ptr_ioctl,
};
/*
diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
index 32dcf7b4c935..411de6a8a0ad 100644
--- a/drivers/dma-buf/sw_sync.c
+++ b/drivers/dma-buf/sw_sync.c
@@ -419,5 +419,5 @@ const struct file_operations sw_sync_debugfs_fops = {
.open = sw_sync_debugfs_open,
.release= sw_sync_debugfs_release,
.unlocked_ioctl = sw_sync_ioctl,
- .compat_ioctl = sw_sync_ioctl,
+ .compat_ioctl = compat_ptr_ioctl,
};
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index 4f6305ca52c8..0949f91eb85f 100644
[PATCH v3 00/26] compat_ioctl: cleanups
Hi Al, It took me way longer than I had hoped to revisit this series, see https://lore.kernel.org/lkml/20180912150142.157913-1-a...@arndb.de/ for the previously posted version. I've come to the point where all conversion handlers and most COMPATIBLE_IOCTL() entries are gone from this file, but for now, this series only has the parts that have either been reviewed previously, or that are simple enough to include. The main missing piece is the SG_IO/SG_GET_REQUEST_TABLE conversion. I'll post the patches I made for that later, as they need more testing and review from the scsi maintainers. I hope you can still take these for the coming merge window, unless new problems come up. Arnd Arnd Bergmann (26): compat_ioctl: pppoe: fix PPPOEIOCSFWD handling compat_ioctl: move simple ppp command handling into driver compat_ioctl: avoid unused function warning for do_ioctl compat_ioctl: move PPPIOCSCOMPRESS32 to ppp-generic.c compat_ioctl: move PPPIOCSPASS32/PPPIOCSACTIVE32 to ppp_generic.c compat_ioctl: handle PPPIOCGIDLE for 64-bit time_t compat_ioctl: move rtc handling into rtc-dev.c compat_ioctl: add compat_ptr_ioctl() compat_ioctl: move drivers to compat_ptr_ioctl compat_ioctl: use correct compat_ptr() translation in drivers ceph: fix compat_ioctl for ceph_dir_operations compat_ioctl: move more drivers to compat_ptr_ioctl compat_ioctl: move tape handling into drivers compat_ioctl: move ATYFB_CLK handling to atyfb driver compat_ioctl: move isdn/capi ioctl translation into driver compat_ioctl: move rfcomm handlers into driver compat_ioctl: move hci_sock handlers into driver compat_ioctl: remove HCIUART handling compat_ioctl: remove HIDIO translation compat_ioctl: remove translation for sound ioctls compat_ioctl: remove IGNORE_IOCTL() compat_ioctl: remove /dev/random commands compat_ioctl: remove joystick ioctl translation compat_ioctl: remove PCI ioctl translation compat_ioctl: remove /dev/raw ioctl translation compat_ioctl: remove last RAID handling code Documentation/networking/ppp_generic.txt| 2 + arch/um/drivers/hostaudio_kern.c| 1 + drivers/android/binder.c| 2 +- drivers/char/ppdev.c| 12 +- drivers/char/random.c | 1 + drivers/char/tpm/tpm_vtpm_proxy.c | 12 +- drivers/crypto/qat/qat_common/adf_ctl_drv.c | 2 +- drivers/dma-buf/dma-buf.c | 4 +- drivers/dma-buf/sw_sync.c | 2 +- drivers/dma-buf/sync_file.c | 2 +- drivers/firewire/core-cdev.c| 12 +- drivers/gpu/drm/amd/amdkfd/kfd_chardev.c| 2 +- drivers/hid/hidraw.c| 4 +- drivers/hid/usbhid/hiddev.c | 11 +- drivers/hwtracing/stm/core.c| 12 +- drivers/ide/ide-tape.c | 31 +- drivers/iio/industrialio-core.c | 2 +- drivers/infiniband/core/uverbs_main.c | 4 +- drivers/isdn/capi/capi.c| 31 + drivers/isdn/i4l/isdn_ppp.c | 14 +- drivers/media/rc/lirc_dev.c | 4 +- drivers/mfd/cros_ec_dev.c | 4 +- drivers/misc/cxl/flash.c| 8 +- drivers/misc/genwqe/card_dev.c | 23 +- drivers/misc/mei/main.c | 22 +- drivers/misc/vmw_vmci/vmci_host.c | 2 +- drivers/mtd/ubi/cdev.c | 36 +- drivers/net/ppp/ppp_generic.c | 99 +++- drivers/net/ppp/pppoe.c | 7 + drivers/net/ppp/pptp.c | 3 + drivers/net/tap.c | 12 +- drivers/nvdimm/bus.c| 4 +- drivers/nvme/host/core.c| 2 +- drivers/pci/switch/switchtec.c | 2 +- drivers/platform/x86/wmi.c | 2 +- drivers/rpmsg/rpmsg_char.c | 4 +- drivers/rtc/dev.c | 13 +- drivers/rtc/rtc-vr41xx.c| 10 + drivers/s390/char/tape_char.c | 41 +- drivers/sbus/char/display7seg.c | 2 +- drivers/sbus/char/envctrl.c | 4 +- drivers/scsi/3w-.c | 4 +- drivers/scsi/cxlflash/main.c| 2 +- drivers/scsi/esas2r/esas2r_main.c | 2 +- drivers/scsi/megaraid/megaraid_mm.c | 28 +- drivers/scsi/osst.c | 34 +- drivers/scsi/pmcraid.c | 4 +- drivers/scsi/st.c | 35 +- drivers/staging/android/ion/ion.c | 4 +- drivers/staging/pi433/pi433_if.c| 12 +- drivers/staging/vme/devices/vme_user.c | 2 +- drivers/tee/tee_core.c | 2 +- drivers/usb/class/cdc-wdm.c | 2 +- drivers/usb/class/usbtmc.c | 4 +- drivers/usb/core/devio.c
[Bug 110443] vaapi/vpp: wrong output for non 64-bytes align width (ex: 1200)
https://bugs.freedesktop.org/show_bug.cgi?id=110443 --- Comment #2 from Julien Isorce --- Thx for your comment. What about the following in vlVaDeriveImage: - w = align(surf->buffer->width, 2); - h = align(surf->buffer->height, 2); + + alignment = screen->get_param(screen, PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT); + w = align(surf->buffer->width, alignment); + h = align(surf->buffer->height, alignment); here https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/va/image.c#n235 This is not entirely right but I feel it has more chance to succeed than the current align 2. At least it works on my GFX6 card. -- 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 110443] vaapi/vpp: wrong output for non 64-bytes align width (ex: 1200)
https://bugs.freedesktop.org/show_bug.cgi?id=110443 --- Comment #1 from Marek Olšák --- (In reply to Julien Isorce from comment #0) > vaDeriveImage reports wrong stride. > > Indeed Mesa's vlVaDeriveImage always sets the stride to w * 4 for RGBA > format > https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/va/ > image.c#n259 > > This results in wrong video output, see > https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/issues/100 > > Is there a way to know the pipe_resource's stride > https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/va/ > image.c#n283 without exporting it to dmabuf (through whandle.stride) and > without mapping it (drv->pipe->transfer_map / pipe_transfer.stride) ? No, there isn't. whandle.stride is pipe_resource's stride and is for GPU access. pipe_transfer.stride can be different and is for CPU access. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: introduce a capability flag for syncobj timeline support
On Tue, 16 Apr 2019 at 22:58, Lionel Landwerlin wrote: > > Unfortunately userspace users of this API cannot be publicly disclosed > yet. > > This commit effectively disables timeline syncobj ioctls for all > drivers. Each driver wishing to support this feature will need to > expose DRIVER_SYNCOBJ_TIMELINE. > > v2: Add uAPI capability check (Christian) > > Signed-off-by: Lionel Landwerlin > Reviewed-by: Christian König (v1) > Cc: Dave Airlie > Cc: Daniel Vetter > Cc: Christian König > Cc: Chunming Zhou LGTM, Reviewed-by: Dave Airlie Not sure if I'm due anymore misc-next pulls, if so would be good to have it go that way, but otherwise I can pull it into -next when I get some time. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Expose "FB_DAMAGE_CLIPS" property to atomic aware user-space only
On Tue, Apr 16, 2019 at 8:28 PM Deepak Singh Rawat wrote:
>
> On Tue, 2019-04-16 at 20:15 +0200, Daniel Vetter wrote:
> > On Tue, Apr 16, 2019 at 6:21 PM Deepak Singh Rawat > > wrote:
> > >
> > > On Tue, 2019-04-16 at 09:42 +0200, Daniel Vetter wrote:
> > > > On Mon, Apr 15, 2019 at 05:28:05PM +, Deepak Singh Rawat
> > > > wrote:
> > > > > Plane property "FB_DAMAGE_CLIPS" can only be used by atomic
> > > > > aware
> > > > > user-space, so no point exposing it otherwise.
> > > > >
> > > > > Signed-off-by: Deepak Rawat
> > > > > Fixes: d3b21767821e ("drm: Add a new plane property to send
> > > > > damage
> > > > > during plane update")
> > > >
> > > > Makes sense, probably good if we add Cc: sta...@vger.kernel.org
> > > > too
> > >
> > > Hi Daniel, thanks for the review. Sure.
> > >
> > > >
> > > > Reviewed-by: Daniel Vetter
> > > >
> > > > btw, want drm-misc commit rights to push this? Assuming you'd
> > > > then
> > > > push
> > > > vmware drm patches in general ofc. See
> > >
> > > Yes I think it would be a good idea if I can have drm-mics commit
> > > rights. I think for occasional vmwgfx patches it would be ideal for
> > > us
> > > to use drm-mics on the other hand if had some major changes better
> > > to
> > > follow pull request way.
> > >
> > > How to apply for drm-mics commit rights?
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.freedesktop.org%2Fwiki%2FAccountRequests%2Fdata=02%7C01%7Cdrawat%40vmware.com%7C8e0fc2a84e8d43a6ee7d08d6c2978af4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636910353461126728sdata=T4RrZ7vdhhu3t0sn2jhU2axEVl7cr5x2JgOgJzVoEl8%3Dreserved=0
> >
> > you need an ssh account for drm-misc. Reply with the bug report here
> > and I'll ack - drm-misc maintainers already acked.
> > -Daniel
>
> If you mean ssh on annarchy.freedesktop.org, I already have one with
> username - drawat
You're added. Please check out the dim toturial and pls ask any
questions here or on irc or wherever - drm(-misc) maintainers are
happy to help out.
-Daniel
>
> >
> > >
> > > >
> > > >
> > >
> > >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdrm.pages.freedesktop.org%2Fmaintainer-tools%2Fgetting-started.htmldata=02%7C01%7Cdrawat%40vmware.com%7C8e0fc2a84e8d43a6ee7d08d6c2978af4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636910353461126728sdata=ZLOBkqM%2BFVKlutvu4u3kFyW8b%2FKp2fV5UFtfaW0wVZc%3Dreserved=0
> > > >
> > > > Cheers, Daniel
> > > >
> > > > > ---
> > > > > drivers/gpu/drm/drm_mode_config.c | 5 +++--
> > > > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_mode_config.c
> > > > > b/drivers/gpu/drm/drm_mode_config.c
> > > > > index 4a1c2023ccf0..1a346ae1599d 100644
> > > > > --- a/drivers/gpu/drm/drm_mode_config.c
> > > > > +++ b/drivers/gpu/drm/drm_mode_config.c
> > > > > @@ -297,8 +297,9 @@ static int
> > > > > drm_mode_create_standard_properties(struct drm_device *dev)
> > > > > return -ENOMEM;
> > > > > dev->mode_config.prop_crtc_id = prop;
> > > > >
> > > > > - prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
> > > > > "FB_DAMAGE_CLIPS",
> > > > > - 0);
> > > > > + prop = drm_property_create(dev,
> > > > > + DRM_MODE_PROP_ATOMIC | DRM_MODE_PROP_BLOB,
> > > > > + "FB_DAMAGE_CLIPS", 0);
> > > > > if (!prop)
> > > > > return -ENOMEM;
> > > > > dev->mode_config.prop_fb_damage_clips = prop;
> > > > > --
> > > > > 2.21.0
> > > > >
> > > > > ___
> > > > > dri-devel mailing list
> > > > > dri-devel@lists.freedesktop.org
> > > > >
> > >
> > >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-develdata=02%7C01%7Cdrawat%40vmware.com%7C8e0fc2a84e8d43a6ee7d08d6c2978af4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636910353461126728sdata=6zQnD6klo9k3%2FvVP0mOUQeuwgoSZ3q7o0OChNNaoG%2BQ%3Dreserved=0
> > > >
> > > >
> >
> >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH] libdrm: tests: Add planetest test from AOSP sources
On Tue, Apr 16, 2019 at 11:29 AM Sean Paul wrote: > On Tue, Apr 16, 2019 at 09:43:49AM -0700, John Stultz wrote: > > In trying to further align the AOSP libdrm branch with upstream, > > I wanted to submit the added test planetest that they have been > > carrying for awhile. > > > > Mostly sending this out for initial reactions and to stir some > > discussion on if folks think upstreaming this would be useful. > > I'll start :) > > IMO, we should just punt this into orbit. I just wrote it to do some very > basic > testing when atomic was first being developed. I think modetest does all of > this and more, not to mention igt which does _much_ more. So unless someone > actually uses this, and has a compelling reason to upstream it I'd say revert > it > from Android and we'll be in sync. Ok, sounds good. I'll follow up with folks on the AOSP side and nudge them to ok dropping it. Thanks so much for the input! -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 02/12] drm/fb-helper: Avoid race with DRM userspace
Den 16.04.2019 09.59, skrev Daniel Vetter:
> On Sun, Apr 07, 2019 at 06:52:33PM +0200, Noralf Trønnes wrote:
>> drm_fb_helper_is_bound() is used to check if DRM userspace is in control.
>> This is done by looking at the fb on the primary plane. By the time
>> fb-helper gets around to committing, it's possible that the facts have
>> changed.
>>
>> Avoid this race by holding the drm_device->master_mutex lock while
>> committing. When DRM userspace does its first open, it will now wait
>> until fb-helper is done. The helper will stay away if there's a master.
>>
>> Locking rule: Always take the fb-helper lock first.
>>
>> v2:
>> - Remove drm_fb_helper_is_bound() (Daniel Vetter)
>> - No need to check fb_helper->dev->master in
>> drm_fb_helper_single_fb_probe(), restore_fbdev_mode() has the check.
>>
>> Suggested-by: Daniel Vetter
>> Signed-off-by: Noralf Trønnes
>> ---
>> drivers/gpu/drm/drm_auth.c | 20
>> drivers/gpu/drm/drm_fb_helper.c | 90 -
>> drivers/gpu/drm/drm_internal.h | 2 +
>> 3 files changed, 67 insertions(+), 45 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
>> index 1669c42c40ed..db199807b7dc 100644
>> --- a/drivers/gpu/drm/drm_auth.c
>> +++ b/drivers/gpu/drm/drm_auth.c
>> @@ -368,3 +368,23 @@ void drm_master_put(struct drm_master **master)
>> *master = NULL;
>> }
>> EXPORT_SYMBOL(drm_master_put);
>> +
>> +/* Used by drm_client and drm_fb_helper */
>> +bool drm_master_internal_acquire(struct drm_device *dev)
>> +{
>> +mutex_lock(>master_mutex);
>> +if (dev->master) {
>> +mutex_unlock(>master_mutex);
>> +return false;
>> +}
>> +
>> +return true;
>> +}
>> +EXPORT_SYMBOL(drm_master_internal_acquire);
>> +
>> +/* Used by drm_client and drm_fb_helper */
>> +void drm_master_internal_release(struct drm_device *dev)
>> +{
>> +mutex_unlock(>master_mutex);
>> +}
>> +EXPORT_SYMBOL(drm_master_internal_release);
>> diff --git a/drivers/gpu/drm/drm_fb_helper.c
>> b/drivers/gpu/drm/drm_fb_helper.c
>> index 84791dd4a90d..a6be09ae899b 100644
>> --- a/drivers/gpu/drm/drm_fb_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>> @@ -44,6 +44,7 @@
>>
>> #include "drm_crtc_internal.h"
>> #include "drm_crtc_helper_internal.h"
>> +#include "drm_internal.h"
>>
>> static bool drm_fbdev_emulation = true;
>> module_param_named(fbdev_emulation, drm_fbdev_emulation, bool, 0600);
>> @@ -509,7 +510,7 @@ static int restore_fbdev_mode_legacy(struct
>> drm_fb_helper *fb_helper)
>> return ret;
>> }
>>
>> -static int restore_fbdev_mode(struct drm_fb_helper *fb_helper)
>> +static int restore_fbdev_mode_force(struct drm_fb_helper *fb_helper)
>
> Bikeshed: usually the function variant that's run with locks already taken
> is called _locked or has a __ prefix. _force feels a bit misplaced.
This isn't a _locked function in the usual sense, it is: apply modeset
even if there is a DRM master. So we are _forcing a modeset on a
possibly unexpecting DRM userspace. To me a _locked function would imply
that the caller _must_ take a lock in order to use it.
But no big deal, I can rename it _locked if that reads better. After a
few years of reading kernel code I've come to appreciate the consistency
in how things are done and named. Every time things are different it
slows down my internal logic/pattern parser.
>> {
>> struct drm_device *dev = fb_helper->dev;
>>
>> @@ -519,6 +520,21 @@ static int restore_fbdev_mode(struct drm_fb_helper
>> *fb_helper)
>> return restore_fbdev_mode_legacy(fb_helper);
>> }
>>
>> +static int restore_fbdev_mode(struct drm_fb_helper *fb_helper)
>> +{
>> +struct drm_device *dev = fb_helper->dev;
>> +int ret;
>> +
>> +if (!drm_master_internal_acquire(dev))
>> +return -EBUSY;
>> +
>> +ret = restore_fbdev_mode_force(fb_helper);
>> +
>> +drm_master_internal_release(dev);
>> +
>> +return ret;
>> +}
>> +
>> /**
>> * drm_fb_helper_restore_fbdev_mode_unlocked - restore fbdev configuration
>> * @fb_helper: driver-allocated fbdev helper, can be NULL
>> @@ -556,34 +572,6 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct
>> drm_fb_helper *fb_helper)
>> }
>> EXPORT_SYMBOL(drm_fb_helper_restore_fbdev_mode_unlocked);
>>
>> -static bool drm_fb_helper_is_bound(struct drm_fb_helper *fb_helper)
>> -{
>> -struct drm_device *dev = fb_helper->dev;
>> -struct drm_crtc *crtc;
>> -int bound = 0, crtcs_bound = 0;
>> -
>> -/*
>> - * Sometimes user space wants everything disabled, so don't steal the
>> - * display if there's a master.
>> - */
>> -if (READ_ONCE(dev->master))
>> -return false;
>> -
>> -drm_for_each_crtc(crtc, dev) {
>> -drm_modeset_lock(>mutex, NULL);
>> -if (crtc->primary->fb)
>> -crtcs_bound++;
>> -if (crtc->primary->fb == fb_helper->fb)
>> -bound++;
>> -
[PATCH 10/12] drm/amdgpu: add independent DMA-buf import v4
Instead of relying on the DRM functions just implement our own import
functions. This prepares support for taking care of unpinned DMA-buf.
v2: enable for all exporters, not just amdgpu, fix invalidation
handling, lock reservation object while setting callback
v3: change to new dma_buf attach interface
v4: split out from unpinned DMA-buf work
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h | 4 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 42 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 34 +++---
4 files changed, 56 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index f1815223a1a1..95195c427e85 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1254,7 +1254,6 @@ static struct drm_driver kms_driver = {
.gem_prime_export = amdgpu_gem_prime_export,
.gem_prime_import = amdgpu_gem_prime_import,
.gem_prime_res_obj = amdgpu_gem_prime_res_obj,
- .gem_prime_import_sg_table = amdgpu_gem_prime_import_sg_table,
.gem_prime_vmap = amdgpu_gem_prime_vmap,
.gem_prime_vunmap = amdgpu_gem_prime_vunmap,
.gem_prime_mmap = amdgpu_gem_prime_mmap,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h
index 0c50d14a9739..01811d8aa8a9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h
@@ -39,10 +39,6 @@ int amdgpu_gem_object_open(struct drm_gem_object *obj,
void amdgpu_gem_object_close(struct drm_gem_object *obj,
struct drm_file *file_priv);
unsigned long amdgpu_gem_timeout(uint64_t timeout_ns);
-struct drm_gem_object *
-amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
-struct dma_buf_attachment *attach,
-struct sg_table *sg);
struct dma_buf *amdgpu_gem_prime_export(struct drm_device *dev,
struct drm_gem_object *gobj,
int flags);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
index 8d748f9d0292..56e2a606b9a1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
@@ -122,31 +122,28 @@ int amdgpu_gem_prime_mmap(struct drm_gem_object *obj,
struct vm_area_struct *vma
}
/**
- * amdgpu_gem_prime_import_sg_table - _driver.gem_prime_import_sg_table
- * implementation
+ * amdgpu_gem_prime_create_obj - create BO for DMA-buf import
+ *
* @dev: DRM device
- * @attach: DMA-buf attachment
- * @sg: Scatter/gather table
+ * @dma_buf: DMA-buf
*
- * Imports shared DMA buffer memory exported by another device.
+ * Creates an empty SG BO for DMA-buf import.
*
* Returns:
* A new GEM BO of the given DRM device, representing the memory
* described by the given DMA-buf attachment and scatter/gather table.
*/
-struct drm_gem_object *
-amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
-struct dma_buf_attachment *attach,
-struct sg_table *sg)
+static struct drm_gem_object *
+amdgpu_gem_prime_create_obj(struct drm_device *dev, struct dma_buf *dma_buf)
{
- struct reservation_object *resv = attach->dmabuf->resv;
+ struct reservation_object *resv = dma_buf->resv;
struct amdgpu_device *adev = dev->dev_private;
struct amdgpu_bo *bo;
struct amdgpu_bo_param bp;
int ret;
memset(, 0, sizeof(bp));
- bp.size = attach->dmabuf->size;
+ bp.size = dma_buf->size;
bp.byte_align = PAGE_SIZE;
bp.domain = AMDGPU_GEM_DOMAIN_CPU;
bp.flags = 0;
@@ -157,11 +154,9 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
if (ret)
goto error;
- bo->tbo.sg = sg;
- bo->tbo.ttm->sg = sg;
bo->allowed_domains = AMDGPU_GEM_DOMAIN_GTT;
bo->preferred_domains = AMDGPU_GEM_DOMAIN_GTT;
- if (attach->dmabuf->ops != _dmabuf_ops)
+ if (dma_buf->ops != _dmabuf_ops)
bo->prime_shared_count = 1;
ww_mutex_unlock(>lock);
@@ -417,6 +412,11 @@ struct dma_buf *amdgpu_gem_prime_export(struct drm_device
*dev,
struct drm_gem_object *amdgpu_gem_prime_import(struct drm_device *dev,
struct dma_buf *dma_buf)
{
+ struct dma_buf_attach_info attach_info = {
+ .dev = dev->dev,
+ .dmabuf = dma_buf,
+ };
+ struct dma_buf_attachment *attach;
struct drm_gem_object *obj;
if (dma_buf->ops == _dmabuf_ops) {
@@ -431,5 +431,17 @@ struct drm_gem_object *amdgpu_gem_prime_import(struct
drm_device *dev,
}
}
- return
[PATCH 11/12] drm/amdgpu: add DMA-buf pin/unpin implementation
Pin and unpin the DMA-buf exported BOs only on demand and invalidate all
DMA-buf mappings when the underlying BO moves.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 5 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 73 --
2 files changed, 72 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index ec9e45004bff..fdb98eb562db 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -31,6 +31,7 @@
*/
#include
#include
+#include
#include
#include
#include
@@ -1192,6 +1193,10 @@ void amdgpu_bo_move_notify(struct ttm_buffer_object *bo,
amdgpu_bo_kunmap(abo);
+ if (abo->gem_base.dma_buf && !abo->gem_base.import_attach &&
+ bo->mem.mem_type != TTM_PL_SYSTEM)
+ dma_buf_invalidate_mappings(abo->gem_base.dma_buf);
+
/* remember the eviction */
if (evict)
atomic64_inc(>num_evictions);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
index 56e2a606b9a1..40cd89271b20 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
@@ -209,6 +209,61 @@ __reservation_object_make_exclusive(struct
reservation_object *obj)
return -ENOMEM;
}
+/**
+ * amdgpu_gem_pin_dma_buf - _buf_ops.pin_dma_buf implementation
+ *
+ * @dma_buf: DMA-buf to pin in memory
+ *
+ * Pin the BO which is backing the DMA-buf so that it can't move any more.
+ */
+static int amdgpu_gem_pin_dma_buf(struct dma_buf *dma_buf)
+{
+ struct drm_gem_object *obj = dma_buf->priv;
+ struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+
+ /* pin buffer into GTT */
+ return amdgpu_bo_pin(bo, AMDGPU_GEM_DOMAIN_GTT);
+}
+
+/**
+ * amdgpu_gem_unpin_dma_buf - _buf_ops.unpin_dma_buf implementation
+ *
+ * @dma_buf: DMA-buf to unpin
+ *
+ * Unpin a previously pinned BO to make it movable again.
+ */
+static void amdgpu_gem_unpin_dma_buf(struct dma_buf *dma_buf)
+{
+ struct drm_gem_object *obj = dma_buf->priv;
+ struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+
+ amdgpu_bo_unpin(bo);
+}
+
+/**
+ * amdgpu_gem_dma_buf_attach - _buf_ops.attach implementation
+ *
+ * @dma_buf: DMA-buf we attach to
+ * @attach: DMA-buf attachment
+ *
+ * Returns:
+ * Always zero for success.
+ */
+static int amdgpu_gem_dma_buf_attach(struct dma_buf *dma_buf,
+struct dma_buf_attachment *attach)
+{
+ struct drm_gem_object *obj = dma_buf->priv;
+ struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+
+ /* Make sure the buffer is pinned when userspace didn't set GTT as
+* preferred domain. This avoid ping/pong situations with scan out BOs.
+*/
+ if (!(bo->preferred_domains & AMDGPU_GEM_DOMAIN_GTT))
+ attach->invalidate = NULL;
+
+ return 0;
+}
+
/**
* amdgpu_gem_map_dma_buf - _buf_ops.map_dma_buf implementation
* @attach: DMA-buf attachment
@@ -247,10 +302,15 @@ amdgpu_gem_map_dma_buf(struct dma_buf_attachment *attach,
return ERR_PTR(r);
}
- /* pin buffer into GTT */
- r = amdgpu_bo_pin(bo, AMDGPU_GEM_DOMAIN_GTT);
- if (r)
- return ERR_PTR(r);
+ if (attach->invalidate) {
+ /* move buffer into GTT */
+ struct ttm_operation_ctx ctx = { false, false };
+
+ amdgpu_bo_placement_from_domain(bo, AMDGPU_GEM_DOMAIN_GTT);
+ r = ttm_bo_validate(>tbo, >placement, );
+ if (r)
+ return ERR_PTR(r);
+ }
sgt = drm_prime_pages_to_sg(bo->tbo.ttm->pages, bo->tbo.num_pages);
if (IS_ERR(sgt))
@@ -289,8 +349,6 @@ static void amdgpu_gem_unmap_dma_buf(struct
dma_buf_attachment *attach,
struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
- amdgpu_bo_unpin(bo);
-
if (attach->dev->driver != adev->dev->driver && bo->prime_shared_count)
bo->prime_shared_count--;
@@ -357,6 +415,9 @@ static int amdgpu_gem_begin_cpu_access(struct dma_buf
*dma_buf,
const struct dma_buf_ops amdgpu_dmabuf_ops = {
.dynamic_sgt_mapping = true,
+ .attach = amdgpu_gem_dma_buf_attach,
+ .pin = amdgpu_gem_pin_dma_buf,
+ .unpin = amdgpu_gem_unpin_dma_buf,
.map_dma_buf = amdgpu_gem_map_dma_buf,
.unmap_dma_buf = amdgpu_gem_unmap_dma_buf,
.release = drm_gem_dmabuf_release,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/12] dma-buf: add explicit buffer pinning
Add optional explicit pinning callbacks instead of implicitly assume the
exporter pins the buffer when a mapping is created.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 39 +++
include/linux/dma-buf.h | 37 +++--
2 files changed, 70 insertions(+), 6 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index a3738fab3927..f23ff8355505 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -630,6 +630,41 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct
dma_buf_attachment *attach)
}
EXPORT_SYMBOL_GPL(dma_buf_detach);
+/**
+ * dma_buf_pin - Lock down the DMA-buf
+ *
+ * @dmabuf:[in]DMA-buf to lock down.
+ *
+ * Returns:
+ * 0 on success, negative error code on failure.
+ */
+int dma_buf_pin(struct dma_buf *dmabuf)
+{
+ int ret = 0;
+
+ reservation_object_assert_held(dmabuf->resv);
+
+ if (dmabuf->ops->pin)
+ ret = dmabuf->ops->pin(dmabuf);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(dma_buf_pin);
+
+/**
+ * dma_buf_unpin - Remove lock from DMA-buf
+ *
+ * @dmabuf:[in]DMA-buf to unlock.
+ */
+void dma_buf_unpin(struct dma_buf *dmabuf)
+{
+ reservation_object_assert_held(dmabuf->resv);
+
+ if (dmabuf->ops->unpin)
+ dmabuf->ops->unpin(dmabuf);
+}
+EXPORT_SYMBOL_GPL(dma_buf_unpin);
+
/**
* dma_buf_map_attachment_locked - Maps the buffer into _device_ address space
* with the reservation lock held. Is a wrapper for map_dma_buf() of the
@@ -666,6 +701,8 @@ dma_buf_map_attachment_locked(struct dma_buf_attachment
*attach,
*/
if (attach->invalidate)
list_del(>node);
+ else
+ dma_buf_pin(attach->dmabuf);
sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
if (attach->invalidate)
list_add(>node, >dmabuf->attachments);
@@ -735,6 +772,8 @@ void dma_buf_unmap_attachment_locked(struct
dma_buf_attachment *attach,
attach->dmabuf->ops->unmap_dma_buf(attach, sg_table,
direction);
+ if (!attach->invalidate)
+ dma_buf_unpin(attach->dmabuf);
}
EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment_locked);
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index ece4638359a8..a615b74e5894 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -100,14 +100,40 @@ struct dma_buf_ops {
*/
void (*detach)(struct dma_buf *, struct dma_buf_attachment *);
+ /**
+* @pin_dma_buf:
+*
+* This is called by dma_buf_pin and lets the exporter know that an
+* importer assumes that the DMA-buf can't be invalidated any more.
+*
+* This is called with the dmabuf->resv object locked.
+*
+* This callback is optional.
+*
+* Returns:
+*
+* 0 on success, negative error code on failure.
+*/
+ int (*pin)(struct dma_buf *);
+
+ /**
+* @unpin_dma_buf:
+*
+* This is called by dma_buf_unpin and lets the exporter know that an
+* importer doesn't need to the DMA-buf to stay were it is any more.
+*
+* This is called with the dmabuf->resv object locked.
+*
+* This callback is optional.
+*/
+ void (*unpin)(struct dma_buf *);
+
/**
* @map_dma_buf:
*
* This is called by dma_buf_map_attachment() and is used to map a
* shared _buf into device address space, and it is mandatory. It
-* can only be called if @attach has been called successfully. This
-* essentially pins the DMA buffer into place, and it cannot be moved
-* any more
+* can only be called if @attach has been called successfully.
*
* This call may sleep, e.g. when the backing storage first needs to be
* allocated, or moved to a location suitable for all currently attached
@@ -148,9 +174,6 @@ struct dma_buf_ops {
*
* This is called by dma_buf_unmap_attachment() and should unmap and
* release the _table allocated in @map_dma_buf, and it is mandatory.
-* It should also unpin the backing storage if this is the last mapping
-* of the DMA buffer, it the exporter supports backing storage
-* migration.
*
* This is always called with the dmabuf->resv object locked when
* no_sgt_cache is true.
@@ -442,6 +465,8 @@ int dma_buf_fd(struct dma_buf *dmabuf, int flags);
struct dma_buf *dma_buf_get(int fd);
void dma_buf_put(struct dma_buf *dmabuf);
+int dma_buf_pin(struct dma_buf *dmabuf);
+void dma_buf_unpin(struct dma_buf *dmabuf);
struct sg_table *dma_buf_map_attachment_locked(struct dma_buf_attachment *,
enum dma_data_direction);
struct sg_table
[PATCH 12/12] drm/amdgpu: add DMA-buf invalidation callback v2
Allow for invalidation of imported DMA-bufs.
v2: add dma_buf_pin/dma_buf_unpin support
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 24 ++
2 files changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index fdb98eb562db..c3a5a115bfc6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -848,6 +848,9 @@ int amdgpu_bo_pin_restricted(struct amdgpu_bo *bo, u32
domain,
return 0;
}
+ if (bo->gem_base.import_attach)
+ dma_buf_pin(bo->gem_base.import_attach->dmabuf);
+
bo->flags |= AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS;
/* force to pin into visible video ram */
if (!(bo->flags & AMDGPU_GEM_CREATE_NO_CPU_ACCESS))
@@ -931,6 +934,9 @@ int amdgpu_bo_unpin(struct amdgpu_bo *bo)
amdgpu_bo_subtract_pin_size(bo);
+ if (bo->gem_base.import_attach)
+ dma_buf_unpin(bo->gem_base.import_attach->dmabuf);
+
for (i = 0; i < bo->placement.num_placement; i++) {
bo->placements[i].lpfn = 0;
bo->placements[i].flags &= ~TTM_PL_FLAG_NO_EVICT;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
index 40cd89271b20..30634396719b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
@@ -459,6 +459,28 @@ struct dma_buf *amdgpu_gem_prime_export(struct drm_device
*dev,
return buf;
}
+/**
+ * amdgpu_gem_prime_invalidate_mappings - implementation
+ *
+ * @attach: the DMA-buf attachment
+ *
+ * Invalidate the DMA-buf attachment, making sure that the we re-create the
+ * mapping before the next use.
+ */
+static void
+amdgpu_gem_prime_invalidate_mappings(struct dma_buf_attachment *attach)
+{
+ struct ttm_operation_ctx ctx = { false, false };
+ struct drm_gem_object *obj = attach->importer_priv;
+ struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+ struct ttm_placement placement = {};
+ int r;
+
+ r = ttm_bo_validate(>tbo, , );
+ if (r)
+ DRM_ERROR("Failed to invalidate DMA-buf import (%d))\n", r);
+}
+
/**
* amdgpu_gem_prime_import - _driver.gem_prime_import implementation
* @dev: DRM device
@@ -476,6 +498,7 @@ struct drm_gem_object *amdgpu_gem_prime_import(struct
drm_device *dev,
struct dma_buf_attach_info attach_info = {
.dev = dev->dev,
.dmabuf = dma_buf,
+ .invalidate = amdgpu_gem_prime_invalidate_mappings
};
struct dma_buf_attachment *attach;
struct drm_gem_object *obj;
@@ -496,6 +519,7 @@ struct drm_gem_object *amdgpu_gem_prime_import(struct
drm_device *dev,
if (IS_ERR(obj))
return obj;
+ attach_info.importer_priv = obj;
attach = dma_buf_attach(_info);
if (IS_ERR(attach)) {
drm_gem_object_put(obj);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/12] drm: remove prime sg_table caching
That is now done by the DMA-buf helpers instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_prime.c | 76 -
1 file changed, 16 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 1fadf5d5ed33..7e439ea3546a 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -86,11 +86,6 @@ struct drm_prime_member {
struct rb_node handle_rb;
};
-struct drm_prime_attachment {
- struct sg_table *sgt;
- enum dma_data_direction dir;
-};
-
static int drm_prime_add_buf_handle(struct drm_prime_file_private *prime_fpriv,
struct dma_buf *dma_buf, uint32_t handle)
{
@@ -188,25 +183,16 @@ static int drm_prime_lookup_buf_handle(struct
drm_prime_file_private *prime_fpri
* @dma_buf: buffer to attach device to
* @attach: buffer attachment data
*
- * Allocates _prime_attachment and calls _driver.gem_prime_pin for
- * device specific attachment. This can be used as the _buf_ops.attach
- * callback.
+ * Calls _driver.gem_prime_pin for device specific handling. This can be
+ * used as the _buf_ops.attach callback.
*
* Returns 0 on success, negative error code on failure.
*/
int drm_gem_map_attach(struct dma_buf *dma_buf,
struct dma_buf_attachment *attach)
{
- struct drm_prime_attachment *prime_attach;
struct drm_gem_object *obj = dma_buf->priv;
- prime_attach = kzalloc(sizeof(*prime_attach), GFP_KERNEL);
- if (!prime_attach)
- return -ENOMEM;
-
- prime_attach->dir = DMA_NONE;
- attach->priv = prime_attach;
-
return drm_gem_pin(obj);
}
EXPORT_SYMBOL(drm_gem_map_attach);
@@ -222,26 +208,8 @@ EXPORT_SYMBOL(drm_gem_map_attach);
void drm_gem_map_detach(struct dma_buf *dma_buf,
struct dma_buf_attachment *attach)
{
- struct drm_prime_attachment *prime_attach = attach->priv;
struct drm_gem_object *obj = dma_buf->priv;
- if (prime_attach) {
- struct sg_table *sgt = prime_attach->sgt;
-
- if (sgt) {
- if (prime_attach->dir != DMA_NONE)
- dma_unmap_sg_attrs(attach->dev, sgt->sgl,
- sgt->nents,
- prime_attach->dir,
- DMA_ATTR_SKIP_CPU_SYNC);
- sg_free_table(sgt);
- }
-
- kfree(sgt);
- kfree(prime_attach);
- attach->priv = NULL;
- }
-
drm_gem_unpin(obj);
}
EXPORT_SYMBOL(drm_gem_map_detach);
@@ -286,39 +254,22 @@ void drm_prime_remove_buf_handle_locked(struct
drm_prime_file_private *prime_fpr
struct sg_table *drm_gem_map_dma_buf(struct dma_buf_attachment *attach,
enum dma_data_direction dir)
{
- struct drm_prime_attachment *prime_attach = attach->priv;
struct drm_gem_object *obj = attach->dmabuf->priv;
struct sg_table *sgt;
- if (WARN_ON(dir == DMA_NONE || !prime_attach))
+ if (WARN_ON(dir == DMA_NONE))
return ERR_PTR(-EINVAL);
- /* return the cached mapping when possible */
- if (prime_attach->dir == dir)
- return prime_attach->sgt;
-
- /*
-* two mappings with different directions for the same attachment are
-* not allowed
-*/
- if (WARN_ON(prime_attach->dir != DMA_NONE))
- return ERR_PTR(-EBUSY);
-
if (obj->funcs)
sgt = obj->funcs->get_sg_table(obj);
else
sgt = obj->dev->driver->gem_prime_get_sg_table(obj);
- if (!IS_ERR(sgt)) {
- if (!dma_map_sg_attrs(attach->dev, sgt->sgl, sgt->nents, dir,
- DMA_ATTR_SKIP_CPU_SYNC)) {
- sg_free_table(sgt);
- kfree(sgt);
- sgt = ERR_PTR(-ENOMEM);
- } else {
- prime_attach->sgt = sgt;
- prime_attach->dir = dir;
- }
+ if (!dma_map_sg_attrs(attach->dev, sgt->sgl, sgt->nents, dir,
+ DMA_ATTR_SKIP_CPU_SYNC)) {
+ sg_free_table(sgt);
+ kfree(sgt);
+ sgt = ERR_PTR(-ENOMEM);
}
return sgt;
@@ -331,14 +282,19 @@ EXPORT_SYMBOL(drm_gem_map_dma_buf);
* @sgt: scatterlist info of the buffer to unmap
* @dir: direction of DMA transfer
*
- * Not implemented. The unmap is done at drm_gem_map_detach(). This can be
- * used as the _buf_ops.unmap_dma_buf callback.
+ * This can be used as the _buf_ops.unmap_dma_buf callback.
*/
void drm_gem_unmap_dma_buf(struct dma_buf_attachment *attach,
struct sg_table *sgt,
enum
[PATCH 01/12] dma-buf: add dynamic caching of sg_table
To allow a smooth transition from pinning buffer objects to dynamic
invalidation we first start to cache the sg_table for an attachment
unless the driver explicitly says to not do so.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 24
include/linux/dma-buf.h | 11 +++
2 files changed, 35 insertions(+)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 7c858020d14b..65161a82d4d5 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -573,6 +573,20 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf
*dmabuf,
list_add(>node, >attachments);
mutex_unlock(>lock);
+
+ if (!dmabuf->ops->dynamic_sgt_mapping) {
+ struct sg_table *sgt;
+
+ sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL);
+ if (!sgt)
+ sgt = ERR_PTR(-ENOMEM);
+ if (IS_ERR(sgt)) {
+ dma_buf_detach(dmabuf, attach);
+ return ERR_CAST(sgt);
+ }
+ attach->sgt = sgt;
+ }
+
return attach;
err_attach:
@@ -595,6 +609,10 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct
dma_buf_attachment *attach)
if (WARN_ON(!dmabuf || !attach))
return;
+ if (attach->sgt)
+ dmabuf->ops->unmap_dma_buf(attach, attach->sgt,
+ DMA_BIDIRECTIONAL);
+
mutex_lock(>lock);
list_del(>node);
if (dmabuf->ops->detach)
@@ -630,6 +648,9 @@ struct sg_table *dma_buf_map_attachment(struct
dma_buf_attachment *attach,
if (WARN_ON(!attach || !attach->dmabuf))
return ERR_PTR(-EINVAL);
+ if (attach->sgt)
+ return attach->sgt;
+
sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
if (!sg_table)
sg_table = ERR_PTR(-ENOMEM);
@@ -657,6 +678,9 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment
*attach,
if (WARN_ON(!attach || !attach->dmabuf || !sg_table))
return;
+ if (attach->sgt == sg_table)
+ return;
+
attach->dmabuf->ops->unmap_dma_buf(attach, sg_table,
direction);
}
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 58725f890b5b..0d9c3c13c9fb 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -51,6 +51,16 @@ struct dma_buf_attachment;
* @vunmap: [optional] unmaps a vmap from the buffer
*/
struct dma_buf_ops {
+ /**
+* @dynamic_sgt_mapping:
+*
+* Flag controlling the caching of the sg_table in the DMA-buf helpers.
+* If not set the sg_table is created during device attaching, if set
+* the sg_table is created dynamically when dma_buf_map_attachment() is
+* called.
+*/
+ bool dynamic_sgt_mapping;
+
/**
* @attach:
*
@@ -323,6 +333,7 @@ struct dma_buf_attachment {
struct device *dev;
struct list_head node;
void *priv;
+ struct sg_table *sgt;
};
/**
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/12] drm/ttm: remove the backing store if no placement is given
Pipeline removal of the BOs backing store when no placement is given
during validation.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 41d07faa2eae..8e7e7caee9d5 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1161,6 +1161,18 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
uint32_t new_flags;
reservation_object_assert_held(bo->resv);
+
+ /*
+* Remove the backing store if no placement is given.
+*/
+ if (!placement->num_placement && !placement->num_busy_placement) {
+ ret = ttm_bo_pipeline_gutting(bo);
+ if (ret)
+ return ret;
+
+ return ttm_tt_create(bo, false);
+ }
+
/*
* Check whether we need to move buffer.
*/
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/12] drm/ttm: use the parent resv for ghost objects
This way we can even pipeline imported BO evictions.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 18 +-
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 895d77d799e4..97f35c4bda35 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -486,7 +486,6 @@ static int ttm_buffer_object_transfer(struct
ttm_buffer_object *bo,
struct ttm_buffer_object **new_obj)
{
struct ttm_transfer_obj *fbo;
- int ret;
fbo = kmalloc(sizeof(*fbo), GFP_KERNEL);
if (!fbo)
@@ -517,10 +516,7 @@ static int ttm_buffer_object_transfer(struct
ttm_buffer_object *bo,
kref_init(>base.kref);
fbo->base.destroy = _transfered_destroy;
fbo->base.acc_size = 0;
- fbo->base.resv = >base.ttm_resv;
- reservation_object_init(fbo->base.resv);
- ret = reservation_object_trylock(fbo->base.resv);
- WARN_ON(!ret);
+ reservation_object_init(>base.ttm_resv);
*new_obj = >base;
return 0;
@@ -716,8 +712,6 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo,
if (ret)
return ret;
- reservation_object_add_excl_fence(ghost_obj->resv, fence);
-
/**
* If we're not moving to fixed memory, the TTM object
* needs to stay alive. Otherwhise hang it on the ghost
@@ -729,7 +723,6 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo,
else
bo->ttm = NULL;
- ttm_bo_unreserve(ghost_obj);
ttm_bo_put(ghost_obj);
}
@@ -772,8 +765,6 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
if (ret)
return ret;
- reservation_object_add_excl_fence(ghost_obj->resv, fence);
-
/**
* If we're not moving to fixed memory, the TTM object
* needs to stay alive. Otherwhise hang it on the ghost
@@ -785,7 +776,6 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
else
bo->ttm = NULL;
- ttm_bo_unreserve(ghost_obj);
ttm_bo_put(ghost_obj);
} else if (from->flags & TTM_MEMTYPE_FLAG_FIXED) {
@@ -841,16 +831,10 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
if (ret)
return ret;
- ret = reservation_object_copy_fences(ghost->resv, bo->resv);
- /* Last resort, wait for the BO to be idle when we are OOM */
- if (ret)
- ttm_bo_wait(bo, false, false);
-
memset(>mem, 0, sizeof(bo->mem));
bo->mem.mem_type = TTM_PL_SYSTEM;
bo->ttm = NULL;
- ttm_bo_unreserve(ghost);
ttm_bo_put(ghost);
return 0;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/12] dma-buf: add optional invalidate_mappings callback v5
Each importer can now provide an invalidate_mappings callback.
This allows the exporter to provide the mappings without the need to pin
the backing store.
v2: don't try to invalidate mappings when the callback is NULL,
lock the reservation obj while using the attachments,
add helper to set the callback
v3: move flag for invalidation support into the DMA-buf,
use new attach_info structure to set the callback
v4: use importer_priv field instead of mangling exporter priv.
v5: drop invalidation_supported flag
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 37 +
include/linux/dma-buf.h | 33 +++--
2 files changed, 68 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 83c92bfd964c..a3738fab3927 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -563,6 +563,8 @@ struct dma_buf_attachment *dma_buf_attach(const struct
dma_buf_attach_info *info
attach->dev = info->dev;
attach->dmabuf = dmabuf;
+ attach->importer_priv = info->importer_priv;
+ attach->invalidate = info->invalidate;
mutex_lock(>lock);
@@ -571,7 +573,9 @@ struct dma_buf_attachment *dma_buf_attach(const struct
dma_buf_attach_info *info
if (ret)
goto err_attach;
}
+ reservation_object_lock(dmabuf->resv, NULL);
list_add(>node, >attachments);
+ reservation_object_unlock(dmabuf->resv);
mutex_unlock(>lock);
@@ -615,7 +619,9 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct
dma_buf_attachment *attach)
DMA_BIDIRECTIONAL);
mutex_lock(>lock);
+ reservation_object_lock(dmabuf->resv, NULL);
list_del(>node);
+ reservation_object_unlock(dmabuf->resv);
if (dmabuf->ops->detach)
dmabuf->ops->detach(dmabuf, attach);
@@ -653,7 +659,16 @@ dma_buf_map_attachment_locked(struct dma_buf_attachment
*attach,
if (attach->sgt)
return attach->sgt;
+ /*
+* Mapping a DMA-buf can trigger its invalidation, prevent sending this
+* event to the caller by temporary removing this attachment from the
+* list.
+*/
+ if (attach->invalidate)
+ list_del(>node);
sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
+ if (attach->invalidate)
+ list_add(>node, >dmabuf->attachments);
if (!sg_table)
sg_table = ERR_PTR(-ENOMEM);
@@ -751,6 +766,26 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment
*attach,
}
EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
+/**
+ * dma_buf_invalidate_mappings - invalidate all mappings of this dma_buf
+ *
+ * @dmabuf:[in]buffer which mappings should be invalidated
+ *
+ * Informs all attachmenst that they need to destroy and recreated all their
+ * mappings.
+ */
+void dma_buf_invalidate_mappings(struct dma_buf *dmabuf)
+{
+ struct dma_buf_attachment *attach;
+
+ reservation_object_assert_held(dmabuf->resv);
+
+ list_for_each_entry(attach, >attachments, node)
+ if (attach->invalidate)
+ attach->invalidate(attach);
+}
+EXPORT_SYMBOL_GPL(dma_buf_invalidate_mappings);
+
/**
* DOC: cpu access
*
@@ -1163,10 +1198,12 @@ static int dma_buf_debug_show(struct seq_file *s, void
*unused)
seq_puts(s, "\tAttached Devices:\n");
attach_count = 0;
+ reservation_object_lock(buf_obj->resv, NULL);
list_for_each_entry(attach_obj, _obj->attachments, node) {
seq_printf(s, "\t%s\n", dev_name(attach_obj->dev));
attach_count++;
}
+ reservation_object_unlock(buf_obj->resv);
seq_printf(s, "Total %d devices attached\n\n",
attach_count);
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 7e23758db3a4..ece4638359a8 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -324,6 +324,7 @@ struct dma_buf {
* @dev: device attached to the buffer.
* @node: list of dma_buf_attachment.
* @priv: exporter specific attachment data.
+ * @importer_priv: importer specific attachment data.
*
* This structure holds the attachment information between the dma_buf buffer
* and its user device(s). The list contains one attachment struct per device
@@ -340,6 +341,29 @@ struct dma_buf_attachment {
struct list_head node;
void *priv;
struct sg_table *sgt;
+ void *importer_priv;
+
+ /**
+* @invalidate:
+*
+* Optional callback provided by the importer of the dma-buf.
+*
+* If provided the exporter can avoid pinning the backing store while
+* mappings exists.
+*
+* The function
[PATCH 09/12] drm/amdgpu: add independent DMA-buf export v3
The caching of SGT's is actually quite harmful and should probably removed
altogether when all drivers are audited.
Start by providing a separate DMA-buf export implementation in amdgpu. This is
also a prerequisite of unpinned DMA-buf handling.
v2: fix unintended recursion, remove debugging leftovers
v3: split out from unpinned DMA-buf work
v4: rebase on top of new no_sgt_cache flag
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 94 ++-
3 files changed, 40 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 13a68f62bcc8..f1815223a1a1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1254,7 +1254,6 @@ static struct drm_driver kms_driver = {
.gem_prime_export = amdgpu_gem_prime_export,
.gem_prime_import = amdgpu_gem_prime_import,
.gem_prime_res_obj = amdgpu_gem_prime_res_obj,
- .gem_prime_get_sg_table = amdgpu_gem_prime_get_sg_table,
.gem_prime_import_sg_table = amdgpu_gem_prime_import_sg_table,
.gem_prime_vmap = amdgpu_gem_prime_vmap,
.gem_prime_vunmap = amdgpu_gem_prime_vunmap,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h
index f1ddfc50bcc7..0c50d14a9739 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h
@@ -39,7 +39,6 @@ int amdgpu_gem_object_open(struct drm_gem_object *obj,
void amdgpu_gem_object_close(struct drm_gem_object *obj,
struct drm_file *file_priv);
unsigned long amdgpu_gem_timeout(uint64_t timeout_ns);
-struct sg_table *amdgpu_gem_prime_get_sg_table(struct drm_gem_object *obj);
struct drm_gem_object *
amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
struct dma_buf_attachment *attach,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
index a38e0fb4a6fe..8d748f9d0292 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
@@ -40,22 +40,6 @@
#include
#include
-/**
- * amdgpu_gem_prime_get_sg_table - _driver.gem_prime_get_sg_table
- * implementation
- * @obj: GEM buffer object (BO)
- *
- * Returns:
- * A scatter/gather table for the pinned pages of the BO's memory.
- */
-struct sg_table *amdgpu_gem_prime_get_sg_table(struct drm_gem_object *obj)
-{
- struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
- int npages = bo->tbo.num_pages;
-
- return drm_prime_pages_to_sg(bo->tbo.ttm->pages, npages);
-}
-
/**
* amdgpu_gem_prime_vmap - _buf_ops.vmap implementation
* @obj: GEM BO
@@ -231,34 +215,29 @@ __reservation_object_make_exclusive(struct
reservation_object *obj)
}
/**
- * amdgpu_gem_map_attach - _buf_ops.attach implementation
- * @dma_buf: Shared DMA buffer
+ * amdgpu_gem_map_dma_buf - _buf_ops.map_dma_buf implementation
* @attach: DMA-buf attachment
+ * @dir: DMA direction
*
* Makes sure that the shared DMA buffer can be accessed by the target device.
* For now, simply pins it to the GTT domain, where it should be accessible by
* all DMA devices.
*
* Returns:
- * 0 on success or a negative error code on failure.
+ * sg_table filled with the DMA addresses to use or ERR_PRT with negative error
+ * code.
*/
-static int amdgpu_gem_map_attach(struct dma_buf *dma_buf,
-struct dma_buf_attachment *attach)
+static struct sg_table *
+amdgpu_gem_map_dma_buf(struct dma_buf_attachment *attach,
+ enum dma_data_direction dir)
{
+ struct dma_buf *dma_buf = attach->dmabuf;
struct drm_gem_object *obj = dma_buf->priv;
struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+ struct sg_table *sgt;
long r;
- r = drm_gem_map_attach(dma_buf, attach);
- if (r)
- return r;
-
- r = amdgpu_bo_reserve(bo, false);
- if (unlikely(r != 0))
- goto error_detach;
-
-
if (attach->dev->driver != adev->dev->driver) {
/*
* We only create shared fences for internal use, but importers
@@ -270,53 +249,61 @@ static int amdgpu_gem_map_attach(struct dma_buf *dma_buf,
*/
r = __reservation_object_make_exclusive(bo->tbo.resv);
if (r)
- goto error_unreserve;
+ return ERR_PTR(r);
}
/* pin buffer into GTT */
r = amdgpu_bo_pin(bo, AMDGPU_GEM_DOMAIN_GTT);
if (r)
- goto error_unreserve;
+ return ERR_PTR(r);
+
+ sgt = drm_prime_pages_to_sg(bo->tbo.ttm->pages, bo->tbo.num_pages);
+ if (IS_ERR(sgt))
+
[PATCH 02/12] dma-buf: add dma_buf_(un)map_attachment_locked variants v3
Add function variants which can be called with the reservation lock
already held.
v2: reordered, add lockdep asserts, fix kerneldoc
v3: rebased on sgt caching
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 63 +++
include/linux/dma-buf.h | 5
2 files changed, 68 insertions(+)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 65161a82d4d5..ef480e5fb239 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -623,6 +623,43 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct
dma_buf_attachment *attach)
}
EXPORT_SYMBOL_GPL(dma_buf_detach);
+/**
+ * dma_buf_map_attachment_locked - Maps the buffer into _device_ address space
+ * with the reservation lock held. Is a wrapper for map_dma_buf() of the
+ *
+ * Returns the scatterlist table of the attachment;
+ * dma_buf_ops.
+ * @attach:[in]attachment whose scatterlist is to be returned
+ * @direction: [in]direction of DMA transfer
+ *
+ * Returns sg_table containing the scatterlist to be returned; returns ERR_PTR
+ * on error. May return -EINTR if it is interrupted by a signal.
+ *
+ * A mapping must be unmapped by using dma_buf_unmap_attachment_locked(). Note
+ * that the underlying backing storage is pinned for as long as a mapping
+ * exists, therefore users/importers should not hold onto a mapping for undue
+ * amounts of time.
+ */
+struct sg_table *
+dma_buf_map_attachment_locked(struct dma_buf_attachment *attach,
+ enum dma_data_direction direction)
+{
+ struct sg_table *sg_table;
+
+ might_sleep();
+ reservation_object_assert_held(attach->dmabuf->resv);
+
+ if (attach->sgt)
+ return attach->sgt;
+
+ sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
+ if (!sg_table)
+ sg_table = ERR_PTR(-ENOMEM);
+
+ return sg_table;
+}
+EXPORT_SYMBOL_GPL(dma_buf_map_attachment_locked);
+
/**
* dma_buf_map_attachment - Returns the scatterlist table of the attachment;
* mapped into _device_ address space. Is a wrapper for map_dma_buf() of the
@@ -659,6 +696,32 @@ struct sg_table *dma_buf_map_attachment(struct
dma_buf_attachment *attach,
}
EXPORT_SYMBOL_GPL(dma_buf_map_attachment);
+/**
+ * dma_buf_unmap_attachment_locked - unmaps the buffer with reservation lock
+ * held, should deallocate the associated scatterlist. Is a wrapper for
+ * unmap_dma_buf() of dma_buf_ops.
+ * @attach:[in]attachment to unmap buffer from
+ * @sg_table: [in]scatterlist info of the buffer to unmap
+ * @direction: [in]direction of DMA transfer
+ *
+ * This unmaps a DMA mapping for @attached obtained by
+ * dma_buf_map_attachment_locked().
+ */
+void dma_buf_unmap_attachment_locked(struct dma_buf_attachment *attach,
+struct sg_table *sg_table,
+enum dma_data_direction direction)
+{
+ might_sleep();
+ reservation_object_assert_held(attach->dmabuf->resv);
+
+ if (attach->sgt == sg_table)
+ return;
+
+ attach->dmabuf->ops->unmap_dma_buf(attach, sg_table,
+ direction);
+}
+EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment_locked);
+
/**
* dma_buf_unmap_attachment - unmaps and decreases usecount of the buffer;might
* deallocate the scatterlist associated. Is a wrapper for unmap_dma_buf() of
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 0d9c3c13c9fb..18a78be53541 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -395,8 +395,13 @@ int dma_buf_fd(struct dma_buf *dmabuf, int flags);
struct dma_buf *dma_buf_get(int fd);
void dma_buf_put(struct dma_buf *dmabuf);
+struct sg_table *dma_buf_map_attachment_locked(struct dma_buf_attachment *,
+ enum dma_data_direction);
struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *,
enum dma_data_direction);
+void dma_buf_unmap_attachment_locked(struct dma_buf_attachment *,
+struct sg_table *,
+enum dma_data_direction);
void dma_buf_unmap_attachment(struct dma_buf_attachment *, struct sg_table *,
enum dma_data_direction);
int dma_buf_begin_cpu_access(struct dma_buf *dma_buf,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/12] dma-buf: lock the reservation object during (un)map_dma_buf v3
Make it mandatory for dynamic dma-buf callbacks to be called with the
reservation lock held.
For static dma-buf exporters we still have the fallback of using cached sgt.
v2: reordered
v3: rebased on sgt caching
v4: use the cached sgt when possible
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 24 ++-
drivers/gpu/drm/armada/armada_gem.c | 6 -
drivers/gpu/drm/drm_prime.c | 6 -
drivers/gpu/drm/i915/i915_gem_dmabuf.c| 6 -
drivers/gpu/drm/tegra/gem.c | 6 -
drivers/gpu/drm/udl/udl_dmabuf.c | 6 -
.../common/videobuf2/videobuf2-dma-contig.c | 6 -
.../media/common/videobuf2/videobuf2-dma-sg.c | 6 -
drivers/staging/media/tegra-vde/tegra-vde.c | 6 -
include/linux/dma-buf.h | 23 --
10 files changed, 74 insertions(+), 21 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index ef480e5fb239..83c92bfd964c 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -532,8 +532,9 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
/**
* dma_buf_attach - Add the device to dma_buf's attachments list; optionally,
* calls attach() of dma_buf_ops to allow device-specific attach functionality
- * @dmabuf:[in]buffer to attach device to.
- * @dev: [in]device to be attached.
+ * @info: [in]holds all the attach related information provided
+ * by the importer. see dma_buf_attach_info
+ * for further details.
*
* Returns struct dma_buf_attachment pointer for this attachment. Attachments
* must be cleaned up by calling dma_buf_detach().
@@ -547,20 +548,20 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
* accessible to @dev, and cannot be moved to a more suitable place. This is
* indicated with the error code -EBUSY.
*/
-struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
- struct device *dev)
+struct dma_buf_attachment *dma_buf_attach(const struct dma_buf_attach_info
*info)
{
+ struct dma_buf *dmabuf = info->dmabuf;
struct dma_buf_attachment *attach;
int ret;
- if (WARN_ON(!dmabuf || !dev))
+ if (WARN_ON(!dmabuf || !info->dev))
return ERR_PTR(-EINVAL);
attach = kzalloc(sizeof(*attach), GFP_KERNEL);
if (!attach)
return ERR_PTR(-ENOMEM);
- attach->dev = dev;
+ attach->dev = info->dev;
attach->dmabuf = dmabuf;
mutex_lock(>lock);
@@ -688,9 +689,9 @@ struct sg_table *dma_buf_map_attachment(struct
dma_buf_attachment *attach,
if (attach->sgt)
return attach->sgt;
- sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
- if (!sg_table)
- sg_table = ERR_PTR(-ENOMEM);
+ reservation_object_lock(attach->dmabuf->resv, NULL);
+ sg_table = dma_buf_map_attachment_locked(attach, direction);
+ reservation_object_unlock(attach->dmabuf->resv);
return sg_table;
}
@@ -744,8 +745,9 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment
*attach,
if (attach->sgt == sg_table)
return;
- attach->dmabuf->ops->unmap_dma_buf(attach, sg_table,
- direction);
+ reservation_object_lock(attach->dmabuf->resv, NULL);
+ dma_buf_unmap_attachment_locked(attach, sg_table, direction);
+ reservation_object_unlock(attach->dmabuf->resv);
}
EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
diff --git a/drivers/gpu/drm/armada/armada_gem.c
b/drivers/gpu/drm/armada/armada_gem.c
index 642d0e70d0f8..19c47821032f 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -501,6 +501,10 @@ armada_gem_prime_export(struct drm_device *dev, struct
drm_gem_object *obj,
struct drm_gem_object *
armada_gem_prime_import(struct drm_device *dev, struct dma_buf *buf)
{
+ struct dma_buf_attach_info attach_info = {
+ .dev = dev->dev,
+ .dmabuf = buf
+ };
struct dma_buf_attachment *attach;
struct armada_gem_object *dobj;
@@ -516,7 +520,7 @@ armada_gem_prime_import(struct drm_device *dev, struct
dma_buf *buf)
}
}
- attach = dma_buf_attach(buf, dev->dev);
+ attach = dma_buf_attach(_info);
if (IS_ERR(attach))
return ERR_CAST(attach);
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 231e3f6d5f41..1fadf5d5ed33 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -709,6 +709,10 @@ struct drm_gem_object *drm_gem_prime_import_dev(struct
drm_device *dev,
struct dma_buf *dma_buf,
struct device *attach_dev)
{
+ struct dma_buf_attach_info
dynamic DMA-buf sharing between devices
Hi everybody, core idea in this patch set is that DMA-buf importers can now provide an optional invalidate callback. Using this callback and the reservation object exporters can now avoid pinning DMA-buf memory for a long time while sharing it between devices. I've already send out an older version roughly a year ago, but didn't had time to further look into cleaning this up. The last time a major problem was that we would had to fix up all drivers implementing DMA-buf at once. Now I avoid this by allowing mappings to be cached in the DMA-buf attachment and so driver can optionally move over to the new interface one by one. This is also a prerequisite to my patchset enabling sharing of device memory with DMA-buf. Please review and/or comment, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Expose "FB_DAMAGE_CLIPS" property to atomic aware user-space only
On Tue, 2019-04-16 at 20:15 +0200, Daniel Vetter wrote:
> On Tue, Apr 16, 2019 at 6:21 PM Deepak Singh Rawat > wrote:
> >
> > On Tue, 2019-04-16 at 09:42 +0200, Daniel Vetter wrote:
> > > On Mon, Apr 15, 2019 at 05:28:05PM +, Deepak Singh Rawat
> > > wrote:
> > > > Plane property "FB_DAMAGE_CLIPS" can only be used by atomic
> > > > aware
> > > > user-space, so no point exposing it otherwise.
> > > >
> > > > Signed-off-by: Deepak Rawat
> > > > Fixes: d3b21767821e ("drm: Add a new plane property to send
> > > > damage
> > > > during plane update")
> > >
> > > Makes sense, probably good if we add Cc: sta...@vger.kernel.org
> > > too
> >
> > Hi Daniel, thanks for the review. Sure.
> >
> > >
> > > Reviewed-by: Daniel Vetter
> > >
> > > btw, want drm-misc commit rights to push this? Assuming you'd
> > > then
> > > push
> > > vmware drm patches in general ofc. See
> >
> > Yes I think it would be a good idea if I can have drm-mics commit
> > rights. I think for occasional vmwgfx patches it would be ideal for
> > us
> > to use drm-mics on the other hand if had some major changes better
> > to
> > follow pull request way.
> >
> > How to apply for drm-mics commit rights?
>
>
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.freedesktop.org%2Fwiki%2FAccountRequests%2Fdata=02%7C01%7Cdrawat%40vmware.com%7C8e0fc2a84e8d43a6ee7d08d6c2978af4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636910353461126728sdata=T4RrZ7vdhhu3t0sn2jhU2axEVl7cr5x2JgOgJzVoEl8%3Dreserved=0
>
> you need an ssh account for drm-misc. Reply with the bug report here
> and I'll ack - drm-misc maintainers already acked.
> -Daniel
If you mean ssh on annarchy.freedesktop.org, I already have one with
username - drawat
>
> >
> > >
> > >
> >
> >
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdrm.pages.freedesktop.org%2Fmaintainer-tools%2Fgetting-started.htmldata=02%7C01%7Cdrawat%40vmware.com%7C8e0fc2a84e8d43a6ee7d08d6c2978af4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636910353461126728sdata=ZLOBkqM%2BFVKlutvu4u3kFyW8b%2FKp2fV5UFtfaW0wVZc%3Dreserved=0
> > >
> > > Cheers, Daniel
> > >
> > > > ---
> > > > drivers/gpu/drm/drm_mode_config.c | 5 +++--
> > > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_mode_config.c
> > > > b/drivers/gpu/drm/drm_mode_config.c
> > > > index 4a1c2023ccf0..1a346ae1599d 100644
> > > > --- a/drivers/gpu/drm/drm_mode_config.c
> > > > +++ b/drivers/gpu/drm/drm_mode_config.c
> > > > @@ -297,8 +297,9 @@ static int
> > > > drm_mode_create_standard_properties(struct drm_device *dev)
> > > > return -ENOMEM;
> > > > dev->mode_config.prop_crtc_id = prop;
> > > >
> > > > - prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
> > > > "FB_DAMAGE_CLIPS",
> > > > - 0);
> > > > + prop = drm_property_create(dev,
> > > > + DRM_MODE_PROP_ATOMIC | DRM_MODE_PROP_BLOB,
> > > > + "FB_DAMAGE_CLIPS", 0);
> > > > if (!prop)
> > > > return -ENOMEM;
> > > > dev->mode_config.prop_fb_damage_clips = prop;
> > > > --
> > > > 2.21.0
> > > >
> > > > ___
> > > > dri-devel mailing list
> > > > dri-devel@lists.freedesktop.org
> > > >
> >
> >
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-develdata=02%7C01%7Cdrawat%40vmware.com%7C8e0fc2a84e8d43a6ee7d08d6c2978af4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636910353461126728sdata=6zQnD6klo9k3%2FvVP0mOUQeuwgoSZ3q7o0OChNNaoG%2BQ%3Dreserved=0
> > >
> > >
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH] libdrm: tests: Add planetest test from AOSP sources
On Tue, Apr 16, 2019 at 09:43:49AM -0700, John Stultz wrote:
> In trying to further align the AOSP libdrm branch with upstream,
> I wanted to submit the added test planetest that they have been
> carrying for awhile.
>
> Mostly sending this out for initial reactions and to stir some
> discussion on if folks think upstreaming this would be useful.
I'll start :)
IMO, we should just punt this into orbit. I just wrote it to do some very basic
testing when atomic was first being developed. I think modetest does all of
this and more, not to mention igt which does _much_ more. So unless someone
actually uses this, and has a compelling reason to upstream it I'd say revert it
from Android and we'll be in sync.
> Feedback and thoughts would be appreciated!
>
/snip
> +int main(int argc, char *argv[])
> +{
> + int ret, i, j, num_test_planes;
> + int x_inc = 1, x = 0, y_inc = 1, y = 0;
> + uint32_t plane_w = 128, plane_h = 128;
> + struct sp_dev *dev;
> + struct sp_plane **plane = NULL;
> + struct sp_crtc *test_crtc;
Terrible names for these structs, geez!
Sean
> + fd_set fds;
> + drmModeAtomicReqPtr pset;
> + drmEventContext event_context = {
> + .version = DRM_EVENT_CONTEXT_VERSION,
> + .page_flip_handler = page_flip_handler,
> + };
> + int card = 0, crtc = 0;
> +
> + signal(SIGINT, sigint_handler);
> +
> + parse_arguments(argc, argv, , );
> +
> + dev = create_sp_dev(card);
> + if (!dev) {
> + printf("Failed to create sp_dev\n");
> + return -1;
> + }
> +
> + if (crtc >= dev->num_crtcs) {
> + printf("Invalid crtc %d (num=%d)\n", crtc, dev->num_crtcs);
> + return -1;
> + }
> +
> + ret = initialize_screens(dev);
> + if (ret) {
> + printf("Failed to initialize screens\n");
> + goto out;
> + }
> + test_crtc = >crtcs[crtc];
> +
> + plane = calloc(dev->num_planes, sizeof(*plane));
> + if (!plane) {
> + printf("Failed to allocate plane array\n");
> + goto out;
> + }
> +
> + /* Create our planes */
> + num_test_planes = test_crtc->num_planes;
> + for (i = 0; i < num_test_planes; i++) {
> + plane[i] = get_sp_plane(dev, test_crtc);
> + if (!plane[i]) {
> + printf("no unused planes available\n");
> + goto out;
> + }
> +
> + plane[i]->bo = create_sp_bo(dev, plane_w, plane_h, 16,
> plane[i]->format, 0);
> + if (!plane[i]->bo) {
> + printf("failed to create plane bo\n");
> + goto out;
> + }
> +
> + fill_bo(plane[i]->bo, 0xFF, 0xFF, 0xFF, 0xFF);
> + }
> +
> + pset = drmModeAtomicAlloc();
> + if (!pset) {
> + printf("Failed to allocate the property set\n");
> + goto out;
> + }
> +
> + while (!terminate) {
> + FD_ZERO();
> + FD_SET(dev->fd, );
> +
> + incrementor(_inc, , 5, 0,
> + test_crtc->crtc->mode.hdisplay - plane_w);
> + incrementor(_inc, , 5, 0, test_crtc->crtc->mode.vdisplay -
> + plane_h * num_test_planes);
> +
> + for (j = 0; j < num_test_planes; j++) {
> + ret = set_sp_plane_pset(dev, plane[j], pset, test_crtc,
> + x, y + j * plane_h);
> + if (ret) {
> + printf("failed to move plane %d\n", ret);
> + goto out;
> + }
> + }
> +
> + ret = drmModeAtomicCommit(dev->fd, pset,
> + DRM_MODE_PAGE_FLIP_EVENT, NULL);
> + if (ret) {
> + printf("failed to commit properties ret=%d\n", ret);
> + goto out;
> + }
> +
> + do {
> + ret = select(dev->fd + 1, , NULL, NULL, NULL);
> + } while (ret == -1 && errno == EINTR);
> +
> + if (FD_ISSET(dev->fd, ))
> + drmHandleEvent(dev->fd, _context);
> + }
> +
> + drmModeAtomicFree(pset);
> +
> + for (i = 0; i < num_test_planes; i++)
> + put_sp_plane(plane[i]);
> +
> +out:
> + destroy_sp_dev(dev);
> + free(plane);
> + return ret;
> +}
> diff --git a/tests/planetest/bo.c b/tests/planetest/bo.c
> new file mode 100644
> index 000..d4b82c6
> --- /dev/null
> +++ b/tests/planetest/bo.c
> @@ -0,0 +1,234 @@
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +#include "bo.h"
> +#include "dev.h"
> +
> +#define MAKE_YUV_601_Y(r, g, b) \
> + ((( 66 * (r) + 129 * (g) + 25 * (b) + 128) >> 8) + 16)
> +#define MAKE_YUV_601_U(r, g, b) \
> + (((-38 * (r) - 74 * (g) + 112 *
[PATCH v4 5/5] drm/amdgpu: Avoid HW reset if guilty job already signaled.
Also reject TDRs if another one already running.
v2:
Stop all schedulers across device and entire XGMI hive before
force signaling HW fences.
Avoid passing job_signaled to helper fnctions to keep all the decision
making about skipping HW reset in one place.
v3:
Fix SW sched. hang after non HW reset. sched.hw_rq_count has to be balanced
against it's decrement in drm_sched_stop in non HW reset case.
v4: rebase
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 151 -
1 file changed, 103 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index a0e165c..bfb6ab0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3334,8 +3334,6 @@ static int amdgpu_device_pre_asic_reset(struct
amdgpu_device *adev,
if (!ring || !ring->sched.thread)
continue;
- drm_sched_stop(>sched, >base);
-
/* after all hw jobs are reset, hw fence is meaningless, so
force_completion */
amdgpu_fence_driver_force_completion(ring);
}
@@ -3343,6 +3341,7 @@ static int amdgpu_device_pre_asic_reset(struct
amdgpu_device *adev,
if(job)
drm_sched_increase_karma(>base);
+ /* Don't suspend on bare metal if we are not going to HW reset the ASIC
*/
if (!amdgpu_sriov_vf(adev)) {
if (!need_full_reset)
@@ -3480,37 +3479,21 @@ static int amdgpu_do_asic_reset(struct amdgpu_hive_info
*hive,
return r;
}
-static void amdgpu_device_post_asic_reset(struct amdgpu_device *adev)
+static bool amdgpu_device_lock_adev(struct amdgpu_device *adev, bool trylock)
{
- int i;
-
- for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
- struct amdgpu_ring *ring = adev->rings[i];
+ if (trylock) {
+ if (!mutex_trylock(>lock_reset))
+ return false;
+ } else
+ mutex_lock(>lock_reset);
- if (!ring || !ring->sched.thread)
- continue;
-
- if (!adev->asic_reset_res)
- drm_sched_resubmit_jobs(>sched);
-
- drm_sched_start(>sched, !adev->asic_reset_res);
- }
-
- if (!amdgpu_device_has_dc_support(adev)) {
- drm_helper_resume_force_mode(adev->ddev);
- }
-
- adev->asic_reset_res = 0;
-}
-
-static void amdgpu_device_lock_adev(struct amdgpu_device *adev)
-{
- mutex_lock(>lock_reset);
atomic_inc(>gpu_reset_counter);
adev->in_gpu_reset = 1;
/* Block kfd: SRIOV would do it separately */
if (!amdgpu_sriov_vf(adev))
amdgpu_amdkfd_pre_reset(adev);
+
+ return true;
}
static void amdgpu_device_unlock_adev(struct amdgpu_device *adev)
@@ -3538,40 +3521,42 @@ static void amdgpu_device_unlock_adev(struct
amdgpu_device *adev)
int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
struct amdgpu_job *job)
{
- int r;
+ struct list_head device_list, *device_list_handle = NULL;
+ bool need_full_reset, job_signaled;
struct amdgpu_hive_info *hive = NULL;
- bool need_full_reset = false;
struct amdgpu_device *tmp_adev = NULL;
- struct list_head device_list, *device_list_handle = NULL;
+ int i, r = 0;
+ need_full_reset = job_signaled = false;
INIT_LIST_HEAD(_list);
dev_info(adev->dev, "GPU reset begin!\n");
+ hive = amdgpu_get_xgmi_hive(adev, false);
+
/*
-* In case of XGMI hive disallow concurrent resets to be triggered
-* by different nodes. No point also since the one node already
executing
-* reset will also reset all the other nodes in the hive.
+* Here we trylock to avoid chain of resets executing from
+* either trigger by jobs on different adevs in XGMI hive or jobs on
+* different schedulers for same device while this TO handler is
running.
+* We always reset all schedulers for device and all devices for XGMI
+* hive so that should take care of them too.
*/
- hive = amdgpu_get_xgmi_hive(adev, 0);
- if (hive && adev->gmc.xgmi.num_physical_nodes > 1 &&
- !mutex_trylock(>reset_lock))
+
+ if (hive && !mutex_trylock(>reset_lock)) {
+ DRM_INFO("Bailing on TDR for s_job:%llx, hive: %llx as another
already in progress",
+job->base.id, hive->hive_id);
return 0;
+ }
/* Start with adev pre asic reset first for soft reset check.*/
- amdgpu_device_lock_adev(adev);
- r = amdgpu_device_pre_asic_reset(adev,
-job,
-_full_reset);
- if (r) {
- /*TODO Should we stop ?*/
-
[PATCH v4 4/5] drm/sched: Keep s_fence->parent pointer
For later driver's reference to see if the fence is signaled.
v2: Move parent fence put to resubmit jobs.
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
---
drivers/gpu/drm/scheduler/sched_main.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 21e8734..04645bb 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -375,8 +375,6 @@ void drm_sched_stop(struct drm_gpu_scheduler *sched, struct
drm_sched_job *bad)
if (s_job->s_fence->parent &&
dma_fence_remove_callback(s_job->s_fence->parent,
_job->cb)) {
- dma_fence_put(s_job->s_fence->parent);
- s_job->s_fence->parent = NULL;
atomic_dec(>hw_rq_count);
} else {
/*
@@ -403,6 +401,14 @@ void drm_sched_stop(struct drm_gpu_scheduler *sched,
struct drm_sched_job *bad)
sched->ops->free_job(s_job);
}
}
+
+ /*
+* Stop pending timer in flight as we rearm it in drm_sched_start. This
+* avoids the pending timeout work in progress to fire right away after
+* this TDR finished and before the newly restarted jobs had a
+* chance to complete.
+*/
+ cancel_delayed_work(>work_tdr);
}
EXPORT_SYMBOL(drm_sched_stop);
@@ -474,6 +480,7 @@ void drm_sched_resubmit_jobs(struct drm_gpu_scheduler
*sched)
if (found_guilty && s_job->s_fence->scheduled.context ==
guilty_context)
dma_fence_set_error(_fence->finished, -ECANCELED);
+ dma_fence_put(s_job->s_fence->parent);
s_job->s_fence->parent = sched->ops->run_job(s_job);
atomic_inc(>hw_rq_count);
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/5] drm/scheduler: rework job destruction
From: Christian König
We now destroy finished jobs from the worker thread to make sure that
we never destroy a job currently in timeout processing.
By this we avoid holding lock around ring mirror list in drm_sched_stop
which should solve a deadlock reported by a user.
v2: Remove unused variable.
v4: Move guilty job free into sched code.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109692
Signed-off-by: Christian König
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 9 +-
drivers/gpu/drm/etnaviv/etnaviv_dump.c | 4 -
drivers/gpu/drm/etnaviv/etnaviv_sched.c| 2 +-
drivers/gpu/drm/lima/lima_sched.c | 2 +-
drivers/gpu/drm/panfrost/panfrost_job.c| 2 +-
drivers/gpu/drm/scheduler/sched_main.c | 145 +
drivers/gpu/drm/v3d/v3d_sched.c| 2 +-
include/drm/gpu_scheduler.h| 6 +-
8 files changed, 94 insertions(+), 78 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 7cee269..a0e165c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3334,7 +3334,7 @@ static int amdgpu_device_pre_asic_reset(struct
amdgpu_device *adev,
if (!ring || !ring->sched.thread)
continue;
- drm_sched_stop(>sched);
+ drm_sched_stop(>sched, >base);
/* after all hw jobs are reset, hw fence is meaningless, so
force_completion */
amdgpu_fence_driver_force_completion(ring);
@@ -3343,8 +3343,6 @@ static int amdgpu_device_pre_asic_reset(struct
amdgpu_device *adev,
if(job)
drm_sched_increase_karma(>base);
-
-
if (!amdgpu_sriov_vf(adev)) {
if (!need_full_reset)
@@ -3482,8 +3480,7 @@ static int amdgpu_do_asic_reset(struct amdgpu_hive_info
*hive,
return r;
}
-static void amdgpu_device_post_asic_reset(struct amdgpu_device *adev,
- struct amdgpu_job *job)
+static void amdgpu_device_post_asic_reset(struct amdgpu_device *adev)
{
int i;
@@ -3623,7 +3620,7 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
/* Post ASIC reset for all devs .*/
list_for_each_entry(tmp_adev, device_list_handle, gmc.xgmi.head) {
- amdgpu_device_post_asic_reset(tmp_adev, tmp_adev == adev ? job
: NULL);
+ amdgpu_device_post_asic_reset(tmp_adev);
if (r) {
/* bad news, how to tell it to userspace ? */
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_dump.c
b/drivers/gpu/drm/etnaviv/etnaviv_dump.c
index 33854c9..5778d9c 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_dump.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_dump.c
@@ -135,13 +135,11 @@ void etnaviv_core_dump(struct etnaviv_gpu *gpu)
mmu_size + gpu->buffer.size;
/* Add in the active command buffers */
- spin_lock_irqsave(>sched.job_list_lock, flags);
list_for_each_entry(s_job, >sched.ring_mirror_list, node) {
submit = to_etnaviv_submit(s_job);
file_size += submit->cmdbuf.size;
n_obj++;
}
- spin_unlock_irqrestore(>sched.job_list_lock, flags);
/* Add in the active buffer objects */
list_for_each_entry(vram, >mmu->mappings, mmu_node) {
@@ -183,14 +181,12 @@ void etnaviv_core_dump(struct etnaviv_gpu *gpu)
gpu->buffer.size,
etnaviv_cmdbuf_get_va(>buffer));
- spin_lock_irqsave(>sched.job_list_lock, flags);
list_for_each_entry(s_job, >sched.ring_mirror_list, node) {
submit = to_etnaviv_submit(s_job);
etnaviv_core_dump_mem(, ETDUMP_BUF_CMD,
submit->cmdbuf.vaddr, submit->cmdbuf.size,
etnaviv_cmdbuf_get_va(>cmdbuf));
}
- spin_unlock_irqrestore(>sched.job_list_lock, flags);
/* Reserve space for the bomap */
if (n_bomap_pages) {
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index 6d24fea..a813c82 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -109,7 +109,7 @@ static void etnaviv_sched_timedout_job(struct drm_sched_job
*sched_job)
}
/* block scheduler */
- drm_sched_stop(>sched);
+ drm_sched_stop(>sched, sched_job);
if(sched_job)
drm_sched_increase_karma(sched_job);
diff --git a/drivers/gpu/drm/lima/lima_sched.c
b/drivers/gpu/drm/lima/lima_sched.c
index 97bd9c1..df98931 100644
--- a/drivers/gpu/drm/lima/lima_sched.c
+++ b/drivers/gpu/drm/lima/lima_sched.c
@@ -300,7 +300,7 @@ static struct dma_fence *lima_sched_run_job(struct
drm_sched_job *job)
static void
[PATCH v4 2/5] drm/amd/display: Use a reasonable timeout for framebuffer fence waits
Patch '5edb0c9b Fix deadlock with display during hanged ring recovery'
was accidentaly removed during one of DALs code merges.
v4: Update description.
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Nicholas Kazlauskas
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index ad4f0e5..88e42ad 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4816,11 +4816,16 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
abo = gem_to_amdgpu_bo(fb->obj[0]);
- /* Wait for all fences on this FB */
+ /*
+* Wait for all fences on this FB. Do limited wait to avoid
+* deadlock during GPU reset when this fence will not signal
+* but we hold reservation lock for the BO.
+*/
r = reservation_object_wait_timeout_rcu(abo->tbo.resv, true,
false,
- MAX_SCHEDULE_TIMEOUT);
- WARN_ON(r < 0);
+ msecs_to_jiffies(5000));
+ if (unlikely(r <= 0))
+ DRM_ERROR("Waiting for fences timed out or
interrupted!");
/*
* TODO This might fail and hence better not used, wait
@@ -4829,10 +4834,8 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
* blocking commit to as per framework helpers
*/
r = amdgpu_bo_reserve(abo, true);
- if (unlikely(r != 0)) {
+ if (unlikely(r != 0))
DRM_ERROR("failed to reserve buffer before flip\n");
- WARN_ON(1);
- }
amdgpu_bo_get_tiling_flags(abo, _flags);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/5] drm/amd/display: wait for fence without holding reservation lock
From: Christian König
Don't block others while waiting for the fences to finish, concurrent
submission is perfectly valid in this case and holding the lock can
prevent killed applications from terminating.
Signed-off-by: Christian König
Reviewed-by: Nicholas Kazlauskas
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 380a7f9..ad4f0e5 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4814,23 +4814,26 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
continue;
}
+ abo = gem_to_amdgpu_bo(fb->obj[0]);
+
+ /* Wait for all fences on this FB */
+ r = reservation_object_wait_timeout_rcu(abo->tbo.resv, true,
+ false,
+ MAX_SCHEDULE_TIMEOUT);
+ WARN_ON(r < 0);
+
/*
* TODO This might fail and hence better not used, wait
* explicitly on fences instead
* and in general should be called for
* blocking commit to as per framework helpers
*/
- abo = gem_to_amdgpu_bo(fb->obj[0]);
r = amdgpu_bo_reserve(abo, true);
if (unlikely(r != 0)) {
DRM_ERROR("failed to reserve buffer before flip\n");
WARN_ON(1);
}
- /* Wait for all fences on this FB */
- WARN_ON(reservation_object_wait_timeout_rcu(abo->tbo.resv,
true, false,
-
MAX_SCHEDULE_TIMEOUT) < 0);
-
amdgpu_bo_get_tiling_flags(abo, _flags);
amdgpu_bo_unreserve(abo);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Expose "FB_DAMAGE_CLIPS" property to atomic aware user-space only
On Tue, Apr 16, 2019 at 6:21 PM Deepak Singh Rawat wrote:
>
> On Tue, 2019-04-16 at 09:42 +0200, Daniel Vetter wrote:
> > On Mon, Apr 15, 2019 at 05:28:05PM +, Deepak Singh Rawat wrote:
> > > Plane property "FB_DAMAGE_CLIPS" can only be used by atomic aware
> > > user-space, so no point exposing it otherwise.
> > >
> > > Signed-off-by: Deepak Rawat
> > > Fixes: d3b21767821e ("drm: Add a new plane property to send damage
> > > during plane update")
> >
> > Makes sense, probably good if we add Cc: sta...@vger.kernel.org too
>
> Hi Daniel, thanks for the review. Sure.
>
> >
> > Reviewed-by: Daniel Vetter
> >
> > btw, want drm-misc commit rights to push this? Assuming you'd then
> > push
> > vmware drm patches in general ofc. See
>
> Yes I think it would be a good idea if I can have drm-mics commit
> rights. I think for occasional vmwgfx patches it would be ideal for us
> to use drm-mics on the other hand if had some major changes better to
> follow pull request way.
>
> How to apply for drm-mics commit rights?
https://www.freedesktop.org/wiki/AccountRequests/
you need an ssh account for drm-misc. Reply with the bug report here
and I'll ack - drm-misc maintainers already acked.
-Daniel
>
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdrm.pages.freedesktop.org%2Fmaintainer-tools%2Fgetting-started.htmldata=02%7C01%7Cdrawat%40vmware.com%7C6c643d95324e44d8783108d6c23f0938%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636909973336030830sdata=PMdonBtvx%2B2bMweQJTRu1b7IjmL0lSd2KKSIBV1ngTk%3Dreserved=0
> >
> > Cheers, Daniel
> >
> > > ---
> > > drivers/gpu/drm/drm_mode_config.c | 5 +++--
> > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_mode_config.c
> > > b/drivers/gpu/drm/drm_mode_config.c
> > > index 4a1c2023ccf0..1a346ae1599d 100644
> > > --- a/drivers/gpu/drm/drm_mode_config.c
> > > +++ b/drivers/gpu/drm/drm_mode_config.c
> > > @@ -297,8 +297,9 @@ static int
> > > drm_mode_create_standard_properties(struct drm_device *dev)
> > > return -ENOMEM;
> > > dev->mode_config.prop_crtc_id = prop;
> > >
> > > - prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
> > > "FB_DAMAGE_CLIPS",
> > > - 0);
> > > + prop = drm_property_create(dev,
> > > + DRM_MODE_PROP_ATOMIC | DRM_MODE_PROP_BLOB,
> > > + "FB_DAMAGE_CLIPS", 0);
> > > if (!prop)
> > > return -ENOMEM;
> > > dev->mode_config.prop_fb_damage_clips = prop;
> > > --
> > > 2.21.0
> > >
> > > ___
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-develdata=02%7C01%7Cdrawat%40vmware.com%7C6c643d95324e44d8783108d6c23f0938%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636909973336030830sdata=QJCrLbtFUv7%2FiRAYOb2R%2Bab4w3l5CWae2K7t9Ya6dZw%3Dreserved=0
> >
> >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/2] Add AUX device entries for DP MST devices
On Tue, Apr 16, 2019 at 03:28:24PM +, Li, Sun peng (Leo) wrote: > >> Hmm. My MST-foo is admittedly weak so I'm not sure. A quick trawl through > >> the spec didn't provide any solid explanations either :( However eg. > >> "Figure 2-83: Example Multi-function MST Branch-Sink Device Enumeration" > >> in the DP 1.4 spec does appear to show kind of virtual DPCD thing behind > >> a logical port. But I'm not really sure what than means. > > > > Good point, I'm gonna dig more into that. It sounds like we should be > > able to access that with the relative addressing as defined by the spec > > (2.11.5). I'll have to see why that's currently getting nacked though. > > > > It looks like DPCD reads on logical ports work on some devices, and not > others... I swapped my MST display out with a different one, and it read > just fine. > > More specifically - in a daisy chain setup with 2 MST displays - with > the one that works at the end: > > # auxrw.py read /dev/drm_dp_aux4_mst\:0-1-8 0x30-0x3f -> ACK > # auxrw.py read /dev/drm_dp_aux6_mst\:0-1 0x30-0x3f -> ACK > (The GUIDs returned are identical) > > With the one that doesn't at the end: > > # auxrw.py read /dev/drm_dp_aux4_mst\:0-1-8 0x30-0x3f -> *NAK* > # auxrw.py read /dev/drm_dp_aux6_mst\:0-1 0x30-0x3f -> ACK > > So it seems there's some device dependent behavior here. I'm not sure if > there's a better way of handling this besides exposing all the > downstream ports: If it works, great. If not, just don't use it? Yeah, I think that's fine. It's really meant for debugging anyway so doesn't really matter if we expose something that's not guaranteed to work. -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC][PATCH] libdrm: tests: Add planetest test from AOSP sources
In trying to further align the AOSP libdrm branch with upstream,
I wanted to submit the added test planetest that they have been
carrying for awhile.
Mostly sending this out for initial reactions and to stir some
discussion on if folks think upstreaming this would be useful.
Feedback and thoughts would be appreciated!
Originally-by: Sean Paul
With fixes folded in by:
Benjamin Gaignard
Vincent Palatin
Cc: Sean Paul
Cc: Benjamin Gaignard
Cc: Alex Deucher
Signed-off-by: John Stultz
---
tests/Makefile.am| 2 +-
tests/planetest/Makefile.am | 30
tests/planetest/Makefile.sources | 13 ++
tests/planetest/atomictest.c | 151
tests/planetest/bo.c | 234 +
tests/planetest/bo.h | 34
tests/planetest/dev.c| 367 +++
tests/planetest/dev.h| 65 +++
tests/planetest/modeset.c| 232 +
tests/planetest/modeset.h| 19 ++
tests/planetest/planetest.c | 116 +
11 files changed, 1262 insertions(+), 1 deletion(-)
create mode 100644 tests/planetest/Makefile.am
create mode 100644 tests/planetest/Makefile.sources
create mode 100644 tests/planetest/atomictest.c
create mode 100644 tests/planetest/bo.c
create mode 100644 tests/planetest/bo.h
create mode 100644 tests/planetest/dev.c
create mode 100644 tests/planetest/dev.h
create mode 100644 tests/planetest/modeset.c
create mode 100644 tests/planetest/modeset.h
create mode 100644 tests/planetest/planetest.c
diff --git a/tests/Makefile.am b/tests/Makefile.am
index d274a3e..42d9854 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -1,7 +1,7 @@
SUBDIRS = util kms modeprint proptest modetest vbltest
if HAVE_LIBKMS
-SUBDIRS += kmstest
+SUBDIRS += kmstest planetest
endif
if HAVE_RADEON
diff --git a/tests/planetest/Makefile.am b/tests/planetest/Makefile.am
new file mode 100644
index 000..b82d05b
--- /dev/null
+++ b/tests/planetest/Makefile.am
@@ -0,0 +1,30 @@
+include Makefile.sources
+
+AM_CFLAGS = $(filter-out -Wpointer-arith, $(WARN_CFLAGS))
+
+AM_CFLAGS += \
+ -I$(top_srcdir)/include/drm \
+ -I$(top_srcdir)/libkms/ \
+ -I$(top_srcdir)
+
+PLANETEST_COMMON_LDADD = \
+ $(top_builddir)/libdrm.la \
+ $(top_builddir)/libkms/libkms.la \
+ -lpthread
+
+if HAVE_INSTALL_TESTS
+bin_PROGRAMS = \
+ atomictest \
+ planetest
+else
+noinst_PROGRAMS = \
+ atomictest \
+ planetest
+endif
+
+atomictest_CFLAGS=-DUSE_ATOMIC_API ${AM_CFLAGS}
+atomictest_SOURCES=${PLANETEST_COMMON_FILES} ${ATOMICTEST_FILES}
+planetest_SOURCES=${PLANETEST_COMMON_FILES} ${PLANETEST_FILES}
+
+atomictest_LDADD=${PLANETEST_COMMON_LDADD}
+planetest_LDADD=${PLANETEST_COMMON_LDADD}
diff --git a/tests/planetest/Makefile.sources b/tests/planetest/Makefile.sources
new file mode 100644
index 000..3cbeb2b
--- /dev/null
+++ b/tests/planetest/Makefile.sources
@@ -0,0 +1,13 @@
+PLANETEST_COMMON_FILES := \
+ bo.c \
+ bo.h \
+ dev.c \
+ dev.h \
+ modeset.c \
+ modeset.h
+
+ATOMICTEST_FILES := \
+ atomictest.c
+
+PLANETEST_FILES := \
+ planetest.c
diff --git a/tests/planetest/atomictest.c b/tests/planetest/atomictest.c
new file mode 100644
index 000..891d242
--- /dev/null
+++ b/tests/planetest/atomictest.c
@@ -0,0 +1,151 @@
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "dev.h"
+#include "bo.h"
+#include "modeset.h"
+
+static int terminate = 0;
+
+static void sigint_handler(int arg)
+{
+ terminate = 1;
+}
+
+static void
+page_flip_handler(int fd, unsigned int sequence, unsigned int tv_sec,
+ unsigned int tv_usec, void *user_data)
+{
+}
+
+static void incrementor(int *inc, int *val, int increment, int lower, int
upper)
+{
+ if(*inc > 0)
+ *inc = *val + increment >= upper ? -1 : 1;
+ else
+ *inc = *val - increment <= lower ? 1 : -1;
+ *val += *inc * increment;
+}
+
+int main(int argc, char *argv[])
+{
+ int ret, i, j, num_test_planes;
+ int x_inc = 1, x = 0, y_inc = 1, y = 0;
+ uint32_t plane_w = 128, plane_h = 128;
+ struct sp_dev *dev;
+ struct sp_plane **plane = NULL;
+ struct sp_crtc *test_crtc;
+ fd_set fds;
+ drmModeAtomicReqPtr pset;
+ drmEventContext event_context = {
+ .version = DRM_EVENT_CONTEXT_VERSION,
+ .page_flip_handler = page_flip_handler,
+ };
+ int card = 0, crtc = 0;
+
+ signal(SIGINT, sigint_handler);
+
+ parse_arguments(argc, argv, , );
+
+ dev = create_sp_dev(card);
+ if (!dev) {
+ printf("Failed to create sp_dev\n");
+ return -1;
+ }
+
+ if (crtc >= dev->num_crtcs) {
+ printf("Invalid crtc %d (num=%d)\n", crtc,
Re: [PATCH] drm: Expose "FB_DAMAGE_CLIPS" property to atomic aware user-space only
On Tue, 2019-04-16 at 09:42 +0200, Daniel Vetter wrote:
> On Mon, Apr 15, 2019 at 05:28:05PM +, Deepak Singh Rawat wrote:
> > Plane property "FB_DAMAGE_CLIPS" can only be used by atomic aware
> > user-space, so no point exposing it otherwise.
> >
> > Signed-off-by: Deepak Rawat
> > Fixes: d3b21767821e ("drm: Add a new plane property to send damage
> > during plane update")
>
> Makes sense, probably good if we add Cc: sta...@vger.kernel.org too
Hi Daniel, thanks for the review. Sure.
>
> Reviewed-by: Daniel Vetter
>
> btw, want drm-misc commit rights to push this? Assuming you'd then
> push
> vmware drm patches in general ofc. See
Yes I think it would be a good idea if I can have drm-mics commit
rights. I think for occasional vmwgfx patches it would be ideal for us
to use drm-mics on the other hand if had some major changes better to
follow pull request way.
How to apply for drm-mics commit rights?
>
>
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdrm.pages.freedesktop.org%2Fmaintainer-tools%2Fgetting-started.htmldata=02%7C01%7Cdrawat%40vmware.com%7C6c643d95324e44d8783108d6c23f0938%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636909973336030830sdata=PMdonBtvx%2B2bMweQJTRu1b7IjmL0lSd2KKSIBV1ngTk%3Dreserved=0
>
> Cheers, Daniel
>
> > ---
> > drivers/gpu/drm/drm_mode_config.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_mode_config.c
> > b/drivers/gpu/drm/drm_mode_config.c
> > index 4a1c2023ccf0..1a346ae1599d 100644
> > --- a/drivers/gpu/drm/drm_mode_config.c
> > +++ b/drivers/gpu/drm/drm_mode_config.c
> > @@ -297,8 +297,9 @@ static int
> > drm_mode_create_standard_properties(struct drm_device *dev)
> > return -ENOMEM;
> > dev->mode_config.prop_crtc_id = prop;
> >
> > - prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
> > "FB_DAMAGE_CLIPS",
> > - 0);
> > + prop = drm_property_create(dev,
> > + DRM_MODE_PROP_ATOMIC | DRM_MODE_PROP_BLOB,
> > + "FB_DAMAGE_CLIPS", 0);
> > if (!prop)
> > return -ENOMEM;
> > dev->mode_config.prop_fb_damage_clips = prop;
> > --
> > 2.21.0
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> >
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-develdata=02%7C01%7Cdrawat%40vmware.com%7C6c643d95324e44d8783108d6c23f0938%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636909973336030830sdata=QJCrLbtFUv7%2FiRAYOb2R%2Bab4w3l5CWae2K7t9Ya6dZw%3Dreserved=0
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/5] drm/scheduler: rework job destruction
Am 16.04.19 um 17:42 schrieb Grodzovsky, Andrey: > On 4/16/19 10:58 AM, Grodzovsky, Andrey wrote: >> On 4/16/19 10:43 AM, Koenig, Christian wrote: >>> Am 16.04.19 um 16:36 schrieb Grodzovsky, Andrey: On 4/16/19 5:47 AM, Christian König wrote: > Am 15.04.19 um 23:17 schrieb Eric Anholt: >> Andrey Grodzovsky writes: >> >>> From: Christian König >>> >>> We now destroy finished jobs from the worker thread to make sure that >>> we never destroy a job currently in timeout processing. >>> By this we avoid holding lock around ring mirror list in drm_sched_stop >>> which should solve a deadlock reported by a user. >>> >>> v2: Remove unused variable. >>> >>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109692 >>> >>> Signed-off-by: Christian König >>> Signed-off-by: Andrey Grodzovsky >>> --- >>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 17 ++-- >>> drivers/gpu/drm/etnaviv/etnaviv_dump.c | 4 - >>> drivers/gpu/drm/etnaviv/etnaviv_sched.c | 9 +- >>> drivers/gpu/drm/scheduler/sched_main.c | 138 >>> + >>> drivers/gpu/drm/v3d/v3d_sched.c | 9 +- >> Missing corresponding panfrost and lima updates. You should probably >> pull in drm-misc for hacking on the scheduler. >> >>> diff --git a/drivers/gpu/drm/v3d/v3d_sched.c >>> b/drivers/gpu/drm/v3d/v3d_sched.c >>> index ce7c737b..8efb091 100644 >>> --- a/drivers/gpu/drm/v3d/v3d_sched.c >>> +++ b/drivers/gpu/drm/v3d/v3d_sched.c >>> @@ -232,11 +232,18 @@ v3d_gpu_reset_for_timeout(struct v3d_dev *v3d, >>> struct drm_sched_job *sched_job) >>> /* block scheduler */ >>> for (q = 0; q < V3D_MAX_QUEUES; q++) >>> - drm_sched_stop(>queue[q].sched); >>> + drm_sched_stop(>queue[q].sched, sched_job); >>> if(sched_job) >>> drm_sched_increase_karma(sched_job); >>> + /* >>> + * Guilty job did complete and hence needs to be manually removed >>> + * See drm_sched_stop doc. >>> + */ >>> + if (list_empty(_job->node)) >>> + sched_job->sched->ops->free_job(sched_job); >> If the if (sched_job) is necessary up above, then this should clearly be >> under it. >> >> But, can we please have a core scheduler thing we call here instead of >> drivers all replicating it? > Yeah that's also something I noted before. > > Essential problem is that we remove finished jobs from the mirror list > and so need to destruct them because we otherwise leak them. > > Alternative approach here would be to keep the jobs on the ring mirror > list, but not submit them again. > > Regards, > Christian. I really prefer to avoid this, it means adding extra flag to sched_job to check in each iteration of the ring mirror list. >>> Mhm, why actually? We just need to check if the scheduler fence is signaled. >> OK, i see it's equivalent but this still en extra check for all the >> iterations. >> What about changing signature of drm_sched_backend_ops.timedout_job to return drm_sched_job* instead of void, this way we can return the guilty job back from the driver specific handler to the generic drm_sched_job_timedout and release it there. >>> Well the timeout handler already has the job, so returning it doesn't >>> make much sense. >>> >>> The problem is rather that the timeout handler doesn't know if it should >>> destroy the job or not. >> But the driver specific handler does, and actually returning back either >> the pointer to the job or null will give an indication of that. We can >> even return bool. >> >> Andrey > > Thinking a bit more about this - the way this check is done now "if > (list_empty(_job->node)) then free the sched_job" actually makes > it possible to just move this as is from driver specific callbacks into > drm_sched_job_timeout without any other changes. Oh, well that sounds like a good idea off hand. Need to see the final code, but at least the best idea so far. Christian. > > Andrey > >>> Christian. >>> Andrey >>> + >>> /* get the GPU back into the init state */ >>> v3d_reset(v3d); >>> ___ >>> amd-gfx mailing list >>> amd-...@lists.freedesktop.org >>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx >> ___ >> amd-gfx mailing list >> amd-...@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/5] drm/scheduler: rework job destruction
On 4/16/19 10:58 AM, Grodzovsky, Andrey wrote: > On 4/16/19 10:43 AM, Koenig, Christian wrote: >> Am 16.04.19 um 16:36 schrieb Grodzovsky, Andrey: >>> On 4/16/19 5:47 AM, Christian König wrote: Am 15.04.19 um 23:17 schrieb Eric Anholt: > Andrey Grodzovsky writes: > >> From: Christian König >> >> We now destroy finished jobs from the worker thread to make sure that >> we never destroy a job currently in timeout processing. >> By this we avoid holding lock around ring mirror list in drm_sched_stop >> which should solve a deadlock reported by a user. >> >> v2: Remove unused variable. >> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109692 >> >> Signed-off-by: Christian König >> Signed-off-by: Andrey Grodzovsky >> --- >> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 17 ++-- >> drivers/gpu/drm/etnaviv/etnaviv_dump.c | 4 - >> drivers/gpu/drm/etnaviv/etnaviv_sched.c | 9 +- >> drivers/gpu/drm/scheduler/sched_main.c | 138 >> + >> drivers/gpu/drm/v3d/v3d_sched.c | 9 +- > Missing corresponding panfrost and lima updates. You should probably > pull in drm-misc for hacking on the scheduler. > >> diff --git a/drivers/gpu/drm/v3d/v3d_sched.c >> b/drivers/gpu/drm/v3d/v3d_sched.c >> index ce7c737b..8efb091 100644 >> --- a/drivers/gpu/drm/v3d/v3d_sched.c >> +++ b/drivers/gpu/drm/v3d/v3d_sched.c >> @@ -232,11 +232,18 @@ v3d_gpu_reset_for_timeout(struct v3d_dev *v3d, >> struct drm_sched_job *sched_job) >> /* block scheduler */ >> for (q = 0; q < V3D_MAX_QUEUES; q++) >> - drm_sched_stop(>queue[q].sched); >> + drm_sched_stop(>queue[q].sched, sched_job); >> if(sched_job) >> drm_sched_increase_karma(sched_job); >> + /* >> + * Guilty job did complete and hence needs to be manually removed >> + * See drm_sched_stop doc. >> + */ >> + if (list_empty(_job->node)) >> + sched_job->sched->ops->free_job(sched_job); > If the if (sched_job) is necessary up above, then this should clearly be > under it. > > But, can we please have a core scheduler thing we call here instead of > drivers all replicating it? Yeah that's also something I noted before. Essential problem is that we remove finished jobs from the mirror list and so need to destruct them because we otherwise leak them. Alternative approach here would be to keep the jobs on the ring mirror list, but not submit them again. Regards, Christian. >>> I really prefer to avoid this, it means adding extra flag to sched_job >>> to check in each iteration of the ring mirror list. >> Mhm, why actually? We just need to check if the scheduler fence is signaled. > OK, i see it's equivalent but this still en extra check for all the > iterations. > >>> What about changing >>> signature of drm_sched_backend_ops.timedout_job to return drm_sched_job* >>> instead of void, this way we can return the guilty job back from the >>> driver specific handler to the generic drm_sched_job_timedout and >>> release it there. >> Well the timeout handler already has the job, so returning it doesn't >> make much sense. >> >> The problem is rather that the timeout handler doesn't know if it should >> destroy the job or not. > > But the driver specific handler does, and actually returning back either > the pointer to the job or null will give an indication of that. We can > even return bool. > > Andrey Thinking a bit more about this - the way this check is done now "if (list_empty(_job->node)) then free the sched_job" actually makes it possible to just move this as is from driver specific callbacks into drm_sched_job_timeout without any other changes. Andrey > >> Christian. >> >>> Andrey >>> >> + >> /* get the GPU back into the init state */ >> v3d_reset(v3d); >> ___ >> amd-gfx mailing list >> amd-...@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/amd-gfx > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/gma500: Add CedarView LVDS blacklist
Hi, On 16-04-19 16:32, Patrik Jakobsson wrote: On Wed, Apr 10, 2019 at 1:51 PM Dominik 'Rathann' Mierzejewski wrote: On Wednesday, 10 April 2019 at 13:33, Patrik Jakobsson wrote: On Wed, Apr 10, 2019 at 1:18 PM Dominik 'Rathann' Mierzejewski wrote: On Wednesday, 10 April 2019 at 11:08, Hans de Goede wrote: On 10-04-19 11:00, Patrik Jakobsson wrote: On Wed, Apr 10, 2019 at 9:27 AM Hans de Goede wrote: On 09-04-19 21:31, Dominik 'Rathann' Mierzejewski wrote: On Tuesday, 09 April 2019 at 16:44, Hans de Goede wrote: On 09-04-19 14:05, Patrik Jakobsson wrote: [...] I'm not totally against this but not sure about the consequences. Is there perhaps a better dmi string to match against? No there are no better DMI strings to match against I'm afraid. I did load default settings in BIOS setup and there's no change in behaviour. LVDS gets detected as connected: $ cat /sys/class/drm/card0-LVDS-1/status connected Only VGA output is physically connected at the moment. To be clear what Dominik means here is that he has a VGA monitor connected. There is no LVDS panel in this device at all. Thanks for testing. I dusted off my DN2800MT and tried turning LVDS on/off in the BIOS. With LVDS disabled gma500 reports it as connected. When LVDS is enabled in bios I instead get a connected eDP connector. I'm starting to think that broken VBT parsing might be the actual problem. Maybe, but I assume there are CedarView based laptops with LVDS panels which works, so I suspect this might be more of a bug in your BIOS. So what is the next step in debugging this? To add a small twist, I got an updated BIOS from the vendor to fix another issue (https://bugzilla.kernel.org/show_bug.cgi?id=199117) and the DMI string has changed to: "CDV W Series 05", so Hans' patch no longer matches my machine. Hi Dominik, Do you have any option to enable/disable LVDS in your BIOS. The BIOS default might not be to disable LVDS since they apparently solved the issue on the command line anyway. If there is an option to turn it off but you still get the same problem, then it is possible that detection of "LVDS disabled" in the driver might be bad. No, there's no option to enable/disable LVDS. The machine is a NAS box and doesn't have an LVDS physically. You can see the motherboard e.g. here: https://youtu.be/ZYNQvZNGLsE?t=855 . I've posted a patch: https://patchwork.freedesktop.org/patch/299821/ Previously we only checked for a child device and ignored the lvds config bits. Hopefully this fixes your problem. Dominik, As also discussed in bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1665766#c23 I've started a Fedora kernel test-build with Patrik's patch added, please test this: https://koji.fedoraproject.org/koji/taskinfo?taskID=34215831 Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/2] Add AUX device entries for DP MST devices
>> Hmm. My MST-foo is admittedly weak so I'm not sure. A quick trawl through >> the spec didn't provide any solid explanations either :( However eg. >> "Figure 2-83: Example Multi-function MST Branch-Sink Device Enumeration" >> in the DP 1.4 spec does appear to show kind of virtual DPCD thing behind >> a logical port. But I'm not really sure what than means. > > Good point, I'm gonna dig more into that. It sounds like we should be > able to access that with the relative addressing as defined by the spec > (2.11.5). I'll have to see why that's currently getting nacked though. > It looks like DPCD reads on logical ports work on some devices, and not others... I swapped my MST display out with a different one, and it read just fine. More specifically - in a daisy chain setup with 2 MST displays - with the one that works at the end: # auxrw.py read /dev/drm_dp_aux4_mst\:0-1-8 0x30-0x3f -> ACK # auxrw.py read /dev/drm_dp_aux6_mst\:0-1 0x30-0x3f -> ACK (The GUIDs returned are identical) With the one that doesn't at the end: # auxrw.py read /dev/drm_dp_aux4_mst\:0-1-8 0x30-0x3f -> *NAK* # auxrw.py read /dev/drm_dp_aux6_mst\:0-1 0x30-0x3f -> ACK So it seems there's some device dependent behavior here. I'm not sure if there's a better way of handling this besides exposing all the downstream ports: If it works, great. If not, just don't use it? Leo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/tegra: hdmi: Setup audio only if configured
From: Thierry Reding
The audio configuration is only valid if the HDMI codec has been
properly set up. Do not attempt to set up audio before that happens
because it causes a division by zero.
Note that this is only problematic on Tegra20 and Tegra30. Later chips
implement the division instructions which return zero when dividing by
zero and don't throw an exception.
Fixes: db5adf4d6dce ("drm/tegra: hdmi: Fix audio to work with any pixel clock
rate")
Reported-by: Marcel Ziswiler
Signed-off-by: Thierry Reding
---
Changes in v2:
- setup audio at ->enable() time if it has been configured, otherwise
audio playback needs to be restarted after the display goes through
a disable/enable cycle
drivers/gpu/drm/tegra/hdmi.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
index 47c55974756d..d23c4bfde790 100644
--- a/drivers/gpu/drm/tegra/hdmi.c
+++ b/drivers/gpu/drm/tegra/hdmi.c
@@ -1260,9 +1260,15 @@ static void tegra_hdmi_encoder_enable(struct drm_encoder
*encoder)
hdmi->dvi = !tegra_output_is_hdmi(output);
if (!hdmi->dvi) {
- err = tegra_hdmi_setup_audio(hdmi);
- if (err < 0)
- hdmi->dvi = true;
+ /*
+* Make sure that the audio format has been configured before
+* enabling audio, otherwise we may try to divide by zero.
+ */
+ if (hdmi->format.sample_rate > 0) {
+ err = tegra_hdmi_setup_audio(hdmi);
+ if (err < 0)
+ hdmi->dvi = true;
+ }
}
if (hdmi->config->has_hda)
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/tegra: hdmi: Setup audio only if configured
On Tue, Apr 16, 2019 at 04:41:37PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> The audio configuration is only valid if the HDMI codec has been
> properly set up. Do not attempt to set up audio before that happens
> because it causes a division by zero.
>
> Note that this is only problematic on Tegra20 and Tegra30. Later chips
> implement the division instructions which return zero when dividing by
> zero and don't throw an exception.
>
> Fixes: db5adf4d6dce ("drm/tegra: hdmi: Fix audio to work with any pixel clock
> rate")
> Reported-by: Marcel Ziswiler
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/tegra/hdmi.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
> index 47c55974756d..e6c60bbc0fec 100644
> --- a/drivers/gpu/drm/tegra/hdmi.c
> +++ b/drivers/gpu/drm/tegra/hdmi.c
> @@ -1259,11 +1259,6 @@ static void tegra_hdmi_encoder_enable(struct
> drm_encoder *encoder)
> tegra_hdmi_writel(hdmi, value, HDMI_NV_PDISP_SOR_REFCLK);
>
> hdmi->dvi = !tegra_output_is_hdmi(output);
> - if (!hdmi->dvi) {
> - err = tegra_hdmi_setup_audio(hdmi);
> - if (err < 0)
> - hdmi->dvi = true;
> - }
This has the disadvantage of keeping audio disabled after a disable/
enable sequence, even if userspace is still playing audio. I'll send
out a better fix that keeps audio working after disable/enable.
Thierry
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [v3 6/7] drm: Add Client Cap for advance gamma mode
On Mon, Apr 15, 2019 at 09:20:55PM +0200, Daniel Vetter wrote: > On Mon, Apr 15, 2019 at 4:14 PM Lankhorst, Maarten > wrote: > > > > mån 2019-04-15 klockan 19:26 +0530 skrev Sharma, Shashank: > > > > -Original Message- > > > > From: Lankhorst, Maarten > > > > Sent: Monday, April 15, 2019 4:28 PM > > > > To: Shankar, Uma ; intel-gfx@lists.freedeskt > > > > op.org; dri- > > > > de...@lists.freedesktop.org > > > > Cc: Syrjala, Ville ; emil.l.velikov@gmail. > > > > com; > > > > s...@ravnborg.org; Roper, Matthew D ; > > > > seanp...@chromium.org; brian.star...@arm.com; dcasta...@chromium.or > > > > g; > > > > Sharma, Shashank > > > > Subject: Re: [v3 6/7] drm: Add Client Cap for advance gamma mode > > > > > > > > fre 2019-04-12 klockan 15:51 +0530 skrev Uma Shankar: > > > > > Introduced a client cap for advance cap mode > > > > > capability. Userspace should set this to get > > > > > to be able to use the new gamma_mode property. > > > > > > > > > > If this is not set, driver will work in legacy > > > > > mode. > > > > > > > > > > Suggested-by: Ville Syrjälä > > > > > Signed-off-by: Uma Shankar > > > > > > > > Nack, this doesn't seem like a sensible idea. We already guard it > > > > behind the gamma mode property. Userspace shouldn't set the gamma > > > > mode > > > > to a value it doesn't understand. > > > > > > > > ~Maarten > > > > > > Hey Maarten, > > > In that case, what do you suggest should be the right way to do this > > > ? > > > > > > @Ville, any comments here ? > > > > > I would say drop this patch, and just enable segmented gamma > > unconditionally, it's not the first property that can cause trouble > > when not understood. > > Yeah, thus far we went with "new properties should have the old > behaviour as default, no cap/flag needed". That's a given. But it doesn't help with the mixed userspace when one of them doesn't know how to reset it back to default. > If you mix old > userspace and stuff starts looking funny, that's not a regression imo. > Also, it's a very uncommon use-case. I was mainly thinking of eg. wayland vs. X type of cases where the user might want to switch. If the wayland compositor uses the new fancy gamma thing but the xserver doesn't then this won't work anymore. But I guess easier solution is to just add the relevant knowledge to the ddx. Which should probably be a hard requirement for landing this. > > Wrt reset to default: fbdev emulation should do that for anything > that's too fancy, which is generally enough for the "developer of > compositors" use case. That part might be missing in the gamma/ctm > support in general I think. Probably. IIRC even running X at 8bpp and then swithcing back to fbcon leaves you with a gargbled palette. -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/5] drm/scheduler: rework job destruction
On 4/16/19 10:43 AM, Koenig, Christian wrote: > Am 16.04.19 um 16:36 schrieb Grodzovsky, Andrey: >> On 4/16/19 5:47 AM, Christian König wrote: >>> Am 15.04.19 um 23:17 schrieb Eric Anholt: Andrey Grodzovsky writes: > From: Christian König > > We now destroy finished jobs from the worker thread to make sure that > we never destroy a job currently in timeout processing. > By this we avoid holding lock around ring mirror list in drm_sched_stop > which should solve a deadlock reported by a user. > > v2: Remove unused variable. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109692 > > Signed-off-by: Christian König > Signed-off-by: Andrey Grodzovsky > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 17 ++-- > drivers/gpu/drm/etnaviv/etnaviv_dump.c | 4 - > drivers/gpu/drm/etnaviv/etnaviv_sched.c | 9 +- > drivers/gpu/drm/scheduler/sched_main.c | 138 > + > drivers/gpu/drm/v3d/v3d_sched.c | 9 +- Missing corresponding panfrost and lima updates. You should probably pull in drm-misc for hacking on the scheduler. > diff --git a/drivers/gpu/drm/v3d/v3d_sched.c > b/drivers/gpu/drm/v3d/v3d_sched.c > index ce7c737b..8efb091 100644 > --- a/drivers/gpu/drm/v3d/v3d_sched.c > +++ b/drivers/gpu/drm/v3d/v3d_sched.c > @@ -232,11 +232,18 @@ v3d_gpu_reset_for_timeout(struct v3d_dev *v3d, > struct drm_sched_job *sched_job) > /* block scheduler */ > for (q = 0; q < V3D_MAX_QUEUES; q++) > - drm_sched_stop(>queue[q].sched); > + drm_sched_stop(>queue[q].sched, sched_job); > if(sched_job) > drm_sched_increase_karma(sched_job); > + /* > + * Guilty job did complete and hence needs to be manually removed > + * See drm_sched_stop doc. > + */ > + if (list_empty(_job->node)) > + sched_job->sched->ops->free_job(sched_job); If the if (sched_job) is necessary up above, then this should clearly be under it. But, can we please have a core scheduler thing we call here instead of drivers all replicating it? >>> Yeah that's also something I noted before. >>> >>> Essential problem is that we remove finished jobs from the mirror list >>> and so need to destruct them because we otherwise leak them. >>> >>> Alternative approach here would be to keep the jobs on the ring mirror >>> list, but not submit them again. >>> >>> Regards, >>> Christian. >> I really prefer to avoid this, it means adding extra flag to sched_job >> to check in each iteration of the ring mirror list. > Mhm, why actually? We just need to check if the scheduler fence is signaled. OK, i see it's equivalent but this still en extra check for all the iterations. > >> What about changing >> signature of drm_sched_backend_ops.timedout_job to return drm_sched_job* >> instead of void, this way we can return the guilty job back from the >> driver specific handler to the generic drm_sched_job_timedout and >> release it there. > Well the timeout handler already has the job, so returning it doesn't > make much sense. > > The problem is rather that the timeout handler doesn't know if it should > destroy the job or not. But the driver specific handler does, and actually returning back either the pointer to the job or null will give an indication of that. We can even return bool. Andrey > > Christian. > >> Andrey >> > + > /* get the GPU back into the init state */ > v3d_reset(v3d); > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 09/12] drm/fb-helper: Remove drm_fb_helper_connector
Den 16.04.2019 11.42, skrev Maxime Ripard: > Hi, > > On Sun, Apr 07, 2019 at 06:52:40PM +0200, Noralf Trønnes wrote: >> All drivers add all their connectors so there's no need to keep around an >> array of available connectors. >> >> Rename functions which signature is changed since they will be moved to >> drm_client in a later patch. >> >> Signed-off-by: Noralf Trønnes > > The patch itself looks fine in itself, but I was planning on using > connector_info to store the connector properties set on the kernel > command line as part of video= > > Where should we put them now? > I don't follow you here. Where do you see the conflict? Noralf. > Maxime > > -- > Maxime Ripard, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] drm/modes: Parse overscan properties
Den 11.04.2019 15.22, skrev Maxime Ripard:
> Properly configuring the overscan properties might be needed for the
> initial setup of the framebuffer for display that still have overscan.
> Let's allow for more properties on the kernel command line to setup each
> margin.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/drm_fb_helper.c | 47 ++-
> drivers/gpu/drm/drm_modes.c | 44 -
> include/drm/drm_connector.h | 1 +-
> 3 files changed, 92 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 8781897559b2..4e403fe1f451 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -2567,6 +2567,51 @@ static void drm_setup_crtc_rotation(struct
> drm_fb_helper *fb_helper,
> fb_helper->sw_rotations |= DRM_MODE_ROTATE_0;
> }
>
> +static void drm_setup_connector_margins(struct drm_connector *connector)
> +{
> + struct drm_cmdline_mode *cmdline = >cmdline_mode;
> + struct drm_modeset_acquire_ctx ctx;
> + struct drm_atomic_state *state;
> + struct drm_device *dev = connector->dev;
> + int ret;
> +
> + if (!drm_drv_uses_atomic_modeset(dev))
> + return;
> +
> + drm_modeset_acquire_init(, 0);
> +
> + state = drm_atomic_state_alloc(dev);
> + state->acquire_ctx =
> +
> +retry:
> + drm_atomic_set_property(state, >base,
> + dev->mode_config.tv_left_margin_property,
> + cmdline->overscan_left);
> +
> + drm_atomic_set_property(state, >base,
> + dev->mode_config.tv_right_margin_property,
> + cmdline->overscan_right);
> +
> + drm_atomic_set_property(state, >base,
> + dev->mode_config.tv_top_margin_property,
> + cmdline->overscan_top);
> +
> + drm_atomic_set_property(state, >base,
> + dev->mode_config.tv_bottom_margin_property,
> + cmdline->overscan_bottom);
> +
> + ret = drm_atomic_commit(state);
> + if (ret == -EDEADLK) {
> + drm_atomic_state_clear(state);
> + drm_modeset_backoff();
> + goto retry;
> + }
> +
> + drm_atomic_state_put(state);
> + drm_modeset_drop_locks();
> + drm_modeset_acquire_fini();
> +}
> +
Should we set these property values in drm_connector_init()?
I assume that DRM userspace would want to use these values as well.
Noralf.
> static void drm_setup_crtcs(struct drm_fb_helper *fb_helper,
> u32 width, u32 height)
> {
> @@ -2680,6 +2725,8 @@ static void drm_setup_crtcs_fb(struct drm_fb_helper
> *fb_helper)
> struct drm_connector *connector =
> fb_helper->connector_info[i]->connector;
>
> + drm_setup_connector_margins(connector);
> +
> /* use first connected connector for the physical dimensions */
> if (connector->status == connector_status_connected) {
> info->var.width = connector->display_info.width_mm;
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index ac8d70b92b62..493ba3ccde70 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -1586,6 +1586,50 @@ static int drm_mode_parse_cmdline_options(char *str,
> size_t len,
> } else if (!strncmp(option, "reflect_y", delim - option)) {
> rotation |= DRM_MODE_REFLECT_Y;
> sep = delim;
> + } else if (!strncmp(option, "overscan_right", delim - option)) {
> + const char *value = delim + 1;
> + unsigned int margin;
> +
> + margin = simple_strtol(value, , 10);
> +
> + /* Make sure we have parsed something */
> + if (sep == value)
> + return -EINVAL;
> +
> + mode->overscan_right = margin;
> + } else if (!strncmp(option, "overscan_left", delim - option)) {
> + const char *value = delim + 1;
> + unsigned int margin;
> +
> + margin = simple_strtol(value, , 10);
> +
> + /* Make sure we have parsed something */
> + if (sep == value)
> + return -EINVAL;
> +
> + mode->overscan_left = margin;
> + } else if (!strncmp(option, "overscan_top", delim - option)) {
> + const char *value = delim + 1;
> + unsigned int margin;
> +
> + margin = simple_strtol(value, , 10);
> +
> + /* Make sure we have parsed something */
> + if (sep == value)
> + return
Re: [PATCH v2 3/5] drm/modes: Allow to specify rotation and reflection on the commandline
Den 11.04.2019 15.22, skrev Maxime Ripard:
> Rotations and reflections setup are needed in some scenarios to initialise
> properly the initial framebuffer. Some drivers already had a bunch of
> quirks to deal with this, such as either a private kernel command line
> parameter (omapdss) or on the device tree (various panels).
>
> In order to accomodate this, let's create a video mode parameter to deal
> with the rotation and reflexion.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/drm_fb_helper.c | 4 +-
> drivers/gpu/drm/drm_modes.c | 110 +++--
> include/drm/drm_connector.h | 1 +-
> 3 files changed, 95 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index b3a5d79436ae..8781897559b2 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -2521,6 +2521,7 @@ static void drm_setup_crtc_rotation(struct
> drm_fb_helper *fb_helper,
> struct drm_connector *connector)
> {
> struct drm_plane *plane = fb_crtc->mode_set.crtc->primary;
> + struct drm_cmdline_mode *mode = >cmdline_mode;
> uint64_t valid_mask = 0;
> int i, rotation;
>
> @@ -2540,6 +2541,9 @@ static void drm_setup_crtc_rotation(struct
> drm_fb_helper *fb_helper,
> rotation = DRM_MODE_ROTATE_0;
> }
>
> + if (mode->rotation != DRM_MODE_ROTATE_0)
> + fb_crtc->rotation = mode->rotation;
> +
We already have a property to describe initial display/panel rotation.
If we can set connector->display_info.panel_orientation from the video=
parameter, then there's no need to modify drm_fb_helper, it will just work.
In that case, maybe 'orientation' is a better argument name with values
mapped to the enum.
And further, should we add the property
(drm_connector_init_panel_orientation_property()) so DRM userspace can
know about it to?
Some pointers:
- 8d70f395e6cb ("drm: Add support for a panel-orientation connector
property")
- 8f0cb418393b ("drm/fb-helper: Apply panel orientation connector prop
to the primary plane")
- drivers/gpu/drm/drm_panel_orientation_quirks.c
Noralf.
> /*
>* TODO: support 90 / 270 degree hardware rotation,
>* depending on the hardware this may require the framebuffer
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 9613c1a28487..ac8d70b92b62 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -1531,6 +1531,71 @@ static int drm_mode_parse_cmdline_res_mode(const char
> *str, unsigned int length,
> return 0;
> }
>
> +static int drm_mode_parse_cmdline_options(char *str, size_t len,
> + struct drm_connector *connector,
> + struct drm_cmdline_mode *mode)
> +{
> + unsigned int rotation = 0;
> + char *sep = str;
> +
> + while ((sep = strchr(sep, ','))) {
> + char *delim, *option;
> +
> + option = sep + 1;
> + delim = strchr(option, '=');
> + if (!delim) {
> + delim = strchr(option, ',');
> +
> + if (!delim)
> + delim = str + len;
> + }
> +
> + if (!strncmp(option, "rotate", delim - option)) {
> + const char *value = delim + 1;
> + unsigned int deg;
> +
> + deg = simple_strtol(value, , 10);
> +
> + /* Make sure we have parsed something */
> + if (sep == value)
> + return -EINVAL;
> +
> + switch (deg) {
> + case 0:
> + rotation |= DRM_MODE_ROTATE_0;
> + break;
> +
> + case 90:
> + rotation |= DRM_MODE_ROTATE_90;
> + break;
> +
> + case 180:
> + rotation |= DRM_MODE_ROTATE_180;
> + break;
> +
> + case 270:
> + rotation |= DRM_MODE_ROTATE_270;
> + break;
> +
> + default:
> + return -EINVAL;
> + }
> + } else if (!strncmp(option, "reflect_x", delim - option)) {
> + rotation |= DRM_MODE_REFLECT_X;
> + sep = delim;
> + } else if (!strncmp(option, "reflect_y", delim - option)) {
> + rotation |= DRM_MODE_REFLECT_Y;
> + sep = delim;
> + } else {
> + return -EINVAL;
> + }
> + }
> +
> + mode->rotation = rotation;
> +
> + return 0;
> +}
> +
> /**
> * drm_mode_parse_command_line_for_connector - parse command line
Re: [PATCH 2/9] mm: Add an apply_to_pfn_range interface
On Sat, Apr 13, 2019 at 08:34:02AM +, Thomas Hellstrom wrote:
> Hi, Jérôme
>
> On Fri, 2019-04-12 at 17:07 -0400, Jerome Glisse wrote:
> > On Fri, Apr 12, 2019 at 04:04:18PM +, Thomas Hellstrom wrote:
> > > This is basically apply_to_page_range with added functionality:
> > > Allocating missing parts of the page table becomes optional, which
> > > means that the function can be guaranteed not to error if
> > > allocation
> > > is disabled. Also passing of the closure struct and callback
> > > function
> > > becomes different and more in line with how things are done
> > > elsewhere.
> > >
> > > Finally we keep apply_to_page_range as a wrapper around
> > > apply_to_pfn_range
> > >
> > > The reason for not using the page-walk code is that we want to
> > > perform
> > > the page-walk on vmas pointing to an address space without
> > > requiring the
> > > mmap_sem to be held rather thand on vmas belonging to a process
> > > with the
> > > mmap_sem held.
> > >
> > > Notable changes since RFC:
> > > Don't export apply_to_pfn range.
> > >
> > > Cc: Andrew Morton
> > > Cc: Matthew Wilcox
> > > Cc: Will Deacon
> > > Cc: Peter Zijlstra
> > > Cc: Rik van Riel
> > > Cc: Minchan Kim
> > > Cc: Michal Hocko
> > > Cc: Huang Ying
> > > Cc: Souptick Joarder
> > > Cc: "Jérôme Glisse"
> > > Cc: linux...@kvack.org
> > > Cc: linux-ker...@vger.kernel.org
> > > Signed-off-by: Thomas Hellstrom
> > > ---
> > > include/linux/mm.h | 10
> > > mm/memory.c| 130 ++---
> > >
> > > 2 files changed, 108 insertions(+), 32 deletions(-)
> > >
> > > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > > index 80bb6408fe73..b7dd4ddd6efb 100644
> > > --- a/include/linux/mm.h
> > > +++ b/include/linux/mm.h
> > > @@ -2632,6 +2632,16 @@ typedef int (*pte_fn_t)(pte_t *pte,
> > > pgtable_t token, unsigned long addr,
> > > extern int apply_to_page_range(struct mm_struct *mm, unsigned long
> > > address,
> > > unsigned long size, pte_fn_t fn, void
> > > *data);
> > >
> > > +struct pfn_range_apply;
> > > +typedef int (*pter_fn_t)(pte_t *pte, pgtable_t token, unsigned
> > > long addr,
> > > + struct pfn_range_apply *closure);
> > > +struct pfn_range_apply {
> > > + struct mm_struct *mm;
> > > + pter_fn_t ptefn;
> > > + unsigned int alloc;
> > > +};
> > > +extern int apply_to_pfn_range(struct pfn_range_apply *closure,
> > > + unsigned long address, unsigned long
> > > size);
> > >
> > > #ifdef CONFIG_PAGE_POISONING
> > > extern bool page_poisoning_enabled(void);
> > > diff --git a/mm/memory.c b/mm/memory.c
> > > index a95b4a3b1ae2..60d67158964f 100644
> > > --- a/mm/memory.c
> > > +++ b/mm/memory.c
> > > @@ -1938,18 +1938,17 @@ int vm_iomap_memory(struct vm_area_struct
> > > *vma, phys_addr_t start, unsigned long
> > > }
> > > EXPORT_SYMBOL(vm_iomap_memory);
> > >
> > > -static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
> > > - unsigned long addr, unsigned long
> > > end,
> > > - pte_fn_t fn, void *data)
> > > +static int apply_to_pte_range(struct pfn_range_apply *closure,
> > > pmd_t *pmd,
> > > + unsigned long addr, unsigned long end)
> > > {
> > > pte_t *pte;
> > > int err;
> > > pgtable_t token;
> > > spinlock_t *uninitialized_var(ptl);
> > >
> > > - pte = (mm == _mm) ?
> > > + pte = (closure->mm == _mm) ?
> > > pte_alloc_kernel(pmd, addr) :
> > > - pte_alloc_map_lock(mm, pmd, addr, );
> > > + pte_alloc_map_lock(closure->mm, pmd, addr, );
> > > if (!pte)
> > > return -ENOMEM;
> > >
> > > @@ -1960,86 +1959,107 @@ static int apply_to_pte_range(struct
> > > mm_struct *mm, pmd_t *pmd,
> > > token = pmd_pgtable(*pmd);
> > >
> > > do {
> > > - err = fn(pte++, token, addr, data);
> > > + err = closure->ptefn(pte++, token, addr, closure);
> > > if (err)
> > > break;
> > > } while (addr += PAGE_SIZE, addr != end);
> > >
> > > arch_leave_lazy_mmu_mode();
> > >
> > > - if (mm != _mm)
> > > + if (closure->mm != _mm)
> > > pte_unmap_unlock(pte-1, ptl);
> > > return err;
> > > }
> > >
> > > -static int apply_to_pmd_range(struct mm_struct *mm, pud_t *pud,
> > > - unsigned long addr, unsigned long
> > > end,
> > > - pte_fn_t fn, void *data)
> > > +static int apply_to_pmd_range(struct pfn_range_apply *closure,
> > > pud_t *pud,
> > > + unsigned long addr, unsigned long end)
> > > {
> > > pmd_t *pmd;
> > > unsigned long next;
> > > - int err;
> > > + int err = 0;
> > >
> > > BUG_ON(pud_huge(*pud));
> > >
> > > - pmd = pmd_alloc(mm, pud, addr);
> > > + pmd = pmd_alloc(closure->mm, pud, addr);
> > > if (!pmd)
> > > return -ENOMEM;
> > > +
> > > do {
> > > next = pmd_addr_end(addr, end);
Re: [PATCH v3 1/5] drm/scheduler: rework job destruction
Am 16.04.19 um 16:36 schrieb Grodzovsky, Andrey: > On 4/16/19 5:47 AM, Christian König wrote: >> Am 15.04.19 um 23:17 schrieb Eric Anholt: >>> Andrey Grodzovsky writes: >>> From: Christian König We now destroy finished jobs from the worker thread to make sure that we never destroy a job currently in timeout processing. By this we avoid holding lock around ring mirror list in drm_sched_stop which should solve a deadlock reported by a user. v2: Remove unused variable. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109692 Signed-off-by: Christian König Signed-off-by: Andrey Grodzovsky --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 17 ++-- drivers/gpu/drm/etnaviv/etnaviv_dump.c | 4 - drivers/gpu/drm/etnaviv/etnaviv_sched.c | 9 +- drivers/gpu/drm/scheduler/sched_main.c | 138 + drivers/gpu/drm/v3d/v3d_sched.c | 9 +- >>> Missing corresponding panfrost and lima updates. You should probably >>> pull in drm-misc for hacking on the scheduler. >>> diff --git a/drivers/gpu/drm/v3d/v3d_sched.c b/drivers/gpu/drm/v3d/v3d_sched.c index ce7c737b..8efb091 100644 --- a/drivers/gpu/drm/v3d/v3d_sched.c +++ b/drivers/gpu/drm/v3d/v3d_sched.c @@ -232,11 +232,18 @@ v3d_gpu_reset_for_timeout(struct v3d_dev *v3d, struct drm_sched_job *sched_job) /* block scheduler */ for (q = 0; q < V3D_MAX_QUEUES; q++) - drm_sched_stop(>queue[q].sched); + drm_sched_stop(>queue[q].sched, sched_job); if(sched_job) drm_sched_increase_karma(sched_job); + /* + * Guilty job did complete and hence needs to be manually removed + * See drm_sched_stop doc. + */ + if (list_empty(_job->node)) + sched_job->sched->ops->free_job(sched_job); >>> If the if (sched_job) is necessary up above, then this should clearly be >>> under it. >>> >>> But, can we please have a core scheduler thing we call here instead of >>> drivers all replicating it? >> Yeah that's also something I noted before. >> >> Essential problem is that we remove finished jobs from the mirror list >> and so need to destruct them because we otherwise leak them. >> >> Alternative approach here would be to keep the jobs on the ring mirror >> list, but not submit them again. >> >> Regards, >> Christian. > > I really prefer to avoid this, it means adding extra flag to sched_job > to check in each iteration of the ring mirror list. Mhm, why actually? We just need to check if the scheduler fence is signaled. > What about changing > signature of drm_sched_backend_ops.timedout_job to return drm_sched_job* > instead of void, this way we can return the guilty job back from the > driver specific handler to the generic drm_sched_job_timedout and > release it there. Well the timeout handler already has the job, so returning it doesn't make much sense. The problem is rather that the timeout handler doesn't know if it should destroy the job or not. Christian. > > Andrey > + /* get the GPU back into the init state */ v3d_reset(v3d); ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/tegra: hdmi: Setup audio only if configured
From: Thierry Reding
The audio configuration is only valid if the HDMI codec has been
properly set up. Do not attempt to set up audio before that happens
because it causes a division by zero.
Note that this is only problematic on Tegra20 and Tegra30. Later chips
implement the division instructions which return zero when dividing by
zero and don't throw an exception.
Fixes: db5adf4d6dce ("drm/tegra: hdmi: Fix audio to work with any pixel clock
rate")
Reported-by: Marcel Ziswiler
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/hdmi.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
index 47c55974756d..e6c60bbc0fec 100644
--- a/drivers/gpu/drm/tegra/hdmi.c
+++ b/drivers/gpu/drm/tegra/hdmi.c
@@ -1259,11 +1259,6 @@ static void tegra_hdmi_encoder_enable(struct drm_encoder
*encoder)
tegra_hdmi_writel(hdmi, value, HDMI_NV_PDISP_SOR_REFCLK);
hdmi->dvi = !tegra_output_is_hdmi(output);
- if (!hdmi->dvi) {
- err = tegra_hdmi_setup_audio(hdmi);
- if (err < 0)
- hdmi->dvi = true;
- }
if (hdmi->config->has_hda)
tegra_hdmi_write_eld(hdmi);
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/5] drm/scheduler: rework job destruction
On 4/16/19 5:47 AM, Christian König wrote: > Am 15.04.19 um 23:17 schrieb Eric Anholt: >> Andrey Grodzovsky writes: >> >>> From: Christian König >>> >>> We now destroy finished jobs from the worker thread to make sure that >>> we never destroy a job currently in timeout processing. >>> By this we avoid holding lock around ring mirror list in drm_sched_stop >>> which should solve a deadlock reported by a user. >>> >>> v2: Remove unused variable. >>> >>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109692 >>> >>> Signed-off-by: Christian König >>> Signed-off-by: Andrey Grodzovsky >>> --- >>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 17 ++-- >>> drivers/gpu/drm/etnaviv/etnaviv_dump.c | 4 - >>> drivers/gpu/drm/etnaviv/etnaviv_sched.c | 9 +- >>> drivers/gpu/drm/scheduler/sched_main.c | 138 >>> + >>> drivers/gpu/drm/v3d/v3d_sched.c | 9 +- >> Missing corresponding panfrost and lima updates. You should probably >> pull in drm-misc for hacking on the scheduler. >> >>> diff --git a/drivers/gpu/drm/v3d/v3d_sched.c >>> b/drivers/gpu/drm/v3d/v3d_sched.c >>> index ce7c737b..8efb091 100644 >>> --- a/drivers/gpu/drm/v3d/v3d_sched.c >>> +++ b/drivers/gpu/drm/v3d/v3d_sched.c >>> @@ -232,11 +232,18 @@ v3d_gpu_reset_for_timeout(struct v3d_dev *v3d, >>> struct drm_sched_job *sched_job) >>> /* block scheduler */ >>> for (q = 0; q < V3D_MAX_QUEUES; q++) >>> - drm_sched_stop(>queue[q].sched); >>> + drm_sched_stop(>queue[q].sched, sched_job); >>> if(sched_job) >>> drm_sched_increase_karma(sched_job); >>> + /* >>> + * Guilty job did complete and hence needs to be manually removed >>> + * See drm_sched_stop doc. >>> + */ >>> + if (list_empty(_job->node)) >>> + sched_job->sched->ops->free_job(sched_job); >> If the if (sched_job) is necessary up above, then this should clearly be >> under it. >> >> But, can we please have a core scheduler thing we call here instead of >> drivers all replicating it? > > Yeah that's also something I noted before. > > Essential problem is that we remove finished jobs from the mirror list > and so need to destruct them because we otherwise leak them. > > Alternative approach here would be to keep the jobs on the ring mirror > list, but not submit them again. > > Regards, > Christian. I really prefer to avoid this, it means adding extra flag to sched_job to check in each iteration of the ring mirror list. What about changing signature of drm_sched_backend_ops.timedout_job to return drm_sched_job* instead of void, this way we can return the guilty job back from the driver specific handler to the generic drm_sched_job_timedout and release it there. Andrey > >> >>> + >>> /* get the GPU back into the init state */ >>> v3d_reset(v3d); > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/gma500: Add CedarView LVDS blacklist
On Wed, Apr 10, 2019 at 1:51 PM Dominik 'Rathann' Mierzejewski wrote: > > On Wednesday, 10 April 2019 at 13:33, Patrik Jakobsson wrote: > > On Wed, Apr 10, 2019 at 1:18 PM Dominik 'Rathann' Mierzejewski > > wrote: > > > > > > On Wednesday, 10 April 2019 at 11:08, Hans de Goede wrote: > > > > On 10-04-19 11:00, Patrik Jakobsson wrote: > > > > > On Wed, Apr 10, 2019 at 9:27 AM Hans de Goede > > > > > wrote: > > > > > > On 09-04-19 21:31, Dominik 'Rathann' Mierzejewski wrote: > > > > > > > On Tuesday, 09 April 2019 at 16:44, Hans de Goede wrote: > > > > > > > > On 09-04-19 14:05, Patrik Jakobsson wrote: > > > [...] > > > > > > > > > I'm not totally against this but not sure about the > > > > > > > > > consequences. Is > > > > > > > > > there perhaps a better dmi string to match against? > > > > > > > > > > > > > > > > No there are no better DMI strings to match against I'm afraid. > > > > > > > > > > > > > > I did load default settings in BIOS setup and there's no change in > > > > > > > behaviour. LVDS gets detected as connected: > > > > > > > $ cat /sys/class/drm/card0-LVDS-1/status > > > > > > > connected > > > > > > > > > > > > > > Only VGA output is physically connected at the moment. > > > > > > > > > > > > To be clear what Dominik means here is that he has a VGA monitor > > > > > > connected. There is no LVDS panel in this device at all. > > > > > > > > > > Thanks for testing. I dusted off my DN2800MT and tried turning LVDS > > > > > on/off in the BIOS. With LVDS disabled gma500 reports it as connected. > > > > > When LVDS is enabled in bios I instead get a connected eDP connector. > > > > > I'm starting to think that broken VBT parsing might be the actual > > > > > problem. > > > > > > > > Maybe, but I assume there are CedarView based laptops with LVDS panels > > > > which works, so I suspect this might be more of a bug in your BIOS. > > > > > > > > So what is the next step in debugging this? > > > > > > To add a small twist, I got an updated BIOS from the vendor to fix > > > another issue (https://bugzilla.kernel.org/show_bug.cgi?id=199117) > > > and the DMI string has changed to: "CDV W Series 05", so Hans' patch > > > no longer matches my machine. > > > > Hi Dominik, > > > > Do you have any option to enable/disable LVDS in your BIOS. The BIOS > > default might not be to disable LVDS since they apparently solved the > > issue on the command line anyway. If there is an option to turn it off > > but you still get the same problem, then it is possible that detection > > of "LVDS disabled" in the driver might be bad. > > No, there's no option to enable/disable LVDS. The machine is a NAS box > and doesn't have an LVDS physically. You can see the motherboard e.g. > here: https://youtu.be/ZYNQvZNGLsE?t=855 . I've posted a patch: https://patchwork.freedesktop.org/patch/299821/ Previously we only checked for a child device and ignored the lvds config bits. Hopefully this fixes your problem. -Patrik > > Regards, > Dominik > -- > Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org > There should be a science of discontent. People need hard times and > oppression to develop psychic muscles. > -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4 v2] ARM: dts: Ux500: Add MCDE and Samsung display
This adds and updates the device tree nodes for the MCDE
display controller and connects the Samsung display to
the TVK1281618 user interface board (UIB) so we get
nicely working graphics on this reference design.
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Drop the port graph links between DSI host and children
and just let the panel be the child of its DSI port.
- Move the DSI HS and LP/ES clocks to be properties on
the DSI host nodes.
---
arch/arm/boot/dts/ste-dbx5x0.dtsi | 50 +-
arch/arm/boot/dts/ste-href-stuib.dtsi | 13 ++
arch/arm/boot/dts/ste-href-tvk1281618.dtsi | 13 ++
3 files changed, 65 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/ste-dbx5x0.dtsi
b/arch/arm/boot/dts/ste-dbx5x0.dtsi
index 43d11346308e..81fabf031eff 100644
--- a/arch/arm/boot/dts/ste-dbx5x0.dtsi
+++ b/arch/arm/boot/dts/ste-dbx5x0.dtsi
@@ -1221,20 +1221,48 @@
};
mcde@a035 {
- compatible = "stericsson,mcde";
- reg = <0xa035 0x1000>, /* MCDE */
- <0xa0351000 0x1000>, /* DSI link 1 */
- <0xa0352000 0x1000>, /* DSI link 2 */
- <0xa0353000 0x1000>; /* DSI link 3 */
+ compatible = "ste,mcde";
+ reg = <0xa035 0x1000>;
interrupts = ;
+ epod-supply = <_b2r2_mcde_reg>;
+ vana-supply = <_ldo_ana_reg>;
clocks = <_clk PRCMU_MCDECLK>, /* Main MCDE clock
*/
<_clk PRCMU_LCDCLK>, /* LCD clock */
-<_clk PRCMU_PLLDSI>, /* HDMI clock */
-<_clk PRCMU_DSI0CLK>, /* DSI 0 */
-<_clk PRCMU_DSI1CLK>, /* DSI 1 */
-<_clk PRCMU_DSI0ESCCLK>, /* TVout clock
0 */
-<_clk PRCMU_DSI1ESCCLK>, /* TVout clock
1 */
-<_clk PRCMU_DSI2ESCCLK>; /* TVout clock
2 */
+<_clk PRCMU_PLLDSI>; /* HDMI clock */
+ clock-names = "mcde", "lcd", "hdmi";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ status = "disabled";
+
+ dsi0: dsi@a0351000 {
+ compatible = "ste,mcde-dsi";
+ reg = <0xa0351000 0x1000>;
+ vana-supply = <_ldo_ana_reg>;
+ clocks = <_clk PRCMU_DSI0CLK>,
<_clk PRCMU_DSI0ESCCLK>;
+ clock-names = "hs", "lp";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ dsi1: dsi@a0352000 {
+ compatible = "ste,mcde-dsi";
+ reg = <0xa0352000 0x1000>;
+ vana-supply = <_ldo_ana_reg>;
+ clocks = <_clk PRCMU_DSI1CLK>,
<_clk PRCMU_DSI1ESCCLK>;
+ clock-names = "hs", "lp";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ dsi2: dsi@a0353000 {
+ compatible = "ste,mcde-dsi";
+ reg = <0xa0353000 0x1000>;
+ vana-supply = <_ldo_ana_reg>;
+ /* This DSI port only has the Low Power /
Energy Save clock */
+ clocks = <_clk PRCMU_DSI2ESCCLK>;
+ clock-names = "lp";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
};
cryp@a03cb000 {
diff --git a/arch/arm/boot/dts/ste-href-stuib.dtsi
b/arch/arm/boot/dts/ste-href-stuib.dtsi
index 35e944d8b5c4..eeaea21f5eca 100644
--- a/arch/arm/boot/dts/ste-href-stuib.dtsi
+++ b/arch/arm/boot/dts/ste-href-stuib.dtsi
@@ -190,5 +190,18 @@
};
};
};
+
+ mcde@a035 {
+ status = "okay";
+
+ dsi@a0351000 {
+ panel {
+ compatible = "samsung,s6d16d0";
+ reg = <0>;
+ vdd1-supply = <_ldo_aux1_reg>;
+ reset-gpios = < 1
GPIO_ACTIVE_LOW>;
+ };
+ };
+ };
};
};
diff --git a/arch/arm/boot/dts/ste-href-tvk1281618.dtsi
[PATCH 2/4 v2] drm/mcde: Add device tree bindings
This adds the device tree bindings for the ST-Ericsson
Multi Channel Display Engine MCDE as found in the U8500
SoCs.
Cc: devicet...@vger.kernel.org
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Drop the graph representation of a port from DSI host
to panel child. Just have panels or bridges be children
of the DSI host.
- Just name the panel node "panel".
- Move the HS and LP/ES clocks to be properties on their
respective DSI host device nodes.
- Clarify that the third DSI block (DSI2) does not have
any high speed clock.
---
.../devicetree/bindings/display/ste,mcde.txt | 104 ++
1 file changed, 104 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/ste,mcde.txt
diff --git a/Documentation/devicetree/bindings/display/ste,mcde.txt
b/Documentation/devicetree/bindings/display/ste,mcde.txt
new file mode 100644
index ..4c33c692bd5f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ste,mcde.txt
@@ -0,0 +1,104 @@
+ST-Ericsson Multi Channel Display Engine MCDE
+
+The ST-Ericsson MCDE is a display controller with support for compositing
+and displaying several channels memory resident graphics data on DSI or
+LCD displays or bridges. It is used in the ST-Ericsson U8500 platform.
+
+Required properties:
+
+- compatible: must be:
+ "ste,mcde"
+- reg: register base for the main MCDE control registers, should be
+ 0x1000 in size
+- interrupts: the interrupt line for the MCDE
+- epod-supply: a phandle to the EPOD regulator
+- vana-supply: a phandle to the analog voltage regulator
+- clocks: an array of the MCDE clocks in this strict order:
+ MCDECLK (main MCDE clock), LCDCLK (LCD clock), PLLDSI
+ (HDMI clock), DSI0ESCLK (DSI0 energy save clock),
+ DSI1ESCLK (DSI1 energy save clock), DSI2ESCLK (DSI2 energy
+ save clock)
+- clock-names: must be the following array:
+ "mcde", "lcd", "hdmi"
+ to match the required clock inputs above.
+- #address-cells: should be <1> (for the DSI hosts that will be children)
+- #size-cells: should be <1> (for the DSI hosts that will be children)
+- ranges: this should always be stated
+
+Required subnodes:
+
+The devicetree must specify subnodes for the DSI host adapters.
+These must have the following characteristics:
+
+- compatible: must be:
+ "ste,mcde-dsi"
+- reg: must specify the register range for the DSI host
+- vana-supply: phandle to the VANA voltage regulator
+- clocks: phandles to the high speed and low power (energy save) clocks
+ the high speed clock is not present on the third (dsi2) block, so it
+ should only have the "lp" clock
+- clock-names: "hs" for the high speed clock and "lp" for the low power
+ (energy save) clock
+- #address-cells: should be <1>
+- #size-cells: should be <0>
+
+Display panels and bridges will appear as children on the DSI hosts, and
+the displays are connected to the DSI hosts using the common binding
+for video transmitter interfaces; see
+Documentation/devicetree/bindings/media/video-interfaces.txt
+
+If a DSI host is unused (not connected) it will have no children defined.
+
+Example:
+
+mcde@a035 {
+ compatible = "ste,mcde";
+ reg = <0xa035 0x1000>;
+ interrupts = ;
+ epod-supply = <_b2r2_mcde_reg>;
+ vana-supply = <_ldo_ana_reg>;
+ clocks = <_clk PRCMU_MCDECLK>, /* Main MCDE clock */
+<_clk PRCMU_LCDCLK>, /* LCD clock */
+<_clk PRCMU_PLLDSI>; /* HDMI clock */
+ clock-names = "mcde", "lcd", "hdmi";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ dsi0: dsi@a0351000 {
+ compatible = "ste,mcde-dsi";
+ reg = <0xa0351000 0x1000>;
+ vana-supply = <_ldo_ana_reg>;
+ clocks = <_clk PRCMU_DSI0CLK>, <_clk
PRCMU_DSI0ESCCLK>;
+ clock-names = "hs", "lp";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel {
+ compatible = "samsung,s6d16d0";
+ reg = <0>;
+ vdd1-supply = <_ldo_aux1_reg>;
+ reset-gpios = < 1 GPIO_ACTIVE_LOW>;
+ };
+
+ };
+ dsi1: dsi@a0352000 {
+ compatible = "ste,mcde-dsi";
+ reg = <0xa0352000 0x1000>;
+ vana-supply = <_ldo_ana_reg>;
+ clocks = <_clk PRCMU_DSI1CLK>, <_clk
PRCMU_DSI1ESCCLK>;
+ clock-names = "hs", "lp";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ dsi2: dsi@a0353000 {
+ compatible = "ste,mcde-dsi";
+ reg = <0xa0353000 0x1000>;
+ vana-supply = <_ldo_ana_reg>;
+ /* This DSI port only has the Low Power / Energy Save clock */
+ clocks = <_clk PRCMU_DSI2ESCCLK>;
+ clock-names = "lp";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+};
--
2.20.1
Re: 2019 X.Org Foundation Elections Results... and a Redo
The turnout for the first election and the vote on the bylaw changes was 80% (56/70). Harry On 2019-04-11 8:03 p.m., Harry Wentland wrote: > To all X.Org Foundation Members: > > The 2019 X.Org ballot closed yesterday. There is some good and some bad news. > > The Good News: > The vote on the bylaw changes passed with 53 for, 1 against, and 2 abstaining. > > The Bad News: > Due to some issues with our new members website all votes for new board > members were recorded incorrectly. Thankfully this was fairly obvious. We > believe we've found the bug and have a fix for it: > https://gitlab.freedesktop.org/xorgfoundation/xorg_membership/commit/15f27d45f1d9b1767377814835f2359f7f76c7e5 > > The Redo: > To assure you and us that we've completely fixed the issues with our > elections site we have decided to run a brief mock election where you can > vote for your favorite pastry. This will run until Monday Apr 15 noon UTC > after which we'll tally and publish the results and confirm whether we fixed > the issue. Please leave your vote at https://members.x.org/ballot/3/admin > > If this all looks good we will start the new election for board members a > week from today, on Apr 18, until May 2. > > You can expect another email from me early-to-mid next week to confirm the > start of the new election for board members. > > We received quite a few membership signups after the membership deadline. > We've decided to approve all currently pending signups. > > Harry, on behalf of the X.Org elections committee ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
2019 X.Org Foundation Election Round 2 Starting Thursday
To all X.Org Foundation Members: as per my last email the election for X.Org board members was invalid due to a bug with the voting systems. We apologize for this and the inconvenience caused to you all. The bug has been fixed and tested with a mock election (see results at the end). Round 2 of the election will therefore proceed starting Thursday, April 18, and close on Thursday May 2. Please take the time to vote. Updated Schedule: Nomination period Start: Jan 31 00:00 UTC Nomination period End: Feb 28 23:59 UTC Deadline of X.Org membership application or renewal: Mar 07 23:59 UTC Publication of Candidates & start of Candidate QA: Mar 11 Election Start: Mar 21 00:00 UTC - Delayed to March 21, again delayed to March 27 at 02:00 UTC Election End: Apr 4 23:59 UTC - Extended to April 11, 02:00 UTC Round 2 Election Start: Apr 18 00:00:00 UTC Round 2 Election End: May 2 23:59:00 UTC Harry, on behalf of the X.Org elections committee --- Mock election results Ballot Statistics Turnout: 27.4% (23 / 84) Select: How much do you like pastries? Answer Votes 42 47.8% (11 / 23) A lot 34.8% (8 / 23) To death17.4% (4 / 23) Ranking: Rank the following lovely pastries! Option Rank 1 Rank 2 Rank 3 Rank 4 Rank 5 Rank 6 Final Score Apple strudel 13 4 2 1 1 2 113 Cinnamon Roll 3 7 3 1 2 7 79 Gâteau Basque 3 4 4 1 8 3 76 Beaver Tails3 1 4 8 3 4 73 Trdelník0 5 3 6 7 2 71 Runeberg's torte1 2 7 6 2 5 71 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [5.2][PATCH 0/3] Ingenic JZ47xx KMS driver
On Mon, 2019-03-11 at 12:45 +0100, Paul Cercueil wrote: > Hi Ezequiel, > > On Mon, Mar 11, 2019 at 1:02 AM, Ezequiel Garcia > wrote: > > On Thu, 2019-02-28 at 19:07 -0300, Paul Cercueil wrote: > > > Hi, > > > > > > This is a first attempt at a KMS driver for the JZ47xx MIPS SoCs by > > > Ingenic. It is aimed to replace the aging jz4740-fb driver. > > > > > > The driver will later be updated with new features (overlays, TV-out > > > etc.), that's why I didn't go with the simple/tiny DRM driver. > > > > > > The driver has been tested on the Ben Nanonote (JZ4740) and the > > > RetroMini RS-90 (JZ4725B) handheld gaming console. > > > > > > > Does this support JZ4780? Or otherwise, > > is there any similarity with JZ4780 display controller? > > > > Thanks, > > Eze > > The JZ4780 LCD controller would in theory work with this driver, but > to test on the CI20 you'd need to add support for HDMI first. > After reviewing a bit this driver and the JZ480 one on the CI20 repo, there seems to be some differences. To begin with, the JZ480 apparently has a new 8-word descriptor. The HDMI looks pretty much a Synopsys DW HDMI, mostly compatible with the dw-hdmi encoder. I'll try to put together some patches to enable JZ4780 support. Won't happen anytime soon, so if anyone wants to give it a shot, be my guest :-) Regards, Eze ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/2] drm: Add detection of changing of edid on between suspend and resume
On Thu, 2019-04-11 at 17:00 +0100, Lisovskiy, Stanislav wrote:
> On Thu, 2019-04-11 at 17:36 +0300, Gwan-gyeong Mun wrote:
> > The hotplug detection routine of drm_helper_hpd_irq_event() can
> > detect
> > changing of status of connector, but it can not detect changing of
> > edid.
> >
> > Following scenario requires detection of changing of edid.
> >
> > 1) plug display device to a connector
> > 2) system suspend
> > 3) unplug 1)'s display device and plug the other display device to
> > a
> > connector
> > 4) system resume
> >
> > It adds edid check routine when a connector status still remains as
> > "connector_status_connected".
> >
> > v2: Add NULL check before comparing of EDIDs.
> > v3: Make it as part of existing drm_helper_hpd_irq_event() (Stan,
> > Mika)
> > v4: Rebased
> > v5: Use a cached edid property blob data of connector instead of
> > adding
> > a new detected_edid variable. (Maarten)
> > Add an using of reference count for getting a cached edid
> > property
> > blob data. (Maarten)
> >
> > Testcase: igt/kms_chamelium/hdmi-edid-change-during-hibernate
> > Testcase: igt/kms_chamelium/hdmi-edid-change-during-suspend
> > Testcase: igt/kms_chamelium/dp-edid-change-during-hibernate
> > Testcase: igt/kms_chamelium/dp-edid-change-during-suspend
> >
> > Signed-off-by: Gwan-gyeong Mun
> > ---
> > drivers/gpu/drm/drm_probe_helper.c | 34
> > +-
> > 1 file changed, 33 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_probe_helper.c
> > b/drivers/gpu/drm/drm_probe_helper.c
> > index 6fd08e04b323..27ad7f3dabb7 100644
> > --- a/drivers/gpu/drm/drm_probe_helper.c
> > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > @@ -742,7 +742,16 @@ EXPORT_SYMBOL(drm_kms_helper_poll_fini);
> > * panels.
> > *
> > * This helper function is useful for drivers which can't or don't
> > track hotplug
> > - * interrupts for each connector.
> > + * interrupts for each connector. And it also supports a detection
> > of changing
> > + * of edid on between suspend and resume when a connector status
> > still remains
> > + * as "connector_status_connected".
> > + *
> > + * Following scenario requires detection of changing of edid.
> > + * 1) plug display device to a connector
> > + * 2) system suspend
> > + * 3) unplug 1)'s display device and plug the other display
> > device
> > to a
> > + * connector
> > + * 4) system resume
> > *
> > * Drivers which support hotplug interrupts for each connector
> > individually and
> > * which have a more fine-grained detect logic should bypass this
> > code and
> > @@ -760,6 +769,7 @@ bool drm_helper_hpd_irq_event(struct drm_device
> > *dev)
> > struct drm_connector *connector;
> > struct drm_connector_list_iter conn_iter;
> > enum drm_connector_status old_status;
> > + struct drm_property_blob *old_edid_blob_ptr;
> > bool changed = false;
> >
> > if (!dev->mode_config.poll_enabled)
> > @@ -774,6 +784,11 @@ bool drm_helper_hpd_irq_event(struct
> > drm_device
> > *dev)
> >
> > old_status = connector->status;
> >
> > + if (connector->edid_blob_ptr)
> > + old_edid_blob_ptr =
> > drm_property_blob_get(connector->edid_blob_ptr);
> > + else
> > + old_edid_blob_ptr = NULL;
> > +
> > connector->status = drm_helper_probe_detect(connector,
> > NULL, false);
> > DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %s
> > to %s\n",
> > connector->base.id,
> > @@ -782,6 +797,23 @@ bool drm_helper_hpd_irq_event(struct
> > drm_device
> > *dev)
> > drm_get_connector_status_name(connector-
> > > status));
> > if (old_status != connector->status)
> > changed = true;
> > +
> > + /* Check changing of edid when a connector status still
> > remains
> > +* as "connector_status_connected".
> > +*/
> > + if (old_edid_blob_ptr && connector->edid_blob_ptr &&
>
> I guess you don't need to check both old_edid_blob_ptr && connector-
> > edid_blob_ptr here. Because if old_edid_blob_ptr is not NULL - it
> means that connector->edid_blob_ptr was not NULL for sure. See the
> condition you have added above.
> I mean this one:
>
> > + if (connector->edid_blob_ptr)
> > + old_edid_blob_ptr =
> > drm_property_blob_get(connector->edid_blob_ptr);
> > + else
> > + old_edid_blob_ptr = NULL;
>
> So I would check only old_edid_blob_ptr for not being NULL here.
>
>
Hi Stan,
Thank you for checking it.
First, drivers could set edid_blob_ptr to NULL with
drm_connector_update_edid_property().
And drm_helper_probe_detect() could lead updating of an internal edid
of driver and if driver can not get EDID from I2C, it could call
drm_connector_update_edid_property() with NULL.
therefore I think that we should check old and new edid_blob_ptr are
Re: [PATCH] drm/sun4i: Use DRM_GEM_CMA_VMAP_DRIVER_OPS for GEM operations
Hi,
Le lundi 15 avril 2019 à 18:15 +0200, Paul Kocialkowski a écrit :
> Our driver makes a typical use of CMA, with GEM object allocated as
> GEM CMA objects. Use DRM_GEM_CMA_VMAP_DRIVER_OPS to describe the ops
> instead of duplicating them.
>
> Because DRM_GEM_CMA_VMAP_DRIVER_OPS implements a gem_create_object op
> which sets per-object funcs (drm_cma_gem_default_funcs), we can also
> get rid of free_object_unlocked and gem_vm_ops, which are superseded
> by the object funcs.
I'll need to respin this one by moving DRM_GEM_CMA_VMAP_DRIVER_OPS
before our custom dumb_create, otherwise DRM_GEM_CMA_VMAP_DRIVER_OPS's
dumb_create will take effect instead of our own.
Cheers,
Paul
> Signed-off-by: Paul Kocialkowski
> ---
> drivers/gpu/drm/sun4i/sun4i_drv.c | 16 +---
> 1 file changed, 1 insertion(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
> b/drivers/gpu/drm/sun4i/sun4i_drv.c
> index 3ebd9f5e2719..453b94f9a5b7 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> @@ -53,21 +53,7 @@ static struct drm_driver sun4i_drv_driver = {
>
> /* GEM Operations */
> .dumb_create= drm_sun4i_gem_dumb_create,
> - .gem_free_object_unlocked = drm_gem_cma_free_object,
> - .gem_vm_ops = _gem_cma_vm_ops,
> -
> - /* PRIME Operations */
> - .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> - .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_import = drm_gem_prime_import,
> - .gem_prime_export = drm_gem_prime_export,
> - .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
> - .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> - .gem_prime_vmap = drm_gem_cma_prime_vmap,
> - .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
> - .gem_prime_mmap = drm_gem_cma_prime_mmap,
> -
> - /* Frame Buffer Operations */
> + DRM_GEM_CMA_VMAP_DRIVER_OPS,
> };
>
> static int sun4i_drv_bind(struct device *dev)
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: introduce a capability flag for syncobj timeline support
I can't judge if that UAPI is actually sufficient, but the rest still
looks good to me.
Acked-by: Christian König
Christian.
Am 16.04.19 um 15:15 schrieb Zhou, David(ChunMing):
Reviewed-by: Chunming Zhou for series.
Original Message
Subject: [PATCH v2] drm: introduce a capability flag for syncobj
timeline support
From: Lionel Landwerlin
To: dri-devel@lists.freedesktop.org
CC: Lionel Landwerlin ,"Koenig, Christian" ,Dave Airlie ,Daniel Vetter
,"Zhou, David(ChunMing)"
Unfortunately userspace users of this API cannot be publicly disclosed
yet.
This commit effectively disables timeline syncobj ioctls for all
drivers. Each driver wishing to support this feature will need to
expose DRIVER_SYNCOBJ_TIMELINE.
v2: Add uAPI capability check (Christian)
Signed-off-by: Lionel Landwerlin
Reviewed-by: Christian König (v1)
Cc: Dave Airlie
Cc: Daniel Vetter
Cc: Christian König
Cc: Chunming Zhou
---
drivers/gpu/drm/drm_ioctl.c | 3 +++
drivers/gpu/drm/drm_syncobj.c | 10 +-
include/drm/drm_drv.h | 7 +++
include/uapi/drm/drm.h | 1 +
4 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index d337f161909c..15ca94338d55 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -245,6 +245,9 @@ static int drm_getcap(struct drm_device *dev, void
*data, struct drm_file *file_
case DRM_CAP_SYNCOBJ:
req->value = drm_core_check_feature(dev, DRIVER_SYNCOBJ);
return 0;
+ case DRM_CAP_SYNCOBJ_TIMELINE:
+ req->value = drm_core_check_feature(dev,
DRIVER_SYNCOBJ_TIMELINE);
+ return 0;
}
/* Other caps only work with KMS drivers */
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index fb65f13d25cf..72a38ff6e3e4 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -755,7 +755,7 @@ drm_syncobj_transfer_ioctl(struct drm_device *dev,
void *data,
struct drm_syncobj_transfer *args = data;
int ret;
- if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+ if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ_TIMELINE))
return -EOPNOTSUPP;
if (args->pad)
@@ -1106,7 +1106,7 @@ drm_syncobj_timeline_wait_ioctl(struct
drm_device *dev, void *data,
struct drm_syncobj **syncobjs;
int ret = 0;
- if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+ if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ_TIMELINE))
return -EOPNOTSUPP;
if (args->flags & ~(DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL |
@@ -1210,7 +1210,7 @@ drm_syncobj_timeline_signal_ioctl(struct
drm_device *dev, void *data,
uint32_t i, j;
int ret;
- if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+ if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ_TIMELINE))
return -EOPNOTSUPP;
if (args->pad != 0)
@@ -1281,8 +1281,8 @@ int drm_syncobj_query_ioctl(struct drm_device
*dev, void *data,
uint32_t i;
int ret;
- if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
- return -ENODEV;
+ if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ_TIMELINE))
+ return -EOPNOTSUPP;
if (args->pad != 0)
return -EINVAL;
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 5cc7f728ec73..68ca736c548d 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -91,6 +91,13 @@ enum drm_driver_feature {
* submission.
*/
DRIVER_SYNCOBJ = BIT(5),
+ /**
+ * @DRIVER_SYNCOBJ_TIMELINE:
+ *
+ * Driver supports the timeline flavor of _syncobj for
explicit
+ * synchronization of command submission.
+ */
+ DRIVER_SYNCOBJ_TIMELINE = BIT(6),
/* IMPORTANT: Below are all the legacy flags, add new ones
above. */
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 236b01a1fabf..661d73f9a919 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -649,6 +649,7 @@ struct drm_gem_open {
#define DRM_CAP_PAGE_FLIP_TARGET 0x11
#define DRM_CAP_CRTC_IN_VBLANK_EVENT 0x12
#define DRM_CAP_SYNCOBJ 0x13
+#define DRM_CAP_SYNCOBJ_TIMELINE 0x14
/** DRM_IOCTL_GET_CAP ioctl argument type */
struct drm_get_cap {
--
2.21.0.392.gf8f6787159e
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110327] [exynos-drm] failed to presentate a dumb buffer format NV12 with modifier DRM_FORMAT_MOD_SAMSUNG_64_32_TILE
https://bugs.freedesktop.org/show_bug.cgi?id=110327 --- Comment #3 from andrzej.ha...@gmail.com --- Looking at the code apparently you are setting V4L2_PIX_FMT_NV12MT_16X16 in MFC, but MIXER requires V4L2_PIX_FMT_NV12MT. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re:[PATCH v2] drm: introduce a capability flag for syncobj timeline support
Reviewed-by: Chunming Zhou for series.
Original Message
Subject: [PATCH v2] drm: introduce a capability flag for syncobj timeline
support
From: Lionel Landwerlin
To: dri-devel@lists.freedesktop.org
CC: Lionel Landwerlin ,"Koenig, Christian" ,Dave Airlie ,Daniel Vetter ,"Zhou,
David(ChunMing)"
Unfortunately userspace users of this API cannot be publicly disclosed
yet.
This commit effectively disables timeline syncobj ioctls for all
drivers. Each driver wishing to support this feature will need to
expose DRIVER_SYNCOBJ_TIMELINE.
v2: Add uAPI capability check (Christian)
Signed-off-by: Lionel Landwerlin
Reviewed-by: Christian König (v1)
Cc: Dave Airlie
Cc: Daniel Vetter
Cc: Christian König
Cc: Chunming Zhou
---
drivers/gpu/drm/drm_ioctl.c | 3 +++
drivers/gpu/drm/drm_syncobj.c | 10 +-
include/drm/drm_drv.h | 7 +++
include/uapi/drm/drm.h| 1 +
4 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index d337f161909c..15ca94338d55 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -245,6 +245,9 @@ static int drm_getcap(struct drm_device *dev, void *data,
struct drm_file *file_
case DRM_CAP_SYNCOBJ:
req->value = drm_core_check_feature(dev, DRIVER_SYNCOBJ);
return 0;
+ case DRM_CAP_SYNCOBJ_TIMELINE:
+ req->value = drm_core_check_feature(dev,
DRIVER_SYNCOBJ_TIMELINE);
+ return 0;
}
/* Other caps only work with KMS drivers */
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index fb65f13d25cf..72a38ff6e3e4 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -755,7 +755,7 @@ drm_syncobj_transfer_ioctl(struct drm_device *dev, void
*data,
struct drm_syncobj_transfer *args = data;
int ret;
- if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+ if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ_TIMELINE))
return -EOPNOTSUPP;
if (args->pad)
@@ -1106,7 +1106,7 @@ drm_syncobj_timeline_wait_ioctl(struct drm_device *dev,
void *data,
struct drm_syncobj **syncobjs;
int ret = 0;
- if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+ if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ_TIMELINE))
return -EOPNOTSUPP;
if (args->flags & ~(DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL |
@@ -1210,7 +1210,7 @@ drm_syncobj_timeline_signal_ioctl(struct drm_device *dev,
void *data,
uint32_t i, j;
int ret;
- if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+ if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ_TIMELINE))
return -EOPNOTSUPP;
if (args->pad != 0)
@@ -1281,8 +1281,8 @@ int drm_syncobj_query_ioctl(struct drm_device *dev, void
*data,
uint32_t i;
int ret;
- if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
- return -ENODEV;
+ if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ_TIMELINE))
+ return -EOPNOTSUPP;
if (args->pad != 0)
return -EINVAL;
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 5cc7f728ec73..68ca736c548d 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -91,6 +91,13 @@ enum drm_driver_feature {
* submission.
*/
DRIVER_SYNCOBJ = BIT(5),
+ /**
+* @DRIVER_SYNCOBJ_TIMELINE:
+*
+* Driver supports the timeline flavor of _syncobj for explicit
+* synchronization of command submission.
+*/
+ DRIVER_SYNCOBJ_TIMELINE = BIT(6),
/* IMPORTANT: Below are all the legacy flags, add new ones above. */
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 236b01a1fabf..661d73f9a919 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -649,6 +649,7 @@ struct drm_gem_open {
#define DRM_CAP_PAGE_FLIP_TARGET0x11
#define DRM_CAP_CRTC_IN_VBLANK_EVENT0x12
#define DRM_CAP_SYNCOBJ 0x13
+#define DRM_CAP_SYNCOBJ_TIMELINE 0x14
/** DRM_IOCTL_GET_CAP ioctl argument type */
struct drm_get_cap {
--
2.21.0.392.gf8f6787159e
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm: introduce a capability flag for syncobj timeline support
Unfortunately userspace users of this API cannot be publicly disclosed
yet.
This commit effectively disables timeline syncobj ioctls for all
drivers. Each driver wishing to support this feature will need to
expose DRIVER_SYNCOBJ_TIMELINE.
v2: Add uAPI capability check (Christian)
Signed-off-by: Lionel Landwerlin
Reviewed-by: Christian König (v1)
Cc: Dave Airlie
Cc: Daniel Vetter
Cc: Christian König
Cc: Chunming Zhou
---
drivers/gpu/drm/drm_ioctl.c | 3 +++
drivers/gpu/drm/drm_syncobj.c | 10 +-
include/drm/drm_drv.h | 7 +++
include/uapi/drm/drm.h| 1 +
4 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index d337f161909c..15ca94338d55 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -245,6 +245,9 @@ static int drm_getcap(struct drm_device *dev, void *data,
struct drm_file *file_
case DRM_CAP_SYNCOBJ:
req->value = drm_core_check_feature(dev, DRIVER_SYNCOBJ);
return 0;
+ case DRM_CAP_SYNCOBJ_TIMELINE:
+ req->value = drm_core_check_feature(dev,
DRIVER_SYNCOBJ_TIMELINE);
+ return 0;
}
/* Other caps only work with KMS drivers */
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index fb65f13d25cf..72a38ff6e3e4 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -755,7 +755,7 @@ drm_syncobj_transfer_ioctl(struct drm_device *dev, void
*data,
struct drm_syncobj_transfer *args = data;
int ret;
- if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+ if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ_TIMELINE))
return -EOPNOTSUPP;
if (args->pad)
@@ -1106,7 +1106,7 @@ drm_syncobj_timeline_wait_ioctl(struct drm_device *dev,
void *data,
struct drm_syncobj **syncobjs;
int ret = 0;
- if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+ if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ_TIMELINE))
return -EOPNOTSUPP;
if (args->flags & ~(DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL |
@@ -1210,7 +1210,7 @@ drm_syncobj_timeline_signal_ioctl(struct drm_device *dev,
void *data,
uint32_t i, j;
int ret;
- if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+ if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ_TIMELINE))
return -EOPNOTSUPP;
if (args->pad != 0)
@@ -1281,8 +1281,8 @@ int drm_syncobj_query_ioctl(struct drm_device *dev, void
*data,
uint32_t i;
int ret;
- if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
- return -ENODEV;
+ if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ_TIMELINE))
+ return -EOPNOTSUPP;
if (args->pad != 0)
return -EINVAL;
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 5cc7f728ec73..68ca736c548d 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -91,6 +91,13 @@ enum drm_driver_feature {
* submission.
*/
DRIVER_SYNCOBJ = BIT(5),
+ /**
+* @DRIVER_SYNCOBJ_TIMELINE:
+*
+* Driver supports the timeline flavor of _syncobj for explicit
+* synchronization of command submission.
+*/
+ DRIVER_SYNCOBJ_TIMELINE = BIT(6),
/* IMPORTANT: Below are all the legacy flags, add new ones above. */
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 236b01a1fabf..661d73f9a919 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -649,6 +649,7 @@ struct drm_gem_open {
#define DRM_CAP_PAGE_FLIP_TARGET 0x11
#define DRM_CAP_CRTC_IN_VBLANK_EVENT 0x12
#define DRM_CAP_SYNCOBJ0x13
+#define DRM_CAP_SYNCOBJ_TIMELINE 0x14
/** DRM_IOCTL_GET_CAP ioctl argument type */
struct drm_get_cap {
--
2.21.0.392.gf8f6787159e
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v2,1/2] drm: Add writeback_w,h properties
On Tue, Apr 16, 2019 at 2:43 PM Liviu Dudau wrote: > > On Tue, Apr 16, 2019 at 11:55:34AM +0200, Daniel Vetter wrote: > > On Tue, Apr 16, 2019 at 11:17 AM Liviu Dudau wrote: > > > > > > On Tue, Apr 16, 2019 at 09:34:20AM +0200, Daniel Vetter wrote: > > > > On Mon, Apr 15, 2019 at 10:20:45AM +0100, Liviu Dudau wrote: > > > > > On Mon, Apr 15, 2019 at 08:59:30AM +0100, james qian wang (Arm > > > > > Technology China) wrote: > > > > > > Hi Ben: > > > > > > Do we real need these two individual properties for specifing the > > > > > > writeback > > > > > > w/h, can we use fb->w/h ? > > > > > > And since these two properties are added as common and standard > > > > > > properties, > > > > > > it influnce all existing write-back implementation which all assumed > > > > > > writeback size as fb->w/h. > > > > > > > > > > The idea of having these additional properties was to maintain > > > > > backwards > > > > > compatibility (of some sort). If you don't set writeback_w/h then the > > > > > assumption is that they are the same as fb->w/h, but I can see how > > > > > it's > > > > > going to be confusing to have fb->w/h different from crtc->w/h and > > > > > different from writeback_w/h. > > > > > > > > Since we already have crtc_w/h independent of writeback_fb_w/h, do we > > > > need > > > > another set of w/h? Are all the interactions between these tree > > > > well-defined? > > > > > > No, we probably don't need another set of w/h values. As for the > > > interaction, I propose the following: > > > > > > - writeback is only attached to a connector, so the crtc_x/y/w/h are the > > > "input source" parameters into the writeback. Given that we put in the > > > writeback the content of the CRTC, I suggest we ignore x,y (consider > > > them to be always 0 for the writeback output). > > > > There's no crtc_x/y. > > Bah, sorry about that! > > > And what I meant with crtc_w/h is > > crtc_state->mode->h/vdisplay. And you can already express scaling with > > that, by setting the plane_state->crtc_x/y/h/w parameters as you wish. > > We don't have a plane associated with the writeback, it's a connector > with a framebuffer attached to it. :( I meant the input planes, I know there's no output/writeback planes. Afaiui what we want to do is: planes -> plane composition hw -> some scaling -> writeback We can model this already (I think at least, that's really my question here) by adjustinv mode->h/vdisplay and ofc also adjusting dst_x/y/w/h of all the input planes. But is that good enough? With your proposal (either autoscaling per fb->w/h from the writeback fb, or the writeback_w/h properties we'd have double-scaling: planes -> plane composition hw -> some scaling (because of crtc->mode.h/vdisplay) -> more scaling (due to writeback h/w, whether as props or from the fb) -> writeback Scaling twice with nothing else in the pipeline seems silly to me. > > > - writeback has a framebuffer attached, so we can use the fb->w/h to > > > determine if we need to do any scaling of the output. > > > > Hm, not sure we want that. You might want to automatically round > > fb->w/h to whatever (ok right now we don't do that I think anywhere), > > so forcing the output to match the fb->h/w doesn't make sense for me. > > It's also inconsistent with how we treat fb attached to planes (where > > we have the full set of src coordinates). > > The writeback will have to fit into that framebuffer, so it can't be > bigger than fb->w/h. Smaller, yes. Yeah we should probably check that in core atomic code. Like we do already for planes in drm_atomic_plane_check() > > > > Atm I'm assuming that writeback is using crtc_w/h into the fb, at offset > > > > 0, not scaled any further. But the planes themselves can be scaled into > > > > the crtc_w/h window ofc. > > > > > > Our hardware has the ability to also write back one of the planes and > > > scale it during writeback, but we have no way of expressing that in DRM > > > via connectors, so we are going to ignore that case. The supported usecase > > > is for the planes to be scaled into the "composition" area which is the > > > size > > > of the CRTC, and then writeback that to memory, possibly with scaling (we > > > officially only going to support downscaling due to external dependencies > > > on the memory clock that is needed for supporting upscaling). > > > > Hm, see above, you can already express that: > > - set crtc_state->mode->h/vdisplay to what you want the resulting > > writeback image to be sized at. > > - place the plane however you want using the plane properties within > > that crtc window. > > The way we agreed ~2 years ago in the community to implement this was to have > the writeback as a connector that gets the "output" of the CRTC and writes it > into > memory rather than on phosphorus. We have not added a plane to that, but > in hindsight we might find it would have been useful. Still not talking about planes on the output side here :-) Adding
Re: [PATCH 1/2] drm: report consistent errors when checking syncobj capibility
Am 16.04.19 um 14:43 schrieb Daniel Vetter:
> On Tue, Apr 16, 2019 at 02:40:37PM +0200, Christian König wrote:
>> Am 16.04.19 um 14:30 schrieb Lionel Landwerlin:
>>> We've been somewhat inconsistent when adding the new ioctl and
>>> returned ENODEV instead of EOPNOTSUPPORTED upon failing the syncobj
>>> capibility.
>>>
>>> Signed-off-by: Lionel Landwerlin
>>> Fixes: ea569910cbab98 ("drm/syncobj: add transition iotcls between binary
>>> and timeline v2")
>>> Fixes: 01d6c357837918 ("drm/syncobj: add support for timeline point wait
>>> v8")
>>> Cc: Dave Airlie
>>> Cc: Christian König
>>> Cc: Chunming Zhou
>> Reviewed-by: Christian König for the series.
>>
>> How about also adding a DRM_CAP_TIMELINE_SYNCOBJ as Daniel suggested so that
>> userspace can note that as well?
> Attempting one of the ioctls and getting a EOPNOTSUPP should be good
> enough. In case that "Daniel" meant me ...
Oh, sorry my fault. It was actually Dave who suggested that...
Christian.
> -Daniel
>
>> Thanks,
>> Christian.
>>
>>> ---
>>>drivers/gpu/drm/drm_syncobj.c | 4 ++--
>>>1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
>>> index c534c5d46f1e..fb65f13d25cf 100644
>>> --- a/drivers/gpu/drm/drm_syncobj.c
>>> +++ b/drivers/gpu/drm/drm_syncobj.c
>>> @@ -756,7 +756,7 @@ drm_syncobj_transfer_ioctl(struct drm_device *dev, void
>>> *data,
>>> int ret;
>>> if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
>>> - return -ENODEV;
>>> + return -EOPNOTSUPP;
>>> if (args->pad)
>>> return -EINVAL;
>>> @@ -1107,7 +1107,7 @@ drm_syncobj_timeline_wait_ioctl(struct drm_device
>>> *dev, void *data,
>>> int ret = 0;
>>> if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
>>> - return -ENODEV;
>>> + return -EOPNOTSUPP;
>>> if (args->flags & ~(DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL |
>>> DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT |
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: report consistent errors when checking syncobj capibility
On 16/04/2019 13:40, Christian König wrote:
Am 16.04.19 um 14:30 schrieb Lionel Landwerlin:
We've been somewhat inconsistent when adding the new ioctl and
returned ENODEV instead of EOPNOTSUPPORTED upon failing the syncobj
capibility.
Signed-off-by: Lionel Landwerlin
Fixes: ea569910cbab98 ("drm/syncobj: add transition iotcls between
binary and timeline v2")
Fixes: 01d6c357837918 ("drm/syncobj: add support for timeline point
wait v8")
Cc: Dave Airlie
Cc: Christian König
Cc: Chunming Zhou
Reviewed-by: Christian König for the series.
How about also adding a DRM_CAP_TIMELINE_SYNCOBJ as Daniel suggested
so that userspace can note that as well?
Thanks,
Christian.
Thanks Christian, I forgot about that...
---
drivers/gpu/drm/drm_syncobj.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c
b/drivers/gpu/drm/drm_syncobj.c
index c534c5d46f1e..fb65f13d25cf 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -756,7 +756,7 @@ drm_syncobj_transfer_ioctl(struct drm_device
*dev, void *data,
int ret;
if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
- return -ENODEV;
+ return -EOPNOTSUPP;
if (args->pad)
return -EINVAL;
@@ -1107,7 +1107,7 @@ drm_syncobj_timeline_wait_ioctl(struct
drm_device *dev, void *data,
int ret = 0;
if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
- return -ENODEV;
+ return -EOPNOTSUPP;
if (args->flags & ~(DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL |
DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v2,1/2] drm: Add writeback_w,h properties
On Tue, Apr 16, 2019 at 11:55:34AM +0200, Daniel Vetter wrote:
> On Tue, Apr 16, 2019 at 11:17 AM Liviu Dudau wrote:
> >
> > On Tue, Apr 16, 2019 at 09:34:20AM +0200, Daniel Vetter wrote:
> > > On Mon, Apr 15, 2019 at 10:20:45AM +0100, Liviu Dudau wrote:
> > > > On Mon, Apr 15, 2019 at 08:59:30AM +0100, james qian wang (Arm
> > > > Technology China) wrote:
> > > > > On Fri, Apr 12, 2019 at 02:08:28PM +, Ben Davis wrote:
> > > > > > Add new properties to specify width and height for writeback.
> > > > > >
> > > > > > Signed-off-by: Ben Davis
> > > > > > ---
> > > > > > drivers/gpu/drm/drm_atomic_uapi.c | 8
> > > > > > drivers/gpu/drm/drm_writeback.c | 28
> > > > > > include/drm/drm_connector.h | 4
> > > > > > include/drm/drm_mode_config.h | 10 ++
> > > > > > 4 files changed, 50 insertions(+)
> > > > > >
> > > > > > --
> > > > > > 2.7.4
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > > > > > b/drivers/gpu/drm/drm_atomic_uapi.c
> > > > > > index d520a04..1f68dce 100644
> > > > > > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > > > > > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > > > > > @@ -765,6 +765,10 @@ static int
> > > > > > drm_atomic_connector_set_property(struct drm_connector *connector,
> > > > > > return -EINVAL;
> > > > > > }
> > > > > > state->content_protection = val;
> > > > > > + } else if (property == config->prop_writeback_w) {
> > > > > > + state->writeback_w = val;
> > > > > > + } else if (property == config->prop_writeback_h) {
> > > > > > + state->writeback_h = val;
> > > > > > } else if (property == config->writeback_fb_id_property) {
> > > > > > struct drm_framebuffer *fb =
> > > > > > drm_framebuffer_lookup(dev, NULL, val);
> > > > > > int ret =
> > > > > > drm_atomic_set_writeback_fb_for_connector(state, fb);
> > > > > > @@ -837,6 +841,10 @@ drm_atomic_connector_get_property(struct
> > > > > > drm_connector *connector,
> > > > > > *val = state->scaling_mode;
> > > > > > } else if (property ==
> > > > > > connector->content_protection_property) {
> > > > > > *val = state->content_protection;
> > > > > > + } else if (property == config->prop_writeback_w) {
> > > > > > + *val = state->writeback_w;
> > > > > > + } else if (property == config->prop_writeback_h) {
> > > > > > + *val = state->writeback_h;
> > > > > > } else if (property == config->writeback_fb_id_property) {
> > > > > > /* Writeback framebuffer is one-shot, write and
> > > > > > forget */
> > > > > > *val = 0;
> > > > > > diff --git a/drivers/gpu/drm/drm_writeback.c
> > > > > > b/drivers/gpu/drm/drm_writeback.c
> > > > > > index c20e6fe..3d0453e 100644
> > > > > > --- a/drivers/gpu/drm/drm_writeback.c
> > > > > > +++ b/drivers/gpu/drm/drm_writeback.c
> > > > > > @@ -74,6 +74,12 @@
> > > > > > * applications making use of writeback connectors *always*
> > > > > > retrieve an
> > > > > > * out-fence for the commit and use it appropriately.
> > > > > > * From userspace, this property will always read as zero.
> > > > > > + *
> > > > > > + * "WRITEBACK_W":
> > > > > > + * The width of the writeback buffer to write back. 0 acts as
> > > > > > default.
> > > > > > + *
> > > > > > + * "WRITEBACK_H":
> > > > > > + * The height of the writeback buffer to write back. 0 acts as
> > > > > > default.
> > > > > > */
> > > > > >
> > > > > > #define fence_to_wb_connector(x) container_of(x->lock, \
> > > > > > @@ -141,6 +147,22 @@ static int create_writeback_properties(struct
> > > > > > drm_device *dev)
> > > > > > dev->mode_config.writeback_out_fence_ptr_property =
> > > > > > prop;
> > > > > > }
> > > > > >
> > > > > > + if (!dev->mode_config.prop_writeback_w) {
> > > > > > + prop = drm_property_create_range(dev,
> > > > > > DRM_MODE_PROP_ATOMIC,
> > > > > > +"WRITEBACK_W", 1,
> > > > > > UINT_MAX);
> > > > > > + if (!prop)
> > > > > > + return -ENOMEM;
> > > > > > + dev->mode_config.prop_writeback_w = prop;
> > > > > > + }
> > > > > > +
> > > > > > + if (!dev->mode_config.prop_writeback_h) {
> > > > > > + prop = drm_property_create_range(dev,
> > > > > > DRM_MODE_PROP_ATOMIC,
> > > > > > +"WRITEBACK_H", 1,
> > > > > > UINT_MAX);
> > > > > > + if (!prop)
> > > > > > + return -ENOMEM;
> > > > > > + dev->mode_config.prop_writeback_h = prop;
> > > > > > + }
> > > > > > +
> > > > > > return 0;
> > > > > > }
> > > > > >
> > > > > > @@ -225,6 +247,12 @@ int
Re: [PATCH 1/2] drm: report consistent errors when checking syncobj capibility
On Tue, Apr 16, 2019 at 02:40:37PM +0200, Christian König wrote:
> Am 16.04.19 um 14:30 schrieb Lionel Landwerlin:
> > We've been somewhat inconsistent when adding the new ioctl and
> > returned ENODEV instead of EOPNOTSUPPORTED upon failing the syncobj
> > capibility.
> >
> > Signed-off-by: Lionel Landwerlin
> > Fixes: ea569910cbab98 ("drm/syncobj: add transition iotcls between binary
> > and timeline v2")
> > Fixes: 01d6c357837918 ("drm/syncobj: add support for timeline point wait
> > v8")
> > Cc: Dave Airlie
> > Cc: Christian König
> > Cc: Chunming Zhou
>
> Reviewed-by: Christian König for the series.
>
> How about also adding a DRM_CAP_TIMELINE_SYNCOBJ as Daniel suggested so that
> userspace can note that as well?
Attempting one of the ioctls and getting a EOPNOTSUPP should be good
enough. In case that "Daniel" meant me ...
-Daniel
>
> Thanks,
> Christian.
>
> > ---
> > drivers/gpu/drm/drm_syncobj.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> > index c534c5d46f1e..fb65f13d25cf 100644
> > --- a/drivers/gpu/drm/drm_syncobj.c
> > +++ b/drivers/gpu/drm/drm_syncobj.c
> > @@ -756,7 +756,7 @@ drm_syncobj_transfer_ioctl(struct drm_device *dev, void
> > *data,
> > int ret;
> > if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
> > - return -ENODEV;
> > + return -EOPNOTSUPP;
> > if (args->pad)
> > return -EINVAL;
> > @@ -1107,7 +1107,7 @@ drm_syncobj_timeline_wait_ioctl(struct drm_device
> > *dev, void *data,
> > int ret = 0;
> > if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
> > - return -ENODEV;
> > + return -EOPNOTSUPP;
> > if (args->flags & ~(DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL |
> > DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT |
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: report consistent errors when checking syncobj capibility
Am 16.04.19 um 14:30 schrieb Lionel Landwerlin:
We've been somewhat inconsistent when adding the new ioctl and
returned ENODEV instead of EOPNOTSUPPORTED upon failing the syncobj
capibility.
Signed-off-by: Lionel Landwerlin
Fixes: ea569910cbab98 ("drm/syncobj: add transition iotcls between binary and
timeline v2")
Fixes: 01d6c357837918 ("drm/syncobj: add support for timeline point wait v8")
Cc: Dave Airlie
Cc: Christian König
Cc: Chunming Zhou
Reviewed-by: Christian König for the series.
How about also adding a DRM_CAP_TIMELINE_SYNCOBJ as Daniel suggested so
that userspace can note that as well?
Thanks,
Christian.
---
drivers/gpu/drm/drm_syncobj.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index c534c5d46f1e..fb65f13d25cf 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -756,7 +756,7 @@ drm_syncobj_transfer_ioctl(struct drm_device *dev, void
*data,
int ret;
if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
- return -ENODEV;
+ return -EOPNOTSUPP;
if (args->pad)
return -EINVAL;
@@ -1107,7 +1107,7 @@ drm_syncobj_timeline_wait_ioctl(struct drm_device *dev,
void *data,
int ret = 0;
if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
- return -ENODEV;
+ return -EOPNOTSUPP;
if (args->flags & ~(DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL |
DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm: report consistent errors when checking syncobj capibility
We've been somewhat inconsistent when adding the new ioctl and
returned ENODEV instead of EOPNOTSUPPORTED upon failing the syncobj
capibility.
Signed-off-by: Lionel Landwerlin
Fixes: ea569910cbab98 ("drm/syncobj: add transition iotcls between binary and
timeline v2")
Fixes: 01d6c357837918 ("drm/syncobj: add support for timeline point wait v8")
Cc: Dave Airlie
Cc: Christian König
Cc: Chunming Zhou
---
drivers/gpu/drm/drm_syncobj.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index c534c5d46f1e..fb65f13d25cf 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -756,7 +756,7 @@ drm_syncobj_transfer_ioctl(struct drm_device *dev, void
*data,
int ret;
if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
- return -ENODEV;
+ return -EOPNOTSUPP;
if (args->pad)
return -EINVAL;
@@ -1107,7 +1107,7 @@ drm_syncobj_timeline_wait_ioctl(struct drm_device *dev,
void *data,
int ret = 0;
if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
- return -ENODEV;
+ return -EOPNOTSUPP;
if (args->flags & ~(DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL |
DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT |
--
2.21.0.392.gf8f6787159e
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm: introduce a capability flag for syncobj timeline support
Unfortunately userspace users of this API cannot be publicly disclosed
yet.
This commit effectively disables timeline syncobj ioctls for all
drivers. Each driver wishing to support this feature will need to
expose DRIVER_SYNCOBJ_TIMELINE.
Signed-off-by: Lionel Landwerlin
Cc: Dave Airlie
Cc: Daniel Vetter
Cc: Christian König
Cc: Chunming Zhou
---
drivers/gpu/drm/drm_syncobj.c | 10 +-
include/drm/drm_drv.h | 7 +++
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index fb65f13d25cf..72a38ff6e3e4 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -755,7 +755,7 @@ drm_syncobj_transfer_ioctl(struct drm_device *dev, void
*data,
struct drm_syncobj_transfer *args = data;
int ret;
- if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+ if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ_TIMELINE))
return -EOPNOTSUPP;
if (args->pad)
@@ -1106,7 +1106,7 @@ drm_syncobj_timeline_wait_ioctl(struct drm_device *dev,
void *data,
struct drm_syncobj **syncobjs;
int ret = 0;
- if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+ if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ_TIMELINE))
return -EOPNOTSUPP;
if (args->flags & ~(DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL |
@@ -1210,7 +1210,7 @@ drm_syncobj_timeline_signal_ioctl(struct drm_device *dev,
void *data,
uint32_t i, j;
int ret;
- if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+ if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ_TIMELINE))
return -EOPNOTSUPP;
if (args->pad != 0)
@@ -1281,8 +1281,8 @@ int drm_syncobj_query_ioctl(struct drm_device *dev, void
*data,
uint32_t i;
int ret;
- if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
- return -ENODEV;
+ if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ_TIMELINE))
+ return -EOPNOTSUPP;
if (args->pad != 0)
return -EINVAL;
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 5cc7f728ec73..68ca736c548d 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -91,6 +91,13 @@ enum drm_driver_feature {
* submission.
*/
DRIVER_SYNCOBJ = BIT(5),
+ /**
+* @DRIVER_SYNCOBJ_TIMELINE:
+*
+* Driver supports the timeline flavor of _syncobj for explicit
+* synchronization of command submission.
+*/
+ DRIVER_SYNCOBJ_TIMELINE = BIT(6),
/* IMPORTANT: Below are all the legacy flags, add new ones above. */
--
2.21.0.392.gf8f6787159e
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/6] Fix crash after reloading a driver using ttm
Am 16.04.19 um 14:18 schrieb Daniel Vetter: > On Tue, Apr 16, 2019 at 11:06:54AM +, Koenig, Christian wrote: >> Am 16.04.19 um 12:54 schrieb Karol Herbst: >>> On Tue, Apr 16, 2019 at 11:12 AM Koenig, Christian >>> wrote: Am 16.04.19 um 11:10 schrieb Karol Herbst: > On Tue, Apr 16, 2019 at 8:38 AM Christian König > wrote: >> Am 16.04.19 um 02:35 schrieb Karol Herbst: >>> Kobjects are supposed to be dynamically allocated, but with recent >>> changes >>> this rule was violated. Reverting those commits fixes crashes when a drm >>> driver using TTM gets loaded again. >>> >>> The object in question is "ttm_mem_glob" declared inside >>> "include/drm/ttm/ttm_memory.h" and instatiated inside >>> "drivers/gpu/drm/ttm/ttm_memory.c". >>> >>> from "Documentation/kobject.txt": >>> "Because kobjects are dynamic, they must not be declared statically or >>> on >>> the stack, but instead, always allocated dynamically. Future versions >>> of >>> the kernel will contain a run-time check for kobjects that are created >>> statically and will warn the developer of this improper usage." >>> >>> Unloading ttm before reloading the driver workarounds that crash, >>> because >>> the memory backing the kobject member "kobj" is cleaned up. The >>> kobject_del >>> and kobject_put function never free or clean up the kobject object >>> leaving >>> it in an undefined state. >>> >>> I reverted a few more commits to make it less painful for me to rever >>> this >>> rather big change. >> Well, NAK. By reverting those change you also re-introduced the problems >> we originally fixed with those patches. >> >> Please work on a proper fix instead, >> Christian. > And which problem was that besides duplicated code (or maybe even a > bit of memory consumption if multiple ttm driver were used)? If I had > to choose between duplicated code and a crash, I choose the former. > > Maybe I missed the real reason why those changes are made, but the > commit messages don't really seem to tell me. The old implementation crashed because different drivers tried to allocate the same kobj. Crashing in one way is not better than crashing in another way. Christian. >>> how can that old crash be triggered? By loading two ttm based drivers >>> at the same time or by other means? >> Yes, exactly. Even worse it could be triggered by one driver >> instantiating multiple times at the same time, e.g two AMD GPUs in the >> same system. >> >> On the other hand I completely agree that using kobj static is >> completely nuts. The problem is that using a kobj was the wrong approach >> in the first place. >> >> In other words when you have something which controls a global behavior >> of a module, what do you use? Right, a module parameter. >> >> Point is that we can't get away from those kobj without breaking the >> uapi, so that is something which can't be done easily. > Randome idea: Push the kobj setup into drm.ko (and shrugg it off as > another lesson in how maybe uapi shouldn't have been designed, but hey not > our worst mistake by far). I think that'd be totally ok. Yeah, thought about that as well. But I would rather re-design this from the scratch instead of just moving it over. And yes I agree with a bit of luck that UAPI is actually not used at all, so we could remove it sooner or later. Regards, Christian. > -Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: add drm_format_helper.c to kerneldoc
On Tue, Apr 16, 2019 at 11:05:33AM +0200, Gerd Hoffmann wrote: > Also drop the dstclip parameter sphinx has warned about (leftolver from > an earlier patch version). > > Signed-off-by: Gerd Hoffmann Assuming it all builds cleanly and all the links work and no warnings from sphinx: Acked-by: Daniel Vetter > --- > drivers/gpu/drm/drm_format_helper.c | 1 - > Documentation/gpu/drm-kms-helpers.rst | 6 ++ > 2 files changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_format_helper.c > b/drivers/gpu/drm/drm_format_helper.c > index da388012df2a..a18da35145b7 100644 > --- a/drivers/gpu/drm/drm_format_helper.c > +++ b/drivers/gpu/drm/drm_format_helper.c > @@ -235,7 +235,6 @@ static void drm_fb_xrgb_to_rgb888_line(u8 *dbuf, u32 > *sbuf, > * @vaddr: XRGB source buffer > * @fb: DRM framebuffer > * @clip: Clip rectangle area to copy > - * @dstclip: Clip destination too. > * > * Drivers can use this function for RGB888 devices that don't natively > * support XRGB. > diff --git a/Documentation/gpu/drm-kms-helpers.rst > b/Documentation/gpu/drm-kms-helpers.rst > index 58b375e47615..14102ae035dc 100644 > --- a/Documentation/gpu/drm-kms-helpers.rst > +++ b/Documentation/gpu/drm-kms-helpers.rst > @@ -107,6 +107,12 @@ fbdev Helper Functions Reference > .. kernel-doc:: drivers/gpu/drm/drm_fb_helper.c > :export: > > +format Helper Functions Reference > += > + > +.. kernel-doc:: drivers/gpu/drm/drm_format_helper.c > + :export: > + > Framebuffer CMA Helper Functions Reference > == > > -- > 2.18.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/6] Fix crash after reloading a driver using ttm
On Tue, Apr 16, 2019 at 11:06:54AM +, Koenig, Christian wrote: > Am 16.04.19 um 12:54 schrieb Karol Herbst: > > On Tue, Apr 16, 2019 at 11:12 AM Koenig, Christian > > wrote: > >> Am 16.04.19 um 11:10 schrieb Karol Herbst: > >>> On Tue, Apr 16, 2019 at 8:38 AM Christian König > >>> wrote: > Am 16.04.19 um 02:35 schrieb Karol Herbst: > > Kobjects are supposed to be dynamically allocated, but with recent > > changes > > this rule was violated. Reverting those commits fixes crashes when a drm > > driver using TTM gets loaded again. > > > > The object in question is "ttm_mem_glob" declared inside > > "include/drm/ttm/ttm_memory.h" and instatiated inside > > "drivers/gpu/drm/ttm/ttm_memory.c". > > > > from "Documentation/kobject.txt": > > "Because kobjects are dynamic, they must not be declared statically or > > on > > the stack, but instead, always allocated dynamically. Future versions > > of > > the kernel will contain a run-time check for kobjects that are created > > statically and will warn the developer of this improper usage." > > > > Unloading ttm before reloading the driver workarounds that crash, > > because > > the memory backing the kobject member "kobj" is cleaned up. The > > kobject_del > > and kobject_put function never free or clean up the kobject object > > leaving > > it in an undefined state. > > > > I reverted a few more commits to make it less painful for me to rever > > this > > rather big change. > Well, NAK. By reverting those change you also re-introduced the problems > we originally fixed with those patches. > > Please work on a proper fix instead, > Christian. > >>> And which problem was that besides duplicated code (or maybe even a > >>> bit of memory consumption if multiple ttm driver were used)? If I had > >>> to choose between duplicated code and a crash, I choose the former. > >>> > >>> Maybe I missed the real reason why those changes are made, but the > >>> commit messages don't really seem to tell me. > >> The old implementation crashed because different drivers tried to > >> allocate the same kobj. > >> > >> Crashing in one way is not better than crashing in another way. > >> > >> Christian. > >> > > how can that old crash be triggered? By loading two ttm based drivers > > at the same time or by other means? > > Yes, exactly. Even worse it could be triggered by one driver > instantiating multiple times at the same time, e.g two AMD GPUs in the > same system. > > On the other hand I completely agree that using kobj static is > completely nuts. The problem is that using a kobj was the wrong approach > in the first place. > > In other words when you have something which controls a global behavior > of a module, what do you use? Right, a module parameter. > > Point is that we can't get away from those kobj without breaking the > uapi, so that is something which can't be done easily. Randome idea: Push the kobj setup into drm.ko (and shrugg it off as another lesson in how maybe uapi shouldn't have been designed, but hey not our worst mistake by far). I think that'd be totally ok. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amdgpu: fix spelling mistake "gateing" -> "gating"
From: Colin Ian King
There is a spelling mistake in a DRM_INFO message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdgpu/vce_v2_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vce_v2_0.c
b/drivers/gpu/drm/amd/amdgpu/vce_v2_0.c
index bed78a778e3f..40363ca6c5f1 100644
--- a/drivers/gpu/drm/amd/amdgpu/vce_v2_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vce_v2_0.c
@@ -283,7 +283,7 @@ static int vce_v2_0_stop(struct amdgpu_device *adev)
}
if (vce_v2_0_wait_for_idle(adev)) {
- DRM_INFO("VCE is busy, Can't set clock gateing");
+ DRM_INFO("VCE is busy, Can't set clock gating");
return 0;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/gma500/cdv: Check vbt config bits when detecting lvds panels
Some machines have an lvds child device in vbt even though a panel is
not attached. To make detection more reliable we now also check the lvds
config bits available in the vbt.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1665766
Signed-off-by: Patrik Jakobsson
Cc: Hans de Goede
Cc: Ville Syrjälä
---
drivers/gpu/drm/gma500/cdv_intel_lvds.c | 3 +++
drivers/gpu/drm/gma500/intel_bios.c | 3 +++
drivers/gpu/drm/gma500/psb_drv.h| 1 +
3 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
index de9531caaca0..9c8446184b17 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
@@ -594,6 +594,9 @@ void cdv_intel_lvds_init(struct drm_device *dev,
int pipe;
u8 pin;
+ if (!dev_priv->lvds_enabled_in_vbt)
+ return;
+
pin = GMBUS_PORT_PANEL;
if (!lvds_is_present_in_vbt(dev, )) {
DRM_DEBUG_KMS("LVDS is not present in VBT\n");
diff --git a/drivers/gpu/drm/gma500/intel_bios.c
b/drivers/gpu/drm/gma500/intel_bios.c
index 63bde4e86c6a..e019ea271ffc 100644
--- a/drivers/gpu/drm/gma500/intel_bios.c
+++ b/drivers/gpu/drm/gma500/intel_bios.c
@@ -436,6 +436,9 @@ parse_driver_features(struct drm_psb_private *dev_priv,
if (driver->lvds_config == BDB_DRIVER_FEATURE_EDP)
dev_priv->edp.support = 1;
+ dev_priv->lvds_enabled_in_vbt = driver->lvds_config != 0;
+ DRM_DEBUG_KMS("LVDS VBT config bits: 0x%x\n", driver->lvds_config);
+
/* This bit means to use 96Mhz for DPLL_A or not */
if (driver->primary_lfp_id)
dev_priv->dplla_96mhz = true;
diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
index 941b238bdcc9..bc608ddc3bd1 100644
--- a/drivers/gpu/drm/gma500/psb_drv.h
+++ b/drivers/gpu/drm/gma500/psb_drv.h
@@ -537,6 +537,7 @@ struct drm_psb_private {
int lvds_ssc_freq;
bool is_lvds_on;
bool is_mipi_on;
+ bool lvds_enabled_in_vbt;
u32 mipi_ctrl_display;
unsigned int core_freq;
--
2.16.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
