Is volatile always verboten for FSL QE structures?

Is volatile always verboten for FSL QE structures?

[Michael Barkowski]

Just wondering - is there a case where using volatile for UCC parameter RAM for example will not work, or is the use of I/O accessors everywhere an attempt to be portable to other architectures?

I'm asking because I really want to know ;)

-- 
Michael Barkowski
905-482-4577

Re: Is volatile always verboten for FSL QE structures?

[Timur Tabi]

Michael Barkowski wrote:
> Just wondering - is there a case where using volatile for UCC parameter RAM for example will not work, or is the use of I/O accessors everywhere an attempt to be portable to other architectures?

'volatile' just doesn't really do what you think it should do.  The PowerPC architecture is too complicated w.r.t. ordering of reads and writes.  In other words, you can't trust it.

No one should be using 'volatile' to access I/O registers.

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: Is volatile always verboten for FSL QE structures?

[Kumar Gala]

On Oct 2, 2009, at 9:46 AM, Timur Tabi wrote:

> Michael Barkowski wrote:
>> Just wondering - is there a case where using volatile for UCC  
>> parameter RAM for example will not work, or is the use of I/O  
>> accessors everywhere an attempt to be portable to other  
>> architectures?
>
> 'volatile' just doesn't really do what you think it should do.  The  
> PowerPC architecture is too complicated w.r.t. ordering of reads and  
> writes.  In other words, you can't trust it.
>
> No one should be using 'volatile' to access I/O registers.

See Documentation/volatile-considered-harmful.txt

- k

Re: Is volatile always verboten for FSL QE structures?

[Michael Barkowski]

Kumar Gala wrote:
> 
> On Oct 2, 2009, at 9:46 AM, Timur Tabi wrote:
> 
>> Michael Barkowski wrote:
>>> Just wondering - is there a case where using volatile for UCC
>>> parameter RAM for example will not work, or is the use of I/O
>>> accessors everywhere an attempt to be portable to other architectures?
>>
>> 'volatile' just doesn't really do what you think it should do.  The
>> PowerPC architecture is too complicated w.r.t. ordering of reads and
>> writes.  In other words, you can't trust it.
>>
>> No one should be using 'volatile' to access I/O registers.
> 
> See Documentation/volatile-considered-harmful.txt
> 

I'm happy to adopt your interpretation of it, and I appreciate the explanation.

from Documentation/volatile-considered-harmful.txt:
>   - The above-mentioned accessor functions might use volatile on
>     architectures where direct I/O memory access does work.  Essentially,
>     each accessor call becomes a little critical section on its own and
>     ensures that the access happens as expected by the programmer.

Part of it was that I wondered if this was one of those architectures.  I guess not.

-- 
Michael Barkowski
905-482-4577

Re: Is volatile always verboten for FSL QE structures?

[Guillaume Knispel]

Michael Barkowski wrote:

> Kumar Gala wrote:
> > 
> > On Oct 2, 2009, at 9:46 AM, Timur Tabi wrote:
> > 
> >> Michael Barkowski wrote:
> >>> Just wondering - is there a case where using volatile for UCC
> >>> parameter RAM for example will not work, or is the use of I/O
> >>> accessors everywhere an attempt to be portable to other architectures?
> >>
> >> 'volatile' just doesn't really do what you think it should do.  The
> >> PowerPC architecture is too complicated w.r.t. ordering of reads and
> >> writes.  In other words, you can't trust it.
> >>
> >> No one should be using 'volatile' to access I/O registers.
> > 
> > See Documentation/volatile-considered-harmful.txt
> > 
> 
> I'm happy to adopt your interpretation of it, and I appreciate the explanation.
> 
> from Documentation/volatile-considered-harmful.txt:
> >   - The above-mentioned accessor functions might use volatile on
> >     architectures where direct I/O memory access does work.  Essentially,
> >     each accessor call becomes a little critical section on its own and
> >     ensures that the access happens as expected by the programmer.
> 
> Part of it was that I wondered if this was one of those architectures.  I guess not.

I guess this could only work on architectures having a totally ordered
memory model.  Definitely not the case for Power.

Re: Is volatile always verboten for FSL QE structures?

[Simon Richter]

Hi,

> > >> 'volatile' just doesn't really do what you think it should do.  The
> > >> PowerPC architecture is too complicated w.r.t. ordering of reads and
> > >> writes.  In other words, you can't trust it.

It's not sufficient on PowerPC.

It might be necessary, depending on the compiler's mood for moving stuff
out of loops.

Consider:

| unsigned int *foo = (unsigned int *)0x12345678;
| void bar(void) { while(*foo != 0) asm("eieio"); }

gcc 4.3.4 with -O3 compiles this to

00000000 <bar>:
   0:   3d 20 00 00     lis     r9,0
                        2: R_PPC_ADDR16_HA      foo
   4:   81 69 00 00     lwz     r11,0(r9)
                        6: R_PPC_ADDR16_LO      foo
   8:   80 0b 00 00     lwz     r0,0(r11)
   c:   2f 80 00 00     cmpwi   cr7,r0,0
  10:   4d 9e 00 20     beqlr   cr7
  14:   7c 00 06 ac     eieio
  18:   7c 00 06 ac     eieio
  1c:   4b ff ff f8     b       14 <bar+0x14>

Making the target of foo volatile properly rechecks the condition on
each iteration.

OTOH my PPC box runs fine, so I'm probably missing something obvious.

   Simon

Re: Is volatile always verboten for FSL QE structures?

[Benjamin Herrenschmidt]

> Making the target of foo volatile properly rechecks the condition on
> each iteration.
> 
> OTOH my PPC box runs fine, so I'm probably missing something obvious.

Probably because the IO accessors do -both- volatile casts and
add the barriers :-) 

Ben.