RFC on writel and writel_relaxed
oohall at gmail.com
Thu Mar 22 20:25:43 AEDT 2018
On Thu, Mar 22, 2018 at 7:20 PM, Gabriel Paubert <paubert at iram.es> wrote:
> On Thu, Mar 22, 2018 at 04:24:24PM +1100, Oliver wrote:
>> On Thu, Mar 22, 2018 at 1:35 AM, David Laight <David.Laight at aculab.com> wrote:
>> >> x86 has compiler barrier inside the relaxed() API so that code does not
>> >> get reordered. ARM64 architecturally guarantees device writes to be observed
>> >> in order.
>> > There are places where you don't even need a compile barrier between
>> > every write.
>> > I had horrid problems getting some ppc code (for a specific embedded SoC)
>> > optimised to have no extra barriers.
>> > I ended up just writing through 'pointer to volatile' and adding an
>> > explicit 'eieio' between the block of writes and status read.
>> This is what you are supposed to do. For accesses to MMIO (cache
>> inhibited + guarded) storage the Power ISA guarantees that load-load
>> and store-store pairs of accesses will always occur in program order,
>> but there's no implicit ordering between load-store or store-load
> And even for load store, eieio is not always necessary, in the important
> case of reading and writing to the same address, when modifying bits in
> a control register for example.
> Typically also loads will be moved ahead of stores, but not the other
> way around, so in practice you won't notice a missed eieio in this case.
> This does not mean you should not insert it.
Yep, but it doesn't really help us here. The generic accessors need to cope
with the general case.
>> pairs. In those cases you need an explicit eieio barrier between the
>> two accesses. At the HW level you can think of the CPU as having
>> separate queues for MMIO loads and stores. Accesses will be added to
>> the respective queue in program order, but there's no synchronisation
>> between the two queues. If the CPU is doing write combining it's easy
>> to imagine the whole store queue being emptied in one big gulp before
>> the load queue is even touched.
> Is write combining allowed on guarded storage?
> <Looking at docs>
> From PowerISA_V3.0.pdf, Book2, section 1.6.2 "Caching inhibited":
> "No combining occurs if the storage is also Guarded"
Yeah it's not allowed. That's what I get for handwaving examples ;)
More information about the Linuxppc-dev