All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Franklin S Cooper Jr <fcooper@ti.com>
Cc: nsekhar@ti.com, dwmw2@infradead.org, computersforpeace@gmail.com,
	rogerq@ti.com, tony@atomide.com, devicetree@vger.kernel.org,
	linux-omap@vger.kernel.org, linux-mtd@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 6/7] mtd: nand: omap2: Fix high memory dma prefetch transfer
Date: Mon, 21 Mar 2016 16:04:43 +0100	[thread overview]
Message-ID: <20160321160443.0a4165d1@bbrezillon> (raw)
In-Reply-To: <1457654203-20856-7-git-send-email-fcooper@ti.com>

Hi Franklin,

On Thu, 10 Mar 2016 17:56:42 -0600
Franklin S Cooper Jr <fcooper@ti.com> wrote:

> Based on DMA documentation and testing using high memory buffer when
> doing dma transfers can lead to various issues including kernel
> panics.

I guess it all comes from the vmalloced buffer case, which are not
guaranteed to be physically contiguous (one of the DMA requirement,
unless you have an iommu).

> 
> To workaround this simply use cpu copy. The amount of high memory
> buffers used are very uncommon so no noticeable performance hit should
> be seen.

Hm, that's not necessarily true. UBI and UBIFS allocate their buffers
using vmalloc (vmalloced buffers fall in the high_memory region), and
those are likely to be dis-contiguous if you have NANDs with pages > 4k.

I recently posted patches to ease sg_table creation from any kind of
virtual address [1][2]. Can you try them and let me know if it fixes
your problem?

Thanks,

Boris

[1]https://lkml.org/lkml/2016/3/8/276
[2]https://lkml.org/lkml/2016/3/8/277


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
To: Franklin S Cooper Jr <fcooper-l0cyMroinI0@public.gmane.org>
Cc: nsekhar-l0cyMroinI0@public.gmane.org,
	dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org,
	computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	rogerq-l0cyMroinI0@public.gmane.org,
	tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v4 6/7] mtd: nand: omap2: Fix high memory dma prefetch transfer
Date: Mon, 21 Mar 2016 16:04:43 +0100	[thread overview]
Message-ID: <20160321160443.0a4165d1@bbrezillon> (raw)
In-Reply-To: <1457654203-20856-7-git-send-email-fcooper-l0cyMroinI0@public.gmane.org>

Hi Franklin,

On Thu, 10 Mar 2016 17:56:42 -0600
Franklin S Cooper Jr <fcooper-l0cyMroinI0@public.gmane.org> wrote:

> Based on DMA documentation and testing using high memory buffer when
> doing dma transfers can lead to various issues including kernel
> panics.

I guess it all comes from the vmalloced buffer case, which are not
guaranteed to be physically contiguous (one of the DMA requirement,
unless you have an iommu).

> 
> To workaround this simply use cpu copy. The amount of high memory
> buffers used are very uncommon so no noticeable performance hit should
> be seen.

Hm, that's not necessarily true. UBI and UBIFS allocate their buffers
using vmalloc (vmalloced buffers fall in the high_memory region), and
those are likely to be dis-contiguous if you have NANDs with pages > 4k.

I recently posted patches to ease sg_table creation from any kind of
virtual address [1][2]. Can you try them and let me know if it fixes
your problem?

Thanks,

Boris

[1]https://lkml.org/lkml/2016/3/8/276
[2]https://lkml.org/lkml/2016/3/8/277


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2016-03-21 15:04 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-10 23:56 [PATCH v4 0/7] mtd: nand: Fix support for NAND DMA prefetch Franklin S Cooper Jr
2016-03-10 23:56 ` Franklin S Cooper Jr
2016-03-10 23:56 ` [PATCH v4 1/7] ARM: OMAP2+: gpmc-nand: Set omap2-nand's parent dev to GPMC dev Franklin S Cooper Jr
2016-03-10 23:56   ` Franklin S Cooper Jr
2016-03-11 13:52   ` Roger Quadros
2016-03-11 13:52     ` Roger Quadros
2016-03-11 15:39     ` Franklin S Cooper Jr.
2016-03-11 15:39       ` Franklin S Cooper Jr.
2016-03-14  9:15       ` Roger Quadros
2016-03-14  9:15         ` Roger Quadros
2016-04-13 19:40         ` Tony Lindgren
2016-03-10 23:56 ` [PATCH v4 2/7] ARM: dts: am33xx: Fix GPMC dma properties Franklin S Cooper Jr
2016-03-10 23:56   ` Franklin S Cooper Jr
2016-03-11 13:56   ` Roger Quadros
2016-03-11 13:56     ` Roger Quadros
2016-03-11 13:58   ` Peter Ujfalusi
2016-03-11 13:58     ` Peter Ujfalusi
2016-04-13 19:45     ` Tony Lindgren
2016-03-10 23:56 ` [PATCH v4 3/7] ARM: dts: am437x: " Franklin S Cooper Jr
2016-03-11 13:56   ` Roger Quadros
2016-03-11 13:56     ` Roger Quadros
2016-03-11 14:03   ` Peter Ujfalusi
2016-03-11 14:03     ` Peter Ujfalusi
2016-03-10 23:56 ` [PATCH v4 4/7] mtd: nand: omap2: Support parsing dma channel information from DT Franklin S Cooper Jr
2016-03-10 23:56 ` [PATCH v4 5/7] mtd: nand: omap2: Start dma request before enabling prefetch Franklin S Cooper Jr
2016-03-10 23:56 ` [PATCH v4 6/7] mtd: nand: omap2: Fix high memory dma prefetch transfer Franklin S Cooper Jr
2016-03-21 15:04   ` Boris Brezillon [this message]
2016-03-21 15:04     ` Boris Brezillon
2016-04-13 20:08     ` Franklin S Cooper Jr.
2016-04-13 20:08       ` Franklin S Cooper Jr.
2016-04-13 20:24       ` Boris Brezillon
2016-04-13 20:24         ` Boris Brezillon
2016-04-13 21:11         ` Franklin S Cooper Jr.
2016-04-13 21:11           ` Franklin S Cooper Jr.
2016-03-10 23:56 ` [PATCH v4 7/7] ARM: OMAP2+: Update GPMC and NAND DT binding documentation Franklin S Cooper Jr
2016-03-18 19:13   ` Rob Herring
2016-03-18 19:13     ` Rob Herring
2016-03-11 14:02 ` [PATCH v4 0/7] mtd: nand: Fix support for NAND DMA prefetch Roger Quadros
2016-03-11 14:02   ` Roger Quadros
2016-03-14 14:17   ` Franklin S Cooper Jr.
2016-03-14 14:17     ` Franklin S Cooper Jr.

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160321160443.0a4165d1@bbrezillon \
    --to=boris.brezillon@free-electrons.com \
    --cc=computersforpeace@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dwmw2@infradead.org \
    --cc=fcooper@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=nsekhar@ti.com \
    --cc=rogerq@ti.com \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.