Partial cacheline flush problems on ARM and MIPS
Tim Kientzle
tim at kientzle.com
Sun Aug 26 18:53:47 UTC 2012
On Sun, Aug 26, 2012 at 12:42 PM, Ian Lepore
<freebsd at damnhippie.dyndns.org> wrote:
> On Thu, 2012-08-23 at 22:00 -0600, Warner Losh wrote:
>> The bottom line is that you can't mix things like that when cache
>> lines are involved.
>>
> …. I think we should more explicitly spell out
> what the appropriate sequences are.
As someone who is just tinkering with driver code for
the first time, I applaud any attempts to better document
this area! ;-)
> In particular:
>
> * The PRE and POST operations must occur in pairs; a PREREAD must
> be followed eventually by a POSTREAD and a PREWRITE must be
> followed by a POSTWRITE.
> * The CPU is not allowed to access the mapped memory after a PRE
> sync and before the corresponding POST sync.
> * The DMA hardware is not allowed to access the mapped memory
> after a POST sync and before the next PRE sync.
These rules sound reasonable. Good documentation might
also give examples of what the PRE/POST operations might entail
(e.g., from the preceding discussion, it sounds like PREREAD
and PREWRITE require at least a partial cache flush on ARM).
That helps folks who are coming to the docs with some hardware
background.
> * Read and write sync operators may be combined in a single call,
> PRE and POST operators may not be. E.G., PREREAD|PREWRITE is
> allowed, PREREAD|POSTREAD is not. We should note that while
> read and write operations may be combined, on some platforms
> PREREAD|PREWRITE is needlessly expensive when only a read is
> being performed.
PREREAD|POSTREAD doesn't sound useful to me, but
why would it be explicitly forbidden?
Would you also forbid POSTREAD|PREWRITE?
(For a buffer that has just completed a DMA read
and is going to be immediately used for a DMA write?)
Tim
More information about the freebsd-arm
mailing list