[coreboot-gerrit] Patch merged into coreboot/master: 509c37e libpayload: Make EHCI driver cache-aware

the following patch was just integrated into master:
commit 509c37e7507c6d68019abb096df0374858f541f5
Author: Julius Werner 
Date:   Wed Aug 28 12:29:28 2013 -0700

libpayload: Make EHCI driver cache-aware

This patch makes the EHCI driver work on ARM platforms which usually do
    not support automatic cache snooping. It uses the new DMA memory
    mechanism (which needs to be correctly set up in the Coreboot mainboard
    code) to allocate all EHCI-internal communication structures in
    cache-coherent memory, and cleans/invalidates the externally supplied
    transfer buffers in Bulk and Control functions with explicit calls as
    necessary.

Old-Change-Id: Ie8a62545d905b7a4fdd2a56b9405774be69779e5
    Signed-off-by: Julius Werner 
    Reviewed-on: https://chromium-review.googlesource.com/167339
    (cherry picked from commit 322338934add36a5372ffe7d2a45e61a4fdd4a54)

libpayload: ehci: Cache management is hard, let's go copying...

It turns out that my previous commit to make the EHCI stack cache aware
    on ARM devices wasn't quite correct, and the problem is actually much
    trickier than I thought. After having some fun with more weird transfer
    problems that appear/disappear based on stack alignment, this is my
    current worst-case threat model that any cache managing implementation
    would need to handle correctly:

Some upper layer calls ehci_bulk() with a transfer buffer on its stack.
    Due to stack alignment, it happens to start just at the top of a cache
    line, so up to 64 - 4 bytes of ehci_bulk's stack will share that line.
    ehci_bulk() calls dcache_clean() and initializes the USB transfer.
    Between that point and the call to dcache_invalidate() at the end of
    ehci_bulk(), any access to the stack variables in that cache line (even
    a speculative prefetch) will refetch the line into the cache. Afterwards
    any other access to a random memory location that just happens to get
    aliased to the same cache line may evict it again, causing the processor
    to write out stale data to the transfer buffer and possibly overwrite
    data that has already been received over USB.

In short, any dcache_clean/dcache_invalidate-based implementation that
    preserves correctness while allowing any arbitrary (non cache-aligned)
    memory location as a transfer buffer is presumed to be impossible.
    Instead, this patch causes all transfer data to be copied to/from a
    cache-coherent bounce buffer. It will still transfer directly if the
    supplied buffer is already cache-coherent, which can be used by callers
    to optimize their transfers (and is true by default on x86).

Old-Change-Id: I112908410bdbc8ca028d44f2f5d388c529f8057f
    Signed-off-by: Julius Werner 
    Reviewed-on: https://chromium-review.googlesource.com/169231
    Reviewed-by: Stefan Reinauer 
    (cherry picked from commit 702dc50f1d56fe206442079fa443437f4336daed)

Squashed the initial commit and a follow up fix.

Change-Id: Idf7e5aa855b4f0221f82fa380a76049f273e4c88
    Signed-off-by: Isaac Christensen 
    Reviewed-on: http://review.coreboot.org/6633
    Tested-by: build bot (Jenkins)
    Reviewed-by: Stefan Reinauer

See http://review.coreboot.org/6633 for details.

-gerrit