aboutsummaryrefslogtreecommitdiff
path: root/board/xilinx
diff options
context:
space:
mode:
authorPali Rohár2022-07-29 13:29:07 +0200
committerStefan Roese2022-08-09 08:57:23 +0200
commit1da53ae26afc4f084cf35fea706090fa03dc8475 (patch)
tree4d2faa9dfb1d7d6bf655929138015eb3c9497e84 /board/xilinx
parent336a27ab1d3659c7e1dd6a48e017f5074be70eca (diff)
arm: mvebu: turris_omnia: Add support for design with SW reset signals
New Turris Omnia HW board revision requires that software controls peripheral reset signals, namely PERST# signals on mPCIe slots, ethernet phy reset and lan switch reset. Those pins are connected to MCU controlled by MCU i2c API as GPIOs. On new HW board revision those pins stay in reset after board reset and software has to release these peripherals from reset manually. MCU announce this requirement by FEAT_PERIPH_MCU bit in CMD_GET_FEATURES command. On older HW board revisions when FEAT_PERIPH_MCU is not announced, all those reset signals are automatically released after board finish reset. Detect FEAT_PERIPH_MCU bit in board_fix_fdt() and ft_board_setup() functions and insert into device tree blob pcie "reset-gpios" and eth phy "phy-reset-gpios" properties with corresponding MCU gpio definitions. PCIe and eth PHY drivers then automatically release resets during device initialization. Both U-Boot and Linux kernel drivers support those device tree reset properties. Initialization of lan switch on new HW board revision is more complicated. Switch strapping pins are shared with switch RGMII pins. And strapping pins must be in specific configuration after releasing switch reset. Due to pin sharing, it is first required to switch A385 side of switch pins into GPIO mode, set strapping configuration, release switch from reset and after that switch A385 pins back to RGMII mode. Because this complicated setup is not supported by switch DSA drivers and cannot be expressed easily in device tree, implement it manually in SPL function spl_board_init(). So in proper U-Boot and OS/kernel would be lan switch initialized and be in same configuration like it was on old HW board revisions (where reset sequence did those steps at hardware level). Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de> Reviewed-by: Marek Behún <kabel@kernel.org>
Diffstat (limited to 'board/xilinx')
0 files changed, 0 insertions, 0 deletions