All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Klotz <DaveWK225@protonmail.com>
To: u-boot@lists.u-boot-project.org
Cc: Huan Zhou <pericycle.cc@gmail.com>,
	Eric Chung <eric.chung@riscstar.com>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Yixun Lan <dlan@kernel.org>, Tom Rini <trini@konsulko.com>,
	u-boot-spacemit@groups.io
Subject: [PATCH 0/9] pci: spacemit: fixes for the K1 PCIe host driver
Date: Fri, 02 Oct 2026 21:30:32 +0000	[thread overview]
Message-ID: <cover.1790975598.git.DaveWK225@protonmail.com> (raw)

Fixes for "pci: spacemit: add DesignWare PCIe host controller driver",
following the Linux driver and the bring-up order that works on the
boards I have:

- power the slot from the root port's vpcie3v3-supply (the vendor
  k1x,pwr_on property is not in any upstream device tree);
- keep the PHY interface in reset until LTSSM enable, and soft-reset
  the controller before bring-up so a warm reset starts clean;
- check clock, reset and iATU setup errors;
- report link up from the SMLH/RDLH bits in the link window;
- leave the link speed alone unless max-link-speed is set, instead of
  writing Gen1 into LNKCAP and LNKCTL2, so the OS can still train the
  link at its full speed;
- drop ASPM L1 from LNKCAP as Linux does for NVMe drives;
- set the link width from num-lanes;
- keep the probe successful when the link is down (an empty slot), and
  answer config cycles behind a down link with all ones.

Tested on an OrangePi RV2: an NVMe drive on port B is found and
FreeBSD boots from it by EFI; FreeBSD then retrains the link to x2 at
5 GT/s (with the Gen1 cap in place it could not). Port C, empty, reports
"Link down" and nothing hangs. Under U-Boot this drive still trains x1
at 2.5 GT/s.

Two observations about the RV2 device tree, not addressed here:
pcie1_3_cfg and pcie2_4_cfg mux CLKREQ#, and with CLKREQ# muxed the
controller gates its DBI clock whenever the endpoint leaves CLKREQ# high,
so the next DBI access hangs; I run the board with PERST# only in those
groups. And port B needs num-lanes = <2>, which the tree does not set.

Dave Klotz (9):
  pci: spacemit: power the slot from vpcie3v3-supply
  pci: spacemit: hold the PHY interface in reset until link start
  pci: spacemit: soft reset the controller before bring-up
  pci: spacemit: check clock, reset and iATU setup results
  pci: spacemit: report link up from the link status register
  pci: spacemit: do not force the link to 2.5 GT/s
  pci: spacemit: do not advertise ASPM L1
  pci: spacemit: set the link width from num-lanes
  pci: spacemit: do not fail the probe when the link is down

 drivers/pci/pcie_dw_spacemit.c | 231 +++++++++++++++++++++++----------
 drivers/pci/pcie_dw_spacemit.h |  12 --
 2 files changed, 162 insertions(+), 81 deletions(-)


base-commit: a000f2af240eaa996cec92f8d44bad96fdf3f898
-- 
2.55.0



WARNING: multiple messages have this Message-ID (diff)
From: Dave Klotz <DaveWK225@protonmail.com>
To: u-boot@lists.u-boot-project.org
Cc: Huan Zhou <pericycle.cc@gmail.com>,
	Eric Chung <eric.chung@riscstar.com>, Yixun Lan <dlan@kernel.org>,
	Tom Rini <trini@konsulko.com>, Guodong Xu <guodong@riscstar.com>,
	Raymond Mao <raymond.mao@riscstar.com>,
	u-boot-spacemit@groups.io
Subject: [PATCH 0/2] spacemit: k1: SPL robustness for boards without a PMIC or SPI NOR
Date: Fri, 02 Oct 2026 21:31:33 +0000	[thread overview]
Message-ID: <cover.1790975598.git.DaveWK225@protonmail.com> (raw)
Message-ID: <20261002213133.GTPAJWy-qdnCacf-4wbD3uPXAWd8ZgASBkeU7uocbsw@z> (raw)

Two small SPL changes for K1 boards that do not look like the BPI-F3
and MusePi Pro:

1. pmic_init() and nor_early_init() panic when the device tree gives
   the SPL no PMIC or no SPI controller. A board that boots from eMMC or
   microSD with its rails already up (the OrangePi R2S and RV2) stops
   there. Log it and carry on.
2. Provide board_boot_order(): the device the BootROM booted from, as
   detected now, then the other MMC controller and SPI NOR, so an
   unexpected BootROM path still finds U-Boot.

Tested on an OrangePi RV2 booting from microSD (no SPI controller in
the SPL): "No SPI controller", then the SPL loads U-Boot from the card
through the detected MMC2. The fallback order was not exercised, since
the detection was right.

Dave Klotz (2):
  spacemit: k1: do not require a PMIC or an SPI controller in SPL
  spacemit: k1: fall back to the other boot devices in SPL

 board/spacemit/k1/spl.c | 48 +++++++++++++++++++++++++++++++++++++----
 1 file changed, 44 insertions(+), 4 deletions(-)


base-commit: a000f2af240eaa996cec92f8d44bad96fdf3f898
-- 
2.55.0



             reply	other threads:[~2026-10-02 21:31 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-02 21:30 Dave Klotz [this message]
2026-10-02 21:31 ` [PATCH 0/2] spacemit: k1: SPL robustness for boards without a PMIC or SPI NOR Dave Klotz
2026-10-02 21:30 ` [PATCH 1/9] pci: spacemit: power the slot from vpcie3v3-supply Dave Klotz
2026-10-02 21:30 ` [PATCH 2/9] pci: spacemit: hold the PHY interface in reset until link start Dave Klotz
2026-10-02 21:30 ` [PATCH 3/9] pci: spacemit: soft reset the controller before bring-up Dave Klotz
2026-10-02 21:30 ` [PATCH 4/9] pci: spacemit: check clock, reset and iATU setup results Dave Klotz
2026-10-02 21:31 ` [PATCH 5/9] pci: spacemit: report link up from the link status register Dave Klotz
2026-10-02 21:31 ` [PATCH 6/9] pci: spacemit: do not force the link to 2.5 GT/s Dave Klotz
2026-10-02 21:31 ` [PATCH 7/9] pci: spacemit: do not advertise ASPM L1 Dave Klotz
2026-10-02 21:31 ` [PATCH 8/9] pci: spacemit: set the link width from num-lanes Dave Klotz
2026-10-02 21:31 ` [PATCH 9/9] pci: spacemit: do not fail the probe when the link is down Dave Klotz
2026-10-02 21:31 ` [PATCH 1/2] spacemit: k1: do not require a PMIC or an SPI controller in SPL Dave Klotz
2026-10-02 21:31 ` [PATCH 2/2] spacemit: k1: fall back to the other boot devices " Dave Klotz

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=cover.1790975598.git.DaveWK225@protonmail.com \
    --to=davewk225@protonmail.com \
    --cc=dlan@kernel.org \
    --cc=eric.chung@riscstar.com \
    --cc=neil.armstrong@linaro.org \
    --cc=pericycle.cc@gmail.com \
    --cc=trini@konsulko.com \
    --cc=u-boot-spacemit@groups.io \
    --cc=u-boot@lists.u-boot-project.org \
    /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.