some question about wmb in mips

some question about wmb in mips

[loody]

Dear all:
AFAIK, wmb in mips is implemented by calling sync,
wmb->fast_wmb->__sync, which makes sure Loads and stores executed
before the SYNC are completed before loads
and stores after the SYNC can start
But will this instruction write the cache back too?
take usb example, it will call this maco before it let host processing
the commands on dram, so I wondering whether sync will write the cache
back to memory.
appreciate your help,
miloody

Re: some question about wmb in mips

[Maciej W. Rozycki]

On Mon, 28 Jun 2010, loody wrote:

> AFAIK, wmb in mips is implemented by calling sync,

 For platforms that support this instructions, yes.

> wmb->fast_wmb->__sync, which makes sure Loads and stores executed
> before the SYNC are completed before loads
> and stores after the SYNC can start

 You shouldn't be relying on implementation details -- WMB is defined as a 
write ordering barrier only, so all the interface guarantees is any 
outstanding stores will be seen on the processor's bus interface before 
any future store starts.  This is AFAIR the case with (at least some) 
platforms that do not have the SYNC instruction -- where any outstanding 
stores can still be delayed until after a future load.

 Actually with the recent introduction of the SYNC_WMB instruction it's 
likely it'll get used as the implementation of the WMB interface as soon 
as the distribution of the instruction is wide enough across platforms.  
As the name implies, this instruction only guarantees an ordering barrier 
for stores and not for loads.

> But will this instruction write the cache back too?

 No, SYNC is only meaningful for uncached (and cached coherent) accesses.  
I think that's clear from how the instruction has been specified.

> take usb example, it will call this maco before it let host processing
> the commands on dram, so I wondering whether sync will write the cache
> back to memory.

 You need to call the appropriate helper -- see the DMA API document for 
details.  Or use a coherent (in the Linux sense) mapping, which in turn 
will make CPU-side memory accesses to this area uncached on non-coherent 
(in the MIPS sense) systems.

  Maciej

Re: some question about wmb in mips

[Ralf Baechle]

On Mon, Jun 28, 2010 at 12:16:06AM +0800, loody wrote:

> Dear all:
> AFAIK, wmb in mips is implemented by calling sync,
> wmb->fast_wmb->__sync, which makes sure Loads and stores executed
> before the SYNC are completed before loads
> and stores after the SYNC can start
> But will this instruction write the cache back too?

No.

> take usb example, it will call this maco before it let host processing
> the commands on dram, so I wondering whether sync will write the cache
> back to memory.

SYNC is for memory consistency, not coherency.

  Ralf

Re: some question about wmb in mips

[Ralf Baechle]

On Sun, Jun 27, 2010 at 06:47:14PM +0100, Maciej W. Rozycki wrote:

> > AFAIK, wmb in mips is implemented by calling sync,
> 
>  For platforms that support this instructions, yes.

For platforms that support this instruction _AND_ are not strongly ordered.
Iow we try to avoid it, if possible.  Details are complicated.

> > wmb->fast_wmb->__sync, which makes sure Loads and stores executed
> > before the SYNC are completed before loads
> > and stores after the SYNC can start
> 
>  You shouldn't be relying on implementation details -- WMB is defined as a 
> write ordering barrier only, so all the interface guarantees is any 
> outstanding stores will be seen on the processor's bus interface before 
> any future store starts.  This is AFAIR the case with (at least some) 
> platforms that do not have the SYNC instruction -- where any outstanding 
> stores can still be delayed until after a future load.
> 
>  Actually with the recent introduction of the SYNC_WMB instruction it's 
> likely it'll get used as the implementation of the WMB interface as soon 
> as the distribution of the instruction is wide enough across platforms.  
> As the name implies, this instruction only guarantees an ordering barrier 
> for stores and not for loads.
> 
> > But will this instruction write the cache back too?
> 
>  No, SYNC is only meaningful for uncached (and cached coherent) accesses.  
> I think that's clear from how the instruction has been specified.
> 
> > take usb example, it will call this maco before it let host processing
> > the commands on dram, so I wondering whether sync will write the cache
> > back to memory.
> 
>  You need to call the appropriate helper -- see the DMA API document for 
> details.  Or use a coherent (in the Linux sense) mapping, which in turn 
> will make CPU-side memory accesses to this area uncached on non-coherent 
> (in the MIPS sense) systems.

  Ralf

