Device tree bindings for linux ramoops use

[Olof Johansson]

On Fri, Jan 6, 2012 at 8:58 AM, Jamie Iles <jamie at jamieiles.com> wrote:
> 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 at firmworks.com> 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?

Only the ramoops-include-oopses is really the runtime configuration,
so that alone in /chosen could be a good idea. But I would rather have
the "partition" described as a device with a compatible field that the
driver can bind against.


-Olof