Hi Markus, Am Donnerstag, 31. Oktober 2019, 19:12:10 CET schrieb Markus Reichl: > Am 31.10.19 um 17:57 schrieb Heiko Stuebner: > > Am Montag, 28. Oktober 2019, 15:47:27 CET schrieb Markus Reichl: > >> rk3399-roc-pc has a PCIe interface. Enable it for use with > >> the M.2 NGFF M_KEY slot on roc-rk3399-mezzanine board. > >> Tested with Samsung 970 evo plus SSD. > >> > >> Signed-off-by: Markus Reichl <m.reichl@xxxxxxxxxxxxx> > >> --- > >> .../arm64/boot/dts/rockchip/rk3399-roc-pc.dts | 38 +++++++++++++++++++ > >> 1 file changed, 38 insertions(+) > >> > >> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts b/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts > >> index 9313251765c7..2d637d54994b 100644 > >> --- a/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts > >> +++ b/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts > >> @@ -158,6 +158,21 @@ > >> regulator-max-microvolt = <1400000>; > >> vin-supply = <&vcc_sys>; > >> }; > >> + > >> + /* on roc-rk3399-mezzanine board */ > > > > I'm undecided on this. From what I've seen that mezzanine board is some > > sort of addon, like a raspberry pi hat. Therefore it's not always present, > > so probably should not be part of the base board dts. > > > > I'm thinking a dt-overlay that can then be activated might be the solution > > of choice, but I've reached out to arm-soc poeple on irc to determine the > > correct course. > > > I have seen some board.dtsi with board_only.dts respective board_extension.dts > in the arch/arm64/boot/dts/rockchip directory. Would that be ok? The answer is twofold I guess ;-) (1) The 100% correct way would probably be to use a devicetree overlay together with capemgr [0] to load the overlay from userspace, but (2a) The distinction between system-on-module + baseboard and board+cape is somewhat foggy I think and it really doesn't look like there will be a big plethora of capes for the roc-rk3399-pc (2b) People may actually want to boot of that nvme pcie drive attached to the mezzanine, so it will be somewhat permanent connection anyway and also the system then cannot wait for userspace to come up first, if the userspace is sitting on that drive ;-) . So I think, going the dts+dts-extension is the best way to go. Heiko [0] https://elinux.org/Capemgr > >> + vcc3v3_pcie: vcc3v3-pcie { > >> + compatible = "regulator-fixed"; > >> + regulator-name = "vcc3v3_pcie"; > >> + enable-active-high; > >> + gpio = <&gpio1 RK_PC1 GPIO_ACTIVE_HIGH>; > >> + pinctrl-names = "default"; > >> + pinctrl-0 = <&vcc3v3_pcie_en>; > >> + regulator-always-on; > >> + regulator-boot-on; > >> + regulator-min-microvolt = <3300000>; > >> + regulator-max-microvolt = <3300000>; > >> + vin-supply = <&dc_12v>; > >> + }; > >> }; > >> > >> &cpu_l0 { > >> @@ -514,6 +529,19 @@ > >> status = "okay"; > >> }; > >> > >> +&pcie_phy { > >> + status = "okay"; > >> +}; > >> + > >> +&pcie0 { > >> + ep-gpios = <&gpio4 RK_PD1 GPIO_ACTIVE_HIGH>; > >> + num-lanes = <4>; > >> + pinctrl-names = "default"; > >> + pinctrl-0 = <&pcie_perst>; > >> + vpcie3v3-supply = <&vcc3v3_pcie>; > >> + status = "okay"; > >> +}; > >> + > >> &pinctrl { > >> lcd-panel { > >> lcd_panel_reset: lcd-panel-reset { > >> @@ -535,6 +563,16 @@ > >> }; > >> }; > >> > >> + pcie { > >> + vcc3v3_pcie_en: vcc3v3-pcie-en { > >> + rockchip,pins = <1 RK_PC1 RK_FUNC_GPIO &pcfg_pull_none>; > >> + }; > >> + > >> + pcie_perst: pcie-perst { > >> + rockchip,pins = <4 RK_PD1 RK_FUNC_GPIO &pcfg_pull_none>; > >> + }; > >> + }; > >> + > >> pmic { > >> vsel1_gpio: vsel1-gpio { > >> rockchip,pins = <1 RK_PC2 RK_FUNC_GPIO &pcfg_pull_down>; > >> > > > > > > > > > > > > _______________________________________________ > > Linux-rockchip mailing list > > Linux-rockchip@xxxxxxxxxxxxxxxxxxx > > http://lists.infradead.org/mailman/listinfo/linux-rockchip > > >