Re: some question about wmb in mips

[loody]

hi all:

2010/7/6 loody <miloody@gmail.com>:
> Dear ralf and maciej:
> 2010/6/28 Ralf Baechle <ralf@linux-mips.org>:
>> On Sun, Jun 27, 2010 at 06:47:14PM +0100, Maciej W. Rozycki wrote:
>>
>>> > AFAIK, wmb in mips is implemented by calling sync,
>>>
>>>  For platforms that support this instructions, yes.
>>
>> For platforms that support this instruction _AND_ are not strongly ordered.
>> Iow we try to avoid it, if possible.  Details are complicated.
>>
>>> > wmb->fast_wmb->__sync, which makes sure Loads and stores executed
>>> > before the SYNC are completed before loads
>>> > and stores after the SYNC can start
>>>
>>>  You shouldn't be relying on implementation details -- WMB is defined as a
>>> write ordering barrier only, so all the interface guarantees is any
>>> outstanding stores will be seen on the processor's bus interface before
>>> any future store starts.  This is AFAIR the case with (at least some)
>>> platforms that do not have the SYNC instruction -- where any outstanding
>>> stores can still be delayed until after a future load.
>>>
>>>  Actually with the recent introduction of the SYNC_WMB instruction it's
>>> likely it'll get used as the implementation of the WMB interface as soon
>>> as the distribution of the instruction is wide enough across platforms.
>>> As the name implies, this instruction only guarantees an ordering barrier
>>> for stores and not for loads.
>>>
>>> > But will this instruction write the cache back too?
>>>
>>>  No, SYNC is only meaningful for uncached (and cached coherent) accesses.
>>> I think that's clear from how the instruction has been specified.
>>>
>>> > take usb example, it will call this maco before it let host processing
>>> > the commands on dram, so I wondering whether sync will write the cache
>>> > back to memory.
>>>
>>>  You need to call the appropriate helper -- see the DMA API document for
>>> details.  Or use a coherent (in the Linux sense) mapping, which in turn
>>> will make CPU-side memory accesses to this area uncached on non-coherent
>>> (in the MIPS sense) systems.
> thanks for your suggestion. :)
> I will take look at the DMA API for details.
> appreciate your help,
after reading the DMA api document and check the source code.
I found mips seems not implement "dma map ops", but x86 has implemented it.
What are they used for and why mips don't implement it?
appreciate your help,
miloody

Re: some question about wmb in mips

[Ralf Baechle]

On Mon, Aug 30, 2010 at 09:58:27PM +0800, loody wrote:

> after reading the DMA api document and check the source code.
> I found mips seems not implement "dma map ops", but x86 has implemented it.
> What are they used for and why mips don't implement it?

This is useful for multiple sets of methods on more complicated systems.
Right now we just don't need that.

  Ralf

Re: some question about wmb in mips

[David Daney]

On 08/31/2010 07:33 AM, Ralf Baechle wrote:
> On Mon, Aug 30, 2010 at 09:58:27PM +0800, loody wrote:
>
>> after reading the DMA api document and check the source code.
>> I found mips seems not implement "dma map ops", but x86 has implemented it.
>> What are they used for and why mips don't implement it?
>
> This is useful for multiple sets of methods on more complicated systems.
> Right now we just don't need that.
>

That said, I am preparing a set of patches that converts MIPS to use 
struct dma_map_ops.  They turn out to be useful in systems where PCI 
devices need different treatment than on-chip devices, and when bounce 
buffers are needed form some devices, but not others.

David Daney