From: "Marek Behún" <kabel@kernel.org>
To: "Pali Rohár" <pali@kernel.org>
Cc: Stefan Roese <sr@denx.de>, u-boot@lists.denx.de
Subject: Re: [PATCH 2/2] arm: mvebu: turris_omnia: Add support for design with SW reset signals
Date: Mon, 1 Aug 2022 17:49:19 +0200 [thread overview]
Message-ID: <20220801174919.6982e055@dellmb> (raw)
In-Reply-To: <20220729112907.8207-2-pali@kernel.org>
On Fri, 29 Jul 2022 13:29:07 +0200
Pali Rohár <pali@kernel.org> wrote:
> 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: Marek Behún <kabel@kernel.org>
next prev parent reply other threads:[~2022-08-01 15:49 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-29 11:29 [PATCH 1/2] arm: mvebu: turris_omnia: Show MCU type in show_board_info() Pali Rohár
2022-07-29 11:29 ` [PATCH 2/2] arm: mvebu: turris_omnia: Add support for design with SW reset signals Pali Rohár
2022-08-01 11:58 ` Stefan Roese
2022-08-01 12:19 ` Pali Rohár
2022-08-01 15:49 ` Marek Behún [this message]
2022-08-09 11:32 ` Stefan Roese
2022-08-01 11:56 ` [PATCH 1/2] arm: mvebu: turris_omnia: Show MCU type in show_board_info() Stefan Roese
2022-08-01 15:49 ` Marek Behún
2022-08-09 11:32 ` Stefan Roese
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220801174919.6982e055@dellmb \
--to=kabel@kernel.org \
--cc=pali@kernel.org \
--cc=sr@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.