[RFC 4/7] ARM: dts: add support for Vybrid running on Cortex-M4

[arnd@arndb.de (Arnd Bergmann)]

On Monday 13 October 2014 18:11:19 Stefan Agner wrote:
> Am 2014-10-13 13:24, schrieb Arnd Bergmann:
> > On Monday 13 October 2014 13:08:12 Stefan Agner wrote:
> >> Am 2014-10-13 12:32, schrieb Mark Rutland:
> >> > On Sun, Oct 12, 2014 at 07:13:58PM +0100, Stefan Agner wrote:
> >> >> This adds an initial device tree to run Linux on the Cortex-M4 on
> >> >> Vybrid.
> >> >>
> >> >> HACK: Because we include armv7-m.dtsi, the soc node happens to
> >> >> be before the clock node. This is a problem for vf610-clk.c, which
> >> >> tries to optain the fixed clocks defined in the clock nodes. But
> >> >> because clock drivers are initialized sequencially, and we do not
> >> >> have support for deferred probing, the clock initialization fails
> >> >> horrible.
> >> >> Move the armv7-m.dtsi include to the bottom to temporarily work
> >> >> work around this...
> >> >>
> >> >> Signed-off-by: Stefan Agner <stefan@agner.ch>
> >> >> ---
> >> >> Maybe a dummy soc entry in armv7-m.dtsi also helps here. But a
> >> >> hack as well. Is it common acceptable that the kernel depends
> >> >> on DTS order?
> >> >
> >> > The kernel should not depend on DTS ordering. We should sort out
> >> > deferred probing if there is an issue with it.
> >> >
> >> > [...]
> >>
> >> Yes I guess to make this working independent of device tree order, we
> >> need to defer probing of vf610-clk when the fixed clocks are not
> >> initialized yet.
> >>
> >> Clock initialization (using CLK_OF_DECLARE) doesn't support EPROBE_DEFER
> >> currently.
> >>
> >> We seem to have already a work around merged because of this.
> >> http://thread.gmane.org/gmane.linux.kernel/1635576
> > 
> > Ah, maybe that's what I remembered. The clock handling should probably
> > do something similar to what we do for irqchips, where we probe the
> > parents first.
> > 
> 
> Would parent really work here? I mean, vf610-"clk"'s parent is
> "aips-bus", then "soc" versus "fxosc"'s parent is "clock" (which I can
> omit according to Mark), so different branches starting from the root. A
> depth based initialization order would help, but this looks rather
> arbitrary.

I meant parents in the clock tree not the device tree. The clock parents
are the nodes listed in the 'clocks' property of a child clock device
node.

This would be similar to how it works for interrupt-controllers, where
we follow the "interrupt-parent" properties.

	Arnd