From: Jamie Iles <jamie-wmLquQDDieKakBO8gow8eQ@public.gmane.org>
To: Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>
Cc: Marco Stornelli
<marco.stornelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
Subject: Re: Device tree bindings for linux ramoops use
Date: Fri, 6 Jan 2012 16:58:23 +0000 [thread overview]
Message-ID: <20120106165823.GB3466@page> (raw)
In-Reply-To: <CAOesGMgstHqtTo0X9Y-SSU+VTUxYRrXW=3h=EhH-biMeDXik8g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Jan 06, 2012 at 08:28:51AM -0800, Olof Johansson wrote:
> On Thu, Jan 5, 2012 at 11:22 PM, Mitch Bradley <wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> wrote:
> >
> > On 1/5/2012 6:39 PM, Olof Johansson wrote:
> >>
> >> Hi,
> >>
> >> I'm considering how to best describe the data that ramoops needs in
> >> the device tree.
> >>
> >> The idea is really about describing a memory area that is (likely to
> >> be) nonvolatile across reboots. Said area is not to be included in the
> >> regular memory map of the system (i.e. not covered by /memory).
> >>
> >> I have a few options on where to do it. It's not really a hardware
> >> device per se, so it's a gray area for the device tree alltogether.
> >>
> >> How about something like?
> >>
> >> compatible = "linux,ramoops"
> >> linux,ramoops-start =<start address of preserved ram>
> >> linux,ramoops-size = ...
> >> linux,ramoops-record-size = ...
> >> linux,ramoops-include-oopses = ... (this one is a bit of a corner
> >> case, it's truly a software setting -- probably leave it out)
> >>
> >> Anybody have a better idea?
> >
> >
> > If it is addressable, it should appear as a device node underneath the node
> > that creates the address space in which it appears, and the start and size
> > should be described by a "reg" property.
>
> A yes, of course.
>
> I got on the wrong track due to the lack of use of resources in the
> linux platform_driver.
But you still need some ramoops specific configuration though right?
Could this be represented with a generic binding for the onchip RAM as
has already proposed then inside the chosen node something like:
chosen {
ramoops {
linux,ramoops-record-size = <12>;
linux,ramoops-include-oopses = <1>;
/* phandle to ram, offset, size */
linux,ramoops-ram = <&iram 0x1000 0x200>;
};
};
to decouple the runtime configuration from the hardware binding?
Jamie
next prev parent reply other threads:[~2012-01-06 16:58 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-06 4:39 Device tree bindings for linux ramoops use Olof Johansson
[not found] ` <CAOesGMiKBQM61DkLFoTcvMFWV2UCgomLQYDX65_Tkmtoy_hGCg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-01-06 7:22 ` Mitch Bradley
[not found] ` <4F06A120.8080505-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2012-01-06 16:28 ` Olof Johansson
[not found] ` <CAOesGMgstHqtTo0X9Y-SSU+VTUxYRrXW=3h=EhH-biMeDXik8g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-01-06 16:58 ` Jamie Iles [this message]
2012-01-06 17:47 ` Olof Johansson
[not found] ` <CAOesGMi54byaL6K_aJU0rm9yLMX-GngydyyjHpYC9_2BvQwEoA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-01-06 17:53 ` Jamie Iles
2012-01-06 22:05 ` Grant Likely
[not found] ` <20120106220530.GI7457-e0URQFbLeQY2iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2012-01-06 22:38 ` Rob Herring
[not found] ` <4F0777EF.3000600-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-01-06 22:55 ` Olof Johansson
[not found] ` <CAOesGMh4wVvW5JYLxDCH8p9iML65KwNoQnWyRKG_Ci9TfUL9Ng-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-01-06 23:02 ` Mitch Bradley
2012-01-06 13:25 ` Rob Herring
[not found] ` <4F06F662.2020803-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-01-06 16:33 ` Olof Johansson
[not found] ` <CAOesGMi3Wc3Bdx5UdXHUxXxv-pMSAhS6VagHaAm6OpA_GFrjAg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-01-06 16:49 ` Mitch Bradley
2012-01-06 22:09 ` Grant Likely
[not found] ` <20120106220908.GJ7457-e0URQFbLeQY2iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2012-01-06 22:24 ` Mitch Bradley
[not found] ` <4F07749B.6070703-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2012-01-06 22:30 ` Grant Likely
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=20120106165823.GB3466@page \
--to=jamie-wmlquqddiekakbo8gow8eq@public.gmane.org \
--cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
--cc=marco.stornelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org \
--cc=rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.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.