Re: [PATCH v2] ARM: realview: basic device tree implementation

[Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On 05/22/2014 09:41 AM, Linus Walleij wrote:
> On Fri, May 9, 2014 at 12:44 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
>>> +++ b/arch/arm/boot/dts/arm-realview-pb1176.dts
>>
>> Can 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 :-(
> 
>>> +     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