[PATCH] arm64: enable EDAC on arm64

[Rob Herring]

On Thu, Nov 7, 2013 at 3:51 AM, Will Deacon <will.deacon at arm.com> wrote:
> On Wed, Nov 06, 2013 at 06:39:18PM +0000, Rob Herring wrote:
>> On Wed, Nov 6, 2013 at 9:26 AM, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> > On Wed, Nov 06, 2013 at 01:02:24PM +0000, Rob Herring wrote:
>> >> +static inline void atomic_scrub(void *va, u32 size)
>> >> +{
>> >> +     unsigned int *virt_addr = va;
>> >> +     unsigned int temp, temp2;
>> >> +     unsigned int i;
>> >> +
>> >> +     for (i = 0; i < size / sizeof(*virt_addr); i++, virt_addr++) {
>> >> +             /*
>> >> +              * No need to check for store failure, another write means
>> >> +              * the scrubbing has effectively already been done for us.
>> >> +              */
>> >> +             asm volatile("\n"
>> >> +                     "       ldxr    %0, %2\n"
>> >> +                     "       stxr    %w1, %0, %2\n"
>> >> +                     : "=&r" (temp), "=&r" (temp2), "+Q" (virt_addr)
>> >> +                     : : "cc");
>> >
>> > But failure of stxr does not necessarily mean another write. It can be
>> > an interrupt, cache line migration etc. The exclusive monitor can be
>> > emulated in many ways.
>>
>> Right, I was thinking I could simplify things.
>>
>> In that case, I could implement this with just "atomic64_add(0,
>> virt_addr)", but is there any guarantee that atomic64_t has a size of
>> 8 bytes and that I can simply increment an atomic64_t ptr?
>>
>> > BTW, can you not use 64-bit loads/stores?
>>
>> Correct, that should be a long instead of int.
>
> Are we guaranteed that va is a 64-bit aligned pointer? Also, usual comment
> about the "cc" clobber.

I'll have to check if the EDAC framework provides any guarantee, but
we can force the alignment widening the scrubbing range if needed.
Normally, DDR ECC would always be done on 64-bit units for 72-bit
DIMMs. I can't imagine you would ever have 32-bit wide DDR with ECC.

Rob