[Top] [All Lists]

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

To: "Maciej W. Rozycki" <>
Subject: Re: [PATCH resend 5/9] MIPS: sync after cacheflush
From: "Gleb O. Raiko" <>
Date: Wed, 20 Oct 2010 12:05:42 +0400
Cc: Ralf Baechle <>, Kevin Cernekee <>, Shinya Kuribayashi <>,,
In-reply-to: <>
Organization: NIISI RAN
Original-recipient: rfc822;
References: <17ebecce124618ddf83ec6fe8e526f93@localhost> <17d8d27a2356640a4359f1a7dcbb3b42@localhost> <> <> <> <> <>
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20091204 Thunderbird/3.0
On 20.10.2010 0:11, Maciej W. Rozycki wrote:
  That said, R4k DECstations seem to perform aggressive write buffering in
the chipset and to make sure a write has propagated to an MMIO register a
SYNC and an uncached read operation are necessary.

Just uncached read may be enough. R4k shall pull data from its store buffer on uncached read.

  I haven't investigated DMA dependencies and I think we currently only
have one TURBOchannel device/driver only (that is the DEFTA/defxx FDDI
thingy) making use of the generic DMA API on DECstations.  It seemed to
work correctly the last time I tried; presumably either because the API
Does The Right Thing, or by pure luck and right timings.

dfx_writel issues sync after store. BTW, it seems no uncached read issued here (just mb() is used, which seems to do sync only), so either those uncached read is not needed (unlikely) or data from dfx_writel wait somewhere in the chipset for being pulled by subsequent reads or writes.


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