| Message ID | b3dd902655e9cc4496170a05a907fcce5a687427.1413136383.git.stefan@agner.ch (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sunday 12 October 2014 20:13:58 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. I thought that was fixed recently. > 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? Generally speaking, the kernel should not rely on the order of nodes in the dtb. > diff --git a/arch/arm/boot/dts/vf610m4.dts b/arch/arm/boot/dts/vf610m4.dts > new file mode 100644 > index 0000000..61488fe > --- /dev/null > +++ b/arch/arm/boot/dts/vf610m4.dts > @@ -0,0 +1,144 @@ > +/* > + * Device tree for VF610 Cortex-M4 support > + */ > + > +/dts-v1/; > +#include "skeleton.dtsi" > +#include "vf610-pinfunc.h" > +#include <dt-bindings/clock/vf610-clock.h> > + > +/ { > + model = "VF610 Cortex-M4"; > + compatible = "fsl,vf610m4"; > + > + chosen { > + bootargs = "console=ttyLP0,115200 ignore_loglevel ihash_entries=64 dhash_entries=64 earlyprintk clk_ignore_unused init=/linuxrc root=/dev/mmcblk0p2 rootwait"; > + }; > + > + memory { > + reg = <0x88000000 0x2000000>; > + }; > + > + aliases { > + serial0 = &uart2; > + }; All of these are board specific, the common way to handle this is to make a vf610m4.dtsi file and include that from a v6610m4-myboard.dts file which sets the properties. The command line should actually be set by the boot loader. Also, it would be good to make the uart driver handle the early console setup through the stdout-path property. > + > + soc { > + aips0: aips-bus@40000000 { > + compatible = "fsl,aips-bus", "simple-bus"; > + #address-cells = <1>; > + #size-cells = <1>; > + reg = <0x40000000 0x70000>; > + ranges; > + > +/* > + uart0: serial@40027000 { > + compatible = "fsl,vf610-lpuart"; > + reg = <0x40027000 0x1000>; > + interrupts = <61>; > + clocks = <&clks VF610_CLK_UART0>; > + clock-names = "ipg"; > + status = "okay"; > + }; > + > + uart1: serial@40028000 { > + compatible = "fsl,vf610-lpuart"; > + reg = <0x40028000 0x1000>; > + interrupts = <62>; > + clocks = <&clks VF610_CLK_UART1>; > + clock-names = "ipg"; > + status = "okay"; > + }; > +*/ Don't comment out nodes, just make them as 'status="disabled"'. For any peripherals that are accessible to both the m4 and the a5 core, it might be nice to put them into a shared .dtsi file. Arnd
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. [...] > + clocks { > + #address-cells = <1>; > + #size-cells = <0>; > + > + sxosc { > + compatible = "fixed-clock"; > + #clock-cells = <0>; > + clock-frequency = <32768>; > + }; > + > + fxosc { > + compatible = "fixed-clock"; > + #clock-cells = <0>; > + clock-frequency = <24000000>; > + }; > + }; Please get rid of the clocks node and put these under the root node. There is nothing special about clocks, and the kernel in no way handles a clocks node specially. > + > + 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? Thanks, Mark.
Am 2014-10-12 20:56, schrieb Arnd Bergmann: > On Sunday 12 October 2014 20:13:58 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. > > I thought that was fixed recently. Unless it was very recently, it didn't solve my case. Both, clk-fixed-rate as well as clk-vf610 are initialized using CLK_OF_DECLARE. So I guess its the dt order. Or is it compile time order? But I think driver code is linked before arch code. > >> 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? > > Generally speaking, the kernel should not rely on the order of > nodes in the dtb. > >> diff --git a/arch/arm/boot/dts/vf610m4.dts b/arch/arm/boot/dts/vf610m4.dts >> new file mode 100644 >> index 0000000..61488fe >> --- /dev/null >> +++ b/arch/arm/boot/dts/vf610m4.dts >> @@ -0,0 +1,144 @@ >> +/* >> + * Device tree for VF610 Cortex-M4 support >> + */ >> + >> +/dts-v1/; >> +#include "skeleton.dtsi" >> +#include "vf610-pinfunc.h" >> +#include <dt-bindings/clock/vf610-clock.h> >> + >> +/ { >> + model = "VF610 Cortex-M4"; >> + compatible = "fsl,vf610m4"; >> + >> + chosen { >> + bootargs = "console=ttyLP0,115200 ignore_loglevel ihash_entries=64 dhash_entries=64 earlyprintk clk_ignore_unused init=/linuxrc root=/dev/mmcblk0p2 rootwait"; >> + }; >> + >> + memory { >> + reg = <0x88000000 0x2000000>; >> + }; >> + >> + aliases { >> + serial0 = &uart2; >> + }; > > All of these are board specific, the common way to handle this is to make > a vf610m4.dtsi file and include that from a v6610m4-myboard.dts file > which sets the properties. > > The command line should actually be set by the boot loader. Hm, this would then be a feature needed in the small boot loader I plan to integrate with m4boot. > Also, it would be good to make the UART driver handle the early console > setup through the stdout-path property. Ok, having a look at that. Do I see things right that this is somewhat like a default "console=" argument? But probably not picked up by user-space (systemd) later on... > >> + >> + soc { >> + aips0: aips-bus@40000000 { >> + compatible = "fsl,aips-bus", "simple-bus"; >> + #address-cells = <1>; >> + #size-cells = <1>; >> + reg = <0x40000000 0x70000>; >> + ranges; >> + >> +/* >> + uart0: serial@40027000 { >> + compatible = "fsl,vf610-lpuart"; >> + reg = <0x40027000 0x1000>; >> + interrupts = <61>; >> + clocks = <&clks VF610_CLK_UART0>; >> + clock-names = "ipg"; >> + status = "okay"; >> + }; >> + >> + uart1: serial@40028000 { >> + compatible = "fsl,vf610-lpuart"; >> + reg = <0x40028000 0x1000>; >> + interrupts = <62>; >> + clocks = <&clks VF610_CLK_UART1>; >> + clock-names = "ipg"; >> + status = "okay"; >> + }; >> +*/ > > Don't comment out nodes, just make them as 'status="disabled"'. > > For any peripherals that are accessible to both the m4 and the a5 > core, it might be nice to put them into a shared .dtsi file. Hm, actually all peripherals are accessible from both core. However, since we do have different interrupt controllers, the interrupt property looks different. But I guess it's perfectly ok to add this property in the m4 and a5 specific dtsi. We already discussed the shared dtsi issue for Vybird in a different thread (VF500 support). Considering we want to create a shared dtsi for both cores and all variants, I guess it would something look like that: vfxxx.dtsi => vf500.dtsi (Cortex-A5, single core) => vf600m4.dtsi (Cortex-M4) => vf600.dtsi (Cortex-A5) => vf610.dtsi (Cortex-A5 with L2 Cache) Or do we want the core included on all dtsi? vfxxx.dtsi => vf500a5.dtsi (Cortex-A5, single core) => vf600m4.dtsi (Cortex-M4) => vf600a5.dtsi (Cortex-A5) => vf610a5.dtsi (Cortex-A5 with L2 Cache) -- Stefan
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 Anybody tried to reverse device tree parsing to unveil how many such assumptions are still slumbering? >> + clocks { >> + #address-cells = <1>; >> + #size-cells = <0>; >> + >> + sxosc { >> + compatible = "fixed-clock"; >> + #clock-cells = <0>; >> + clock-frequency = <32768>; >> + }; >> + >> + fxosc { >> + compatible = "fixed-clock"; >> + #clock-cells = <0>; >> + clock-frequency = <24000000>; >> + }; >> + }; > > Please get rid of the clocks node and put these under the root node. > There is nothing special about clocks, and the kernel in no way handles > a clocks node specially. > >> + >> + 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. -- Stefan
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. > 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
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. >> 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. Oh yes, these seems wrong. I copied this from the vf610.dtsi, but when we make one common file we can fix it for all then. -- Stefan
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
Am 2014-10-13 21:54, schrieb 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. > Ah ok I see. This parent/child relation is not yet part of the Vybrid device tree: slowosc: sxosc { compatible = "fixed-clock"; #clock-cells = <0>; clock-frequency = <32768>; }; fastosc: fxosc { compatible = "fixed-clock"; #clock-cells = <0>; clock-frequency = <24000000>; }; .... clks: ccm@4006b000 { compatible = "fsl,vf610-ccm"; reg = <0x4006b000 0x1000>; #clock-cells = <1>; }; So we would need something like: clocks = <&slowosc>, <&fastosc>; clock-names = "sxosc", "fxosc"; But how can we identify clock tree entries? There is no marker like "clock-controller;" currently, is there? -- Stefan
On Monday 13 October 2014 23:20:38 Stefan Agner wrote: > Ah ok I see. This parent/child relation is not yet part of the Vybrid > device tree: > > > slowosc: sxosc { > compatible = "fixed-clock"; > #clock-cells = <0>; > clock-frequency = <32768>; > }; > fastosc: fxosc { > compatible = "fixed-clock"; > #clock-cells = <0>; > clock-frequency = <24000000>; > }; > > .... > > clks: ccm@4006b000 { > compatible = "fsl,vf610-ccm"; > reg = <0x4006b000 0x1000>; > #clock-cells = <1>; > }; > > So we would need something like: > > clocks = <&slowosc>, <&fastosc>; > clock-names = "sxosc", "fxosc"; > > But how can we identify clock tree entries? There is no marker like > "clock-controller;" currently, is there? Actually it seems the of_clk_init does have all the code it needs: for_each_matching_node_and_match(np, matches, &match) { struct clock_provider *parent = kzalloc(sizeof(struct clock_provider), GFP_KERNEL); parent->clk_init_cb = match->data; parent->np = np; list_add_tail(&parent->node, &clk_provider_list); } while (!list_empty(&clk_provider_list)) { is_init_done = false; list_for_each_entry_safe(clk_provider, next, &clk_provider_list, node) { if (force || parent_ready(clk_provider->np)) { clk_provider->clk_init_cb(clk_provider->np); of_clk_set_defaults(clk_provider->np, true); list_del(&clk_provider->node); kfree(clk_provider); is_init_done = true; } } /* * We didn't manage to initialize any of the * remaining providers during the last loop, so now we * initialize all the remaining ones unconditionally * in case the clock parent was not mandatory */ if (!is_init_done) force = true; } You are just missing the clock properties to describe the hierarchy in your dts. Arnd
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index b8c5cd3..b1c6c1d 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -64,6 +64,7 @@ dtb-$(CONFIG_ARCH_BRCMSTB) += \ dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb \ da850-evm.dtb dtb-$(CONFIG_ARCH_EFM32) += efm32gg-dk3750.dtb +dtb-$(CONFIG_SOC_VF610M4) += vf610m4.dtb dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \ exynos4210-smdkv310.dtb \ exynos4210-trats.dtb \ diff --git a/arch/arm/boot/dts/armv7-m.dtsi b/arch/arm/boot/dts/armv7-m.dtsi index 5a660d0..0516484 100644 --- a/arch/arm/boot/dts/armv7-m.dtsi +++ b/arch/arm/boot/dts/armv7-m.dtsi @@ -1,4 +1,3 @@ -#include "skeleton.dtsi" / { nvic: nv-interrupt-controller { diff --git a/arch/arm/boot/dts/vf610m4.dts b/arch/arm/boot/dts/vf610m4.dts new file mode 100644 index 0000000..61488fe --- /dev/null +++ b/arch/arm/boot/dts/vf610m4.dts @@ -0,0 +1,144 @@ +/* + * Device tree for VF610 Cortex-M4 support + */ + +/dts-v1/; +#include "skeleton.dtsi" +#include "vf610-pinfunc.h" +#include <dt-bindings/clock/vf610-clock.h> + +/ { + model = "VF610 Cortex-M4"; + compatible = "fsl,vf610m4"; + + chosen { + bootargs = "console=ttyLP0,115200 ignore_loglevel ihash_entries=64 dhash_entries=64 earlyprintk clk_ignore_unused init=/linuxrc root=/dev/mmcblk0p2 rootwait"; + }; + + memory { + reg = <0x88000000 0x2000000>; + }; + + aliases { + serial0 = &uart2; + }; + + clocks { + #address-cells = <1>; + #size-cells = <0>; + + sxosc { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <32768>; + }; + + fxosc { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <24000000>; + }; + }; + + soc { + aips0: aips-bus@40000000 { + compatible = "fsl,aips-bus", "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0x40000000 0x70000>; + ranges; + +/* + uart0: serial@40027000 { + compatible = "fsl,vf610-lpuart"; + reg = <0x40027000 0x1000>; + interrupts = <61>; + clocks = <&clks VF610_CLK_UART0>; + clock-names = "ipg"; + status = "okay"; + }; + + uart1: serial@40028000 { + compatible = "fsl,vf610-lpuart"; + reg = <0x40028000 0x1000>; + interrupts = <62>; + clocks = <&clks VF610_CLK_UART1>; + clock-names = "ipg"; + status = "okay"; + }; +*/ + uart2: serial@40029000 { + compatible = "fsl,vf610-lpuart"; + reg = <0x40029000 0x1000>; + interrupts = <63>; + clocks = <&clks VF610_CLK_UART2>; + clock-names = "ipg"; + status = "okay"; + }; + + pit: pit@40037000 { + compatible = "fsl,vf610-pit"; + reg = <0x40037000 0x1000>; + interrupts = <39>; + clocks = <&clks VF610_CLK_PIT>; + clock-names = "pit"; + }; + + iomuxc: iomuxc@40048000 { + compatible = "fsl,vf610-iomuxc"; + reg = <0x40048000 0x1000>; + #gpio-range-cells = <3>; + + vf610-colibri { + pinctrl_esdhc1: esdhc1grp { + fsl,pins = < + VF610_PAD_PTA24__ESDHC1_CLK 0x31ef + VF610_PAD_PTA25__ESDHC1_CMD 0x31ef + VF610_PAD_PTA26__ESDHC1_DAT0 0x31ef + VF610_PAD_PTA27__ESDHC1_DAT1 0x31ef + VF610_PAD_PTA28__ESDHC1_DATA2 0x31ef + VF610_PAD_PTA29__ESDHC1_DAT3 0x31ef + VF610_PAD_PTB20__GPIO_42 0x219d + >; + }; + }; + }; + + anatop@40050000 { + compatible = "fsl,vf610-anatop"; + reg = <0x40050000 0x1000>; + }; + + clks: ccm@4006b000 { + compatible = "fsl,vf610-ccm"; + reg = <0x4006b000 0x1000>; + #clock-cells = <1>; + }; + }; + + aips1: aips-bus@40080000 { + compatible = "fsl,aips-bus", "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0x40080000 0x80000>; + ranges; + + + esdhc1: esdhc@400b2000 { + compatible = "fsl,imx53-esdhc"; + reg = <0x400b2000 0x1000>; + interrupts = <28>; + clocks = <&clks VF610_CLK_IPG_BUS>, + <&clks VF610_CLK_PLATFORM_BUS>, + <&clks VF610_CLK_ESDHC1>; + clock-names = "ipg", "ahb", "per"; + bus-width = <4>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_esdhc1>; + status = "okay"; + }; + }; + }; +}; + +#include "armv7-m.dtsi"
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? arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/armv7-m.dtsi | 1 - arch/arm/boot/dts/vf610m4.dts | 144 +++++++++++++++++++++++++++++++++++++++++ 3 files changed, 145 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/vf610m4.dts