Skip to content
Commit 1da53ae2 authored by This contributor prefers not to receive mails's avatar This contributor prefers not to receive mails Committed by Stefan Roese
Browse files

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: default avatarPali Rohár <pali@kernel.org>
Reviewed-by: default avatarStefan Roese <sr@denx.de>
Reviewed-by: default avatarMarek Behún <kabel@kernel.org>
parent 336a27ab
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment