Re: [PATCH v2] ARM: realview: basic device tree implementation
From: Sebastian Hesselbarth <hidden>
Date: 2014-05-22 22:34:43
Also in:
linux-arm-kernel
On 05/22/2014 09:41 AM, Linus Walleij wrote:
On Fri, May 9, 2014 at 12:44 PM, Arnd Bergmann [off-list ref] wrote:quoted
quoted
+++ b/arch/arm/boot/dts/arm-realview-pb1176.dtsCan you split this up into an arm-realview.dtsi file for the common parts and a pb1176 specific file for the rest?I wonder if that makes any kind of sense. The RealView platforms does not really share much more than the name, sadly. For example: IP blocks aren't even at the same address. I could create a .dtsi file but it would be empty :-(quoted
quoted
+ soc { + #address-cells = <1>; + #size-cells = <1>; + compatible = "simple-bus"; + ranges; + + syscon: syscon@10000000 { + compatible = "arm,realview-pb1176-syscon", "syscon"; + reg = <0x10000000 0x1000>; + };Hmm, in order to have a proper reset driver, we probably want a separate node for the reset controller. I believe the x-gene people have just posted a generic reset driver based on syscon. Let's see if we can share that.I have looked at it. Patch titled "power: reset: Add generic SYSCON register mapped reset" Sadly it does not work for our case. This is because it assumes that reboot will be triggered by writing one value to one register. The RealViews need you to *first* write to a special unlock register, then write a magic value to a magic register. So of course we could extend the syscon regmap reset driver by starting to encode a jam table such as a sequence of register writes to a sequence of registers, but we have refused such code in the past because as I recall Grant said, it is the beginning of a byte code interpreter and then we could as well bite the bullet and start implementing open firmware. This is exactly the type of thing that ACPI AML code usually does by the way so what he says makes a *lot* of sense. So for now I keep to our special driver.
+1 for drivers/soc _and_ of_xlate for regmap instead of syscon. driven by Mike Turquette's request to join mach-berlin clock node into a single node, we currently use pinctrl driver (that must be somewhere in Linus inbox) as a crutch to register a regmap for other drivers. I also saw that Arnd requested to not chop chip registers into tiny pieces for Linux subsystems but rather have a single DT node and make the drivers use it. Mike also mentioned he is fine with different subsystem drivers reusing the same node property-wise, i.e. reset and clock in a single node. With Berlin (and other SoCs for sure) ultimately there will be a bunch of drivers that require the io resource and the node early and non-early. Now, using syscon would still require dummy nodes for each subsystem, as there will be only one driver registered to a single DT node. With a drivers/soc we'd have a good place for those messy, SoC-specific registers to put a driver that hooks up to a single node and takes care of registering e.g. pinctrl and reset the plain-old platform_device way. It will be a little bit like arm/mach-foo before, but maybe we have to admit that on SoCs there will always be some amount of very specific, non-probable, non-describable registers that simply need special treatment. Sebastian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html