-
Chen-Yu Tsai authored
Only the NanoPC T4 hs the PCIe reset pin routed to the SoC. For the NanoPi M4 family, no such signal is routed to the expansion header on the base board. As the schematics for the expansion board were not released, it is unclear how this is handled, but the likely answer is that the signal is always pulled high. Move the ep-gpios property from the common nanopi4.dtsi file to the board level nanopc-t4.dts file. This makes the nanopi-m4 lack ep-gpios, matching the board design. A companion patch "PCI: rockchip: make ep_gpio optional" for the Linux driver is required, as the driver currently requires the property to be present. Fixes: e7a09590 ("arm64: dts: rockchip: Add devicetree for NanoPC-T4") Reviewed-by:
Robin Murphy <robin.murphy@arm.com> Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Link: https://lore.kernel.org/r/20210121162321.4538-4-wens@kernel.org Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
3503376dChen-Yu Tsai authoredOnly the NanoPC T4 hs the PCIe reset pin routed to the SoC. For the NanoPi M4 family, no such signal is routed to the expansion header on the base board. As the schematics for the expansion board were not released, it is unclear how this is handled, but the likely answer is that the signal is always pulled high. Move the ep-gpios property from the common nanopi4.dtsi file to the board level nanopc-t4.dts file. This makes the nanopi-m4 lack ep-gpios, matching the board design. A companion patch "PCI: rockchip: make ep_gpio optional" for the Linux driver is required, as the driver currently requires the property to be present. Fixes: e7a09590 ("arm64: dts: rockchip: Add devicetree for NanoPC-T4") Reviewed-by:
Loading