On Fri, Jan 6, 2012 at 8:58 AM, Jamie Iles <ja...@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 <w...@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 _______________________________________________ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss