From: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: dan.j.williams@intel.com, linux-kernel@vger.kernel.org,
maciej.sosnowski@intel.com, ralf@linux-mips.org
Subject: Re: [PATCH] dmatest: flush and invalidate destination buffer before DMA
Date: Thu, 8 Jan 2009 09:36:03 +0100 [thread overview]
Message-ID: <20090108093603.691c1200@hskinnemoen-d830> (raw)
In-Reply-To: <20090108.134336.127659765.nemoto@toshiba-tops.co.jp>
Atsushi Nemoto wrote:
> I should argue another reason to do writeback/invalidate here in
> dmatest for non-coherent archs (not only for MIPS).
>
> The dmatest compares dstbuf outside the real DMA region to detect
> illegal overwriting. But on non-coherent archs, this comparison just
> validates contents of cache, not main memory. So dmatest might not
> able to detect illegal overwriting. Doing writeback/invalidate
> _whole_ dstbuf are before dma_async_memcpy_buf_to_buf() will make
> dmatest more strict.
>
> This is why I used DMA_BIDIRECTIONAL for whole dstbuf area rather than
> DMA_TO_DEVICE for two cache lines on both edges of the real DMA area.
>
> Doesn't this make sense?
I think it does. The dmatest driver should definitely use
DMA_BIDIRECTIONAL on the destination buffer to ensure that the poison
values are written to RAM and not just written to cache and discarded.
Now, this probably means that the destination buffer must be _unmapped_
with DMA_BIDIRECTIONAL too, which is difficult to do with the current
asymmetrical API...
In the general case, however, I think MIPS has a bug: I've seen drivers
DMA to/from tiny buffers stored inside another struct. This is legal
because the driver can guarantee that the other fields in the struct
aren't accessed in the mean time, but any fields sharing a cacheline
with the buffer must be written back before the lines are invalidated.
Haavard
next prev parent reply other threads:[~2009-01-08 8:36 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-26 15:31 Atsushi Nemoto
2008-12-27 10:10 ` Haavard Skinnemoen
2008-12-28 17:53 ` Atsushi Nemoto
2009-01-05 18:31 ` Dan Williams
2009-01-06 1:14 ` Atsushi Nemoto
2009-01-06 1:29 ` Dan Williams
2009-01-06 2:06 ` Atsushi Nemoto
2009-01-08 4:43 ` Atsushi Nemoto
2009-01-08 8:36 ` Haavard Skinnemoen [this message]
2009-01-08 17:20 ` Dan Williams
2009-01-09 8:30 ` Atsushi Nemoto
2009-01-10 0:39 ` Dan Williams
2009-01-09 11:19 ` Ralf Baechle
2009-01-09 22:27 ` Russell King
2009-01-11 18:44 ` Ralf Baechle
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=20090108093603.691c1200@hskinnemoen-d830 \
--to=haavard.skinnemoen@atmel.com \
--cc=anemo@mba.ocn.ne.jp \
--cc=dan.j.williams@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maciej.sosnowski@intel.com \
--cc=ralf@linux-mips.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
all inboxes | Powered by JetHome®