| Message ID | 1411371952-5618-4-git-send-email-jingchang.lu@freescale.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Monday 22 September 2014 15:45:49 Jingchang Lu wrote: > @@ -0,0 +1,117 @@ > +/* > + * Copyright 2013-2014 Freescale Semiconductor, Inc. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + */ Can you change the license so this file is available under both GPL and BSD or X11 license? > +/dts-v1/; > +#include "ls1021a.dtsi" > + > +/ { > + model = "LS1021A TWR Board"; > + > + aliases { > + enet2_rgmii_phy = &rgmii_phy1; > + enet0_sgmii_phy = &sgmii_phy2; > + enet1_sgmii_phy = &sgmii_phy0; > + }; > +}; > I've never seen alias nodes for mdio devices. What are these used for? Shouldn't you use 'phy-handle' properties in the ethernet nodes instead? Arnd
>-----Original Message----- >From: Arnd Bergmann [mailto:arnd@arndb.de] >Sent: Tuesday, September 23, 2014 10:54 PM >To: Lu Jingchang-B35083 >Cc: Guo Shawn-R65073; mark.rutland@arm.com; linux-arm- >kernel@lists.infradead.org; devicetree@vger.kernel.org; Lu Chen-B46807; Fu >Chao-B44548 >Subject: Re: [PATCHv4 3/6] ARM: dts: Add initial LS1021A TWR board dts >support > >On Monday 22 September 2014 15:45:49 Jingchang Lu wrote: >> @@ -0,0 +1,117 @@ >> +/* >> + * Copyright 2013-2014 Freescale Semiconductor, Inc. >> + * >> + * This program is free software; you can redistribute it and/or >> +modify >> + * it under the terms of the GNU General Public License as published >> +by >> + * the Free Software Foundation; either version 2 of the License, or >> + * (at your option) any later version. >> + */ > >Can you change the license so this file is available under both GPL and >BSD or X11 license? > I'd like to add this. Is there any template for my reference? Thanks. >> +/dts-v1/; >> +#include "ls1021a.dtsi" >> + >> +/ { >> + model = "LS1021A TWR Board"; >> + >> + aliases { >> + enet2_rgmii_phy = &rgmii_phy1; >> + enet0_sgmii_phy = &sgmii_phy2; >> + enet1_sgmii_phy = &sgmii_phy0; >> + }; >> +}; >> > >I've never seen alias nodes for mdio devices. What are these used for? >Shouldn't you use 'phy-handle' properties in the ethernet nodes instead? > > Arnd The ethernet device nodes already have the phy-handle properties to their mdio nodes. The alias for PHY nodes here is: The ethernet has two kind of PHY interface, one is SGMII, and the other is RGMII, The selection is done by the reset configuration word(RCW), so Phy-handle properties should be change properly to reflecting the PHY interface selection. This is done by fixing up dtb in u-boot before booting the kernel. Thus the alias for PHY nodes is added here for fdt finding the PHY nodes easily. Best Regards, Jingchang
On Wednesday 24 September 2014 05:47:53 Jingchang Lu wrote: > > The ethernet device nodes already have the phy-handle properties to their mdio nodes. > > The alias for PHY nodes here is: > The ethernet has two kind of PHY interface, one is SGMII, and the other is RGMII, > The selection is done by the reset configuration word(RCW), so Phy-handle properties > should be change properly to reflecting the PHY interface selection. This is done > by fixing up dtb in u-boot before booting the kernel. Thus the alias for PHY nodes > is added here for fdt finding the PHY nodes easily. Ok, I see. I thought that this was what the labels in the dtb were supposed to be used for. Can't you do the same thing in u-boot by using a label as opposed to the alias? IIRC you should be able to add an additional label like +&mdio0 { + enet1_sgmii_phy: sgmii_phy0: ethernet-phy@0 { + reg = <0x0>; + }; and then use libfdt to find the node through that, rather than through the alias. I don't know how things are handled on other platforms, but I think that was how it was initially thought up when we introduced the fdt format on PowerPC. Arnd
>-----Original Message----- >From: Arnd Bergmann [mailto:arnd@arndb.de] >Sent: Wednesday, September 24, 2014 5:36 PM >To: Lu Jingchang-B35083 >Cc: Guo Shawn-R65073; mark.rutland@arm.com; linux-arm- >kernel@lists.infradead.org; devicetree@vger.kernel.org; Lu Chen-B46807; Fu >Chao-B44548 >Subject: Re: [PATCHv4 3/6] ARM: dts: Add initial LS1021A TWR board dts >support > >On Wednesday 24 September 2014 05:47:53 Jingchang Lu wrote: >> >> The ethernet device nodes already have the phy-handle properties to >their mdio nodes. >> >> The alias for PHY nodes here is: >> The ethernet has two kind of PHY interface, one is SGMII, and the >> other is RGMII, The selection is done by the reset configuration >> word(RCW), so Phy-handle properties should be change properly to >> reflecting the PHY interface selection. This is done by fixing up dtb >> in u-boot before booting the kernel. Thus the alias for PHY nodes is >added here for fdt finding the PHY nodes easily. > >Ok, I see. I thought that this was what the labels in the dtb were >supposed to be used for. Can't you do the same thing in u-boot by using a >label as opposed to the alias? > >IIRC you should be able to add an additional label like > >+&mdio0 { >+ enet1_sgmii_phy: sgmii_phy0: ethernet-phy@0 { >+ reg = <0x0>; >+ }; > >and then use libfdt to find the node through that, rather than through the >alias. I don't know how things are handled on other platforms, but I think >that was how it was initially thought up when we introduced the fdt format >on PowerPC. > > Arnd We also do the phy-handle fixup on our PowerPC platform based on the aliases, and so I adopt the same way to make these fixup consistent between SoCs. And the u-boot fdt fixup code base on the aliases has been upstreamed, so may we keep this aliases unchanged? BTW, find a node by alias is easily, could you give me some clue on finding a node by a label directly, Thanks. Best Regards, Jingchang
On Wednesday 24 September 2014 11:00:34 Jingchang Lu wrote: > > We also do the phy-handle fixup on our PowerPC platform based on the aliases, > and so I adopt the same way to make these fixup consistent between SoCs. > And the u-boot fdt fixup code base on the aliases has been upstreamed, so may > we keep this aliases unchanged? I don't see a strong reason to change it, it just seemed strange to me. > BTW, find a node by alias is easily, could you give me some clue on finding a node > by a label directly, Thanks. I haven't used libfdt in this way myself, so I don't know how it would be done. However, the idea is that the labels in dts files end up as ELF symbols in the dtb, so you can look them up by following the ELF headers. Arnd
>-----Original Message----- >From: Arnd Bergmann [mailto:arnd@arndb.de] >Sent: Wednesday, September 24, 2014 11:55 PM >To: Lu Jingchang-B35083 >Cc: Guo Shawn-R65073; mark.rutland@arm.com; linux-arm- >kernel@lists.infradead.org; devicetree@vger.kernel.org; Lu Chen-B46807; Fu >Chao-B44548 >Subject: Re: [PATCHv4 3/6] ARM: dts: Add initial LS1021A TWR board dts >support > >On Wednesday 24 September 2014 11:00:34 Jingchang Lu wrote: >> >> We also do the phy-handle fixup on our PowerPC platform based on the >> aliases, and so I adopt the same way to make these fixup consistent >between SoCs. >> And the u-boot fdt fixup code base on the aliases has been upstreamed, >> so may we keep this aliases unchanged? > >I don't see a strong reason to change it, it just seemed strange to me. > >> BTW, find a node by alias is easily, could you give me some clue on >> finding a node by a label directly, Thanks. > >I haven't used libfdt in this way myself, so I don't know how it would be >done. However, the idea is that the labels in dts files end up as ELF >symbols in the dtb, so you can look them up by following the ELF headers. > > Arnd Libfdt doesn't provide way to find a node by label. Label is just a shortcut to a full absolute path, it's useful in device tree source reference, but is hard to find a label after build to dtb. Aliases just provide the way to save a full absolute path in properties like label, but they can be find in dtb after build so that fixup on dtb can find a node efficiently. So I think the aliases for the phy nodes is also reasonable. Many others boards also use labels for various dts nodes. Thanks. Best Regards, Jingchang
On Thursday 25 September 2014 08:06:27 Jingchang Lu wrote: > > Libfdt doesn't provide way to find a node by label. Label is just a shortcut to > a full absolute path, it's useful in device tree source reference, but is hard > to find a label after build to dtb. Aliases just provide the way to save a > full absolute path in properties like label, but they can be find in dtb after > build so that fixup on dtb can find a node efficiently. So I think the aliases > for the phy nodes is also reasonable. Many others boards also use labels for > various dts nodes. Ok, fair enough. I still think it would be a good idea in general to let all boot loaders find nodes and properties by label, which in theory should be simpler than finding them by aliases, but if they don't do that today it should not stop your file from getting merged. Arnd
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index 384aa74..f716461 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -246,6 +246,7 @@ dtb-$(CONFIG_ARCH_MXC) += \ imx6sl-evk.dtb \ imx6sx-sdb.dtb \ ls1021a-qds.dtb \ + ls1021a-twr.dtb \ vf610-colibri-eval-v3.dtb \ vf610-cosmic.dtb \ vf610-twr.dtb diff --git a/arch/arm/boot/dts/ls1021a-twr.dts b/arch/arm/boot/dts/ls1021a-twr.dts new file mode 100755 index 0000000..1a7e9fb --- /dev/null +++ b/arch/arm/boot/dts/ls1021a-twr.dts @@ -0,0 +1,117 @@ +/* + * Copyright 2013-2014 Freescale Semiconductor, Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + */ + +/dts-v1/; +#include "ls1021a.dtsi" + +/ { + model = "LS1021A TWR Board"; + + aliases { + enet2_rgmii_phy = &rgmii_phy1; + enet0_sgmii_phy = &sgmii_phy2; + enet1_sgmii_phy = &sgmii_phy0; + }; +}; + +&dspi1 { + bus-num = <0>; + status = "okay"; + + dspiflash: s25fl064k@0 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "spansion,s25fl064k"; + spi-max-frequency = <16000000>; + spi-cpol; + spi-cpha; + reg = <0>; + }; +}; + +&enet0 { + tbi-handle = <&tbi1>; + phy-handle = <&sgmii_phy2>; + phy-connection-type = "sgmii"; + status = "okay"; +}; + +&enet1 { + tbi-handle = <&tbi1>; + phy-handle = <&sgmii_phy0>; + phy-connection-type = "sgmii"; + status = "okay"; +}; + +&enet2 { + phy-handle = <&rgmii_phy1>; + phy-connection-type = "rgmii-id"; + status = "okay"; +}; + +&i2c0 { + status = "okay"; +}; + +&i2c1 { + status = "okay"; +}; + +&ifc { + status = "okay"; + #address-cells = <2>; + #size-cells = <1>; + /* NOR, and CPLD on board */ + ranges = <0x0 0x0 0x0 0x60000000 0x08000000>; + + nor@0,0 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "cfi-flash"; + reg = <0x0 0x0 0x8000000>; + bank-width = <2>; + device-width = <1>; + }; +}; + +&lpuart0 { + status = "okay"; +}; + +&mdio0 { + sgmii_phy0: ethernet-phy@0 { + reg = <0x0>; + }; + rgmii_phy1: ethernet-phy@1 { + reg = <0x1>; + }; + sgmii_phy2: ethernet-phy@2 { + reg = <0x2>; + }; + tbi1: tbi-phy@1f { + reg = <0x1f>; + device_type = "tbi-phy"; + }; +}; + +&pwm6 { + status = "okay"; +}; + +&pwm7 { + status = "okay"; +}; + +&uart0 { + status = "okay"; +}; + +&uart1 { + status = "okay"; +};