drm: etnaviv: avoid DMA API warning when importing buffers

Submitted by Russell King on Feb. 25, 2019, 10:51 a.m.

Details

Message ID E1gyDr8-0001cW-8d@rmk-PC.armlinux.org.uk
State New
Headers show
Series "drm: etnaviv: avoid DMA API warning when importing buffers" ( rev: 1 ) in DRI devel

Not browsing as part of any series.

Commit Message

Russell King Feb. 25, 2019, 10:51 a.m.
During boot, I get this kernel warning:

WARNING: CPU: 0 PID: 19001 at kernel/dma/debug.c:1301 debug_dma_map_sg+0x284/0x3dc
etnaviv etnaviv: DMA-API: mapping sg segment longer than device claims to support [len=3145728] [max=65536]
Modules linked in: ip6t_REJECT nf_reject_ipv6 ip6t_rpfilter xt_tcpudp ipt_REJECT nf_reject_ipv4 xt_conntrack ip_set nfnetlink ebtable_broute ebtable_nat ip6table_raw ip6table_nat nf_nat_ipv6 ip6table_mangle iptable_raw iptable_nat nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv4 nf_defrag_ipv6 libcrc32c iptable_mangle ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter caam_jr error snd_soc_imx_spdif imx_thermal snd_soc_imx_audmux nvmem_imx_ocotp snd_soc_sgtl5000
caam imx_sdma virt_dma coda rc_cec v4l2_mem2mem snd_soc_fsl_ssi snd_soc_fsl_spdif imx_vdoa imx_pcm_dma videobuf2_dma_contig etnaviv dw_hdmi_cec gpu_sched dw_hdmi_ahb_audio imx6q_cpufreq nfsd sch_fq_codel ip_tables x_tables
CPU: 0 PID: 19001 Comm: Xorg Not tainted 4.20.0+ #307
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[<c0019658>] (unwind_backtrace) from [<c001489c>] (show_stack+0x10/0x14)
[<c001489c>] (show_stack) from [<c07fb420>] (dump_stack+0x9c/0xd4)
[<c07fb420>] (dump_stack) from [<c00312dc>] (__warn+0xf8/0x124)
[<c00312dc>] (__warn) from [<c00313d0>] (warn_slowpath_fmt+0x38/0x48)
[<c00313d0>] (warn_slowpath_fmt) from [<c00b14e8>] (debug_dma_map_sg+0x284/0x3dc)
[<c00b14e8>] (debug_dma_map_sg) from [<c046eb40>] (drm_gem_map_dma_buf+0xc4/0x13c)
[<c046eb40>] (drm_gem_map_dma_buf) from [<c04c3314>] (dma_buf_map_attachment+0x38/0x5c)
[<c04c3314>] (dma_buf_map_attachment) from [<c046e728>] (drm_gem_prime_import_dev+0x74/0x104)
[<c046e728>] (drm_gem_prime_import_dev) from [<c046e5bc>] (drm_gem_prime_fd_to_handle+0x84/0x17c)
[<c046e5bc>] (drm_gem_prime_fd_to_handle) from [<c046edd0>] (drm_prime_fd_to_handle_ioctl+0x38/0x4c)
[<c046edd0>] (drm_prime_fd_to_handle_ioctl) from [<c0460efc>] (drm_ioctl_kernel+0x90/0xc8)
[<c0460efc>] (drm_ioctl_kernel) from [<c0461114>] (drm_ioctl+0x1e0/0x3b0)
[<c0461114>] (drm_ioctl) from [<c01cae20>] (do_vfs_ioctl+0x90/0xa48)
[<c01cae20>] (do_vfs_ioctl) from [<c01cb80c>] (ksys_ioctl+0x34/0x60)
[<c01cb80c>] (ksys_ioctl) from [<c0009000>] (ret_fast_syscall+0x0/0x28)
Exception stack(0xd81a9fa8 to 0xd81a9ff0)
9fa0:                   b6c69c88 bec613f8 00000009 c00c642e bec613f8 b86c4600
9fc0: b6c69c88 bec613f8 c00c642e 00000036 012762e0 01276348 00000300 012d91f8
9fe0: b6989f18 bec613dc b697185c b667be5c
irq event stamp: 47905
hardirqs last  enabled at (47913): [<c0098824>] console_unlock+0x46c/0x680
hardirqs last disabled at (47922): [<c0098470>] console_unlock+0xb8/0x680
softirqs last  enabled at (47754): [<c000a484>] __do_softirq+0x344/0x540
softirqs last disabled at (47701): [<c0038700>] irq_exit+0x124/0x144
---[ end trace af477747acbcc642 ]---

