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@xxxxxxxx> > >> --- > >> 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. > Anybody tried to reverse device tree parsing to unveil how many such > assumptions are still slumbering? Not that I'm aware of. Sounds like a good thing to try. > >> + > >> + soc { > >> + aips0: aips-bus@40000000 { > >> + compatible = "fsl,aips-bus", "simple-bus"; > >> + #address-cells = <1>; > >> + #size-cells = <1>; > >> + reg = <0x40000000 0x70000>; > > > > Out of curiosity, given that this can be driven as a simple-bus, what do > > the aips bus registers allow to be configured? > > > > There is a chapter about the AIPS lite bus in the RM, but according to > this the AIPS lite bus itself has no registers by itself. I just noticed that the only child you list below this node uses registers within the area of the bus. I suspect you just confused 'reg' and 'ranges' here, please use 'ranges' to list which registers are visible on the bus, and modify the 'reg' properties of the children as necessary. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
