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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).