From: robherring2@gmail.com (Rob Herring)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 3/3] pstore/ram: avoid atomic accesses for ioremapped regions
Date: Wed, 10 Apr 2013 10:55:35 -0500 [thread overview]
Message-ID: <51658B77.4050400@gmail.com> (raw)
In-Reply-To: <CAMbhsRSNPz1d9bGGEjqyTwVg_1pv8PB15WybEL5ZRVgmnTDWLQ@mail.gmail.com>
On 04/09/2013 11:10 PM, Colin Cross wrote:
> On Tue, Apr 9, 2013 at 8:08 PM, Rob Herring <robherring2@gmail.com> wrote:
>> From: Rob Herring <rob.herring@calxeda.com>
>>
>> For persistent RAM outside of main memory, the memory may have limitations
>> on supported accesses. For internal RAM on highbank platform exclusive
>> accesses are not supported and will hang the system. So atomic_cmpxchg
>> cannot be used. This commit uses spinlock protection for buffer size and
>> start updates on ioremapped regions instead.
>
> I used atomics in persistent_ram to support persistent ftrace, which
> now exists as PSTORE_FTRACE. At some point during development I had
> trouble with recursive tracing causing an infinite loop, so you may
> want to test that calling out to spinlock functions with PSTORE_FTRACE
> turned on and enabled doesn't cause a problem.
I've tested that now and it appears to work fine. Was there some
specific setup of ftrace that caused problems?
Rob
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robherring2@gmail.com>
To: Colin Cross <ccross@android.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Rob Herring <rob.herring@calxeda.com>,
Anton Vorontsov <cbouatmailru@gmail.com>,
Kees Cook <keescook@chromium.org>,
Tony Luck <tony.luck@intel.com>
Subject: Re: [RFC PATCH 3/3] pstore/ram: avoid atomic accesses for ioremapped regions
Date: Wed, 10 Apr 2013 10:55:35 -0500 [thread overview]
Message-ID: <51658B77.4050400@gmail.com> (raw)
In-Reply-To: <CAMbhsRSNPz1d9bGGEjqyTwVg_1pv8PB15WybEL5ZRVgmnTDWLQ@mail.gmail.com>
On 04/09/2013 11:10 PM, Colin Cross wrote:
> On Tue, Apr 9, 2013 at 8:08 PM, Rob Herring <robherring2@gmail.com> wrote:
>> From: Rob Herring <rob.herring@calxeda.com>
>>
>> For persistent RAM outside of main memory, the memory may have limitations
>> on supported accesses. For internal RAM on highbank platform exclusive
>> accesses are not supported and will hang the system. So atomic_cmpxchg
>> cannot be used. This commit uses spinlock protection for buffer size and
>> start updates on ioremapped regions instead.
>
> I used atomics in persistent_ram to support persistent ftrace, which
> now exists as PSTORE_FTRACE. At some point during development I had
> trouble with recursive tracing causing an infinite loop, so you may
> want to test that calling out to spinlock functions with PSTORE_FTRACE
> turned on and enabled doesn't cause a problem.
I've tested that now and it appears to work fine. Was there some
specific setup of ftrace that caused problems?
Rob
next prev parent reply other threads:[~2013-04-10 15:55 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-10 3:08 [RFC PATCH 1/3] pstore-ram: use write-combine mappings Rob Herring
2013-04-10 3:08 ` Rob Herring
2013-04-10 3:08 ` [RFC PATCH 2/3] pstore ram: remove the power of buffer size limitation Rob Herring
2013-04-10 3:08 ` Rob Herring
2013-04-10 3:08 ` [RFC PATCH 3/3] pstore/ram: avoid atomic accesses for ioremapped regions Rob Herring
2013-04-10 3:08 ` Rob Herring
2013-04-10 4:10 ` Colin Cross
2013-04-10 4:10 ` Colin Cross
2013-04-10 15:55 ` Rob Herring [this message]
2013-04-10 15:55 ` Rob Herring
2013-04-10 3:53 ` [RFC PATCH 1/3] pstore-ram: use write-combine mappings Colin Cross
2013-04-10 3:53 ` Colin Cross
2013-04-10 13:30 ` Rob Herring
2013-04-10 13:30 ` Rob Herring
2013-04-15 22:21 ` Colin Cross
2013-04-15 22:21 ` Colin Cross
2013-04-15 23:59 ` Rob Herring
2013-04-15 23:59 ` Rob Herring
2013-04-16 0:43 ` Colin Cross
2013-04-16 0:43 ` Colin Cross
2013-04-16 8:44 ` Will Deacon
2013-04-16 8:44 ` Will Deacon
2013-04-16 12:58 ` Rob Herring
2013-04-16 12:58 ` Rob Herring
2013-04-16 13:48 ` Catalin Marinas
2013-04-16 13:48 ` Catalin Marinas
2013-04-19 9:54 ` Russell King - ARM Linux
2013-04-19 9:54 ` Russell King - ARM Linux
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51658B77.4050400@gmail.com \
--to=robherring2@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.