On Thu, Jan 7, 2016 at 10:45 AM, Arnd Bergmann arnd@arndb.de wrote:
On Tuesday 05 January 2016 20:53:50 John Stultz wrote:
From: Greg Hackmann ghackmann@google.com
ramoops is one of the remaining places where ARM vendors still rely on board-specific shims. Device Tree lets us replace those shims with generic code.
These bindings mirror the ramoops module parameters, with two small differences:
(1) dump_oops becomes an optional "no-dump-oops" property, since ramoops sets dump_oops=1 by default.
The code has a "dump-oops" property, not "no-dump-oops".
(2) mem_type=1 becomes the more self-explanatory "unbuffered" property.
There should also be a DT binding document that describes the valid properties.
There is. I think John dropped it. You should review the version on lkml.
[...]
+static int ramoops_parse_dt(struct platform_device *pdev,
struct ramoops_platform_data *pdata)+{
struct device_node *of_node = pdev->dev.of_node;struct device_node *mem_region;struct resource res;u32 ecc_size;int ret;dev_dbg(&pdev->dev, "using Device Tree\n");mem_region = of_parse_phandle(of_node, "memory-region", 0);if (!mem_region) {dev_err(&pdev->dev, "no memory-region phandle\n");return -ENODEV;}ret = of_address_to_resource(mem_region, 0, &res);of_node_put(mem_region);if (ret) {dev_err(&pdev->dev, "failed to translate memory-region to resource: %d\n",ret);return ret;}This is a rather odd way of doing it. Why is the ramoops block not a device under the memory region itself?
Probably so that a platform device will be created. Your suggestion is probably a better way to go. We also have to consider pstore in onchip RAM buffers. We really need a way to instantiate platform drivers from DT yet don't map 1-1 with a device node and a compatible string (I'm looking at you, cpufreq drivers). I attempted something before but anything creating platform device in an initcall gets shot down.
Rob