| Message ID | 20220606082629.79682-3-sjoerd@collabora.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Add support for Radxa ROCK Pi S | expand |
Hi, On 6/6/22 10:26, Sjoerd Simons wrote: > This enables the following peripherals: > * Onboard ethernet support > * Bluetooth > * USB 2 port > * OTG port via type-c connector > * Hardware watchog > > Also add aliases for the mmc devices and the ethernet interface > > Signed-off-by: Sjoerd Simons <sjoerd@collabora.com> > > --- > > .../boot/dts/rockchip/rk3308-rock-pi-s.dts | 52 +++++++++++++++++++ > 1 file changed, 52 insertions(+) > > diff --git a/arch/arm64/boot/dts/rockchip/rk3308-rock-pi-s.dts b/arch/arm64/boot/dts/rockchip/rk3308-rock-pi-s.dts > index 9095efe25ccd..46ba48b843c5 100644 > --- a/arch/arm64/boot/dts/rockchip/rk3308-rock-pi-s.dts > +++ b/arch/arm64/boot/dts/rockchip/rk3308-rock-pi-s.dts > @@ -11,6 +11,12 @@ / { > model = "Radxa ROCK Pi S"; > compatible = "radxa,rockpis", "rockchip,rk3308"; > > + aliases { > + ethernet0 = &gmac; > + mmc0 = &emmc; > + mmc1 = &sdmmc; Sure? emmc is at address ff49000 which is larger than sdmmc's address ff480000. I believe the aliases should be sorted w.r.t. addresses. Best regards, Michael > + }; > + > chosen { > stdout-path = "serial0:1500000n8"; > }; > @@ -132,6 +138,15 @@ &emmc { > status = "okay"; > }; > > +&gmac { > + clock_in_out = "output"; > + phy-supply = <&vcc_io>; > + snps,reset-gpio = <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>; > + snps,reset-active-low; > + snps,reset-delays-us = <0 50000 50000>; > + status = "okay"; > +}; > + > &i2c1 { > status = "okay"; > }; > @@ -195,10 +210,47 @@ &sdmmc { > status = "okay"; > }; > > +&u2phy { > + status = "okay"; > + > + u2phy_host: host-port { > + phy-supply = <&vcc5v0_otg>; > + status = "okay"; > + }; > + > + u2phy_otg: otg-port { > + phy-supply = <&vcc5v0_otg>; > + status = "okay"; > + }; > +}; > + > &uart0 { > status = "okay"; > }; > > &uart4 { > status = "okay"; > + > + bluetooth { > + compatible = "realtek,rtl8723bs-bt"; > + device-wake-gpios = <&gpio4 RK_PB3 GPIO_ACTIVE_HIGH>; > + host-wake-gpios = <&gpio4 RK_PB4 GPIO_ACTIVE_HIGH>; > + }; > +}; > + > +&usb_host_ehci { > + status = "okay"; > +}; > + > +&usb_host_ohci { > + status = "okay"; > +}; > + > +&usb20_otg { > + dr_mode = "peripheral"; > + status = "okay"; > +}; > + > +&wdt { > + status = "okay"; > };
Hey Michael, On Mon, 2022-06-06 at 14:00 +0200, Michael Riesch wrote: > > > + aliases { > > + ethernet0 = &gmac; > > + mmc0 = &emmc; > > + mmc1 = &sdmmc; > > Sure? emmc is at address ff49000 which is larger than sdmmc's address > ff480000. I believe the aliases should be sorted w.r.t. addresses. Do you have a reference about this sorting requirement? Also do you mean that mmc0 should be &sdmmc *or* that the aliases should have mmc1 listed first. For reference the reason is that mmc0 is emmc is because it seems more logical to have the builtin devices come first (e.g. as mmcblk0) > Best regards, > Michael > > > + }; > > + > > chosen { > > stdout-path = "serial0:1500000n8"; > > }; > > @@ -132,6 +138,15 @@ &emmc { > > status = "okay"; > > }; > > > > +&gmac { > > + clock_in_out = "output"; > > + phy-supply = <&vcc_io>; > > + snps,reset-gpio = <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>; > > + snps,reset-active-low; > > + snps,reset-delays-us = <0 50000 50000>; > > + status = "okay"; > > +}; > > + > > &i2c1 { > > status = "okay"; > > }; > > @@ -195,10 +210,47 @@ &sdmmc { > > status = "okay"; > > }; > > > > +&u2phy { > > + status = "okay"; > > + > > + u2phy_host: host-port { > > + phy-supply = <&vcc5v0_otg>; > > + status = "okay"; > > + }; > > + > > + u2phy_otg: otg-port { > > + phy-supply = <&vcc5v0_otg>; > > + status = "okay"; > > + }; > > +}; > > + > > &uart0 { > > status = "okay"; > > }; > > > > &uart4 { > > status = "okay"; > > + > > + bluetooth { > > + compatible = "realtek,rtl8723bs-bt"; > > + device-wake-gpios = <&gpio4 RK_PB3 > > GPIO_ACTIVE_HIGH>; > > + host-wake-gpios = <&gpio4 RK_PB4 GPIO_ACTIVE_HIGH>; > > + }; > > +}; > > + > > +&usb_host_ehci { > > + status = "okay"; > > +}; > > + > > +&usb_host_ohci { > > + status = "okay"; > > +}; > > + > > +&usb20_otg { > > + dr_mode = "peripheral"; > > + status = "okay"; > > +}; > > + > > +&wdt { > > + status = "okay"; > > };
Am Mittwoch, 8. Juni 2022, 14:07:33 CEST schrieb Sjoerd Simons: > Hey Michael, > > On Mon, 2022-06-06 at 14:00 +0200, Michael Riesch wrote: > > > > > + aliases { > > > + ethernet0 = &gmac; > > > + mmc0 = &emmc; > > > + mmc1 = &sdmmc; > > > > Sure? emmc is at address ff49000 which is larger than sdmmc's address > > ff480000. I believe the aliases should be sorted w.r.t. addresses. > > Do you have a reference about this sorting requirement? I do believe we used that mmcx -> *mmc-device sorted by address when the aliases still were in the main soc dtsi. Simply because one couldn't really know what was available on a specific board (no emmc for example). I guess now on a per-board level we could actually do that more relaxed and let that be the decision of the board submitter ;-) . Heiko > Also do you mean that mmc0 should be &sdmmc *or* that the aliases > should have mmc1 listed first. > > For reference the reason is that mmc0 is emmc is because it seems more > logical to have the builtin devices come first (e.g. as mmcblk0) > > > > Best regards, > > Michael > > > > > + }; > > > + > > > chosen { > > > stdout-path = "serial0:1500000n8"; > > > }; > > > @@ -132,6 +138,15 @@ &emmc { > > > status = "okay"; > > > }; > > > > > > +&gmac { > > > + clock_in_out = "output"; > > > + phy-supply = <&vcc_io>; > > > + snps,reset-gpio = <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>; > > > + snps,reset-active-low; > > > + snps,reset-delays-us = <0 50000 50000>; > > > + status = "okay"; > > > +}; > > > + > > > &i2c1 { > > > status = "okay"; > > > }; > > > @@ -195,10 +210,47 @@ &sdmmc { > > > status = "okay"; > > > }; > > > > > > +&u2phy { > > > + status = "okay"; > > > + > > > + u2phy_host: host-port { > > > + phy-supply = <&vcc5v0_otg>; > > > + status = "okay"; > > > + }; > > > + > > > + u2phy_otg: otg-port { > > > + phy-supply = <&vcc5v0_otg>; > > > + status = "okay"; > > > + }; > > > +}; > > > + > > > &uart0 { > > > status = "okay"; > > > }; > > > > > > &uart4 { > > > status = "okay"; > > > + > > > + bluetooth { > > > + compatible = "realtek,rtl8723bs-bt"; > > > + device-wake-gpios = <&gpio4 RK_PB3 > > > GPIO_ACTIVE_HIGH>; > > > + host-wake-gpios = <&gpio4 RK_PB4 GPIO_ACTIVE_HIGH>; > > > + }; > > > +}; > > > + > > > +&usb_host_ehci { > > > + status = "okay"; > > > +}; > > > + > > > +&usb_host_ohci { > > > + status = "okay"; > > > +}; > > > + > > > +&usb20_otg { > > > + dr_mode = "peripheral"; > > > + status = "okay"; > > > +}; > > > + > > > +&wdt { > > > + status = "okay"; > > > }; > >
Hi all, On 6/8/22 14:19, Heiko Stübner wrote: > Am Mittwoch, 8. Juni 2022, 14:07:33 CEST schrieb Sjoerd Simons: >> Hey Michael, >> >> On Mon, 2022-06-06 at 14:00 +0200, Michael Riesch wrote: >>> >>>> + aliases { >>>> + ethernet0 = &gmac; >>>> + mmc0 = &emmc; >>>> + mmc1 = &sdmmc; >>> >>> Sure? emmc is at address ff49000 which is larger than sdmmc's address >>> ff480000. I believe the aliases should be sorted w.r.t. addresses. >> >> Do you have a reference about this sorting requirement? No, not really. I did have the impression that such a convention existed... > I do believe we used that mmcx -> *mmc-device sorted by address > when the aliases still were in the main soc dtsi. Simply because one > couldn't really know what was available on a specific board > (no emmc for example). ... and this seems to be the case indeed... > I guess now on a per-board level we could actually do that more relaxed > and let that be the decision of the board submitter ;-) . ... but apparently the convention is not that crucial anymore :-) Just wanted to point it out. >> Also do you mean that mmc0 should be &sdmmc *or* that the aliases >> should have mmc1 listed first. FTR, I would have suggested mmc0 = &sdmmc; mmc1 = &emmc; according to said convention, but then I would also take a look on whatever any other rk3308 boards do and aim to be in sync... >> For reference the reason is that mmc0 is emmc is because it seems more >> logical to have the builtin devices come first (e.g. as mmcblk0) ... unless there is a good reason not to. You be the judge of that ;-) Best regards, Michael >> [...]
diff --git a/arch/arm64/boot/dts/rockchip/rk3308-rock-pi-s.dts b/arch/arm64/boot/dts/rockchip/rk3308-rock-pi-s.dts index 9095efe25ccd..46ba48b843c5 100644 --- a/arch/arm64/boot/dts/rockchip/rk3308-rock-pi-s.dts +++ b/arch/arm64/boot/dts/rockchip/rk3308-rock-pi-s.dts @@ -11,6 +11,12 @@ / { model = "Radxa ROCK Pi S"; compatible = "radxa,rockpis", "rockchip,rk3308"; + aliases { + ethernet0 = &gmac; + mmc0 = &emmc; + mmc1 = &sdmmc; + }; + chosen { stdout-path = "serial0:1500000n8"; }; @@ -132,6 +138,15 @@ &emmc { status = "okay"; }; +&gmac { + clock_in_out = "output"; + phy-supply = <&vcc_io>; + snps,reset-gpio = <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>; + snps,reset-active-low; + snps,reset-delays-us = <0 50000 50000>; + status = "okay"; +}; + &i2c1 { status = "okay"; }; @@ -195,10 +210,47 @@ &sdmmc { status = "okay"; }; +&u2phy { + status = "okay"; + + u2phy_host: host-port { + phy-supply = <&vcc5v0_otg>; + status = "okay"; + }; + + u2phy_otg: otg-port { + phy-supply = <&vcc5v0_otg>; + status = "okay"; + }; +}; + &uart0 { status = "okay"; }; &uart4 { status = "okay"; + + bluetooth { + compatible = "realtek,rtl8723bs-bt"; + device-wake-gpios = <&gpio4 RK_PB3 GPIO_ACTIVE_HIGH>; + host-wake-gpios = <&gpio4 RK_PB4 GPIO_ACTIVE_HIGH>; + }; +}; + +&usb_host_ehci { + status = "okay"; +}; + +&usb_host_ohci { + status = "okay"; +}; + +&usb20_otg { + dr_mode = "peripheral"; + status = "okay"; +}; + +&wdt { + status = "okay"; };
This enables the following peripherals: * Onboard ethernet support * Bluetooth * USB 2 port * OTG port via type-c connector * Hardware watchog Also add aliases for the mmc devices and the ethernet interface Signed-off-by: Sjoerd Simons <sjoerd@collabora.com> --- .../boot/dts/rockchip/rk3308-rock-pi-s.dts | 52 +++++++++++++++++++ 1 file changed, 52 insertions(+)