[PATCH v2] video: fbdev: Fix Warning comparing pointer to 0 reported by coccicheck
From: Shobhit Kukreti Fixed Warning Comparing Pointer to 0. Changed return value to -ENOMEM to report kzalloc failure drivers/video/fbdev/controlfb.c: WARNING comparing pointer to 0 drivers/video/fbdev/controlfb.c: WARNING comparing pointer to 0 drivers/video/fbdev/controlfb.c: WARNING comparing pointer to 0 Signed-off-by: Shobhit Kukreti --- Changes in v2: - Modified commit message to report change in return type drivers/video/fbdev/controlfb.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/video/fbdev/controlfb.c b/drivers/video/fbdev/controlfb.c index 7af8db2..07907c5 100644 --- a/drivers/video/fbdev/controlfb.c +++ b/drivers/video/fbdev/controlfb.c @@ -182,7 +182,7 @@ int init_module(void) int ret = -ENXIO; dp = of_find_node_by_name(NULL, "control"); - if (dp != 0 && !control_of_init(dp)) + if (dp != NULL && !control_of_init(dp)) ret = 0; of_node_put(dp); @@ -580,7 +580,7 @@ static int __init control_init(void) control_setup(option); dp = of_find_node_by_name(NULL, "control"); - if (dp != 0 && !control_of_init(dp)) + if (dp != NULL && !control_of_init(dp)) ret = 0; of_node_put(dp); @@ -683,8 +683,8 @@ static int __init control_of_init(struct device_node *dp) return -ENXIO; } p = kzalloc(sizeof(*p), GFP_KERNEL); - if (p == 0) - return -ENXIO; + if (p == NULL) + return -ENOMEM; control_fb = p; /* save it for cleanups */ /* Map in frame buffer and registers */ -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] linux-firmware: update firmware for mhdp8546
This patch updates mhdp8546 firmware from v1.2.12 to v1.2.15. Added support for performing arbitrary I2C-over-AUX transactions. Corrected handling of erroneous requests for reading/writing 0 bytes over DPCD. Add mailbox message to force uCPU fatal error. Signed-off-by: Damian Kos --- WHENCE | 2 +- cadence/mhdp8546.bin | Bin 131072 -> 131072 bytes 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/WHENCE b/WHENCE index 32eca87..5a2f388 100644 --- a/WHENCE +++ b/WHENCE @@ -4383,7 +4383,7 @@ Licence: Driver: cdns-mhdp - Cadence MHDP DP bridge File: cadence/mhdp8546.bin -Version: 1.2.12 +Version: 1.2.15 Licence: Redistributable. See LICENCE.cadence for details diff --git a/cadence/mhdp8546.bin b/cadence/mhdp8546.bin index 01a31f6775e1c4d8d889216e78ef90e62888c487..40097e0ec908ab5c4b54803f4b99519ced7a5e3d 100755 GIT binary patch delta 20442 zcmbun30PCt)-b$JCXgHz6r)0b5C}M+0$R0*1p=l_wnAH4r(PL?L)EIawOTcUmZGIC
Re: [PATCH] video: fbdev: Fix Warning comparing pointer to 0 reported by coccicheck
On Sat, Jun 1, 2019 at 5:39 PM Shobhit Kukreti wrote: > > drivers/video/fbdev/controlfb.c: WARNING comparing pointer to 0 > drivers/video/fbdev/controlfb.c: WARNING comparing pointer to 0 > drivers/video/fbdev/controlfb.c: WARNING comparing pointer to 0 > > Signed-off-by: Shobhit Kukreti > --- > drivers/video/fbdev/controlfb.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/video/fbdev/controlfb.c b/drivers/video/fbdev/controlfb.c > index 7af8db2..07907c5 100644 > --- a/drivers/video/fbdev/controlfb.c > +++ b/drivers/video/fbdev/controlfb.c > @@ -182,7 +182,7 @@ int init_module(void) > int ret = -ENXIO; > > dp = of_find_node_by_name(NULL, "control"); > - if (dp != 0 && !control_of_init(dp)) > + if (dp != NULL && !control_of_init(dp)) > ret = 0; > of_node_put(dp); > > @@ -580,7 +580,7 @@ static int __init control_init(void) > control_setup(option); > > dp = of_find_node_by_name(NULL, "control"); > - if (dp != 0 && !control_of_init(dp)) > + if (dp != NULL && !control_of_init(dp)) > ret = 0; > of_node_put(dp); > > @@ -683,8 +683,8 @@ static int __init control_of_init(struct device_node *dp) > return -ENXIO; > } > p = kzalloc(sizeof(*p), GFP_KERNEL); > - if (p == 0) > - return -ENXIO; > + if (p == NULL) > + return -ENOMEM; IMHO the above should be described in the commit message. > control_fb = p; /* save it for cleanups */ > > /* Map in frame buffer and registers */ > -- > 2.7.4 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] of/device: add blacklist for iommu dma_ops
On Mon, Jun 3, 2019 at 4:14 PM Rob Clark wrote: > > On Mon, Jun 3, 2019 at 12:57 AM Vivek Gautam > wrote: > > > > > > > > On 6/3/2019 11:50 AM, Tomasz Figa wrote: > > > On Mon, Jun 3, 2019 at 4:40 AM Rob Clark wrote: > > >> On Fri, May 10, 2019 at 7:35 AM Rob Clark wrote: > > >>> On Tue, Dec 4, 2018 at 2:29 PM Rob Herring wrote: > > On Sat, Dec 1, 2018 at 10:54 AM Rob Clark wrote: > > > This solves a problem we see with drm/msm, caused by getting > > > iommu_dma_ops while we attach our own domain and manage it directly at > > > the iommu API level: > > > > > >[0038] user address but active_mm is swapper > > >Internal error: Oops: 9605 [#1] PREEMPT SMP > > >Modules linked in: > > >CPU: 7 PID: 70 Comm: kworker/7:1 Tainted: GW > > > 4.19.3 #90 > > >Hardware name: xxx (DT) > > >Workqueue: events deferred_probe_work_func > > >pstate: 80c9 (Nzcv daif +PAN +UAO) > > >pc : iommu_dma_map_sg+0x7c/0x2c8 > > >lr : iommu_dma_map_sg+0x40/0x2c8 > > >sp : ff80095eb4f0 > > >x29: ff80095eb4f0 x28: > > >x27: ffc0f9431578 x26: > > >x25: x24: 0003 > > >x23: 0001 x22: ffc0fa9ac010 > > >x21: x20: ffc0fab40980 > > >x19: ffc0fab40980 x18: 0003 > > >x17: 01c4 x16: 0007 > > >x15: 000e x14: > > >x13: x12: 0028 > > >x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f > > >x9 : x8 : ffc0fab409a0 > > >x7 : x6 : 0002 > > >x5 : 0001 x4 : > > >x3 : 0001 x2 : 0002 > > >x1 : ffc0f9431578 x0 : > > >Process kworker/7:1 (pid: 70, stack limit = 0x17d08ffb) > > >Call trace: > > > iommu_dma_map_sg+0x7c/0x2c8 > > > __iommu_map_sg_attrs+0x70/0x84 > > > get_pages+0x170/0x1e8 > > > msm_gem_get_iova+0x8c/0x128 > > > _msm_gem_kernel_new+0x6c/0xc8 > > > msm_gem_kernel_new+0x4c/0x58 > > > dsi_tx_buf_alloc_6g+0x4c/0x8c > > > msm_dsi_host_modeset_init+0xc8/0x108 > > > msm_dsi_modeset_init+0x54/0x18c > > > _dpu_kms_drm_obj_init+0x430/0x474 > > > dpu_kms_hw_init+0x5f8/0x6b4 > > > msm_drm_bind+0x360/0x6c8 > > > try_to_bring_up_master.part.7+0x28/0x70 > > > component_master_add_with_match+0xe8/0x124 > > > msm_pdev_probe+0x294/0x2b4 > > > platform_drv_probe+0x58/0xa4 > > > really_probe+0x150/0x294 > > > driver_probe_device+0xac/0xe8 > > > __device_attach_driver+0xa4/0xb4 > > > bus_for_each_drv+0x98/0xc8 > > > __device_attach+0xac/0x12c > > > device_initial_probe+0x24/0x30 > > > bus_probe_device+0x38/0x98 > > > deferred_probe_work_func+0x78/0xa4 > > > process_one_work+0x24c/0x3dc > > > worker_thread+0x280/0x360 > > > kthread+0x134/0x13c > > > ret_from_fork+0x10/0x18 > > >Code: d284 91000725 6b17039f 5400048a (f9401f40) > > >---[ end trace f22dda57f3648e2c ]--- > > >Kernel panic - not syncing: Fatal exception > > >SMP: stopping secondary CPUs > > >Kernel Offset: disabled > > >CPU features: 0x0,22802a18 > > >Memory Limit: none > > > > > > The problem is that when drm/msm does it's own iommu_attach_device(), > > > now the domain returned by iommu_get_domain_for_dev() is drm/msm's > > > domain, and it doesn't have domain->iova_cookie. > > > > > > We kind of avoided this problem prior to sdm845/dpu because the iommu > > > was attached to the mdp node in dt, which is a child of the toplevel > > > mdss node (which corresponds to the dev passed in dma_map_sg()). But > > > with sdm845, now the iommu is attached at the mdss level so we hit the > > > iommu_dma_ops in dma_map_sg(). > > > > > > But auto allocating/attaching a domain before the driver is probed was > > > already a blocking problem for enabling per-context pagetables for the > > > GPU. This problem is also now solved with this patch. > > > > > > Fixes: 97890ba9289c dma-mapping: detect and configure IOMMU in > > > of_dma_configure > > > Tested-by: Douglas Anderson > > > Signed-off-by: Rob Clark > > > --- > > > This is an alternative/replacement for [1]. What it lacks in elegance > > > it makes up for in practicality ;-) > > > > > > [1] https://patchwork.freedesktop.org/patch/264930/ > > > > > > drivers/of/device.c | 22 ++ > > > 1 file changed, 22 insertions(+) > > > > > > diff --git
Re: [PATCH] of/device: add blacklist for iommu dma_ops
On Mon, Jun 3, 2019 at 4:47 PM Christoph Hellwig wrote: > > If you (and a few others actors in the thread) want people to actually > read what you wrote please follow proper mailing list ettiquette. I've > given up on reading all the recent mails after scrolling through two > pages of full quotes. Apologies for not cutting down the quoted text. I will be more careful next time onwards. Regards Vivek -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH] of/device: add blacklist for iommu dma_ops
If you (and a few others actors in the thread) want people to actually read what you wrote please follow proper mailing list ettiquette. I've given up on reading all the recent mails after scrolling through two pages of full quotes.
Re: [PATCH] of/device: add blacklist for iommu dma_ops
On 03/06/2019 11:47, Rob Clark wrote:
On Sun, Jun 2, 2019 at 11:25 PM Tomasz Figa wrote:
On Mon, Jun 3, 2019 at 4:40 AM Rob Clark wrote:
On Fri, May 10, 2019 at 7:35 AM Rob Clark wrote:
On Tue, Dec 4, 2018 at 2:29 PM Rob Herring wrote:
On Sat, Dec 1, 2018 at 10:54 AM Rob Clark wrote:
This solves a problem we see with drm/msm, caused by getting
iommu_dma_ops while we attach our own domain and manage it directly at
the iommu API level:
[0038] user address but active_mm is swapper
Internal error: Oops: 9605 [#1] PREEMPT SMP
Modules linked in:
CPU: 7 PID: 70 Comm: kworker/7:1 Tainted: GW 4.19.3 #90
Hardware name: xxx (DT)
Workqueue: events deferred_probe_work_func
pstate: 80c9 (Nzcv daif +PAN +UAO)
pc : iommu_dma_map_sg+0x7c/0x2c8
lr : iommu_dma_map_sg+0x40/0x2c8
sp : ff80095eb4f0
x29: ff80095eb4f0 x28:
x27: ffc0f9431578 x26:
x25: x24: 0003
x23: 0001 x22: ffc0fa9ac010
x21: x20: ffc0fab40980
x19: ffc0fab40980 x18: 0003
x17: 01c4 x16: 0007
x15: 000e x14:
x13: x12: 0028
x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f
x9 : x8 : ffc0fab409a0
x7 : x6 : 0002
x5 : 0001 x4 :
x3 : 0001 x2 : 0002
x1 : ffc0f9431578 x0 :
Process kworker/7:1 (pid: 70, stack limit = 0x17d08ffb)
Call trace:
iommu_dma_map_sg+0x7c/0x2c8
__iommu_map_sg_attrs+0x70/0x84
get_pages+0x170/0x1e8
msm_gem_get_iova+0x8c/0x128
_msm_gem_kernel_new+0x6c/0xc8
msm_gem_kernel_new+0x4c/0x58
dsi_tx_buf_alloc_6g+0x4c/0x8c
msm_dsi_host_modeset_init+0xc8/0x108
msm_dsi_modeset_init+0x54/0x18c
_dpu_kms_drm_obj_init+0x430/0x474
dpu_kms_hw_init+0x5f8/0x6b4
msm_drm_bind+0x360/0x6c8
try_to_bring_up_master.part.7+0x28/0x70
component_master_add_with_match+0xe8/0x124
msm_pdev_probe+0x294/0x2b4
platform_drv_probe+0x58/0xa4
really_probe+0x150/0x294
driver_probe_device+0xac/0xe8
__device_attach_driver+0xa4/0xb4
bus_for_each_drv+0x98/0xc8
__device_attach+0xac/0x12c
device_initial_probe+0x24/0x30
bus_probe_device+0x38/0x98
deferred_probe_work_func+0x78/0xa4
process_one_work+0x24c/0x3dc
worker_thread+0x280/0x360
kthread+0x134/0x13c
ret_from_fork+0x10/0x18
Code: d284 91000725 6b17039f 5400048a (f9401f40)
---[ end trace f22dda57f3648e2c ]---
Kernel panic - not syncing: Fatal exception
SMP: stopping secondary CPUs
Kernel Offset: disabled
CPU features: 0x0,22802a18
Memory Limit: none
The problem is that when drm/msm does it's own iommu_attach_device(),
now the domain returned by iommu_get_domain_for_dev() is drm/msm's
domain, and it doesn't have domain->iova_cookie.
We kind of avoided this problem prior to sdm845/dpu because the iommu
was attached to the mdp node in dt, which is a child of the toplevel
mdss node (which corresponds to the dev passed in dma_map_sg()). But
with sdm845, now the iommu is attached at the mdss level so we hit the
iommu_dma_ops in dma_map_sg().
But auto allocating/attaching a domain before the driver is probed was
already a blocking problem for enabling per-context pagetables for the
GPU. This problem is also now solved with this patch.
Fixes: 97890ba9289c dma-mapping: detect and configure IOMMU in of_dma_configure
Tested-by: Douglas Anderson
Signed-off-by: Rob Clark
---
This is an alternative/replacement for [1]. What it lacks in elegance
it makes up for in practicality ;-)
[1] https://patchwork.freedesktop.org/patch/264930/
drivers/of/device.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 5957cd4fa262..15ffee00fb22 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -72,6 +72,14 @@ int of_device_add(struct platform_device *ofdev)
return device_add(>dev);
}
+static const struct of_device_id iommu_blacklist[] = {
+ { .compatible = "qcom,mdp4" },
+ { .compatible = "qcom,mdss" },
+ { .compatible = "qcom,sdm845-mdss" },
+ { .compatible = "qcom,adreno" },
+ {}
+};
Not completely clear to whether this is still needed or not, but this
really won't scale. Why can't the driver for these devices override
whatever has been setup by default?
fwiw, at the moment it is not needed, but it will become needed again
to implement per-context pagetables (although I suppose for this we
only need to blacklist qcom,adreno and not also the display nodes).
So, another case I've come across, on the display side.. I'm working
on handling the case where bootloader enables display (and takes iommu
out of reset).. as soon as DMA domain
[Bug 202445] amdgpu/dc: framerate dropping below adaptive sync range causes screen flickering
https://bugzilla.kernel.org/show_bug.cgi?id=202445 jaapbuur...@gmail.com changed: What|Removed |Added CC||jaapbuur...@gmail.com --- Comment #32 from jaapbuur...@gmail.com --- I am experiencing the exact same issue, although I am still running the 5.1 kernel. I feel uncomfortable compiling my own kernel, so I cannot test 5.2 just yet. I do have an additional observation that might be useful for debugging. My freesync monitor has a 48-144 freesync range, and displays the current refresh rate on its OSD. The issue for me is the easiest to reproduce in Kerbal Space program while in space, since the flickering is especially visible with the many white stars on the blackness of space. While in space with a large vessel that pushes your FPS down (33-40 FPS in the ingame FPS monitor), my monitor is rapidly oscillating through the entire freesync range (as low as 48 and as high as 144, and everything in between). As far as I understand the technology, whenever the FPS is stable (for example at 37), it should use LFC to display each frame twice or thrice, and the monitor should refresh at a constant 74hz or 111hz. But that is not what is happening if I use a static view with a constant 37 FPS. Is there something I can do to rule out a monitor issue? Perhaps by setting some kind of debug option to see what the driver is instructing the monitor to do? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110781] Radeon: heavy r300 performance drop regression between 11.x and 19.x
https://bugs.freedesktop.org/show_bug.cgi?id=110781 --- Comment #12 from Richard Thier --- My friend "Googling" at the commit hash we found that my problem might possibly relate to this other bug report already existing: https://bugs.freedesktop.org/show_bug.cgi?id=105171 They also report a slowdown, but not the amount I see. My slowdown is of a much higher percentage but I am on gallium/r300 code paths... -- 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] of/device: add blacklist for iommu dma_ops
On Sun, Jun 2, 2019 at 11:25 PM Tomasz Figa wrote: > > On Mon, Jun 3, 2019 at 4:40 AM Rob Clark wrote: > > > > On Fri, May 10, 2019 at 7:35 AM Rob Clark wrote: > > > > > > On Tue, Dec 4, 2018 at 2:29 PM Rob Herring wrote: > > > > > > > > On Sat, Dec 1, 2018 at 10:54 AM Rob Clark wrote: > > > > > > > > > > This solves a problem we see with drm/msm, caused by getting > > > > > iommu_dma_ops while we attach our own domain and manage it directly at > > > > > the iommu API level: > > > > > > > > > > [0038] user address but active_mm is swapper > > > > > Internal error: Oops: 9605 [#1] PREEMPT SMP > > > > > Modules linked in: > > > > > CPU: 7 PID: 70 Comm: kworker/7:1 Tainted: GW 4.19.3 > > > > > #90 > > > > > Hardware name: xxx (DT) > > > > > Workqueue: events deferred_probe_work_func > > > > > pstate: 80c9 (Nzcv daif +PAN +UAO) > > > > > pc : iommu_dma_map_sg+0x7c/0x2c8 > > > > > lr : iommu_dma_map_sg+0x40/0x2c8 > > > > > sp : ff80095eb4f0 > > > > > x29: ff80095eb4f0 x28: > > > > > x27: ffc0f9431578 x26: > > > > > x25: x24: 0003 > > > > > x23: 0001 x22: ffc0fa9ac010 > > > > > x21: x20: ffc0fab40980 > > > > > x19: ffc0fab40980 x18: 0003 > > > > > x17: 01c4 x16: 0007 > > > > > x15: 000e x14: > > > > > x13: x12: 0028 > > > > > x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f > > > > > x9 : x8 : ffc0fab409a0 > > > > > x7 : x6 : 0002 > > > > > x5 : 0001 x4 : > > > > > x3 : 0001 x2 : 0002 > > > > > x1 : ffc0f9431578 x0 : > > > > > Process kworker/7:1 (pid: 70, stack limit = 0x17d08ffb) > > > > > Call trace: > > > > >iommu_dma_map_sg+0x7c/0x2c8 > > > > >__iommu_map_sg_attrs+0x70/0x84 > > > > >get_pages+0x170/0x1e8 > > > > >msm_gem_get_iova+0x8c/0x128 > > > > >_msm_gem_kernel_new+0x6c/0xc8 > > > > >msm_gem_kernel_new+0x4c/0x58 > > > > >dsi_tx_buf_alloc_6g+0x4c/0x8c > > > > >msm_dsi_host_modeset_init+0xc8/0x108 > > > > >msm_dsi_modeset_init+0x54/0x18c > > > > >_dpu_kms_drm_obj_init+0x430/0x474 > > > > >dpu_kms_hw_init+0x5f8/0x6b4 > > > > >msm_drm_bind+0x360/0x6c8 > > > > >try_to_bring_up_master.part.7+0x28/0x70 > > > > >component_master_add_with_match+0xe8/0x124 > > > > >msm_pdev_probe+0x294/0x2b4 > > > > >platform_drv_probe+0x58/0xa4 > > > > >really_probe+0x150/0x294 > > > > >driver_probe_device+0xac/0xe8 > > > > >__device_attach_driver+0xa4/0xb4 > > > > >bus_for_each_drv+0x98/0xc8 > > > > >__device_attach+0xac/0x12c > > > > >device_initial_probe+0x24/0x30 > > > > >bus_probe_device+0x38/0x98 > > > > >deferred_probe_work_func+0x78/0xa4 > > > > >process_one_work+0x24c/0x3dc > > > > >worker_thread+0x280/0x360 > > > > >kthread+0x134/0x13c > > > > >ret_from_fork+0x10/0x18 > > > > > Code: d284 91000725 6b17039f 5400048a (f9401f40) > > > > > ---[ end trace f22dda57f3648e2c ]--- > > > > > Kernel panic - not syncing: Fatal exception > > > > > SMP: stopping secondary CPUs > > > > > Kernel Offset: disabled > > > > > CPU features: 0x0,22802a18 > > > > > Memory Limit: none > > > > > > > > > > The problem is that when drm/msm does it's own iommu_attach_device(), > > > > > now the domain returned by iommu_get_domain_for_dev() is drm/msm's > > > > > domain, and it doesn't have domain->iova_cookie. > > > > > > > > > > We kind of avoided this problem prior to sdm845/dpu because the iommu > > > > > was attached to the mdp node in dt, which is a child of the toplevel > > > > > mdss node (which corresponds to the dev passed in dma_map_sg()). But > > > > > with sdm845, now the iommu is attached at the mdss level so we hit the > > > > > iommu_dma_ops in dma_map_sg(). > > > > > > > > > > But auto allocating/attaching a domain before the driver is probed was > > > > > already a blocking problem for enabling per-context pagetables for the > > > > > GPU. This problem is also now solved with this patch. > > > > > > > > > > Fixes: 97890ba9289c dma-mapping: detect and configure IOMMU in > > > > > of_dma_configure > > > > > Tested-by: Douglas Anderson > > > > > Signed-off-by: Rob Clark > > > > > --- > > > > > This is an alternative/replacement for [1]. What it lacks in elegance > > > > > it makes up for in practicality ;-) > > > > > > > > > > [1] https://patchwork.freedesktop.org/patch/264930/ > > > > > > > > > > drivers/of/device.c | 22 ++ > > > > > 1 file changed, 22 insertions(+) > > > > > > > > > > diff --git a/drivers/of/device.c b/drivers/of/device.c > > > > > index 5957cd4fa262..15ffee00fb22 100644 > > > > > --- a/drivers/of/device.c > > > > > +++
Re: [PATCH] of/device: add blacklist for iommu dma_ops
On Mon, Jun 3, 2019 at 12:57 AM Vivek Gautam wrote: > > > > On 6/3/2019 11:50 AM, Tomasz Figa wrote: > > On Mon, Jun 3, 2019 at 4:40 AM Rob Clark wrote: > >> On Fri, May 10, 2019 at 7:35 AM Rob Clark wrote: > >>> On Tue, Dec 4, 2018 at 2:29 PM Rob Herring wrote: > On Sat, Dec 1, 2018 at 10:54 AM Rob Clark wrote: > > This solves a problem we see with drm/msm, caused by getting > > iommu_dma_ops while we attach our own domain and manage it directly at > > the iommu API level: > > > >[0038] user address but active_mm is swapper > >Internal error: Oops: 9605 [#1] PREEMPT SMP > >Modules linked in: > >CPU: 7 PID: 70 Comm: kworker/7:1 Tainted: GW 4.19.3 > > #90 > >Hardware name: xxx (DT) > >Workqueue: events deferred_probe_work_func > >pstate: 80c9 (Nzcv daif +PAN +UAO) > >pc : iommu_dma_map_sg+0x7c/0x2c8 > >lr : iommu_dma_map_sg+0x40/0x2c8 > >sp : ff80095eb4f0 > >x29: ff80095eb4f0 x28: > >x27: ffc0f9431578 x26: > >x25: x24: 0003 > >x23: 0001 x22: ffc0fa9ac010 > >x21: x20: ffc0fab40980 > >x19: ffc0fab40980 x18: 0003 > >x17: 01c4 x16: 0007 > >x15: 000e x14: > >x13: x12: 0028 > >x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f > >x9 : x8 : ffc0fab409a0 > >x7 : x6 : 0002 > >x5 : 0001 x4 : > >x3 : 0001 x2 : 0002 > >x1 : ffc0f9431578 x0 : > >Process kworker/7:1 (pid: 70, stack limit = 0x17d08ffb) > >Call trace: > > iommu_dma_map_sg+0x7c/0x2c8 > > __iommu_map_sg_attrs+0x70/0x84 > > get_pages+0x170/0x1e8 > > msm_gem_get_iova+0x8c/0x128 > > _msm_gem_kernel_new+0x6c/0xc8 > > msm_gem_kernel_new+0x4c/0x58 > > dsi_tx_buf_alloc_6g+0x4c/0x8c > > msm_dsi_host_modeset_init+0xc8/0x108 > > msm_dsi_modeset_init+0x54/0x18c > > _dpu_kms_drm_obj_init+0x430/0x474 > > dpu_kms_hw_init+0x5f8/0x6b4 > > msm_drm_bind+0x360/0x6c8 > > try_to_bring_up_master.part.7+0x28/0x70 > > component_master_add_with_match+0xe8/0x124 > > msm_pdev_probe+0x294/0x2b4 > > platform_drv_probe+0x58/0xa4 > > really_probe+0x150/0x294 > > driver_probe_device+0xac/0xe8 > > __device_attach_driver+0xa4/0xb4 > > bus_for_each_drv+0x98/0xc8 > > __device_attach+0xac/0x12c > > device_initial_probe+0x24/0x30 > > bus_probe_device+0x38/0x98 > > deferred_probe_work_func+0x78/0xa4 > > process_one_work+0x24c/0x3dc > > worker_thread+0x280/0x360 > > kthread+0x134/0x13c > > ret_from_fork+0x10/0x18 > >Code: d284 91000725 6b17039f 5400048a (f9401f40) > >---[ end trace f22dda57f3648e2c ]--- > >Kernel panic - not syncing: Fatal exception > >SMP: stopping secondary CPUs > >Kernel Offset: disabled > >CPU features: 0x0,22802a18 > >Memory Limit: none > > > > The problem is that when drm/msm does it's own iommu_attach_device(), > > now the domain returned by iommu_get_domain_for_dev() is drm/msm's > > domain, and it doesn't have domain->iova_cookie. > > > > We kind of avoided this problem prior to sdm845/dpu because the iommu > > was attached to the mdp node in dt, which is a child of the toplevel > > mdss node (which corresponds to the dev passed in dma_map_sg()). But > > with sdm845, now the iommu is attached at the mdss level so we hit the > > iommu_dma_ops in dma_map_sg(). > > > > But auto allocating/attaching a domain before the driver is probed was > > already a blocking problem for enabling per-context pagetables for the > > GPU. This problem is also now solved with this patch. > > > > Fixes: 97890ba9289c dma-mapping: detect and configure IOMMU in > > of_dma_configure > > Tested-by: Douglas Anderson > > Signed-off-by: Rob Clark > > --- > > This is an alternative/replacement for [1]. What it lacks in elegance > > it makes up for in practicality ;-) > > > > [1] https://patchwork.freedesktop.org/patch/264930/ > > > > drivers/of/device.c | 22 ++ > > 1 file changed, 22 insertions(+) > > > > diff --git a/drivers/of/device.c b/drivers/of/device.c > > index 5957cd4fa262..15ffee00fb22 100644 > > --- a/drivers/of/device.c > > +++ b/drivers/of/device.c > > @@ -72,6 +72,14 @@ int of_device_add(struct platform_device *ofdev) > > return
[Bug 110813] Vega hang on Surviving Mars game
https://bugs.freedesktop.org/show_bug.cgi?id=110813 Yury Zhuravlev changed: What|Removed |Added Summary|Vega hung on Surviving Mars |Vega hang on Surviving Mars |game|game -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110823] [Intel-GFX-CI][BAT] igt@amdgpu/amd_basic@userptr - fail - Failed assertion: r == 0
https://bugs.freedesktop.org/show_bug.cgi?id=110823 --- Comment #1 from CI Bug Log --- The CI Bug Log issue associated to this bug has been updated. ### New filters associated * VEGA M: igt@amdgpu/amd_basic@userptr - fail - Failed assertion: r == 0 - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13156/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_4368/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5027/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6172/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6173/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3085/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13143/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3086/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6174/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3089/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3090/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6176/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13148/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3091/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13149/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3087/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13145/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13147/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_4356/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13153/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6178/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_4358/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13154/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6175/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13146/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_4357/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3088/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_4359/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_4361/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_4362/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_4363/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_4365/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_4366/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6179/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_4360/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_4364/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_4367/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13155/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110823] [Intel-GFX-CI][BAT] igt@amdgpu/amd_basic@userptr - fail - Failed assertion: r == 0
https://bugs.freedesktop.org/show_bug.cgi?id=110823 Martin Peres changed: What|Removed |Added Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop |sktop.org |.org Component|DRM/Intel |DRM/AMDgpu QA Contact|intel-gfx-bugs@lists.freede | |sktop.org | -- 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 110781] Radeon: heavy r300 performance drop regression between 11.x and 19.x
https://bugs.freedesktop.org/show_bug.cgi?id=110781 --- Comment #11 from Richard Thier --- Slowdown cause is found when bisecting: 8b3a257851905ff444d981e52938cbf2b36ba830 is the first bad commit commit 8b3a257851905ff444d981e52938cbf2b36ba830 Author: Marek Olšák Date: Tue Jul 18 16:08:44 2017 -0400 radeonsi: set a per-buffer flag that disables inter-process sharing (v4) For lower overhead in the CS ioctl. Winsys allocators are not used with interprocess-sharable resources. v2: It shouldn't crash anymore, but the kernel will reject the new flag. v3 (christian): Rename the flag, avoid sending those buffers in the BO list. v4 (christian): Remove setting the kernel flag for now Reviewed-by: Marek Olšák -- 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: [RFC PATCH 1/1] drm/i915: Split off pci_driver.remove() tail to drm_driver.release()
On Monday, June 3, 2019 9:28:18 AM CEST Daniel Vetter wrote:
> On Thu, May 30, 2019 at 10:40:09AM +0100, Chris Wilson wrote:
> > Quoting Janusz Krzysztofik (2019-05-30 10:24:26)
> > > In order to support driver hot unbind, some cleanup operations, now
> > > performed on PCI driver remove, must be called later, after all device
> > > file descriptors are closed.
> > >
> > > Split out those operations from the tail of pci_driver.remove()
> > > callback and put them into drm_driver.release() which is called as soon
> > > as all references to the driver are put. As a result, those cleanups
> > > will be now run on last drm_dev_put(), either still called from
> > > pci_driver.remove() if all device file descriptors are already closed,
> > > or on last drm_release() file operation.
> > >
> > > Signed-off-by: Janusz Krzysztofik
> > > ---
> > > drivers/gpu/drm/i915/i915_drv.c | 17 +
> > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > drivers/gpu/drm/i915/i915_gem.c | 10 +-
> > > 3 files changed, 23 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/
i915_drv.c
> > > index 83d2eb9e74cb..8be69f84eb6d 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > @@ -738,6 +738,7 @@ static int i915_load_modeset_init(struct drm_device
*dev)
> > >
> > > cleanup_gem:
> > > i915_gem_suspend(dev_priv);
> > > + i915_gem_fini_hw(dev_priv);
> > > i915_gem_fini(dev_priv);
> > > cleanup_modeset:
> > > intel_modeset_cleanup(dev);
> > > @@ -1685,7 +1686,6 @@ static void i915_driver_cleanup_hw(struct
drm_i915_private *dev_priv)
> > > pci_disable_msi(pdev);
> > >
> > > pm_qos_remove_request(_priv->pm_qos);
> > > - i915_ggtt_cleanup_hw(dev_priv);
> > > }
> > >
> > > /**
> > > @@ -1909,6 +1909,7 @@ int i915_driver_load(struct pci_dev *pdev, const
struct pci_device_id *ent)
> >
> > Would it make sense to rename load/unload from the legacy drm stubs over
> > to match the pci entry points?
>
> +1 on that rename, load/unload is really terribly confusing and has
> horrible semantics in the dri1 shadow attach world ...
> -Daniel
I've not responded to that comment, sorry, but I agree too. I've assumed
that's a candidate for a separate patch or series. I'm willing to work on
that as time permits.
Thanks,
Janusz
> >
> > > out_cleanup_hw:
> > > i915_driver_cleanup_hw(dev_priv);
> > > + i915_ggtt_cleanup_hw(dev_priv);
> > > out_cleanup_mmio:
> > > i915_driver_cleanup_mmio(dev_priv);
> > > out_runtime_pm_put:
> > > @@ -1960,21 +1961,29 @@ void i915_driver_unload(struct drm_device *dev)
> > > cancel_delayed_work_sync(_priv->gpu_error.hangcheck_work);
> > > i915_reset_error_state(dev_priv);
> > >
> > > - i915_gem_fini(dev_priv);
> > > + i915_gem_fini_hw(dev_priv);
> > >
> > > intel_power_domains_fini_hw(dev_priv);
> > >
> > > i915_driver_cleanup_hw(dev_priv);
> > > - i915_driver_cleanup_mmio(dev_priv);
> > >
> > > enable_rpm_wakeref_asserts(dev_priv);
> > > - intel_runtime_pm_cleanup(dev_priv);
> > > }
> > >
> > > static void i915_driver_release(struct drm_device *dev)
> > > {
> > > struct drm_i915_private *dev_priv = to_i915(dev);
> > >
> > > + disable_rpm_wakeref_asserts(dev_priv);
> > > +
> > > + i915_gem_fini(dev_priv);
> > > +
> > > + i915_ggtt_cleanup_hw(dev_priv);
> > > + i915_driver_cleanup_mmio(dev_priv);
> > > +
> > > + enable_rpm_wakeref_asserts(dev_priv);
> > > + intel_runtime_pm_cleanup(dev_priv);
> >
> > We should really propagate the release nomenclature down and replace our
> > mixed fini/cleanup. Consistency is helpful when trying to work out which
> > phase the code is in.
> >
> > > i915_driver_cleanup_early(dev_priv);
> > > i915_driver_destroy(dev_priv);
> > > }
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/
i915_drv.h
> > > index a2664ea1395b..d08e7bd83544 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -3047,6 +3047,7 @@ void i915_gem_init_mmio(struct drm_i915_private
*i915);
> > > int __must_check i915_gem_init(struct drm_i915_private *dev_priv);
> > > int __must_check i915_gem_init_hw(struct drm_i915_private *dev_priv);
> > > void i915_gem_init_swizzling(struct drm_i915_private *dev_priv);
> > > +void i915_gem_fini_hw(struct drm_i915_private *dev_priv);
> > > void i915_gem_fini(struct drm_i915_private *dev_priv);
> > > int i915_gem_wait_for_idle(struct drm_i915_private *dev_priv,
> > >unsigned int flags, long timeout);
> > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/
i915_gem.c
> > > index 7cafd5612f71..c6a8e665a6ba 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem.c
Re: [PATCH 2/2] drm/panel: Add Novatek NT39016 panel support
On Sunday, 2 June 2019 20:44:53 CEST Sam Ravnborg wrote: > > Signed-off-by: Paul Cercueil > > This driver is authored by Maarten ter Huurne > as well as you. > Could you get a s-o-b or at least some other formal > attribution of Maarten in the changelog. This is based on a driver I wrote for the GCW Zero back when we were using fbdev. Paul updated it for drm and did additional cleanups. Signed-off-by: Maarten ter Huurne Bye, Maarten
Re: [PATCH v7 09/11] drm: uevent for connector status change
On 2019-05-21 9:52 a.m., Daniel Vetter wrote: > On Tue, May 21, 2019 at 8:55 AM Pekka Paalanen wrote: >> On Mon, 20 May 2019 18:11:07 +0200 >> Daniel Vetter wrote: >> >>> There's also a fairly easy fix for that -modesetting issue: We don't >>> expose atomic if the compositor has a process name of "Xserver". Brutal, >>> but gets the job done. Once X is fixed, we can give a new "I'm not totally >>> broken anymore" interface to get back at atomic. >> >> You mean "Xorg". Or maybe "X". Or maybe the setuid helper? Wait, do you >> check against the process issuing ioctl by ioctl, or the process that >> opened the device? Which would be logind? What about DRM leasing? ... > > In the Get/SetCaps ioctl we can do the check, which is called from X, > not logind. We just need some way to tell -modesetting apart from > everything else, and luckily there's not any other atomic X drivers. Not yet... As for a "I'm not totally broken anymore" interface, we did something like that (though kind of in the other direction) with RADEON_INFO_ACCEL_WORKING, but later RADEON_INFO_ACCEL_WORKING2 had to be added, because the former claimed acceleration was "working" in cases where it really wasn't... That kind of thing could become ugly in the long run if other Xorg driver start using atomic, and they'll inevitably be broken in different ways. -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: unable to fetch the drm-intel-fixes tree
Hi Daniel, On Mon, 3 Jun 2019 09:31:03 +0200 Daniel Vetter wrote: > > drm.git too I guess? No, I fetch that from git://git.freedesktop.org/ which seems to answer. > But yeah fd.o anongit keeled over over the w/e :-( Admins not yet awake, > so can't tell you what's up. No worries, I will just keep using what I have previously fetched. -- Cheers, Stephen Rothwell pgpoXbUJ7_9XM.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110822] booting with kernel version 5.1.0 or higher on RX 580 hangs
https://bugs.freedesktop.org/show_bug.cgi?id=110822 --- Comment #1 from Gobinda Joy --- I've tested kernel version from 5.1.0 to the latest git all shows similar problems. For the 5.2 git versions when using amdgpu.dpm=0 command line the following error occurs: kernel: [drm] amdgpu kernel modesetting enabled. kernel: CRAT table not found kernel: Virtual CRAT table created for CPU kernel: Parsing CRAT table with 1 nodes kernel: Creating topology SYSFS entries kernel: Topology: Add CPU node kernel: Finished initializing topology kernel: amdgpu :04:00.0: remove_conflicting_pci_framebuffers: bar 0: 0xe000 -> 0xefff kernel: amdgpu :04:00.0: remove_conflicting_pci_framebuffers: bar 2: 0xf000 -> 0xf01f kernel: amdgpu :04:00.0: remove_conflicting_pci_framebuffers: bar 5: 0xf780 -> 0xf783 kernel: checking generic (e000 30) vs hw (e000 1000) kernel: fb0: switching to amdgpudrmfb from EFI VGA kernel: Console: switching to colour dummy device 80x25 kernel: amdgpu :04:00.0: vgaarb: deactivate vga console kernel: [drm] initializing kernel modesetting (POLARIS10 0x1002:0x67DF 0x1DA2:0xE387 0xE7). kernel: [drm] register mmio base: 0xF780 kernel: [drm] register mmio size: 262144 kernel: [drm] add ip block number 0 kernel: [drm] add ip block number 1 kernel: [drm] add ip block number 2 kernel: [drm] add ip block number 3 kernel: [drm] add ip block number 4 kernel: [drm] add ip block number 5 kernel: [drm] add ip block number 6 kernel: [drm] add ip block number 7 kernel: [drm] add ip block number 8 kernel: kfd kfd: skipped device 1002:67df, PCI rejects atomics kernel: [drm] UVD is enabled in VM mode kernel: [drm] UVD ENC is enabled in VM mode kernel: [drm] VCE enabled in VM mode kernel: resource sanity check: requesting [mem 0x000c-0x000d], which spans more than PCI Bus :00 [mem 0x000d-0x000d3fff window] kernel: caller pci_map_rom+0x6a/0x17d mapping multiple BARs kernel: amdgpu :04:00.0: No more image in the PCI ROM kernel: ATOM BIOS: 113-1E3870U-O45 kernel: [drm] RAS INFO: ras initialized successfully, hardware ability[0] ras_mask[0] kernel: [drm] vm size is 128 GB, 2 levels, block size is 10-bit, fragment size is 9-bit kernel: amdgpu :04:00.0: VRAM: 8192M 0x00F4 - 0x00F5 (8192M used) kernel: amdgpu :04:00.0: GART: 256M 0x00FF - 0x00FF0FFF kernel: [drm] Detected VRAM RAM=8192M, BAR=256M kernel: [drm] RAM width 256bits GDDR5 kernel: [TTM] Zone kernel: Available graphics memory: 12350340 KiB kernel: [TTM] Zone dma32: Available graphics memory: 2097152 KiB kernel: [TTM] Initializing pool allocator kernel: [TTM] Initializing DMA pool allocator kernel: [drm] amdgpu: 8192M of VRAM memory ready kernel: [drm] amdgpu: 8192M of GTT memory ready. kernel: [drm] GART: num cpu pages 65536, num gpu pages 65536 kernel: [drm] PCIE GART of 256M enabled (table at 0x00F40030). kernel: [drm] Chained IB support enabled! kernel: [drm] Found UVD firmware Version: 1.130 Family ID: 16 kernel: [drm] Found VCE firmware Version: 53.26 Binary ID: 3 kernel: BUG: unable to handle page fault for address: a5bd8394f650 kernel: #PF: supervisor read access in kernel mode kernel: #PF: error_code(0x) - not-present page kernel: PGD 606549067 P4D 606549067 PUD 0 kernel: Oops: [#1] SMP PTI kernel: CPU: 6 PID: 461 Comm: systemd-udevd Not tainted 5.2.0-0.rc1.git1.1.vanilla.knurd.1.fc30.x86_64 #1 kernel: Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./G1.Sniper 3, BIOS F8k 04/29/2013 kernel: RIP: 0010:bw_calcs_data_update_from_pplib.isra.0+0x378/0x4d0 [amdgpu] kernel: Code: 00 00 5b 5d 41 5c 41 5d 41 5e c3 48 8b 7d 00 4c 89 f2 be 02 00 00 00 e8 26 bf f9 ff 8b 04 24 4c 8b 23 be e8 03 00 00 83 e8 01 <8b> 7c 84 04 e8 6f 4d fb ff be e8 03 00 00 49 89 44 24 60 8b 04 24 kernel: RSP: 0018:a5b98394f650 EFLAGS: 00010297 kernel: RAX: RBX: 928b34cb92d8 RCX: kernel: RDX: a5b98394f58c RSI: 03e8 RDI: 928b39c12800 kernel: RBP: 928b34cb9208 R08: 0020 R09: 00032a00 kernel: R10: 0003ce00 R11: 00177000 R12: 928b3ac0b300 kernel: R13: a5b98394f76c R14: a5b98394f650 R15: c0839d60 kernel: FS: 7f1133ad1940() GS:928b46b8() knlGS: kernel: CS: 0010 DS: ES: CR0: 80050033 kernel: CR2: a5bd8394f650 CR3: 0005faf54004 CR4: 001606e0 kernel: Call Trace: kernel: dce112_create_resource_pool+0x6de/0x700 [amdgpu] kernel: dc_create_resource_pool+0x16c/0x220 [amdgpu] kernel: ? dal_gpio_service_create+0x92/0x110 [amdgpu] kernel: dc_create+0x219/0x620 [amdgpu] kernel: ? amdgpu_cgs_create_device+0x23/0x50 [amdgpu] kernel: amdgpu_dm_init+0xeb/0x160 [amdgpu] kernel: dm_hw_init+0xe/0x20 [amdgpu] kernel: amdgpu_device_init.cold+0x128d/0x161f [amdgpu] kernel: ? kmalloc_order+0x14/0x30 kernel: amdgpu_driver_load_kms+0x88/0x270
[Bug 110822] booting with kernel version 5.1.0 or higher on RX 580 hangs
https://bugs.freedesktop.org/show_bug.cgi?id=110822 Bug ID: 110822 Summary: booting with kernel version 5.1.0 or higher on RX 580 hangs Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: blocker Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: gobinda@gmail.com Created attachment 144420 --> https://bugs.freedesktop.org/attachment.cgi?id=144420=edit Linux version 5.1.6-350.vanilla.knurd.1.fc30.x86_64 My hardware is as follows: CPU: i7 3770 at stock clock Motherboard: Gigabyte G1.Sniper 3 latest BIOS available RAM: 24 GB DDR3 at 1600 mhz GPU: RX 580 8GB (Sapphire) latest VBIOS The problem is with kernel 5.1.0 or higher (currently 5.1.6) Display hangs when amdgpu driver loads. I'm unable to determine if the booting is continued or hangs as well. Disk activity stops after couple seconds and not possible to switch TTY. Ctrl+Alt+Del is unresponsive as well. This problem goes away when amdgpu.dpm=0 is used but in that case dynamic power scaling is not available and gpu stuck at low clock, graphics performance is abysmal. Also GPU temp/fan speed utilities doesn't work. Here is the excerpt of the problematic log lines: Jun 02 09:54:05 kernel: amdgpu: [powerplay] last message was failed ret is 65535 Jun 02 09:54:06 kernel: amdgpu: [powerplay] failed to send message 15b ret is 65535 Jun 02 09:54:06 kernel: hrtimer: interrupt took 287743313 ns Jun 02 09:54:06 kernel: clocksource: timekeeping watchdog on CPU3: Marking clocksource 'tsc' as unstable because the skew is too large: Jun 02 09:54:06 kernel: clocksource: 'hpet' wd_now: 628dd7b wd_last: 5fef431 mask: Jun 02 09:54:06 kernel: clocksource: 'tsc' cs_now: 254aa24747 cs_last: 25104a5bfd mask: Jun 02 09:54:06 kernel: tsc: Marking TSC unstable due to clocksource watchdog Jun 02 09:54:07 kernel: amdgpu: [powerplay] last message was failed ret is 65535 Jun 02 09:54:07 kernel: amdgpu: [powerplay] failed to send message 148 ret is 65535 Jun 02 09:54:07 kernel: amdgpu: [powerplay] last message was failed ret is 65535 Jun 02 09:54:07 kernel: amdgpu: [powerplay] failed to send message 145 ret is 65535 Jun 02 09:54:08 kernel: amdgpu: [powerplay] last message was failed ret is 65535 Jun 02 09:54:08 kernel: TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'. Jun 02 09:54:08 kernel: sched_clock: Marking unstable (8791691311, 362291)<-(8817904668, -25851212) Jun 02 09:54:08 kernel: amdgpu: [powerplay] failed to send message 146 ret is 65535 Jun 02 09:54:08 kernel: hid-generic 0003:09DA:FC7C.0003: input,hidraw2: USB HID v1.11 Mouse [COMPANY USB Device] on usb-:00:1a.0-1.5.3/input0 Jun 02 09:54:09 kernel: hid-generic 0003:09DA:FC7C.0004: hiddev97,hidraw3: USB HID v1.11 Device [COMPANY USB Device] on usb-:00:1a.0-1.5.3/input1 Jun 02 09:54:11 kernel: clocksource: Switched to clocksource hpet Jun 02 09:54:13 kernel: amdgpu: [powerplay] last message was failed ret is 65535 Jun 02 09:54:13 kernel: amdgpu: [powerplay] failed to send message 260 ret is 65535 Jun 02 09:54:14 kernel: amdgpu: [powerplay] last message was failed ret is 65535 Jun 02 09:54:14 kernel: amdgpu: [powerplay] failed to send message 260 ret is 65535 Jun 02 09:54:14 kernel: amdgpu: [powerplay] last message was failed ret is 65535 Jun 02 09:54:14 kernel: amdgpu: [powerplay] failed to send message 260 ret is 65535 Jun 02 09:54:14 kernel: amdgpu: [powerplay] last message was failed ret is 65535 Jun 02 09:54:14 kernel: amdgpu: [powerplay] failed to send message 260 ret is 65535 Jun 02 09:54:14 kernel: amdgpu: [powerplay] last message was failed ret is 65535 Jun 02 09:54:14 kernel: amdgpu: [powerplay] failed to send message 260 ret is 65535 Jun 02 09:54:14 kernel: amdgpu: [powerplay] last message was failed ret is 65535 Jun 02 09:54:14 kernel: amdgpu: [powerplay] failed to send message 260 ret is 65535 Jun 02 09:54:14 kernel: amdgpu: [powerplay] last message was failed ret is 65535 Jun 02 09:54:14 kernel: amdgpu: [powerplay] failed to send message 260 ret is 65535 Jun 02 09:54:14 kernel: amdgpu: [powerplay] last message was failed ret is 65535 Jun 02 09:54:14 kernel:
Re: [PATCH 1/7] video: add HDMI state notifier support
On 6/3/19 10:09 AM, Daniel Vetter wrote: > On Mon, Jun 03, 2019 at 09:45:49AM +0200, Hans Verkuil wrote: >> On 6/3/19 6:32 AM, Cheng-Yi Chiang wrote: >>> From: Hans Verkuil >>> >>> Add support for HDMI hotplug and EDID notifiers, which is used to convey >>> information from HDMI drivers to their CEC and audio counterparts. >>> >>> Based on an earlier version from Russell King: >>> >>> https://patchwork.kernel.org/patch/9277043/ >>> >>> The hdmi_notifier is a reference counted object containing the HDMI state >>> of an HDMI device. >>> >>> When a new notifier is registered the current state will be reported to >>> that notifier at registration time. >>> >>> Based on Hans Verkuil's patch: >>> >>> https://patchwork.kernel.org/patch/9472521/ >> >> Erm, you are aware that this patch morphed into a CEC-specific notifier >> found in drivers/media/cec/cec-notifier.c? >> >> I don't think it makes sense to have two notifier implementations in the >> kernel. >> The original intention was to have the notifier deal with both CEC and ASoC >> notifications, but there was not enough interest for the ASoC bits at the >> time >> and it was dropped. >> >> I am planning changes to the cec-notifier API, I hope to work on that this >> week. I'll CC you when I post those. Those might be a good starting point >> to convert the cec-notifier to an hdmi-notifier as was originally intended. >> >> I've added your colleague Dariusz Marcinkiewicz to the CC list since he's >> been >> working on some nice cec-notifier improvements as well. > > We also have some interfaces for drm/alsa interactions around hdmi > already in drm/drm_audio_component.h, but it's not used by anything > outside of i915. Imo we should extend that, not reinvent a new wheel. If that can be used instead of this hdmi-notifier, then that's fine by me. > Another note: notifiers considered evil, imo. Gets the job done for one > case, as soon as you have multiple devices and need to make sure you get > the update for the right one it all comes crashing down. Please create an > api which registers for updates from a specific device only, plus > something that has real callbacks (like the drm_audio_component.h thing we > started already). For CEC the notifier works very well. But CEC has some special requirements that ASoC doesn't have: - The cec-notifier can be used by both HDMI transmitters and receivers (so has to work with two different subsystems). - There may be multiple CEC devices connected to one HDMI transmitter: one that is used when the system is in Standby, and a more capable CEC device used when the system is powered up. This isn't supported yet, but it is likely that we'll need this. - HDMI and CEC devices are often completely independent and one or the other (or both) can be unbound at any time. A real-world example is when an FPGA containing the HDMI and/or CEC support is unloaded to save power when in standby. - In some cases you want to register a CEC device via a notifier to an HDMI connector based on userspace information. E.g. the popular USB Pulse-Eight CEC device can be connected to any HDMI output by the user, there is no way to know this in the kernel. An application that knows about the Pulse-Eight currently has to parse the EDID and set the Physical Address of the Pulse-Eight accordingly. I want to make it possible that the user can just tell the Pulse-Eight which HDMI output is used and have it connect to that output using the notifier. I have a proof-of-concept, but this needs Dariusz' series to make it work. Regards, Hans > -Daniel > >> >> Regards, >> >> Hans >> >>> >>> Modified by Cheng-Yi Chiang: >>> - Add a section in MAINTAINER. >>> - Changes connected and has_eld to bitfield of unsigned int. >>> - Other minor fixes to pass checkpatch.pl --strict checks. >>> >>> Signed-off-by: Hans Verkuil >>> Acked-by: Philipp Zabel >>> Signed-off-by: Cheng-Yi Chiang >>> --- >>> The original patch is at >>> https://lore.kernel.org/linux-arm-kernel/20161213150813.37966-2-hverk...@xs4all.nl >>> >>> MAINTAINERS | 6 ++ >>> drivers/video/Kconfig | 3 + >>> drivers/video/Makefile| 1 + >>> drivers/video/hdmi-notifier.c | 145 ++ >>> include/linux/hdmi-notifier.h | 112 ++ >>> 5 files changed, 267 insertions(+) >>> create mode 100644 drivers/video/hdmi-notifier.c >>> create mode 100644 include/linux/hdmi-notifier.h >>> >>> diff --git a/MAINTAINERS b/MAINTAINERS >>> index 5cfbea4ce575..ffb7376f9509 100644 >>> --- a/MAINTAINERS >>> +++ b/MAINTAINERS >>> @@ -16676,6 +16676,12 @@ W: https://linuxtv.org >>> S: Maintained >>> F: drivers/media/platform/vicodec/* >>> >>> +VIDEO FRAMEWORK >>> +M: Hans Verkuil >>> +L: linux-me...@vger.kernel.org >>> +F: drivers/video/hdmi-notifier.* >>> +S: Maintained >>> + >>> VIDEO MULTIPLEXER DRIVER >>> M: Philipp Zabel >>> L: linux-me...@vger.kernel.org >>> diff --git
Re: [alsa-devel] [PATCH 2/7] ASoC: hdmi-codec: use HDMI state notifier to add jack support
On Mon, Jun 3, 2019 at 3:59 PM Amadeusz Sławiński
wrote:
>
> On Mon, 3 Jun 2019 12:32:46 +0800
> Cheng-Yi Chiang wrote:
>
> > From: Philipp Zabel
> >
> > Use HDMI connection / disconnection notifications to update an ALSA
> > jack object. Also make a copy of the ELD block after every change.
> >
> > This was posted by Philipp Zabel at
> >
> > https://patchwork.kernel.org/patch/9430747/
> >
> > Modified by Cheng-Yi Chiang:
> > - Fix the conflict of removed hdmi_codec_remove ops.
> > - Other minor fix for the conflict with latest hdmi-codec on ASoC
> > for-next tree.
> >
> > Signed-off-by: Philipp Zabel
> > Signed-off-by: Cheng-Yi Chiang
> > ---
> > The original patch is at https://patchwork.kernel.org/patch/9430747/
> > I could not find the LKML link for the patch.
> >
> > include/sound/hdmi-codec.h| 7 +++
> > sound/soc/codecs/Kconfig | 1 +
> > sound/soc/codecs/hdmi-codec.c | 104
> > +- 3 files changed, 110
> > insertions(+), 2 deletions(-)
> >
> > diff --git a/include/sound/hdmi-codec.h b/include/sound/hdmi-codec.h
> > index 9483c55f871b..4fa39c93363f 100644
> > --- a/include/sound/hdmi-codec.h
> > +++ b/include/sound/hdmi-codec.h
> > @@ -107,6 +107,13 @@ struct hdmi_codec_pdata {
> > void *data;
> > };
> >
> > +struct snd_soc_component;
> > +struct snd_soc_jack;
> > +
> > +int hdmi_codec_set_jack_detect(struct snd_soc_component *component,
> > +struct snd_soc_jack *jack,
> > +struct device *dev);
> > +
> > #define HDMI_CODEC_DRV_NAME "hdmi-audio-codec"
> >
> > #endif /* __HDMI_CODEC_H__ */
> > diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
> > index 8f577258080b..f5f6dd04234c 100644
> > --- a/sound/soc/codecs/Kconfig
> > +++ b/sound/soc/codecs/Kconfig
> > @@ -639,6 +639,7 @@ config SND_SOC_HDMI_CODEC
> > select SND_PCM_ELD
> > select SND_PCM_IEC958
> > select HDMI
> > + select HDMI_NOTIFIERS
> >
> > config SND_SOC_ES7134
> > tristate "Everest Semi ES7134 CODEC"
> > diff --git a/sound/soc/codecs/hdmi-codec.c
> > b/sound/soc/codecs/hdmi-codec.c index 6a0cc8d7e141..fe796a7475a5
> > 100644 --- a/sound/soc/codecs/hdmi-codec.c
> > +++ b/sound/soc/codecs/hdmi-codec.c
> > @@ -12,9 +12,12 @@
> > * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See
> > the GNU
> > * General Public License for more details.
> > */
> > +#include
> > #include
> > +#include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -282,6 +285,13 @@ struct hdmi_codec_priv {
> > struct snd_pcm_chmap *chmap_info;
> > unsigned int chmap_idx;
> > struct mutex lock;
> > + struct snd_soc_jack *jack;
> > + /* Lock to protect setting and getting eld. */
> > + struct mutex eld_lock;
> > + struct device *dev;
> > + struct hdmi_notifier *notifier;
> > + struct notifier_block nb;
> > + unsigned int jack_status;
> > };
> >
> > static const struct snd_soc_dapm_widget hdmi_widgets[] = {
> > @@ -308,7 +318,9 @@ static int hdmi_eld_ctl_get(struct snd_kcontrol
> > *kcontrol, struct snd_soc_component *component =
> > snd_kcontrol_chip(kcontrol); struct hdmi_codec_priv *hcp =
> > snd_soc_component_get_drvdata(component);
> > + mutex_lock(>eld_lock);
> > memcpy(ucontrol->value.bytes.data, hcp->eld,
> > sizeof(hcp->eld));
> > + mutex_unlock(>eld_lock);
> >
> > return 0;
> > }
> > @@ -393,7 +405,7 @@ static int hdmi_codec_startup(struct
> > snd_pcm_substream *substream, struct snd_soc_dai *dai)
> > {
> > struct hdmi_codec_priv *hcp = snd_soc_dai_get_drvdata(dai);
> > - int ret = 0;
> > + int ret;
> >
> > ret = mutex_trylock(>lock);
> > if (!ret) {
> > @@ -408,9 +420,9 @@ static int hdmi_codec_startup(struct
> > snd_pcm_substream *substream, }
> >
> > if (hcp->hcd.ops->get_eld) {
> > + mutex_lock(>eld_lock);
> > ret = hcp->hcd.ops->get_eld(dai->dev->parent,
> > hcp->hcd.data, hcp->eld, sizeof(hcp->eld));
> > -
> > if (!ret) {
> > ret =
> > snd_pcm_hw_constraint_eld(substream->runtime, hcp->eld);
>
> Seems to me like you missed unlock here. There is return inside this
> if().
>
Thanks for checking!
The latest patch on hdmi-codec.c on ASoC tree has a change to replace
that return to goto err.
https://patchwork.kernel.org/patch/10930875/
My patch is based on that so it should be okay.
Thanks!
> > @@ -419,6 +431,7 @@ static int hdmi_codec_startup(struct
> > snd_pcm_substream *substream, }
> > /* Select chmap supported */
> > hdmi_codec_eld_chmap(hcp);
> > + mutex_unlock(>eld_lock);
> > }
> > return 0;
> >
> > @@ -747,6 +760,77 @@ static const struct snd_soc_component_driver
> > hdmi_driver = { .non_legacy_dai_naming= 1,
> > };
> >
> > +static void hdmi_codec_jack_report(struct hdmi_codec_priv *hcp,
> > +
[Bug 110781] Radeon: heavy r300 performance drop regression between 11.x and 19.x
https://bugs.freedesktop.org/show_bug.cgi?id=110781 --- Comment #10 from Richard Thier --- I am getting really close to bisecting the bigger identified problem. bad: b672c3833b7 good: aff1ad0798 Now at this point: Bisecting: 9 revisions left to test after this (roughly 3 steps) [3efedf98e8272d1a32a3837b22161582d28c4487] i965: Always flush caches after blitting to a GL buffer object. Also now compiation is not even taking an hour like before where bisect was jumping big time periods as code barely changes I guess ;-) -- 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 109345] drm-next-2018-12-14 -Linux PPC
https://bugs.freedesktop.org/show_bug.cgi?id=109345 --- Comment #48 from Michel Dänzer --- (In reply to Allan Cairns from comment #47) > My Amigone x5000 would only boot to a black screen. No ability to input. Please attach the corresponding Xorg log file. If you can't log into the system remotely, it should be available as Xorg.0.log.old after rebooting. -- 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] drm/stm: support runtime power management
This patch enables runtime power management (runtime PM) support for
the display controller. pm_runtime_enable() and pm_runtime_disable()
are added during ltdc load and unload respectively.
pm_runtime_get_sync() and pm_runtime_put_sync() are added for ltdc
register access.
Signed-off-by: Yannick Fertré
---
drivers/gpu/drm/stm/drv.c | 43 +++--
drivers/gpu/drm/stm/ltdc.c | 67 +++---
2 files changed, 86 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
index 5834ef5..5659572 100644
--- a/drivers/gpu/drm/stm/drv.c
+++ b/drivers/gpu/drm/stm/drv.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
@@ -135,14 +136,15 @@ static __maybe_unused int drv_suspend(struct device *dev)
struct ltdc_device *ldev = ddev->dev_private;
struct drm_atomic_state *state;
- drm_kms_helper_poll_disable(ddev);
+ if (WARN_ON(!ldev->suspend_state))
+ return -ENOENT;
+
state = drm_atomic_helper_suspend(ddev);
- if (IS_ERR(state)) {
- drm_kms_helper_poll_enable(ddev);
+ if (IS_ERR(state))
return PTR_ERR(state);
- }
+
ldev->suspend_state = state;
- ltdc_suspend(ddev);
+ pm_runtime_force_suspend(dev);
return 0;
}
@@ -151,16 +153,41 @@ static __maybe_unused int drv_resume(struct device *dev)
{
struct drm_device *ddev = dev_get_drvdata(dev);
struct ltdc_device *ldev = ddev->dev_private;
+ int ret;
- ltdc_resume(ddev);
- drm_atomic_helper_resume(ddev, ldev->suspend_state);
- drm_kms_helper_poll_enable(ddev);
+ pm_runtime_force_resume(dev);
+ ret = drm_atomic_helper_resume(ddev, ldev->suspend_state);
+ if (ret) {
+ pm_runtime_force_suspend(dev);
+ ldev->suspend_state = NULL;
+ return ret;
+ }
return 0;
}
+static __maybe_unused int drv_runtime_suspend(struct device *dev)
+{
+ struct drm_device *ddev = dev_get_drvdata(dev);
+
+ DRM_DEBUG_DRIVER("\n");
+ ltdc_suspend(ddev);
+
+ return 0;
+}
+
+static __maybe_unused int drv_runtime_resume(struct device *dev)
+{
+ struct drm_device *ddev = dev_get_drvdata(dev);
+
+ DRM_DEBUG_DRIVER("\n");
+ return ltdc_resume(ddev);
+}
+
static const struct dev_pm_ops drv_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(drv_suspend, drv_resume)
+ SET_RUNTIME_PM_OPS(drv_runtime_suspend,
+ drv_runtime_resume, NULL)
};
static int stm_drm_platform_probe(struct platform_device *pdev)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index ac29890..a40870b 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
@@ -444,6 +445,7 @@ static void ltdc_crtc_atomic_disable(struct drm_crtc *crtc,
struct drm_crtc_state *old_state)
{
struct ltdc_device *ldev = crtc_to_ltdc(crtc);
+ struct drm_device *ddev = crtc->dev;
DRM_DEBUG_DRIVER("\n");
@@ -457,6 +459,8 @@ static void ltdc_crtc_atomic_disable(struct drm_crtc *crtc,
/* immediately commit disable of layers before switching off LTDC */
reg_set(ldev->regs, LTDC_SRCR, SRCR_IMR);
+
+ pm_runtime_put_sync(ddev->dev);
}
#define CLK_TOLERANCE_HZ 50
@@ -505,17 +509,31 @@ static bool ltdc_crtc_mode_fixup(struct drm_crtc *crtc,
struct drm_display_mode *adjusted_mode)
{
struct ltdc_device *ldev = crtc_to_ltdc(crtc);
+ struct drm_device *ddev = crtc->dev;
int rate = mode->clock * 1000;
+ bool runtime_active;
+ int ret;
+
+ runtime_active = pm_runtime_active(ddev->dev);
+
+ if (runtime_active)
+ pm_runtime_put_sync(ddev->dev);
- clk_disable(ldev->pixel_clk);
if (clk_set_rate(ldev->pixel_clk, rate) < 0) {
DRM_ERROR("Cannot set rate (%dHz) for pixel clk\n", rate);
return false;
}
- clk_enable(ldev->pixel_clk);
adjusted_mode->clock = clk_get_rate(ldev->pixel_clk) / 1000;
+ if (runtime_active) {
+ ret = pm_runtime_get_sync(ddev->dev);
+ if (ret) {
+ DRM_ERROR("Failed to fixup mode, cannot get sync\n");
+ return false;
+ }
+ }
+
DRM_DEBUG_DRIVER("requested clock %dkHz, adjusted clock %dkHz\n",
mode->clock, adjusted_mode->clock);
@@ -525,11 +543,21 @@ static bool ltdc_crtc_mode_fixup(struct drm_crtc *crtc,
static void ltdc_crtc_mode_set_nofb(struct drm_crtc *crtc)
{
struct ltdc_device *ldev = crtc_to_ltdc(crtc);
+ struct drm_device *ddev = crtc->dev;
struct drm_display_mode *mode =
[PATCH] drm/stm: ltdc: No message if probe
Print display controller hardware version in debug mode only.
Signed-off-by: Yannick Fertré
---
drivers/gpu/drm/stm/ltdc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index a40870b..2fe6c4a 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -1229,7 +1229,7 @@ int ltdc_load(struct drm_device *ddev)
goto err;
}
- DRM_INFO("ltdc hw version 0x%08x - ready\n", ldev->caps.hw_version);
+ DRM_DEBUG_DRIVER("ltdc hw version 0x%08x\n", ldev->caps.hw_version);
/* Add endpoints panels or bridges if any */
for (i = 0; i < MAX_ENDPOINTS; i++) {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv6 0/4] omapdrm: DSI command mode panel support
Hi! > > > Here is another round of the DSI command mode panel patchset > > > integrating the feedback from PATCHv5. The patches are based > > > on v5.2-rc1 tag. It does not contain the patches required for > > > OMAP3 support (it needs a workaround for a hardware bug) and > > > for automatic display rotation. They should get their own series, > > > once after everything has been moved to DRM panel API. I think > > > DRM panel conversion should happen _after_ this series, since > > > otherwise there is a high risk of bricking DSI support completely. > > > I already started a WIP branch for converting DSI to the DRM panel > > > API on top of this patchset. > > > > Looks good to me. For some reason I can't boot 5.2-rc2 (on x15) so I haven't > > been able to test yet. I'll pick the series up in any case, and I'll test it > > when I get the kernel booting. > > Great good to have these merged finally :) > > Hmm I wonder if some x15 models are affected by the SoC variant > changes queued in my fixes branch? I still don't see the patches in next-20190603 . Are they expected to be there, or should I use different tree? Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH 3/4] drm: Fixed doc warnings in drm uapi header
On Thu, May 30, 2019 at 01:29:03AM +0530, Uma Shankar wrote:
> Fixed doc warnings in drm uapi header. All the UAPI
> structures are now documented in kernel doc.
>
> Signed-off-by: Uma Shankar
Applied, thanks for the patch.
Long-term there's obviously a lot more to do here, but this at least gets
us started.
Btw I think it'd be good to split out the "add new uapi ioctl structures
section" part from the previous patch, and merge that separately.
Thanks, Daniel
> ---
> include/uapi/drm/drm_mode.h | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 5d3964f..02b2a2b 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -861,6 +861,10 @@ struct drm_format_modifier {
> };
>
> /**
> + * struct drm_mode_create_blob - Create New block property
> + * @data: Pointer to data to copy.
> + * @length: Length of data to copy.
> + * @blob_id: new property ID.
> * Create a new 'blob' data property, copying length bytes from data pointer,
> * and returning new blob ID.
> */
> @@ -874,6 +878,8 @@ struct drm_mode_create_blob {
> };
>
> /**
> + * struct drm_mode_destroy_blob - Destroy user blob
> + * @blob_id: blob_id to destroy
> * Destroy a user-created blob property.
> */
> struct drm_mode_destroy_blob {
> @@ -881,6 +887,12 @@ struct drm_mode_destroy_blob {
> };
>
> /**
> + * struct drm_mode_create_lease - Create lease
> + * @object_ids: Pointer to array of object ids.
> + * @object_count: Number of object ids.
> + * @flags: flags for new FD.
> + * @lessee_id: unique identifier for lessee.
> + * @fd: file descriptor to new drm_master file.
> * Lease mode resources, creating another drm_master.
> */
> struct drm_mode_create_lease {
> @@ -898,6 +910,10 @@ struct drm_mode_create_lease {
> };
>
> /**
> + * struct drm_mode_list_lessees - List lessees
> + * @count_lessees: Number of lessees.
> + * @pad: pad.
> + * @lessees_ptr: Pointer to lessess.
> * List lesses from a drm_master
> */
> struct drm_mode_list_lessees {
> @@ -918,6 +934,10 @@ struct drm_mode_list_lessees {
> };
>
> /**
> + * struct drm_mode_get_lease - Get Lease
> + * @count_objects: Number of leased objects.
> + * @pad: pad.
> + * @objects_ptr: Pointer to objects.
> * Get leased objects
> */
> struct drm_mode_get_lease {
> @@ -938,6 +958,8 @@ struct drm_mode_get_lease {
> };
>
> /**
> + * struct drm_mode_revoke_lease - Revoke lease
> + * @lessee_id: Unique ID of lessee.
> * Revoke lease
> */
> struct drm_mode_revoke_lease {
> --
> 1.9.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 4/4] video/hdmi: Dropped static functions from kernel doc
On Thu, May 30, 2019 at 01:29:04AM +0530, Uma Shankar wrote: > Dropped static functions from kernel documentation. > > Suggested-by: Daniel Vetter > Signed-off-by: Uma Shankar > --- > drivers/video/hdmi.c | 32 > 1 file changed, 16 insertions(+), 16 deletions(-) > > diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c > index b99ba01..72c654b 100644 > --- a/drivers/video/hdmi.c > +++ b/drivers/video/hdmi.c > @@ -1191,11 +1191,11 @@ static const char *hdmi_nups_get_name(enum hdmi_nups > nups) > return "Invalid"; > } > > -/** > +/* > * hdmi_avi_infoframe_log() - log info of HDMI AVI infoframe > - * @level: logging level > - * @dev: device > - * @frame: HDMI AVI infoframe > + * level: logging level > + * dev: device > + * frame: HDMI AVI infoframe > */ > static void hdmi_avi_infoframe_log(const char *level, > struct device *dev, > @@ -1268,11 +1268,11 @@ static const char *hdmi_spd_sdi_get_name(enum > hdmi_spd_sdi sdi) > return "Reserved"; > } > > -/** > +/* > * hdmi_spd_infoframe_log() - log info of HDMI SPD infoframe > - * @level: logging level > - * @dev: device > - * @frame: HDMI SPD infoframe > + * level: logging level > + * dev: device > + * frame: HDMI SPD infoframe > */ For internal functions I think there's not really any value in documenting this. The variable names are obvious enough. Imo better to ditch this outright. -Daniel > static void hdmi_spd_infoframe_log(const char *level, > struct device *dev, > @@ -1404,11 +1404,11 @@ static void hdmi_spd_infoframe_log(const char *level, > return "Reserved"; > } > > -/** > +/* > * hdmi_audio_infoframe_log() - log info of HDMI AUDIO infoframe > - * @level: logging level > - * @dev: device > - * @frame: HDMI AUDIO infoframe > + * level: logging level > + * dev: device > + * frame: HDMI AUDIO infoframe > */ > static void hdmi_audio_infoframe_log(const char *level, >struct device *dev, > @@ -1437,11 +1437,11 @@ static void hdmi_audio_infoframe_log(const char > *level, > frame->downmix_inhibit ? "Yes" : "No"); > } > > -/** > +/* > * hdmi_drm_infoframe_log() - log info of HDMI DRM infoframe > - * @level: logging level > - * @dev: device > - * @frame: HDMI DRM infoframe > + * level: logging level > + * dev: device > + * frame: HDMI DRM infoframe > */ > static void hdmi_drm_infoframe_log(const char *level, > struct device *dev, > -- > 1.9.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 2/4] drm: Fix docbook warnings in hdr metadata helper structures
On Thu, May 30, 2019 at 01:29:02AM +0530, Uma Shankar wrote: > Fixes the following warnings: > ./include/drm/drm_mode_config.h:841: warning: Incorrect use of > kernel-doc format: * hdr_output_metadata_property: Connector > property containing hdr > ./include/drm/drm_mode_config.h:918: warning: Function parameter or member > 'hdr_output_metadata_property' not described in 'drm_mode_config' > ./include/drm/drm_connector.h:1251: warning: Function parameter or member > 'hdr_output_metadata' not described in 'drm_connector' > ./include/drm/drm_connector.h:1251: warning: Function parameter or member > 'hdr_sink_metadata' not described in 'drm_connector' > > Also adds some property documentation for HDR Metadata Connector > Property in connector property create function. > > v2: Fixed Sean Paul's review comments. > > v3: Fixed Daniel Vetter's review comments, added the UAPI structure > definition section in kernel docs. > > Cc: Shashank Sharma > Cc: Ville Syrjälä > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Sean Paul > Cc: David Airlie > Cc: Daniel Vetter > Cc: Bartlomiej Zolnierkiewicz > Cc: "Ville Syrjälä" > Cc: Hans Verkuil > Cc: dri-devel@lists.freedesktop.org > Cc: linux-fb...@vger.kernel.org > Reviewed-by: Sean Paul > Signed-off-by: Uma Shankar > --- > Documentation/gpu/drm-uapi.rst | 9 + > drivers/gpu/drm/drm_connector.c | 31 +++ > include/drm/drm_connector.h | 1 + > include/drm/drm_mode_config.h | 4 ++-- > include/linux/hdmi.h| 1 + > include/uapi/drm/drm_mode.h | 37 - > 6 files changed, 80 insertions(+), 3 deletions(-) > > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst > index 05874d0..6b39e2c 100644 > --- a/Documentation/gpu/drm-uapi.rst > +++ b/Documentation/gpu/drm-uapi.rst > @@ -329,3 +329,12 @@ DRM_IOCTL_MODESET_CTL > mode setting, since on many devices the vertical blank counter is > reset to 0 at some point during modeset. Modern drivers should not > call this any more since with kernel mode setting it is a no-op. > + > +Userspace API Structures > + > + > +.. kernel-doc:: include/uapi/drm/drm_mode.h > + :doc: overview > + > +.. kernel-doc:: include/uapi/drm/drm_mode.h > + :internal: > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c > index c9ac8b9..6a93527 100644 > --- a/drivers/gpu/drm/drm_connector.c > +++ b/drivers/gpu/drm/drm_connector.c > @@ -956,6 +956,37 @@ int drm_display_info_set_bus_formats(struct > drm_display_info *info, > * is no longer protected and userspace should take appropriate action > * (whatever that might be). > * > + * HDR_OUTPUT_METADATA: > + * Connector property to enable userspace to send HDR Metadata to > + * driver. This metadata is based on the composition and blending > + * policies decided by user, taking into account the hardware and > + * sink capabilities. The driver gets this metadata and creates a > + * Dynamic Range and Mastering Infoframe (DRM) in case of HDMI, > + * SDP packet (Non-audio INFOFRAME SDP v1.3) for DP. This is then > + * sent to sink. This notifies the sink of the upcoming frame's Color > + * Encoding and Luminance parameters. > + * > + * Userspace first need to detect the HDR capabilities of sink by > + * reading and parsing the EDID. Details of HDR metadata for HDMI > + * are added in CTA 861.G spec. For DP , its defined in VESA DP > + * Standard v1.4. It needs to then get the metadata information > + * of the video/game/app content which are encoded in HDR (basically > + * using HDR transfer functions). With this information it needs to > + * decide on a blending policy and compose the relevant > + * layers/overlays into a common format. Once this blending is done, > + * userspace will be aware of the metadata of the composed frame to > + * be send to sink. It then uses this property to communicate this > + * metadata to driver which then make a Infoframe packet and sends > + * to sink based on the type of encoder connected. > + * > + * Userspace will be responsible to do Tone mapping operation in case: > + * - Some layers are HDR and others are SDR > + * - HDR layers luminance is not same as sink > + * It will even need to do colorspace conversion and get all layers > + * to one common colorspace for blending. It can use either GL, Media > + * or display engine to get this done based on the capabilties of the > + * associated hardware. I think it'd be good to add 1-2 sentences here about what this looks like for the driver side. E.g. which function drivers need to call to set up hdr, how to get at the metadata and whether there's any helpers for these. Here I'd point at hdr_output_metadata, hdr_sink_metadata, and drm_add_display_info() for filling in the former. I think with that this is a solid doc patch. > + * >
Re: [PATCH 1/4] drm: Drop a redundant unused variable
On Thu, May 30, 2019 at 01:29:01AM +0530, Uma Shankar wrote:
> Drop a redundant and unused variable "hdr_output_metadata" from
> drm_connector.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Uma Shankar
For next time around: Please add Fixes: lines to indicate which already
merged commit you're improving.
Patch merged, thanks.
-Daniel
> ---
> include/drm/drm_connector.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index f8f4003..5476561 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -1244,8 +1244,6 @@ struct drm_connector {
>*/
> struct llist_node free_node;
>
> - /* HDR metdata */
> - struct hdr_output_metadata hdr_output_metadata;
> struct hdr_sink_metadata hdr_sink_metadata;
> };
>
> --
> 1.9.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
[Bug 110803] Coruption and flickering on polaris with mesa 19.0.5
https://bugs.freedesktop.org/show_bug.cgi?id=110803 diplosa...@gmail.com changed: What|Removed |Added CC||mezin.alexan...@gmail.com --- Comment #3 from diplosa...@gmail.com --- *** Bug 110807 has been marked as a duplicate of this bug. *** -- 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 110807] Regression: artifacts in Chromium after mesa 19.0.5 update
https://bugs.freedesktop.org/show_bug.cgi?id=110807 diplosa...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from diplosa...@gmail.com --- *** This bug has been marked as a duplicate of bug 110803 *** -- 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 1/7] video: add HDMI state notifier support
On Mon, Jun 03, 2019 at 09:45:49AM +0200, Hans Verkuil wrote: > On 6/3/19 6:32 AM, Cheng-Yi Chiang wrote: > > From: Hans Verkuil > > > > Add support for HDMI hotplug and EDID notifiers, which is used to convey > > information from HDMI drivers to their CEC and audio counterparts. > > > > Based on an earlier version from Russell King: > > > > https://patchwork.kernel.org/patch/9277043/ > > > > The hdmi_notifier is a reference counted object containing the HDMI state > > of an HDMI device. > > > > When a new notifier is registered the current state will be reported to > > that notifier at registration time. > > > > Based on Hans Verkuil's patch: > > > > https://patchwork.kernel.org/patch/9472521/ > > Erm, you are aware that this patch morphed into a CEC-specific notifier > found in drivers/media/cec/cec-notifier.c? > > I don't think it makes sense to have two notifier implementations in the > kernel. > The original intention was to have the notifier deal with both CEC and ASoC > notifications, but there was not enough interest for the ASoC bits at the time > and it was dropped. > > I am planning changes to the cec-notifier API, I hope to work on that this > week. I'll CC you when I post those. Those might be a good starting point > to convert the cec-notifier to an hdmi-notifier as was originally intended. > > I've added your colleague Dariusz Marcinkiewicz to the CC list since he's been > working on some nice cec-notifier improvements as well. We also have some interfaces for drm/alsa interactions around hdmi already in drm/drm_audio_component.h, but it's not used by anything outside of i915. Imo we should extend that, not reinvent a new wheel. Another note: notifiers considered evil, imo. Gets the job done for one case, as soon as you have multiple devices and need to make sure you get the update for the right one it all comes crashing down. Please create an api which registers for updates from a specific device only, plus something that has real callbacks (like the drm_audio_component.h thing we started already). -Daniel > > Regards, > > Hans > > > > > Modified by Cheng-Yi Chiang: > > - Add a section in MAINTAINER. > > - Changes connected and has_eld to bitfield of unsigned int. > > - Other minor fixes to pass checkpatch.pl --strict checks. > > > > Signed-off-by: Hans Verkuil > > Acked-by: Philipp Zabel > > Signed-off-by: Cheng-Yi Chiang > > --- > > The original patch is at > > https://lore.kernel.org/linux-arm-kernel/20161213150813.37966-2-hverk...@xs4all.nl > > > > MAINTAINERS | 6 ++ > > drivers/video/Kconfig | 3 + > > drivers/video/Makefile| 1 + > > drivers/video/hdmi-notifier.c | 145 ++ > > include/linux/hdmi-notifier.h | 112 ++ > > 5 files changed, 267 insertions(+) > > create mode 100644 drivers/video/hdmi-notifier.c > > create mode 100644 include/linux/hdmi-notifier.h > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 5cfbea4ce575..ffb7376f9509 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -16676,6 +16676,12 @@ W: https://linuxtv.org > > S: Maintained > > F: drivers/media/platform/vicodec/* > > > > +VIDEO FRAMEWORK > > +M: Hans Verkuil > > +L: linux-me...@vger.kernel.org > > +F: drivers/video/hdmi-notifier.* > > +S: Maintained > > + > > VIDEO MULTIPLEXER DRIVER > > M: Philipp Zabel > > L: linux-me...@vger.kernel.org > > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig > > index 83d3d271ca15..000ba9bc0ae7 100644 > > --- a/drivers/video/Kconfig > > +++ b/drivers/video/Kconfig > > @@ -34,6 +34,9 @@ config VIDEOMODE_HELPERS > > config HDMI > > bool > > > > +config HDMI_NOTIFIERS > > + bool > > + > > endif # HAS_IOMEM > > > > if VT > > diff --git a/drivers/video/Makefile b/drivers/video/Makefile > > index df7650adede9..eff4736102ca 100644 > > --- a/drivers/video/Makefile > > +++ b/drivers/video/Makefile > > @@ -1,6 +1,7 @@ > > # SPDX-License-Identifier: GPL-2.0 > > obj-$(CONFIG_VGASTATE)+= vgastate.o > > obj-$(CONFIG_HDMI)+= hdmi.o > > +obj-$(CONFIG_HDMI_NOTIFIERS) += hdmi-notifier.o > > > > obj-$(CONFIG_VT) += console/ > > obj-$(CONFIG_FB_STI) += console/ > > diff --git a/drivers/video/hdmi-notifier.c b/drivers/video/hdmi-notifier.c > > new file mode 100644 > > index ..d1eedf661648 > > --- /dev/null > > +++ b/drivers/video/hdmi-notifier.c > > @@ -0,0 +1,145 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* hdmi-notifier.c - notify interested parties of (dis)connect and EDID > > + * events > > + * > > + * Copyright 2016 Russell King > > + * Copyright 2016 Cisco Systems, Inc. and/or its affiliates. > > + * All rights reserved. > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +static LIST_HEAD(hdmi_notifiers); > > +static DEFINE_MUTEX(hdmi_notifiers_lock); > > + > > +struct hdmi_notifier
[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
https://bugs.freedesktop.org/show_bug.cgi?id=109955 --- Comment #25 from Matt Coffin --- (In reply to Mauro Gaspari from comment #24) > Hi, a bit frustrating eh? :) > I have been asking around and it seems that RadeonVII and RX590 do not > suffer those issues. Probably related to default clock speeds by > manufacturers. FWIW, I'm seeing this exact same issue, and I'm on an RX590. -- 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: [alsa-devel] [PATCH 2/7] ASoC: hdmi-codec: use HDMI state notifier to add jack support
On Mon, 3 Jun 2019 12:32:46 +0800
Cheng-Yi Chiang wrote:
> From: Philipp Zabel
>
> Use HDMI connection / disconnection notifications to update an ALSA
> jack object. Also make a copy of the ELD block after every change.
>
> This was posted by Philipp Zabel at
>
> https://patchwork.kernel.org/patch/9430747/
>
> Modified by Cheng-Yi Chiang:
> - Fix the conflict of removed hdmi_codec_remove ops.
> - Other minor fix for the conflict with latest hdmi-codec on ASoC
> for-next tree.
>
> Signed-off-by: Philipp Zabel
> Signed-off-by: Cheng-Yi Chiang
> ---
> The original patch is at https://patchwork.kernel.org/patch/9430747/
> I could not find the LKML link for the patch.
>
> include/sound/hdmi-codec.h| 7 +++
> sound/soc/codecs/Kconfig | 1 +
> sound/soc/codecs/hdmi-codec.c | 104
> +- 3 files changed, 110
> insertions(+), 2 deletions(-)
>
> diff --git a/include/sound/hdmi-codec.h b/include/sound/hdmi-codec.h
> index 9483c55f871b..4fa39c93363f 100644
> --- a/include/sound/hdmi-codec.h
> +++ b/include/sound/hdmi-codec.h
> @@ -107,6 +107,13 @@ struct hdmi_codec_pdata {
> void *data;
> };
>
> +struct snd_soc_component;
> +struct snd_soc_jack;
> +
> +int hdmi_codec_set_jack_detect(struct snd_soc_component *component,
> +struct snd_soc_jack *jack,
> +struct device *dev);
> +
> #define HDMI_CODEC_DRV_NAME "hdmi-audio-codec"
>
> #endif /* __HDMI_CODEC_H__ */
> diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
> index 8f577258080b..f5f6dd04234c 100644
> --- a/sound/soc/codecs/Kconfig
> +++ b/sound/soc/codecs/Kconfig
> @@ -639,6 +639,7 @@ config SND_SOC_HDMI_CODEC
> select SND_PCM_ELD
> select SND_PCM_IEC958
> select HDMI
> + select HDMI_NOTIFIERS
>
> config SND_SOC_ES7134
> tristate "Everest Semi ES7134 CODEC"
> diff --git a/sound/soc/codecs/hdmi-codec.c
> b/sound/soc/codecs/hdmi-codec.c index 6a0cc8d7e141..fe796a7475a5
> 100644 --- a/sound/soc/codecs/hdmi-codec.c
> +++ b/sound/soc/codecs/hdmi-codec.c
> @@ -12,9 +12,12 @@
> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See
> the GNU
> * General Public License for more details.
> */
> +#include
> #include
> +#include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -282,6 +285,13 @@ struct hdmi_codec_priv {
> struct snd_pcm_chmap *chmap_info;
> unsigned int chmap_idx;
> struct mutex lock;
> + struct snd_soc_jack *jack;
> + /* Lock to protect setting and getting eld. */
> + struct mutex eld_lock;
> + struct device *dev;
> + struct hdmi_notifier *notifier;
> + struct notifier_block nb;
> + unsigned int jack_status;
> };
>
> static const struct snd_soc_dapm_widget hdmi_widgets[] = {
> @@ -308,7 +318,9 @@ static int hdmi_eld_ctl_get(struct snd_kcontrol
> *kcontrol, struct snd_soc_component *component =
> snd_kcontrol_chip(kcontrol); struct hdmi_codec_priv *hcp =
> snd_soc_component_get_drvdata(component);
> + mutex_lock(>eld_lock);
> memcpy(ucontrol->value.bytes.data, hcp->eld,
> sizeof(hcp->eld));
> + mutex_unlock(>eld_lock);
>
> return 0;
> }
> @@ -393,7 +405,7 @@ static int hdmi_codec_startup(struct
> snd_pcm_substream *substream, struct snd_soc_dai *dai)
> {
> struct hdmi_codec_priv *hcp = snd_soc_dai_get_drvdata(dai);
> - int ret = 0;
> + int ret;
>
> ret = mutex_trylock(>lock);
> if (!ret) {
> @@ -408,9 +420,9 @@ static int hdmi_codec_startup(struct
> snd_pcm_substream *substream, }
>
> if (hcp->hcd.ops->get_eld) {
> + mutex_lock(>eld_lock);
> ret = hcp->hcd.ops->get_eld(dai->dev->parent,
> hcp->hcd.data, hcp->eld, sizeof(hcp->eld));
> -
> if (!ret) {
> ret =
> snd_pcm_hw_constraint_eld(substream->runtime, hcp->eld);
Seems to me like you missed unlock here. There is return inside this
if().
> @@ -419,6 +431,7 @@ static int hdmi_codec_startup(struct
> snd_pcm_substream *substream, }
> /* Select chmap supported */
> hdmi_codec_eld_chmap(hcp);
> + mutex_unlock(>eld_lock);
> }
> return 0;
>
> @@ -747,6 +760,77 @@ static const struct snd_soc_component_driver
> hdmi_driver = { .non_legacy_dai_naming= 1,
> };
>
> +static void hdmi_codec_jack_report(struct hdmi_codec_priv *hcp,
> +unsigned int jack_status)
> +{
> + if (!hcp->jack)
> + return;
> +
> + if (jack_status != hcp->jack_status) {
> + snd_soc_jack_report(hcp->jack, jack_status,
> SND_JACK_LINEOUT);
> + hcp->jack_status = jack_status;
> + }
> +}
> +
> +static int hdmi_codec_notify(struct notifier_block *nb, unsigned
> long event,
> + void *data)
> +{
> + struct hdmi_codec_priv *hcp = container_of(nb, struct
> hdmi_codec_priv,
> +
Re: [PATCH] of/device: add blacklist for iommu dma_ops
On 6/3/2019 11:50 AM, Tomasz Figa wrote:
On Mon, Jun 3, 2019 at 4:40 AM Rob Clark wrote:
On Fri, May 10, 2019 at 7:35 AM Rob Clark wrote:
On Tue, Dec 4, 2018 at 2:29 PM Rob Herring wrote:
On Sat, Dec 1, 2018 at 10:54 AM Rob Clark wrote:
This solves a problem we see with drm/msm, caused by getting
iommu_dma_ops while we attach our own domain and manage it directly at
the iommu API level:
[0038] user address but active_mm is swapper
Internal error: Oops: 9605 [#1] PREEMPT SMP
Modules linked in:
CPU: 7 PID: 70 Comm: kworker/7:1 Tainted: GW 4.19.3 #90
Hardware name: xxx (DT)
Workqueue: events deferred_probe_work_func
pstate: 80c9 (Nzcv daif +PAN +UAO)
pc : iommu_dma_map_sg+0x7c/0x2c8
lr : iommu_dma_map_sg+0x40/0x2c8
sp : ff80095eb4f0
x29: ff80095eb4f0 x28:
x27: ffc0f9431578 x26:
x25: x24: 0003
x23: 0001 x22: ffc0fa9ac010
x21: x20: ffc0fab40980
x19: ffc0fab40980 x18: 0003
x17: 01c4 x16: 0007
x15: 000e x14:
x13: x12: 0028
x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f
x9 : x8 : ffc0fab409a0
x7 : x6 : 0002
x5 : 0001 x4 :
x3 : 0001 x2 : 0002
x1 : ffc0f9431578 x0 :
Process kworker/7:1 (pid: 70, stack limit = 0x17d08ffb)
Call trace:
iommu_dma_map_sg+0x7c/0x2c8
__iommu_map_sg_attrs+0x70/0x84
get_pages+0x170/0x1e8
msm_gem_get_iova+0x8c/0x128
_msm_gem_kernel_new+0x6c/0xc8
msm_gem_kernel_new+0x4c/0x58
dsi_tx_buf_alloc_6g+0x4c/0x8c
msm_dsi_host_modeset_init+0xc8/0x108
msm_dsi_modeset_init+0x54/0x18c
_dpu_kms_drm_obj_init+0x430/0x474
dpu_kms_hw_init+0x5f8/0x6b4
msm_drm_bind+0x360/0x6c8
try_to_bring_up_master.part.7+0x28/0x70
component_master_add_with_match+0xe8/0x124
msm_pdev_probe+0x294/0x2b4
platform_drv_probe+0x58/0xa4
really_probe+0x150/0x294
driver_probe_device+0xac/0xe8
__device_attach_driver+0xa4/0xb4
bus_for_each_drv+0x98/0xc8
__device_attach+0xac/0x12c
device_initial_probe+0x24/0x30
bus_probe_device+0x38/0x98
deferred_probe_work_func+0x78/0xa4
process_one_work+0x24c/0x3dc
worker_thread+0x280/0x360
kthread+0x134/0x13c
ret_from_fork+0x10/0x18
Code: d284 91000725 6b17039f 5400048a (f9401f40)
---[ end trace f22dda57f3648e2c ]---
Kernel panic - not syncing: Fatal exception
SMP: stopping secondary CPUs
Kernel Offset: disabled
CPU features: 0x0,22802a18
Memory Limit: none
The problem is that when drm/msm does it's own iommu_attach_device(),
now the domain returned by iommu_get_domain_for_dev() is drm/msm's
domain, and it doesn't have domain->iova_cookie.
We kind of avoided this problem prior to sdm845/dpu because the iommu
was attached to the mdp node in dt, which is a child of the toplevel
mdss node (which corresponds to the dev passed in dma_map_sg()). But
with sdm845, now the iommu is attached at the mdss level so we hit the
iommu_dma_ops in dma_map_sg().
But auto allocating/attaching a domain before the driver is probed was
already a blocking problem for enabling per-context pagetables for the
GPU. This problem is also now solved with this patch.
Fixes: 97890ba9289c dma-mapping: detect and configure IOMMU in of_dma_configure
Tested-by: Douglas Anderson
Signed-off-by: Rob Clark
---
This is an alternative/replacement for [1]. What it lacks in elegance
it makes up for in practicality ;-)
[1] https://patchwork.freedesktop.org/patch/264930/
drivers/of/device.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 5957cd4fa262..15ffee00fb22 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -72,6 +72,14 @@ int of_device_add(struct platform_device *ofdev)
return device_add(>dev);
}
+static const struct of_device_id iommu_blacklist[] = {
+ { .compatible = "qcom,mdp4" },
+ { .compatible = "qcom,mdss" },
+ { .compatible = "qcom,sdm845-mdss" },
+ { .compatible = "qcom,adreno" },
+ {}
+};
Not completely clear to whether this is still needed or not, but this
really won't scale. Why can't the driver for these devices override
whatever has been setup by default?
fwiw, at the moment it is not needed, but it will become needed again
to implement per-context pagetables (although I suppose for this we
only need to blacklist qcom,adreno and not also the display nodes).
So, another case I've come across, on the display side.. I'm working
on handling the case where bootloader enables display (and takes iommu
out of reset).. as soon as DMA domain gets attached we get iommu
faults, because bootloader has
Re: [PATCH 1/7] video: add HDMI state notifier support
On 6/3/19 6:32 AM, Cheng-Yi Chiang wrote:
> From: Hans Verkuil
>
> Add support for HDMI hotplug and EDID notifiers, which is used to convey
> information from HDMI drivers to their CEC and audio counterparts.
>
> Based on an earlier version from Russell King:
>
> https://patchwork.kernel.org/patch/9277043/
>
> The hdmi_notifier is a reference counted object containing the HDMI state
> of an HDMI device.
>
> When a new notifier is registered the current state will be reported to
> that notifier at registration time.
>
> Based on Hans Verkuil's patch:
>
> https://patchwork.kernel.org/patch/9472521/
Erm, you are aware that this patch morphed into a CEC-specific notifier
found in drivers/media/cec/cec-notifier.c?
I don't think it makes sense to have two notifier implementations in the kernel.
The original intention was to have the notifier deal with both CEC and ASoC
notifications, but there was not enough interest for the ASoC bits at the time
and it was dropped.
I am planning changes to the cec-notifier API, I hope to work on that this
week. I'll CC you when I post those. Those might be a good starting point
to convert the cec-notifier to an hdmi-notifier as was originally intended.
I've added your colleague Dariusz Marcinkiewicz to the CC list since he's been
working on some nice cec-notifier improvements as well.
Regards,
Hans
>
> Modified by Cheng-Yi Chiang:
> - Add a section in MAINTAINER.
> - Changes connected and has_eld to bitfield of unsigned int.
> - Other minor fixes to pass checkpatch.pl --strict checks.
>
> Signed-off-by: Hans Verkuil
> Acked-by: Philipp Zabel
> Signed-off-by: Cheng-Yi Chiang
> ---
> The original patch is at
> https://lore.kernel.org/linux-arm-kernel/20161213150813.37966-2-hverk...@xs4all.nl
>
> MAINTAINERS | 6 ++
> drivers/video/Kconfig | 3 +
> drivers/video/Makefile| 1 +
> drivers/video/hdmi-notifier.c | 145 ++
> include/linux/hdmi-notifier.h | 112 ++
> 5 files changed, 267 insertions(+)
> create mode 100644 drivers/video/hdmi-notifier.c
> create mode 100644 include/linux/hdmi-notifier.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5cfbea4ce575..ffb7376f9509 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -16676,6 +16676,12 @@ W: https://linuxtv.org
> S: Maintained
> F: drivers/media/platform/vicodec/*
>
> +VIDEO FRAMEWORK
> +M: Hans Verkuil
> +L: linux-me...@vger.kernel.org
> +F: drivers/video/hdmi-notifier.*
> +S: Maintained
> +
> VIDEO MULTIPLEXER DRIVER
> M: Philipp Zabel
> L: linux-me...@vger.kernel.org
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 83d3d271ca15..000ba9bc0ae7 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -34,6 +34,9 @@ config VIDEOMODE_HELPERS
> config HDMI
> bool
>
> +config HDMI_NOTIFIERS
> + bool
> +
> endif # HAS_IOMEM
>
> if VT
> diff --git a/drivers/video/Makefile b/drivers/video/Makefile
> index df7650adede9..eff4736102ca 100644
> --- a/drivers/video/Makefile
> +++ b/drivers/video/Makefile
> @@ -1,6 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0
> obj-$(CONFIG_VGASTATE)+= vgastate.o
> obj-$(CONFIG_HDMI)+= hdmi.o
> +obj-$(CONFIG_HDMI_NOTIFIERS) += hdmi-notifier.o
>
> obj-$(CONFIG_VT) += console/
> obj-$(CONFIG_FB_STI) += console/
> diff --git a/drivers/video/hdmi-notifier.c b/drivers/video/hdmi-notifier.c
> new file mode 100644
> index ..d1eedf661648
> --- /dev/null
> +++ b/drivers/video/hdmi-notifier.c
> @@ -0,0 +1,145 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* hdmi-notifier.c - notify interested parties of (dis)connect and EDID
> + * events
> + *
> + * Copyright 2016 Russell King
> + * Copyright 2016 Cisco Systems, Inc. and/or its affiliates.
> + * All rights reserved.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static LIST_HEAD(hdmi_notifiers);
> +static DEFINE_MUTEX(hdmi_notifiers_lock);
> +
> +struct hdmi_notifier *hdmi_notifier_get(struct device *dev)
> +{
> + struct hdmi_notifier *n;
> +
> + mutex_lock(_notifiers_lock);
> + list_for_each_entry(n, _notifiers, head) {
> + if (n->dev == dev) {
> + mutex_unlock(_notifiers_lock);
> + kref_get(>kref);
> + return n;
> + }
> + }
> + n = kzalloc(sizeof(*n), GFP_KERNEL);
> + if (!n)
> + goto unlock;
> + n->dev = dev;
> + mutex_init(>lock);
> + BLOCKING_INIT_NOTIFIER_HEAD(>notifiers);
> + kref_init(>kref);
> + list_add_tail(>head, _notifiers);
> +unlock:
> + mutex_unlock(_notifiers_lock);
> + return n;
> +}
> +EXPORT_SYMBOL_GPL(hdmi_notifier_get);
> +
> +static void hdmi_notifier_release(struct kref *kref)
> +{
> + struct hdmi_notifier *n =
> + container_of(kref, struct hdmi_notifier, kref);
[PATCH] drm/radeon: avoid a possible arrary overflow
When looking up the connector type make sure the index
is valid. Avoids a later crash if we read past the end
of the array.
This bug is similar to the issue which was fixed in
commit e1718d97aa88 ("drm/amdgpu: avoid a possible
array overflow").
Signed-off-by: Young Xiao <92siuy...@gmail.com>
---
drivers/gpu/drm/radeon/radeon_atombios.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c
b/drivers/gpu/drm/radeon/radeon_atombios.c
index f422a8d..971c541 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -632,6 +632,10 @@ bool
radeon_get_atom_connector_info_from_object_table(struct drm_device *dev)
connector_object_id = con_obj_id;
}
} else {
+ if (con_obj_id >=
ARRAY_SIZE(object_connector_convert)) {
+ DRM_ERROR("invalid con_obj_id %d\n",
con_obj_id);
+ continue;
+ }
igp_lane_info = 0;
connector_type =
object_connector_convert[con_obj_id];
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 0/2] Fix meson.build on FreeBSD
There are a few small nits needed to make the meson build script work properly on FreeBSD. In short: sys/sysctl.h needs sys/types.h Use sh if bash isn't around. Also fix a typo while I'm here. [ please CC me, I'm not subscribed to dri-devel@ ] Niclas Zeising (2): meson.build: Fix typo meson.build: Fix meson script on FreeBSD meson.build | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 2/2] meson.build: Fix meson script on FreeBSD
FreeBSD requires sys/types.h for sys/sysctl.h, add it as part of the
includes when checking for headers.
Instead of splitting out the check for sys/sysctl.h from the other
header checks, just add sys/types.h to all header checks.
FreeBSD doesn't normally ship bash, try regular sh instead if we can't
find bash.
---
meson.build | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meson.build b/meson.build
index 64f0d5b1..eb55b918 100644
--- a/meson.build
+++ b/meson.build
@@ -181,7 +181,7 @@ endif
dep_m = cc.find_library('m', required : false)
foreach header : ['sys/sysctl.h', 'sys/select.h', 'alloca.h']
config.set('HAVE_' + header.underscorify().to_upper(),
-cc.compiles('#include <@0@>'.format(header), name : '@0@
works'.format(header)))
+cc.compiles('#include \n#include <@0@>'.format(header), name
: '@0@ works'.format(header)))
endforeach
if cc.has_header_symbol('sys/sysmacros.h', 'major')
config.set10('MAJOR_IN_SYSMACROS', true)
@@ -249,7 +249,7 @@ endif
with_man_pages = with_man_pages != 'false' and prog_xslt.found() and
prog_sed.found()
# Used for tests
-prog_bash = find_program('bash')
+prog_bash = find_program('bash', 'sh')
config.set10('HAVE_VISIBILITY',
cc.compiles('''int foo_hidden(void)
__attribute__((visibility(("hidden";''',
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 1/2] meson.build: Fix typo
---
meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meson.build b/meson.build
index be768afa..64f0d5b1 100644
--- a/meson.build
+++ b/meson.build
@@ -248,7 +248,7 @@ if prog_xslt.found()
endif
with_man_pages = with_man_pages != 'false' and prog_xslt.found() and
prog_sed.found()
-# Used for tets
+# Used for tests
prog_bash = find_program('bash')
config.set10('HAVE_VISIBILITY',
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/doc: More fine-tuning on userspace review requirements
On Tue, May 21, 2019 at 12:07:12PM +0300, Pekka Paalanen wrote: > On Tue, 21 May 2019 10:48:49 +0200 > Daniel Vetter wrote: > > > With Eric's patch > > > > commit ba6e798ecf320716780bb6a6088a8d17dcba1d49 > > Author: Eric Anholt > > Date: Wed Apr 24 11:56:17 2019 -0700 > > > > drm/doc: Document expectation that userspace review looks at kernel > > uAPI. > > > > there's been concerns raised that we expect userspace people to do > > in-depth kernel patch review. That's not reasonable, same way kernel > > people can't review all the userspace we have. Try to clarify > > expectations a bit more. > > > > Cc: Eric Anholt > > Cc: Pekka Paalanen > > Cc: cont...@emersion.fr > > Cc: wayland-de...@lists.freedesktop.org > > Signed-off-by: Daniel Vetter > > --- > > Documentation/gpu/drm-uapi.rst | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst > > index 05874d09820c..f368e58fb727 100644 > > --- a/Documentation/gpu/drm-uapi.rst > > +++ b/Documentation/gpu/drm-uapi.rst > > @@ -85,9 +85,9 @@ leads to a few additional requirements: > > - The userspace side must be fully reviewed and tested to the standards of > > that > >userspace project. For e.g. mesa this means piglit testcases and review > > on the > >mailing list. This is again to ensure that the new interface actually > > gets the > > - job done. The userspace-side reviewer should also provide at least an > > - Acked-by on the kernel uAPI patch indicating that they've looked at how > > the > > - kernel side is implementing the new feature being used. > > + job done. The userspace-side reviewer should also provide an Acked-by > > on the > > + kernel uAPI patch indicating that they believe the proposed uAPI is > > sound and > > + sufficiently documented and validated for userspace's consumption. > > > > - The userspace patches must be against the canonical upstream, not some > > vendor > >fork. This is to make sure that no one cheats on the review and testing > > Thank you for clarifying this. I can work with that. > > Reviewed-by: Pekka Paalanen Merged with Eric's irc-ack, thanks everyone for helping improve this text. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 00/10] Add C8, 30bpp and FP16 support to modetest
On Sun, Jun 02, 2019 at 08:40:08PM -0400, Ilia Mirkin wrote: > This series improves the pattern generation logic to support additional > formats, as well as a new "gradient" pattern (see patch comments on why > I found it useful). > > Furthermore, these formats are piped through to modetest, including the > ability to set a gamma table, which is necessary for the C8 indexed > format. > > This was tested on nouveau, and used for bring-up of the C8, XB30, and > FP16 formats on the NVIDIA hardware that supports these. Does nouveau also work with igt tests for this stuff? We do have support for interactive testing (i.e. "human pls check yourself" kind of tests) in igt, so ideally we could merge everything into one place. Long-term at least ... -Daniel > > Ilia Mirkin (10): > util: add C8 format, support it with SMPTE pattern > util: fix MAKE_RGBA macro for 10bpp modes > util: add gradient pattern > util: add fp16 format support > util: add cairo drawing for 30bpp formats when available > modetest: don't pretend that atomic mode includes a format > modetest: add an add_property_optional variant that does not print > errors > modetest: add C8 support to generate SMPTE pattern > modetest: add the ability to specify fill patterns on the commandline > modetest: add FP16 format support > > tests/modetest/buffers.c | 13 ++ > tests/modetest/modetest.c | 109 -- > tests/util/format.c | 7 + > tests/util/pattern.c | 432 +- > tests/util/pattern.h | 7 + > 5 files changed, 543 insertions(+), 25 deletions(-) > > -- > 2.21.0 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/22] docs: mark orphan documents as such
Le 30/05/2019 à 01:23, Mauro Carvalho Chehab a écrit : Sphinx doesn't like orphan documents: Documentation/accelerators/ocxl.rst: WARNING: document isn't included in any toctree Documentation/arm/stm32/overview.rst: WARNING: document isn't included in any toctree Documentation/arm/stm32/stm32f429-overview.rst: WARNING: document isn't included in any toctree Documentation/arm/stm32/stm32f746-overview.rst: WARNING: document isn't included in any toctree Documentation/arm/stm32/stm32f769-overview.rst: WARNING: document isn't included in any toctree Documentation/arm/stm32/stm32h743-overview.rst: WARNING: document isn't included in any toctree Documentation/arm/stm32/stm32mp157-overview.rst: WARNING: document isn't included in any toctree Documentation/gpu/msm-crash-dump.rst: WARNING: document isn't included in any toctree Documentation/interconnect/interconnect.rst: WARNING: document isn't included in any toctree Documentation/laptops/lg-laptop.rst: WARNING: document isn't included in any toctree Documentation/powerpc/isa-versions.rst: WARNING: document isn't included in any toctree Documentation/virtual/kvm/amd-memory-encryption.rst: WARNING: document isn't included in any toctree Documentation/virtual/kvm/vcpu-requests.rst: WARNING: document isn't included in any toctree So, while they aren't on any toctree, add :orphan: to them, in order to silent this warning. Are those files really not meant to be included in a toctree ? Shouldn't we include them in the relevant toctree instead of just shutting up Sphinx warnings ? Christophe Signed-off-by: Mauro Carvalho Chehab --- Documentation/accelerators/ocxl.rst | 2 ++ Documentation/arm/stm32/overview.rst| 2 ++ Documentation/arm/stm32/stm32f429-overview.rst | 2 ++ Documentation/arm/stm32/stm32f746-overview.rst | 2 ++ Documentation/arm/stm32/stm32f769-overview.rst | 2 ++ Documentation/arm/stm32/stm32h743-overview.rst | 2 ++ Documentation/arm/stm32/stm32mp157-overview.rst | 2 ++ Documentation/gpu/msm-crash-dump.rst| 2 ++ Documentation/interconnect/interconnect.rst | 2 ++ Documentation/laptops/lg-laptop.rst | 2 ++ Documentation/powerpc/isa-versions.rst | 2 ++ Documentation/virtual/kvm/amd-memory-encryption.rst | 2 ++ Documentation/virtual/kvm/vcpu-requests.rst | 2 ++ 13 files changed, 26 insertions(+) diff --git a/Documentation/accelerators/ocxl.rst b/Documentation/accelerators/ocxl.rst index 14cefc020e2d..b1cea19a90f5 100644 --- a/Documentation/accelerators/ocxl.rst +++ b/Documentation/accelerators/ocxl.rst @@ -1,3 +1,5 @@ +:orphan: + OpenCAPI (Open Coherent Accelerator Processor Interface) diff --git a/Documentation/arm/stm32/overview.rst b/Documentation/arm/stm32/overview.rst index 85cfc8410798..f7e734153860 100644 --- a/Documentation/arm/stm32/overview.rst +++ b/Documentation/arm/stm32/overview.rst @@ -1,3 +1,5 @@ +:orphan: + STM32 ARM Linux Overview diff --git a/Documentation/arm/stm32/stm32f429-overview.rst b/Documentation/arm/stm32/stm32f429-overview.rst index 18feda97f483..65bbb1c3b423 100644 --- a/Documentation/arm/stm32/stm32f429-overview.rst +++ b/Documentation/arm/stm32/stm32f429-overview.rst @@ -1,3 +1,5 @@ +:orphan: + STM32F429 Overview == diff --git a/Documentation/arm/stm32/stm32f746-overview.rst b/Documentation/arm/stm32/stm32f746-overview.rst index b5f4b6ce7656..42d593085015 100644 --- a/Documentation/arm/stm32/stm32f746-overview.rst +++ b/Documentation/arm/stm32/stm32f746-overview.rst @@ -1,3 +1,5 @@ +:orphan: + STM32F746 Overview == diff --git a/Documentation/arm/stm32/stm32f769-overview.rst b/Documentation/arm/stm32/stm32f769-overview.rst index 228656ced2fe..f6adac862b17 100644 --- a/Documentation/arm/stm32/stm32f769-overview.rst +++ b/Documentation/arm/stm32/stm32f769-overview.rst @@ -1,3 +1,5 @@ +:orphan: + STM32F769 Overview == diff --git a/Documentation/arm/stm32/stm32h743-overview.rst b/Documentation/arm/stm32/stm32h743-overview.rst index 3458dc00095d..c525835e7473 100644 --- a/Documentation/arm/stm32/stm32h743-overview.rst +++ b/Documentation/arm/stm32/stm32h743-overview.rst @@ -1,3 +1,5 @@ +:orphan: + STM32H743 Overview == diff --git a/Documentation/arm/stm32/stm32mp157-overview.rst b/Documentation/arm/stm32/stm32mp157-overview.rst index 62e176d47ca7..2c52cd020601 100644 --- a/Documentation/arm/stm32/stm32mp157-overview.rst +++ b/Documentation/arm/stm32/stm32mp157-overview.rst @@ -1,3 +1,5 @@ +:orphan: + STM32MP157 Overview === diff --git a/Documentation/gpu/msm-crash-dump.rst
Re: linux-next: unable to fetch the drm-intel-fixes tree
On Mon, Jun 03, 2019 at 11:04:03AM +1000, Stephen Rothwell wrote: > Hi Stephen, > > On Mon, 3 Jun 2019 08:20:51 +1000 Stephen Rothwell > wrote: > > > > Hi all, > > > > Trying to fetch the drm-intel-fixes tree today gives me this error: > > > > - > > fatal: Could not read from remote repository. > > > > Please make sure you have the correct access rights > > and the repository exists. > > - > > > > The same for drm-misc-fixes, drm-intel and drm-misc. These are all > > hosted on git://anongit.freedesktop.org/ . > > Also the drm-tegra tree. drm.git too I guess? But yeah fd.o anongit keeled over over the w/e :-( Admins not yet awake, so can't tell you what's up. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v2] drm/i915: Split off pci_driver.remove() tail to drm_driver.release()
On Thu, May 30, 2019 at 03:31:05PM +0200, Janusz Krzysztofik wrote:
> In order to support driver hot unbind, some cleanup operations, now
> performed on PCI driver remove, must be called later, after all device
> file descriptors are closed.
>
> Split out those operations from the tail of pci_driver.remove()
> callback and put them into drm_driver.release() which is called as soon
> as all references to the driver are put. As a result, those cleanups
> will be now run on last drm_dev_put(), either still called from
> pci_driver.remove() if all device file descriptors are already closed,
> or on last drm_release() file operation.
>
> Signed-off-by: Janusz Krzysztofik
> Reviewed-by: Chris Wilson
> ---
> Changelog:
> v1 -> v2:
> - defer intel_engines_cleanup() as well. (Chris)
Just an aside, we generally keep the changelog in the commit message on
dri-devel, it's occasionally useful to reference in the future. Yes that's
different from some other areas of the kernel.
-Daniel
>
> drivers/gpu/drm/i915/i915_drv.c | 17 +
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/i915_gem.c | 10 +-
> 3 files changed, 23 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 83d2eb9e74cb..8be69f84eb6d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -738,6 +738,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
>
> cleanup_gem:
> i915_gem_suspend(dev_priv);
> + i915_gem_fini_hw(dev_priv);
> i915_gem_fini(dev_priv);
> cleanup_modeset:
> intel_modeset_cleanup(dev);
> @@ -1685,7 +1686,6 @@ static void i915_driver_cleanup_hw(struct
> drm_i915_private *dev_priv)
> pci_disable_msi(pdev);
>
> pm_qos_remove_request(_priv->pm_qos);
> - i915_ggtt_cleanup_hw(dev_priv);
> }
>
> /**
> @@ -1909,6 +1909,7 @@ int i915_driver_load(struct pci_dev *pdev, const struct
> pci_device_id *ent)
>
> out_cleanup_hw:
> i915_driver_cleanup_hw(dev_priv);
> + i915_ggtt_cleanup_hw(dev_priv);
> out_cleanup_mmio:
> i915_driver_cleanup_mmio(dev_priv);
> out_runtime_pm_put:
> @@ -1960,21 +1961,29 @@ void i915_driver_unload(struct drm_device *dev)
> cancel_delayed_work_sync(_priv->gpu_error.hangcheck_work);
> i915_reset_error_state(dev_priv);
>
> - i915_gem_fini(dev_priv);
> + i915_gem_fini_hw(dev_priv);
>
> intel_power_domains_fini_hw(dev_priv);
>
> i915_driver_cleanup_hw(dev_priv);
> - i915_driver_cleanup_mmio(dev_priv);
>
> enable_rpm_wakeref_asserts(dev_priv);
> - intel_runtime_pm_cleanup(dev_priv);
> }
>
> static void i915_driver_release(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = to_i915(dev);
>
> + disable_rpm_wakeref_asserts(dev_priv);
> +
> + i915_gem_fini(dev_priv);
> +
> + i915_ggtt_cleanup_hw(dev_priv);
> + i915_driver_cleanup_mmio(dev_priv);
> +
> + enable_rpm_wakeref_asserts(dev_priv);
> + intel_runtime_pm_cleanup(dev_priv);
> +
> i915_driver_cleanup_early(dev_priv);
> i915_driver_destroy(dev_priv);
> }
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index a2664ea1395b..d08e7bd83544 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3047,6 +3047,7 @@ void i915_gem_init_mmio(struct drm_i915_private *i915);
> int __must_check i915_gem_init(struct drm_i915_private *dev_priv);
> int __must_check i915_gem_init_hw(struct drm_i915_private *dev_priv);
> void i915_gem_init_swizzling(struct drm_i915_private *dev_priv);
> +void i915_gem_fini_hw(struct drm_i915_private *dev_priv);
> void i915_gem_fini(struct drm_i915_private *dev_priv);
> int i915_gem_wait_for_idle(struct drm_i915_private *dev_priv,
> unsigned int flags, long timeout);
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 7cafd5612f71..20d3f7532cef 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4667,7 +4667,7 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
> return ret;
> }
>
> -void i915_gem_fini(struct drm_i915_private *dev_priv)
> +void i915_gem_fini_hw(struct drm_i915_private *dev_priv)
> {
> GEM_BUG_ON(dev_priv->gt.awake);
>
> @@ -4680,6 +4680,14 @@ void i915_gem_fini(struct drm_i915_private *dev_priv)
> mutex_lock(_priv->drm.struct_mutex);
> intel_uc_fini_hw(dev_priv);
> intel_uc_fini(dev_priv);
> + mutex_unlock(_priv->drm.struct_mutex);
> +
> + i915_gem_drain_freed_objects(dev_priv);
> +}
> +
> +void i915_gem_fini(struct drm_i915_private *dev_priv)
> +{
> + mutex_lock(_priv->drm.struct_mutex);
> intel_engines_cleanup(dev_priv);
> i915_gem_contexts_fini(dev_priv);
> i915_gem_fini_scratch(dev_priv);
> --
> 2.21.0
>
--
Daniel Vetter
Software Engineer,
Re: [RFC PATCH 1/1] drm/i915: Split off pci_driver.remove() tail to drm_driver.release()
On Thu, May 30, 2019 at 10:40:09AM +0100, Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-05-30 10:24:26)
> > In order to support driver hot unbind, some cleanup operations, now
> > performed on PCI driver remove, must be called later, after all device
> > file descriptors are closed.
> >
> > Split out those operations from the tail of pci_driver.remove()
> > callback and put them into drm_driver.release() which is called as soon
> > as all references to the driver are put. As a result, those cleanups
> > will be now run on last drm_dev_put(), either still called from
> > pci_driver.remove() if all device file descriptors are already closed,
> > or on last drm_release() file operation.
> >
> > Signed-off-by: Janusz Krzysztofik
> > ---
> > drivers/gpu/drm/i915/i915_drv.c | 17 +
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > drivers/gpu/drm/i915/i915_gem.c | 10 +-
> > 3 files changed, 23 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index 83d2eb9e74cb..8be69f84eb6d 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -738,6 +738,7 @@ static int i915_load_modeset_init(struct drm_device
> > *dev)
> >
> > cleanup_gem:
> > i915_gem_suspend(dev_priv);
> > + i915_gem_fini_hw(dev_priv);
> > i915_gem_fini(dev_priv);
> > cleanup_modeset:
> > intel_modeset_cleanup(dev);
> > @@ -1685,7 +1686,6 @@ static void i915_driver_cleanup_hw(struct
> > drm_i915_private *dev_priv)
> > pci_disable_msi(pdev);
> >
> > pm_qos_remove_request(_priv->pm_qos);
> > - i915_ggtt_cleanup_hw(dev_priv);
> > }
> >
> > /**
> > @@ -1909,6 +1909,7 @@ int i915_driver_load(struct pci_dev *pdev, const
> > struct pci_device_id *ent)
>
> Would it make sense to rename load/unload from the legacy drm stubs over
> to match the pci entry points?
+1 on that rename, load/unload is really terribly confusing and has
horrible semantics in the dri1 shadow attach world ...
-Daniel
>
> > out_cleanup_hw:
> > i915_driver_cleanup_hw(dev_priv);
> > + i915_ggtt_cleanup_hw(dev_priv);
> > out_cleanup_mmio:
> > i915_driver_cleanup_mmio(dev_priv);
> > out_runtime_pm_put:
> > @@ -1960,21 +1961,29 @@ void i915_driver_unload(struct drm_device *dev)
> > cancel_delayed_work_sync(_priv->gpu_error.hangcheck_work);
> > i915_reset_error_state(dev_priv);
> >
> > - i915_gem_fini(dev_priv);
> > + i915_gem_fini_hw(dev_priv);
> >
> > intel_power_domains_fini_hw(dev_priv);
> >
> > i915_driver_cleanup_hw(dev_priv);
> > - i915_driver_cleanup_mmio(dev_priv);
> >
> > enable_rpm_wakeref_asserts(dev_priv);
> > - intel_runtime_pm_cleanup(dev_priv);
> > }
> >
> > static void i915_driver_release(struct drm_device *dev)
> > {
> > struct drm_i915_private *dev_priv = to_i915(dev);
> >
> > + disable_rpm_wakeref_asserts(dev_priv);
> > +
> > + i915_gem_fini(dev_priv);
> > +
> > + i915_ggtt_cleanup_hw(dev_priv);
> > + i915_driver_cleanup_mmio(dev_priv);
> > +
> > + enable_rpm_wakeref_asserts(dev_priv);
> > + intel_runtime_pm_cleanup(dev_priv);
>
> We should really propagate the release nomenclature down and replace our
> mixed fini/cleanup. Consistency is helpful when trying to work out which
> phase the code is in.
>
> > i915_driver_cleanup_early(dev_priv);
> > i915_driver_destroy(dev_priv);
> > }
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index a2664ea1395b..d08e7bd83544 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -3047,6 +3047,7 @@ void i915_gem_init_mmio(struct drm_i915_private
> > *i915);
> > int __must_check i915_gem_init(struct drm_i915_private *dev_priv);
> > int __must_check i915_gem_init_hw(struct drm_i915_private *dev_priv);
> > void i915_gem_init_swizzling(struct drm_i915_private *dev_priv);
> > +void i915_gem_fini_hw(struct drm_i915_private *dev_priv);
> > void i915_gem_fini(struct drm_i915_private *dev_priv);
> > int i915_gem_wait_for_idle(struct drm_i915_private *dev_priv,
> >unsigned int flags, long timeout);
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 7cafd5612f71..c6a8e665a6ba 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -4667,7 +4667,7 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
> > return ret;
> > }
> >
> > -void i915_gem_fini(struct drm_i915_private *dev_priv)
> > +void i915_gem_fini_hw(struct drm_i915_private *dev_priv)
> > {
> > GEM_BUG_ON(dev_priv->gt.awake);
> >
> > @@ -4681,6 +4681,14 @@ void i915_gem_fini(struct drm_i915_private *dev_priv)
> > intel_uc_fini_hw(dev_priv);
> >
Re: [PATCH] drm/sched: Fix make htmldocs warnings.
On Thu, May 30, 2019 at 05:04:20PM +0200, Christian König wrote: > Am 29.05.19 um 21:36 schrieb Daniel Vetter: > > On Wed, May 29, 2019 at 04:43:45PM +, Grodzovsky, Andrey wrote: > > > I don't, sorry. > > Should we fix that? Seems like you do plenty of scheduler stuff, so would > > make sense I guess ... > > Reviewed-by: Christian König for the patch. > > And +1 for giving Andrey commit rights to drm-misc-next. If Andrey is on board too, pls file an issue with the legacy ssh account requests template here: https://gitlab.freedesktop.org/freedesktop/freedesktop/ And then ping on irc or here so drm-misc folks can ack -Daniel > > Christian. > > > -Daniel > > > > > Andrey > > > > > > On 5/29/19 12:42 PM, Alex Deucher wrote: > > > > On Wed, May 29, 2019 at 10:29 AM Andrey Grodzovsky > > > > wrote: > > > > > Signed-off-by: Andrey Grodzovsky > > > > Reviewed-by: Alex Deucher > > > > > > > > I'll push it to drm-misc in a minute unless you have commit rights. > > > > > > > > Alex > > > > > > > > > --- > > > > >drivers/gpu/drm/scheduler/sched_main.c | 2 ++ > > > > >1 file changed, 2 insertions(+) > > > > > > > > > > diff --git a/drivers/gpu/drm/scheduler/sched_main.c > > > > > b/drivers/gpu/drm/scheduler/sched_main.c > > > > > index 49e7d07..c1058ee 100644 > > > > > --- a/drivers/gpu/drm/scheduler/sched_main.c > > > > > +++ b/drivers/gpu/drm/scheduler/sched_main.c > > > > > @@ -353,6 +353,7 @@ EXPORT_SYMBOL(drm_sched_increase_karma); > > > > > * drm_sched_stop - stop the scheduler > > > > > * > > > > > * @sched: scheduler instance > > > > > + * @bad: job which caused the time out > > > > > * > > > > > * Stop the scheduler and also removes and frees all completed > > > > > jobs. > > > > > * Note: bad job will not be freed as it might be used later and > > > > > so it's > > > > > @@ -422,6 +423,7 @@ EXPORT_SYMBOL(drm_sched_stop); > > > > > * drm_sched_job_recovery - recover jobs after a reset > > > > > * > > > > > * @sched: scheduler instance > > > > > + * @full_recovery: proceed with complete sched restart > > > > > * > > > > > */ > > > > >void drm_sched_start(struct drm_gpu_scheduler *sched, bool > > > > > full_recovery) > > > > > -- > > > > > 2.7.4 > > > > > > > > > > ___ > > > > > dri-devel mailing list > > > > > dri-devel@lists.freedesktop.org > > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/gem_shmem: Use a writecombine mapping for ->vaddr
On Fri, May 31, 2019 at 08:46:58AM -0700, Eric Anholt wrote: > Boris Brezillon writes: > > > Right now, the BO is mapped as a cached region when ->vmap() is called > > and the underlying object is not a dmabuf. > > Doing that makes cache management a bit more complicated (you'd need > > to call dma_map/unmap_sg() on the ->sgt field everytime the BO is about > > to be passed to the GPU/CPU), so let's map the BO with writecombine > > attributes instead (as done in most drivers). > > > > Signed-off-by: Boris Brezillon > > --- > > Found this issue while working on panfrost perfcnt where the GPU dumps > > perf counter values in memory and the CPU reads them back in > > kernel-space. This patch seems to solve the unpredictable behavior I > > had. > > > > I can also go for the other option (call dma_map/unmap/_sg() when > > needed) if you think that's more appropriate. > > writecombined was the intent, and this makes kernel vmap match the > userspace mmap path. Since I missed that obviously: Where do the shmem helpers set write combined mode for userspace mmap? -Daniel > > Reviewed-by: Eric Anholt > ___ > 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
[PATCH v1 1/2] drm/komeda: Add slave pipeline support
One crtc can use two komeda_pipeline, and one works as master and as
slave. the slave pipeline doesn't have its own output and timing
ctrlr, but pre-composite the input layer data flow and then feed the
result to master. the pipeline configuration like:
slave-layer-0 \
...slave->CU
slave-layer-4 / \
\
master-layer-0 > master->CU -> ...
... /
master-layer-4 -->
Since komeda Compiz doesn't output alpha, so the slave->CU result
only can be used as bottom input when blend it with master input data
flows.
Signed-off-by: Lowry Li (Arm Technology China)
---
drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 41 --
drivers/gpu/drm/arm/display/komeda/komeda_kms.c| 10 ++
drivers/gpu/drm/arm/display/komeda/komeda_kms.h| 9 +
.../gpu/drm/arm/display/komeda/komeda_pipeline.c | 22
.../gpu/drm/arm/display/komeda/komeda_pipeline.h | 2 ++
.../drm/arm/display/komeda/komeda_pipeline_state.c | 15
drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 32 -
7 files changed, 128 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index 18c23f8..b5190a1 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -64,6 +64,10 @@ static void komeda_crtc_update_clock_ratio(struct
komeda_crtc_state *kcrtc_st)
}
/* release unclaimed pipeline resources */
+ err = komeda_release_unclaimed_resources(kcrtc->slave, kcrtc_st);
+ if (err)
+ return err;
+
err = komeda_release_unclaimed_resources(kcrtc->master, kcrtc_st);
if (err)
return err;
@@ -230,6 +234,7 @@ void komeda_crtc_handle_event(struct komeda_crtc *kcrtc,
struct komeda_crtc_state *kcrtc_st = to_kcrtc_st(crtc->state);
struct komeda_dev *mdev = kcrtc->base.dev->dev_private;
struct komeda_pipeline *master = kcrtc->master;
+ struct komeda_pipeline *slave = kcrtc->slave;
struct komeda_wb_connector *wb_conn = kcrtc->wb_conn;
struct drm_connector_state *conn_st;
@@ -241,6 +246,9 @@ void komeda_crtc_handle_event(struct komeda_crtc *kcrtc,
if (has_bit(master->id, kcrtc_st->affected_pipes))
komeda_pipeline_update(master, old->state);
+ if (slave && has_bit(slave->id, kcrtc_st->affected_pipes))
+ komeda_pipeline_update(slave, old->state);
+
conn_st = wb_conn ? wb_conn->base.base.state : NULL;
if (conn_st && conn_st->writeback_job)
drm_writeback_queue_job(_conn->base, conn_st);
@@ -266,6 +274,7 @@ void komeda_crtc_handle_event(struct komeda_crtc *kcrtc,
struct komeda_crtc_state *old_st = to_kcrtc_st(old);
struct komeda_dev *mdev = crtc->dev->dev_private;
struct komeda_pipeline *master = kcrtc->master;
+ struct komeda_pipeline *slave = kcrtc->slave;
struct completion *disable_done = >state->commit->flip_done;
struct completion temp;
int timeout;
@@ -274,6 +283,9 @@ void komeda_crtc_handle_event(struct komeda_crtc *kcrtc,
drm_crtc_index(crtc),
old_st->active_pipes, old_st->affected_pipes);
+ if (slave && has_bit(slave->id, old_st->active_pipes))
+ komeda_pipeline_disable(slave, old->state);
+
if (has_bit(master->id, old_st->active_pipes))
komeda_pipeline_disable(master, old->state);
@@ -425,6 +437,7 @@ static void komeda_crtc_reset(struct drm_crtc *crtc)
new->affected_pipes = old->active_pipes;
new->clock_ratio = old->clock_ratio;
+ new->max_slave_zorder = old->max_slave_zorder;
return >base;
}
@@ -499,7 +512,7 @@ int komeda_kms_setup_crtcs(struct komeda_kms_dev *kms,
master = mdev->pipelines[i];
crtc->master = master;
- crtc->slave = NULL;
+ crtc->slave = komeda_pipeline_get_slave(master);
if (crtc->slave)
sprintf(str, "pipe-%d", crtc->slave->id);
@@ -533,6 +546,26 @@ static int komeda_crtc_create_clock_ratio_property(struct
komeda_crtc *kcrtc)
return 0;
}
+static int komeda_crtc_create_slave_planes_property(struct komeda_crtc *kcrtc)
+{
+ struct drm_crtc *crtc = >base;
+ struct drm_property *prop;
+
+ if (kcrtc->slave_planes == 0)
+ return 0;
+
+ prop = drm_property_create_range(crtc->dev, DRM_MODE_PROP_IMMUTABLE,
+"slave_planes", 0, U32_MAX);
+ if (!prop)
+ return -ENOMEM;
+
+ drm_object_attach_property(>base, prop, kcrtc->slave_planes);
+
+ kcrtc->slave_planes_property = prop;
+
+ return 0;
+}
+
static struct drm_plane *
get_crtc_primary(struct
[PATCH v1 2/2] drm/komeda: Adds komeda_kms_drop_master
The komeda internal resources (pipelines) are shared between crtcs,
and resources release by disable_crtc. This commit is working for once
user forgot disabling crtc like app quit abnomally, and then the
resources can not be used by another crtc. Adds drop_master to
shutdown the device and make sure all the komeda resources have been
released and can be used for the next usage.
Signed-off-by: Lowry Li (Arm Technology China)
---
drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
index 8543860..647bce5 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
@@ -54,11 +54,24 @@ static irqreturn_t komeda_kms_irq_handler(int irq, void
*data)
return status;
}
+/* Komeda internal resources (pipelines) are shared between crtcs, and
resources
+ * are released by disable_crtc. But if user forget disabling crtc like app
quit
+ * abnormally, the resources can not be used by another crtc.
+ * Use drop_master to shutdown the device and make sure all the komeda
resources
+ * have been released, and can be used for the next usage.
+ */
+static void komeda_kms_drop_master(struct drm_device *dev,
+ struct drm_file *file_priv)
+{
+ drm_atomic_helper_shutdown(dev);
+}
+
static struct drm_driver komeda_kms_driver = {
.driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC |
DRIVER_PRIME | DRIVER_HAVE_IRQ,
.lastclose = drm_fb_helper_lastclose,
.irq_handler= komeda_kms_irq_handler,
+ .master_drop= komeda_kms_drop_master,
.gem_free_object_unlocked = drm_gem_cma_free_object,
.gem_vm_ops = _gem_cma_vm_ops,
.dumb_create= komeda_gem_cma_dumb_create,
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 0/2] Adds slave pipeline support
Hi, This serie aims at adding the support for slave pipeline on Komeda driver. Also adds drop_master to shutdown the device and make sure all the komeda resources shared between crtcs have been released. This patch series depends on: - https://patchwork.freedesktop.org/series/58710/ - https://patchwork.freedesktop.org/series/59000/ - https://patchwork.freedesktop.org/series/59002/ - https://patchwork.freedesktop.org/series/59747/ - https://patchwork.freedesktop.org/series/59915/ - https://patchwork.freedesktop.org/series/60083/ - https://patchwork.freedesktop.org/series/60698/ - https://patchwork.freedesktop.org/series/60856/ - https://patchwork.freedesktop.org/series/60893/ - https://patchwork.freedesktop.org/series/61370/ Regards, Lowry Lowry Li (Arm Technology China) (2): drm/komeda: Add slave pipeline support drm/komeda: Adds komeda_kms_drop_master drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 41 -- drivers/gpu/drm/arm/display/komeda/komeda_kms.c| 23 drivers/gpu/drm/arm/display/komeda/komeda_kms.h| 9 + .../gpu/drm/arm/display/komeda/komeda_pipeline.c | 22 .../gpu/drm/arm/display/komeda/komeda_pipeline.h | 2 ++ .../drm/arm/display/komeda/komeda_pipeline_state.c | 15 drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 32 - 7 files changed, 141 insertions(+), 3 deletions(-) -- 1.9.1
Re: [PATCH] of/device: add blacklist for iommu dma_ops
On Mon, Jun 3, 2019 at 4:40 AM Rob Clark wrote:
>
> On Fri, May 10, 2019 at 7:35 AM Rob Clark wrote:
> >
> > On Tue, Dec 4, 2018 at 2:29 PM Rob Herring wrote:
> > >
> > > On Sat, Dec 1, 2018 at 10:54 AM Rob Clark wrote:
> > > >
> > > > This solves a problem we see with drm/msm, caused by getting
> > > > iommu_dma_ops while we attach our own domain and manage it directly at
> > > > the iommu API level:
> > > >
> > > > [0038] user address but active_mm is swapper
> > > > Internal error: Oops: 9605 [#1] PREEMPT SMP
> > > > Modules linked in:
> > > > CPU: 7 PID: 70 Comm: kworker/7:1 Tainted: GW 4.19.3
> > > > #90
> > > > Hardware name: xxx (DT)
> > > > Workqueue: events deferred_probe_work_func
> > > > pstate: 80c9 (Nzcv daif +PAN +UAO)
> > > > pc : iommu_dma_map_sg+0x7c/0x2c8
> > > > lr : iommu_dma_map_sg+0x40/0x2c8
> > > > sp : ff80095eb4f0
> > > > x29: ff80095eb4f0 x28:
> > > > x27: ffc0f9431578 x26:
> > > > x25: x24: 0003
> > > > x23: 0001 x22: ffc0fa9ac010
> > > > x21: x20: ffc0fab40980
> > > > x19: ffc0fab40980 x18: 0003
> > > > x17: 01c4 x16: 0007
> > > > x15: 000e x14:
> > > > x13: x12: 0028
> > > > x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f
> > > > x9 : x8 : ffc0fab409a0
> > > > x7 : x6 : 0002
> > > > x5 : 0001 x4 :
> > > > x3 : 0001 x2 : 0002
> > > > x1 : ffc0f9431578 x0 :
> > > > Process kworker/7:1 (pid: 70, stack limit = 0x17d08ffb)
> > > > Call trace:
> > > >iommu_dma_map_sg+0x7c/0x2c8
> > > >__iommu_map_sg_attrs+0x70/0x84
> > > >get_pages+0x170/0x1e8
> > > >msm_gem_get_iova+0x8c/0x128
> > > >_msm_gem_kernel_new+0x6c/0xc8
> > > >msm_gem_kernel_new+0x4c/0x58
> > > >dsi_tx_buf_alloc_6g+0x4c/0x8c
> > > >msm_dsi_host_modeset_init+0xc8/0x108
> > > >msm_dsi_modeset_init+0x54/0x18c
> > > >_dpu_kms_drm_obj_init+0x430/0x474
> > > >dpu_kms_hw_init+0x5f8/0x6b4
> > > >msm_drm_bind+0x360/0x6c8
> > > >try_to_bring_up_master.part.7+0x28/0x70
> > > >component_master_add_with_match+0xe8/0x124
> > > >msm_pdev_probe+0x294/0x2b4
> > > >platform_drv_probe+0x58/0xa4
> > > >really_probe+0x150/0x294
> > > >driver_probe_device+0xac/0xe8
> > > >__device_attach_driver+0xa4/0xb4
> > > >bus_for_each_drv+0x98/0xc8
> > > >__device_attach+0xac/0x12c
> > > >device_initial_probe+0x24/0x30
> > > >bus_probe_device+0x38/0x98
> > > >deferred_probe_work_func+0x78/0xa4
> > > >process_one_work+0x24c/0x3dc
> > > >worker_thread+0x280/0x360
> > > >kthread+0x134/0x13c
> > > >ret_from_fork+0x10/0x18
> > > > Code: d284 91000725 6b17039f 5400048a (f9401f40)
> > > > ---[ end trace f22dda57f3648e2c ]---
> > > > Kernel panic - not syncing: Fatal exception
> > > > SMP: stopping secondary CPUs
> > > > Kernel Offset: disabled
> > > > CPU features: 0x0,22802a18
> > > > Memory Limit: none
> > > >
> > > > The problem is that when drm/msm does it's own iommu_attach_device(),
> > > > now the domain returned by iommu_get_domain_for_dev() is drm/msm's
> > > > domain, and it doesn't have domain->iova_cookie.
> > > >
> > > > We kind of avoided this problem prior to sdm845/dpu because the iommu
> > > > was attached to the mdp node in dt, which is a child of the toplevel
> > > > mdss node (which corresponds to the dev passed in dma_map_sg()). But
> > > > with sdm845, now the iommu is attached at the mdss level so we hit the
> > > > iommu_dma_ops in dma_map_sg().
> > > >
> > > > But auto allocating/attaching a domain before the driver is probed was
> > > > already a blocking problem for enabling per-context pagetables for the
> > > > GPU. This problem is also now solved with this patch.
> > > >
> > > > Fixes: 97890ba9289c dma-mapping: detect and configure IOMMU in
> > > > of_dma_configure
> > > > Tested-by: Douglas Anderson
> > > > Signed-off-by: Rob Clark
> > > > ---
> > > > This is an alternative/replacement for [1]. What it lacks in elegance
> > > > it makes up for in practicality ;-)
> > > >
> > > > [1] https://patchwork.freedesktop.org/patch/264930/
> > > >
> > > > drivers/of/device.c | 22 ++
> > > > 1 file changed, 22 insertions(+)
> > > >
> > > > diff --git a/drivers/of/device.c b/drivers/of/device.c
> > > > index 5957cd4fa262..15ffee00fb22 100644
> > > > --- a/drivers/of/device.c
> > > > +++ b/drivers/of/device.c
> > > > @@ -72,6 +72,14 @@ int of_device_add(struct platform_device *ofdev)
> > > > return device_add(>dev);
> > > > }
> > > >
> > > > +static const struct of_device_id iommu_blacklist[] = {
> > > > + { .compatible = "qcom,mdp4" },
> > > > +
Re: [v4 1/7] drm/mediatek: move mipi_dsi_host_register to probe
On Sat, Jun 1, 2019 at 9:26 AM Jitao Shi wrote:
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -1045,12 +1045,6 @@ static int mtk_dsi_bind(struct device *dev, struct
> device *master, void *data)
> return ret;
> }
>
> - ret = mipi_dsi_host_register(>host);
> - if (ret < 0) {
> - dev_err(dev, "failed to register DSI host: %d\n", ret);
> - goto err_ddp_comp_unregister;
> - }
> -
> @@ -1097,31 +1089,37 @@ static int mtk_dsi_probe(struct platform_device *pdev)
>
> dsi->host.ops = _dsi_ops;
> dsi->host.dev = dev;
> + dsi->dev = dev;
> + ret = mipi_dsi_host_register(>host);
> + if (ret < 0) {
> + dev_err(dev, "failed to register DSI host: %d\n", ret);
> + return ret;
> + }
(It's commented on v3, in case it's missed, sent this again.)
Since mipi_dsi_host_register() is moved from .bind to .probe,
mipi_dsi_host_unregister() should also be moved from .unbind to
.remove?
Thanks