The reason is the contiguous buffer exceeds the default maximum segment
size of 64K as specified by dma_get_max_seg_size() in
linux/dma-mapping.h.  Fix this by providing our own segment size, which
is set to 2GiB to cover the window found in MMUv1 GPUs.

Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
Patch against v4.20.

 drivers/gpu/drm/etnaviv/etnaviv_drv.c | 4 ++++
 drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 +
 2 files changed, 5 insertions(+)

Patch hide | download patch | download mbox

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 4713885012ab..e414f284f424 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -527,6 +527,9 @@  static int etnaviv_bind(struct device *dev)
 	}
 	drm->dev_private = priv;
 
+	dev->dma_parms = &priv->dma_parms;
+	dma_set_max_seg_size(dev, SZ_2G);
+
 	mutex_init(&priv->gem_lock);
 	INIT_LIST_HEAD(&priv->gem_list);
 	priv->num_gpus = 0;
@@ -564,6 +567,7 @@  static void etnaviv_unbind(struct device *dev)
 
 	component_unbind_all(dev, drm);
 
+	dev->dma_parms = NULL;
 	drm->dev_private = NULL;
 	kfree(priv);
 
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
index 8d02d1b7dcf5..b2930d1fe97c 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
@@ -43,6 +43,7 @@  struct etnaviv_file_private {
 
 struct etnaviv_drm_private {
 	int num_gpus;
+	struct device_dma_parameters dma_parms;
 	struct etnaviv_gpu *gpu[ETNA_MAX_PIPES];
 
 	/* list of GEM objects: */

Comments

Ping.

On Mon, Feb 25, 2019 at 10:54:23AM +0000, Russell King - ARM Linux admin wrote:
> On Mon, Feb 25, 2019 at 10:51:30AM +0000, Russell King wrote:
> > During boot, I get this kernel warning:
> > 
> > WARNING: CPU: 0 PID: 19001 at kernel/dma/debug.c:1301 debug_dma_map_sg+0x284/0x3dc
> > etnaviv etnaviv: DMA-API: mapping sg segment longer than device claims to support [len=3145728] [max=65536]
> > Modules linked in: ip6t_REJECT nf_reject_ipv6 ip6t_rpfilter xt_tcpudp ipt_REJECT nf_reject_ipv4 xt_conntrack ip_set nfnetlink ebtable_broute ebtable_nat ip6table_raw ip6table_nat nf_nat_ipv6 ip6table_mangle iptable_raw iptable_nat nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv4 nf_defrag_ipv6 libcrc32c iptable_mangle ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter caam_jr error snd_soc_imx_spdif imx_thermal snd_soc_imx_audmux nvmem_imx_ocotp snd_soc_sgtl5000
> > caam imx_sdma virt_dma coda rc_cec v4l2_mem2mem snd_soc_fsl_ssi snd_soc_fsl_spdif imx_vdoa imx_pcm_dma videobuf2_dma_contig etnaviv dw_hdmi_cec gpu_sched dw_hdmi_ahb_audio imx6q_cpufreq nfsd sch_fq_codel ip_tables x_tables
> > CPU: 0 PID: 19001 Comm: Xorg Not tainted 4.20.0+ #307
> > Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> > [<c0019658>] (unwind_backtrace) from [<c001489c>] (show_stack+0x10/0x14)
> > [<c001489c>] (show_stack) from [<c07fb420>] (dump_stack+0x9c/0xd4)
> > [<c07fb420>] (dump_stack) from [<c00312dc>] (__warn+0xf8/0x124)
> > [<c00312dc>] (__warn) from [<c00313d0>] (warn_slowpath_fmt+0x38/0x48)
> > [<c00313d0>] (warn_slowpath_fmt) from [<c00b14e8>] (debug_dma_map_sg+0x284/0x3dc)
> > [<c00b14e8>] (debug_dma_map_sg) from [<c046eb40>] (drm_gem_map_dma_buf+0xc4/0x13c)
> > [<c046eb40>] (drm_gem_map_dma_buf) from [<c04c3314>] (dma_buf_map_attachment+0x38/0x5c)
> > [<c04c3314>] (dma_buf_map_attachment) from [<c046e728>] (drm_gem_prime_import_dev+0x74/0x104)
> > [<c046e728>] (drm_gem_prime_import_dev) from [<c046e5bc>] (drm_gem_prime_fd_to_handle+0x84/0x17c)
> > [<c046e5bc>] (drm_gem_prime_fd_to_handle) from [<c046edd0>] (drm_prime_fd_to_handle_ioctl+0x38/0x4c)
> > [<c046edd0>] (drm_prime_fd_to_handle_ioctl) from [<c0460efc>] (drm_ioctl_kernel+0x90/0xc8)
> > [<c0460efc>] (drm_ioctl_kernel) from [<c0461114>] (drm_ioctl+0x1e0/0x3b0)
> > [<c0461114>] (drm_ioctl) from [<c01cae20>] (do_vfs_ioctl+0x90/0xa48)
> > [<c01cae20>] (do_vfs_ioctl) from [<c01cb80c>] (ksys_ioctl+0x34/0x60)
> > [<c01cb80c>] (ksys_ioctl) from [<c0009000>] (ret_fast_syscall+0x0/0x28)
> > Exception stack(0xd81a9fa8 to 0xd81a9ff0)
> > 9fa0:                   b6c69c88 bec613f8 00000009 c00c642e bec613f8 b86c4600
> > 9fc0: b6c69c88 bec613f8 c00c642e 00000036 012762e0 01276348 00000300 012d91f8
> > 9fe0: b6989f18 bec613dc b697185c b667be5c
> > irq event stamp: 47905
> > hardirqs last  enabled at (47913): [<c0098824>] console_unlock+0x46c/0x680
> > hardirqs last disabled at (47922): [<c0098470>] console_unlock+0xb8/0x680
> > softirqs last  enabled at (47754): [<c000a484>] __do_softirq+0x344/0x540
> > softirqs last disabled at (47701): [<c0038700>] irq_exit+0x124/0x144
> > ---[ end trace af477747acbcc642 ]---
> > 
> > The reason is the contiguous buffer exceeds the default maximum segment
> > size of 64K as specified by dma_get_max_seg_size() in
> > linux/dma-mapping.h.  Fix this by providing our own segment size, which
> > is set to 2GiB to cover the window found in MMUv1 GPUs.
> > 
> > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> 
> Fixes: 78c47830a5cb ("dma-debug: check scatterlist segments")
> 
> not really that there's a problem with that commit, but it is where the
> warning was introduced.
> 
> > ---
> > Patch against v4.20.
> > 
> >  drivers/gpu/drm/etnaviv/etnaviv_drv.c | 4 ++++
> >  drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 +
> >  2 files changed, 5 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> > index 4713885012ab..e414f284f424 100644
> > --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> > +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> > @@ -527,6 +527,9 @@ static int etnaviv_bind(struct device *dev)
> >  	}
> >  	drm->dev_private = priv;
> >  
> > +	dev->dma_parms = &priv->dma_parms;
> > +	dma_set_max_seg_size(dev, SZ_2G);
> > +
> >  	mutex_init(&priv->gem_lock);
> >  	INIT_LIST_HEAD(&priv->gem_list);
> >  	priv->num_gpus = 0;
> > @@ -564,6 +567,7 @@ static void etnaviv_unbind(struct device *dev)
> >  
> >  	component_unbind_all(dev, drm);
> >  
> > +	dev->dma_parms = NULL;
> >  	drm->dev_private = NULL;
> >  	kfree(priv);
> >  
> > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> > index 8d02d1b7dcf5..b2930d1fe97c 100644
> > --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> > +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> > @@ -43,6 +43,7 @@ struct etnaviv_file_private {
> >  
> >  struct etnaviv_drm_private {
> >  	int num_gpus;
> > +	struct device_dma_parameters dma_parms;
> >  	struct etnaviv_gpu *gpu[ETNA_MAX_PIPES];
> >  
> >  	/* list of GEM objects: */
> > -- 
> > 2.7.4
> > 
> > 
> 
> -- 
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up
Hi Russell,

On Sat, May 18, 2019 at 2:51 PM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> Ping.

This patch is present in Lucas' pull request:
https://lists.freedesktop.org/archives/etnaviv/2019-May/002490.html
On Sat, May 18, 2019 at 06:04:42PM -0300, Fabio Estevam wrote:
> Hi Russell,
> 
> On Sat, May 18, 2019 at 2:51 PM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> >
> > Ping.
> 
> This patch is present in Lucas' pull request:
> https://lists.freedesktop.org/archives/etnaviv/2019-May/002490.html

I'm wondering why it didn't make 5.1 since it's a regression.
Hi Russell,

Am Samstag, den 18.05.2019, 22:37 +0100 schrieb Russell King - ARM
Linux admin:
> On Sat, May 18, 2019 at 06:04:42PM -0300, Fabio Estevam wrote:
> > Hi Russell,
> > 
> > On Sat, May 18, 2019 at 2:51 PM Russell King - ARM Linux admin
> > <linux@armlinux.org.uk> wrote:
> > > 
> > > Ping.
> > 
> > This patch is present in Lucas' pull request:
> > https://lists.freedesktop.org/archives/etnaviv/2019-May/002490.html
> 
> I'm wondering why it didn't make 5.1 since it's a regression.

I didn't see the importance to put this into fixes, as it's getting rid
of a warning which will only be present when a debug option is enabled.
So it should be invisible to most users and it doesn't regress
functionality.

Regards,
Lucas
On Wed, May 22, 2019 at 12:04:27PM +0200, Lucas Stach wrote:
> Hi Russell,
> 
> Am Samstag, den 18.05.2019, 22:37 +0100 schrieb Russell King - ARM
> Linux admin:
> > On Sat, May 18, 2019 at 06:04:42PM -0300, Fabio Estevam wrote:
> > > Hi Russell,
> > > 
> > > On Sat, May 18, 2019 at 2:51 PM Russell King - ARM Linux admin
> > > <linux@armlinux.org.uk> wrote:
> > > > 
> > > > Ping.
> > > 
> > > This patch is present in Lucas' pull request:
> > > https://lists.freedesktop.org/archives/etnaviv/2019-May/002490.html
> > 
> > I'm wondering why it didn't make 5.1 since it's a regression.
> 
> I didn't see the importance to put this into fixes, as it's getting rid
> of a warning which will only be present when a debug option is enabled.
> So it should be invisible to most users and it doesn't regress
> functionality.

That depends on your point of view, how you use the kernel, and what
you're using the kernel for.  If you're trying to use dma debugging
(which should always be enabled when doing driver development) and
you have a subsystem that keeps triggering it, then it is a serious
problem.

Given that we want developers to have such options on, having false
complaints is counter-productive.