From: vigneshr@ti.com (Vignesh R)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 4/6] spi: davinci: flush caches when performing DMA
Date: Mon, 20 Feb 2017 12:25:33 +0530 [thread overview]
Message-ID: <0f3607fd-4542-be92-da2e-b2da6f8ac26f@ti.com> (raw)
In-Reply-To: <20170217120749.GF21222@n2100.armlinux.org.uk>
On Friday 17 February 2017 05:37 PM, Russell King - ARM Linux wrote:
[...]
> SPI is rather another special case - rather than SPI following the
> established mechanism of passing data references via scatterlists or
> similar, it also passes them via virtual addresses, which means SPI
> can directly access the vmalloc area when performing PIO. This
> really makes the problem more complex, because it means that if you
> do have a SPI driver that does that, it's going to be
> reading/writing direct from vmalloc space.
>
> That's not a problem as long as the data is only accessed via
> vmalloc space, but it will definitely go totally wrong if the data
> is subsequently mapped into userspace.
>
> The other important thing to realise is that the interfaces in
> cachetlb.txt assume that it's the lowmem mapping that will be
> accessed, and the IO device will push that data out to physical
> memory (either via the DMA API, or flush_kernel_dcache_page()).
> That's not true of SPI, as it passes virtual addresses around.
>
> So... overall, I'm not sure that this problem is properly solvable
> given SPIs insistance on passing virtual addresses and the
> differences in this area between SPI and block.
>
I am debugging another issue with UBIFS wherein pages allocated by
vmalloc are in highmem region that are not addressable using 32 bit
addresses and is backed by LPAE. So, a 32 bit DMA cannot access these
buffers at all.
When dma_map_sg() is called to map these pages by spi_map_buf() the
physical address is just truncated to 32 bit in pfn_to_dma() (as part of
dma_map_sg() call). This results in random crashes as DMA starts
accessing random memory during SPI read.
Given, the above problem and also issue surrounding VIVT caches, I am
thinking of may be using pre-allocated fixed size bounce buffer to
handle buffers not in lowmem mapping.
I have tried using 64KB pre-allocated buffer on TI DRA74 EVM with QSPI
running at 76.8MHz and do not see any significant degradation in
performance with UBIFS. Mainly because UBIFS seems to use vmalloc'd
buffers only during initial preparing and mounting phase and not during
file read/write.
So, is it an acceptable solution to modify spi_map_buf() to use bounce
buffer when buffer does not belong to lowmem region?
--
Regards
Vignesh
next prev parent reply other threads:[~2017-02-20 6:55 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-17 10:38 [PATCH v2 0/6] Enable DMA for daVinci SPI controller Frode Isaksen
2017-02-17 10:38 ` [PATCH v2 1/6] spi: davinci: Use SPI framework to handle DMA mapping Frode Isaksen
2017-02-19 16:29 ` Mark Brown
2017-02-17 10:38 ` [PATCH v2 2/6] spi: davinci: enable DMA when channels are defined in DT Frode Isaksen
2017-02-19 16:30 ` Mark Brown
2017-02-17 10:38 ` [PATCH v2 3/6] spi: davinci: use rx buffer as dummy tx buffer Frode Isaksen
2017-03-15 19:37 ` Applied "spi: davinci: use rx buffer as dummy tx buffer" to the spi tree Mark Brown
2017-02-17 10:38 ` [PATCH v2 4/6] spi: davinci: flush caches when performing DMA Frode Isaksen
2017-02-17 10:57 ` Vignesh R
2017-02-17 11:22 ` Russell King - ARM Linux
2017-02-17 11:36 ` Frode Isaksen
2017-02-17 12:07 ` Russell King - ARM Linux
2017-02-17 17:45 ` Frode Isaksen
2017-02-20 6:55 ` Vignesh R [this message]
2017-02-20 9:26 ` Frode Isaksen
2017-02-20 9:47 ` Vignesh R
2017-02-20 10:34 ` Frode Isaksen
2017-02-20 11:27 ` Vignesh R
2017-02-20 15:49 ` Frode Isaksen
2017-02-21 5:08 ` Vignesh R
2017-02-17 10:38 ` [PATCH v2 5/6] spi: davinci: do not use DMA if transfer length is less than 16 Frode Isaksen
2017-02-17 16:37 ` Arnd Bergmann
2017-02-17 16:43 ` Frode Isaksen
2017-02-17 16:55 ` Arnd Bergmann
2017-02-17 10:38 ` [PATCH v2 6/6] spi: loopback-test: add option to use vmalloc'ed buffers Frode Isaksen
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=0f3607fd-4542-be92-da2e-b2da6f8ac26f@ti.com \
--to=vigneshr@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox