Find the answer to your Linux question:
Results 1 to 3 of 3
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1

    Do ioread32/iowrite32 assume volatile pointer?

    I'm trying to convert all my driver references from using pointer dereferencing to read/write PCI device memory, to using ioread/iowrite functions as recommended elsewhere.

    I have a memory test, which does what memory tests do... the memory pointer in the function is defined as volatile u32*, because otherwise the optimizer just removes all the loops (thinking a write followed by read at same address has an obvious result). However, when I pass the volatile pointer to ioread32/iowrite32, I get compiler warnings because those functions don't take volatile pointers. I could cast away the volatiles, of course, but then I may still have the same problem with the compiler.

    So I'm hoping that ioread()/iowrite(), by their nature, assume that they are dealing with external memory which is inherently volatile. Is this a reliable assumption? If not, how do I solve this problem?

  2. #2
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Making assumptions like this regarding volatility of a variable is not a safe one to make, in my opinion. I checked, and on my CentOS kernel the arguments are not volatile. Since these are I/O addresses, they probably are volatile, and may be changed at any time by the hardware they are mapped to. However, using the volatile keyword in your code is so that the compiler will better guard it from being changed by another thread (not hardware) while you are reading it. Then again, in this case it probably is not an issue as far as you are concerned.

    So, why are you worried about this?
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  3. #3
    Well, I'm worried about this because it's a memory test... if the compiler does not realize that a write followed by a read does not produce an obvious result (i.e., the memory is volatile), then I won't get the result that I expect, and I won't detect failed memory... but then I won't know *that* until memory *does* fail in the field, and I don't detect it.

    The *real* problem, however, is that I don't know why there's a difference between
    *(char *) (xilinx_base + OFFSET) = u8value ;
    is different from
    iowrite8(u8value, (xilinx_base + OFFSET)) ;
    but I've seen that it is, because the former did not work for some of my register writes. So now I'm tediously grinding through 262 xilinx_base references in my 33,000 lines of driver code, trying to carefully convert them over to the new syntax.

    And the reason I'm bothering with *that* is because I'm hoping that it's some memory reference BEFORE my DMA test, that is causing the DMA test to fail (as discussed in a separate, earlier message, which is also an unresolved issue).

  4. $spacer_open

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts