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

On Thu, May 29, 2014 at 12:10 PM, Sebastian Hesselbarth
[off-list ref] wrote:

On 05/29/2014 11:44 AM, Linus Walleij wrote:

quoted

Hmmmm well I want to see that code before I believe it ... but
I get what you mean.

Well, the register set on Berlin I was thinking about tackles pinctrl,
padmux, clock, reset and some other freaky stuff I cannot recall. The
mess in it is that there is no order you can apply to split it up into
separate nodes. Moreover, the next SoC has some registers just shoved
into it, moving some other registers.

Berlin hardware engineers seem to be hellbent on complicating
your life.

The way we will go for it on Berlin is now:

(a) have a single node for the whole chip-ctrl register set
(b) register clk driver on it (early, as it provides timer clk)
(c) register one chip-ctrl driver on it that will
    (d) reserve the iomap,
    (e) register a regmap-mmio,
    (f) register platform_devices for {pinctrl,reset,...} that will
        use regmap-mmio and read their properties from the single
        node

OK makes perfect sense actually.

The individual drivers should stay in their respective drivers/ folder,
but (c) needs a good home. It would have been mach-foo in the past, and
could be drivers/soc now. In (f), I tend to just lookup regmap by name,
no DT involved at all.

OK

BTW, syscon is of no use here at all, once it registers itself as a
driver for the node, there will be no other drivers registered. That
would at least require (again subsystem driven) dummy-nodes for
pinctrl, clk, reset.

Yeah that sucks, we need something more flexible no question
about that.

Will the chipctrl driver be as generic as syscon or a
Berlin-specific thing?

Also, using some of_xlate as we already have for clk, gpio, pinctrl ...
would put an end to syscon's syscon_get_regmap_from_{foo,bar,baz,...}
that gets a new helper every cycle.

This part I don't understand but I guess I will understand it
when I see the code.

Yours,
Linus Walleij