[Top] [All Lists]

Re: [PATCH resend 5/9] MIPS: sync after cacheflush

To: Shinya Kuribayashi <>
Subject: Re: [PATCH resend 5/9] MIPS: sync after cacheflush
From: Kevin Cernekee <>
Date: Mon, 18 Oct 2010 17:51:09 -0700
Cc: Shinya Kuribayashi <>, Ralf Baechle <>,,
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ER04KrYW9Xn7Xnmodj7ASS3KHx40P1lThc1l+6DqPMA=; b=RzhKJtUx9zBIrBBo7gL5pUIxsm0xVlmB1oeU4xrlDwZ75OaBQ3jUWw7fKtvtt7WudC PIMS4EBsYESF6GVpklCbR9v3EQT3l0QeQ7+GTrcQt4YPDM4tMDyrRQvTqXBZnDQ3wJBU hwT1Kfrv107EsPfY/l8dHxrPOHq1akpIVuaOA=
Domainkey-signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vfl7j9IoDszbkEamNSr161ANtbqRAGOZiJco1AMSCIo/ojemE9XcRLGyzN0kwxcPU+ nCK5o7Bq8iyR9MkTjOug7l6/MBRIrNzSPWyJRPoOezLE0129sXV7SvEnInA1lded+e/I UdXtXc1RTXxF1rdhNBJe4mvTOrMCz+k8MVhz8=
In-reply-to: <>
Original-recipient: rfc822;
References: <17ebecce124618ddf83ec6fe8e526f93@localhost> <17d8d27a2356640a4359f1a7dcbb3b42@localhost> <> <> <>
On Mon, Oct 18, 2010 at 5:03 PM, Shinya Kuribayashi
<> wrote:
> IIUC, the problem is that write operation originating from step 5. seems
> to overtake the one originating from step 3., correct?

Correct.  This particular system makes no guarantees that data flushed
out through CACHE operations will not overtake subsequent uncached

For the case of DMA, it is possible that data that I am attempting to
send to a device (via DRAM) could still be in transit when
dma_cache_wback() returns, and may be incomplete when the DMA
operation starts.  Or that dirty cachelines that I am attempting to
"free up" for a DMA_FROM_DEVICE operation are still in transit when
dma_cache_wback_inv() returns, potentially clobbering whatever data
the peripheral is trying to write to memory.

Adding SYNC at the end of dma_cache_wback* guarantees that the write
buffers have been emptied out to DRAM and I do not have to worry
anymore about any of these cases.

> Then we'd like to know, what is that 'Caller mentioned at step 5.', and
> what kind of operation will be done by the Caller?

It is my recollection that the caller was the USB EHCI driver, and it
was allocating some sort of uncached descriptor block that contained
pointers.  Sometimes those pointers got inexplicably zeroed out, and
this is what we found to be the root cause.

<Prev in Thread] Current Thread [Next in Thread>