Re: Device tree bindings for linux ramoops use

[Jamie Iles <jamie-wmLquQDDieKakBO8gow8eQ@public.gmane.org>]

On Fri, Jan 06, 2012 at 09:47:22AM -0800, Olof Johansson wrote:
> On Fri, Jan 6, 2012 at 8:58 AM, Jamie Iles <jamie-wmLquQDDieKakBO8gow8eQ@public.gmane.org> 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-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?
> 
> 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.

I can see why that would be nice too, but to me this feels different to 
say MTD partitions as it really is Linux specific and it doesn't seem 
unreasonable that someone may want to include ramoops support when 
debugging something, but for another application, use the whole of the 
onchip RAM as a buffer.  Requiring modifications for the DT on identical 
hardware platforms but different applications doesn't feel quite right 
to me.  Seeing as chosen is special that doesn't feel too bad.

Jamie