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