From: mike.looijmans@topic.nl (Mike Looijmans)
To: linux-arm-kernel@lists.infradead.org
Subject: dma_alloc_coherent versus streaming DMA, neither works satisfactory
Date: Fri, 1 May 2015 08:08:18 +0200 [thread overview]
Message-ID: <55431852.2000302@topic.nl> (raw)
In-Reply-To: <2309938.la6bU0Xy8o@wuerfel>
?On 30-04-15 15:54, Arnd Bergmann wrote:
> On Thursday 30 April 2015 15:50:15 Mike Looijmans wrote:
>>
>> Just to give you a status update, I tried that too (by adding a
>> dma_mmap_coherent variant that omits the "prot" change, and some printks to
>> verify that it actually does as expected).
>>
>> Current status is that the ACP behaves exactly like the HP port, which it
>> should not do. If I send data from logic via the ACP port through the L2
>> cache, using a version of dma_sync that just invalidates the cache could
>> (should?) result in data corruption. Instead, the data gets corrupted only if
>> you do not invalidate the line. This is what the (non-coherent) HP port
>> behaves like, as it writes directly to DDR.
>>
>> Currently I'm assuming that the tools did something wrong in the bitstream,
>> for example, wiring the "AWCACHE" and similar signals on the ACP to logic "0"
>> instead of "1" while claiming to have wired them to "1" in the UI. A bug like
>> that would also explain the behaviour I'm seeing now.
>>
>> I'll let you know once I find out more.
>
> Ok, maybe you have to configure the SCU to include the ACP in the
> cache coherency? That might not be done by default. I don't really
> know anything about the SCU or the ACP, so I'm just taking wild
> guesses here.
The issue seems to be in these signals, the tool falsely claimed to have them
set high, but it actually only sets half of them, which thus has no effect at
all. I'll be able to test that in an hour or so once the bitstream is ready.
Interestingly, the coherency is not a property of the port or of the device
itself, it is a property of the DMA transaction. One single master on this
post can do both coherent and non-coherent transfers.
Now there's an interesting challenge, since the kernel appears to assume that
one device can only do one type. My 'hardware' actually has multiple masters,
which could potentially be tied to different ports or busses.
Kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijmans at topicproducts.com
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
next prev parent reply other threads:[~2015-05-01 6:08 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-23 11:52 dma_alloc_coherent versus streaming DMA, neither works satisfactory Mike Looijmans
2015-04-23 12:32 ` Arnd Bergmann
2015-04-23 13:05 ` Mike Looijmans
2015-04-29 8:47 ` Mike Looijmans
2015-04-29 9:01 ` Arnd Bergmann
2015-04-29 9:17 ` Russell King - ARM Linux
2015-04-29 9:47 ` Mike Looijmans
2015-04-29 10:07 ` Arnd Bergmann
2015-04-29 10:33 ` Mike Looijmans
2015-04-29 10:41 ` Arnd Bergmann
2015-04-29 12:49 ` Mike Looijmans
2015-04-29 13:13 ` Arnd Bergmann
2015-04-30 13:50 ` Mike Looijmans
2015-04-30 13:54 ` Arnd Bergmann
2015-05-01 6:08 ` Mike Looijmans [this message]
2015-05-01 7:01 ` Mike Looijmans
2015-05-07 11:18 ` Mike Looijmans
2015-05-07 11:56 ` Arnd Bergmann
2015-05-07 13:21 ` Daniel Drake
2015-05-07 13:31 ` Mike Looijmans
2015-05-07 14:08 ` Mike Looijmans
2015-05-07 14:30 ` Russell King - ARM Linux
2015-05-08 5:55 ` Mike Looijmans
2015-05-08 7:54 ` Arnd Bergmann
2015-05-08 8:31 ` Mike Looijmans
2015-05-08 13:19 ` Arnd Bergmann
2015-05-08 14:18 ` Mike Looijmans
2015-05-08 14:27 ` Arnd Bergmann
2015-05-08 11:10 ` Russell King - ARM Linux
2015-05-08 12:17 ` Mike Looijmans
2015-04-29 11:09 ` Mike Looijmans
2015-04-29 12:35 ` Arnd Bergmann
2015-04-29 12:52 ` Mike Looijmans
2015-04-29 12:54 ` Arnd Bergmann
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=55431852.2000302@topic.nl \
--to=mike.looijmans@topic.nl \
--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;
as well as URLs for NNTP newsgroup(s).