BPI-R3 : problem with pcie

[frank-w]

Mtk responded to patch

• patch cause regression on platforms with multiple pcie-ports
• r3 seem to miss coupling capacitors and so problem seems to be caused by signal quality

https://patchwork.kernel.org/project/linux-mediatek/patch/[email protected]/#25317833

@sinovoip @simon can you confirm this or give mtk (Jianjun Wang) the full shematic?

Can anyone (maybe @RRKh61 @f11 @doudootiana ) please try to remove the existing msleep(100) above the patch and test if the issue is still fixed? As i do not had the issue i cannot verify it…seems to only happen with some special m.2 devices

[RRKh61]

Hello Frank.

I tested the patch with removing the existing msleep(100), it gave the same result as without the patch, i.e. no disk detection on cold start.

In attach modified patch and “Kernel Log” for cold start with original patch and cold/hot start with modified patch (no existing msleep(100)).

modified_bad.patch (702 Байта) good_patch_cold_start.txt (31.5 КБ) bad_patch_cold_start.txt (22.3 КБ) bad_patch_hot_start.txt (31.2 КБ)

P.S. My NVME SSD Patriot P300P1TBM28, probably NVME controller - Maxio MAP1202A-F1C

[jianjun]

Hi RRKh61,

Can you please try if the following changes work for your case?

--- a/drivers/pci/controller/pcie-mediatek-gen3.c
+++ b/drivers/pci/controller/pcie-mediatek-gen3.c
@@ -341,16 +341,22 @@ static int mtk_pcie_startup_port(struct mtk_gen3_pcie *pcie)
        val |= PCIE_MAC_RSTB | PCIE_PHY_RSTB | PCIE_BRG_RSTB | PCIE_PE_RSTB;
        writel_relaxed(val, pcie->base + PCIE_RST_CTRL_REG);

+       usleep_range(10 * 1000, 15 * 1000);
+
+       /* De-assert reset signals */
+       val &= ~(PCIE_MAC_RSTB | PCIE_PHY_RSTB | PCIE_BRG_RSTB);

	/*
	 * Described in PCIe CEM specification sections 2.2 (PERST# Signal)
	 * and 2.2.1 (Initial Power-Up (G3 to S0)).
	 * The deassertion of PERST# should be delayed 100ms (TPVPERL)
	 * for the power and clock to become stable.
	 */
-       msleep(100);
+       msleep(90);

-       /* De-assert reset signals */
-       val &= ~(PCIE_MAC_RSTB | PCIE_PHY_RSTB | PCIE_BRG_RSTB | PCIE_PE_RSTB);
+       /* De-assert PERST# signals */
+       val &= ~PCIE_PE_RSTB;
        writel_relaxed(val, pcie->base + PCIE_RST_CTRL_REG);

[Nakato]

I’m able to reproduce this behaviour as well, and my hardware is similar to RRKh61.

NVMe: Patriot P310P240GM28, reported as MAXIO Technology (Hangzhou) Ltd. NVMe SSD Controller MAP1202 (rev 01)

For the dmesg output attached I’ve taken notes and placed those at the beginning of those files to attempt to make it clear what each dmesg output pertains to. This includes noting if the PCI root is visible in lspci on cold boot as well as the nvme drive, and including the patch used on the kernel that the output was produced from.

1. No patch In general, the PCI root doesn’t appear, but sometimes it and the nvme drive will show up on a cold boot, it’s exceedingly rare though. bpir3-dmesg-and-notes.txt (27.1 KB)

2. frank-w’s original patch Two dmesg are included. One where the PCI root exists, but no NVMe and the other with both. The nvme worked once out of over 20 cold boots. bpir3-frankw-coldboot1-dmesg-and-notes.txt (28.1 KB) bpir3-frankw-coldboot2-dmesg-and-notes.txt (29.7 KB)

3. jianjun’s patch, as posted. This was the same as no-patch. It looks to me that the patch is missing a write to the device registers between /* De-assert reset signals */ and the msleep(90). bpir3-jianjun-patch-dmesg-and-notes.txt (28.0 KB)

4. jianjun’s patch with writel_relaxed(val, pcie->base + PCIE_RST_CTRL_REG); inserted after val &= ~(PCIE_MAC_RSTB | PCIE_PHY_RSTB | PCIE_BRG_RSTB);, patch included in the attached dmesg, which should retain formatting. I cold-booted this one 5 times and each time received the PCI root, but no NVMe device. bpir3-jianjun-patch-modified-dmesg-and-notes.txt (28.9 KB)