Thread (1 message) 1 message, 1 author, 2012-01-06

Re: Device tree bindings for linux ramoops use

From: Grant Likely <hidden>
Date: 2012-01-06 22:30:45

On Fri, Jan 6, 2012 at 3:24 PM, Mitch Bradley [off-list ref] wrote:
On 1/6/2012 12:09 PM, Grant Likely wrote:
quoted
On Thu, Jan 05, 2012 at 08:39:50PM -0800, Olof Johansson wrote:
quoted
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 = ...

I'm not a fan of using separate start&  size properties.  I'd rather

see a 'reg' type property like "linux,ramoops-mem =<start size>;",
but doing it in separate properties does may early boot code easier to
write.  I assume that is why the initrd start and size values are
passed separately.

Separate properties admit the possibility of errors where one is present but
not the other.  I prefer atomicity.  It's either there, with all the
information, or it isn't.
.... I was /going/ to argue that having a single property requires
parsing #{address,size}-cells whereas passing separately does not...
but thinking about it more that isn't actually true (although the
cells size could be inferred when using separate properties).  So,
yes, I agree with Mitch.  A single property is better.

g.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help