From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6F2C8C433FE for ; Thu, 11 Nov 2021 15:36:25 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D131E61354 for ; Thu, 11 Nov 2021 15:36:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D131E61354 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 6CAD983A40; Thu, 11 Nov 2021 16:36:12 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="LjXrOMfI"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id B591683A58; Thu, 11 Nov 2021 16:36:03 +0100 (CET) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 6464383A34 for ; Thu, 11 Nov 2021 16:35:55 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=kabel@kernel.org Received: by mail.kernel.org (Postfix) with ESMTPSA id 239C761284; Thu, 11 Nov 2021 15:35:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1636644954; bh=GDLDzH3Ta6wT43qLRtBWEvbjmQHHCO829OPvC3orIJ8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LjXrOMfIiEfZZwCM0jE95mG6ULQle+avKiZqV9UoeOKV3gvNSeOf4vRKbnbXzSdxH hbE27S/KhqoP/fLwJMsNkBK6T/zLp/Y/qJiCJhqiMPhrYPzQyJPHm5xPgxCVPxGeFF yiDiroT2q194ZvGqtYuUrN49G+HTVvy6gaG/c9/n70dW7Weop34NDbwAIMmtlGspkH UnD3W5ogmDt/fYFnCRtwjZwqXHUbv1+/dYk5/76zJV/qx6R1cjudOrBKNqfy+1Ijq1 +tXWAIfUzrZlEqk1787SRRM5cImwGld/trsOAwXuotcuTbmdwHbriPrWa6ZBhWFFf+ Rpd63E3PgbIyQ== From: =?UTF-8?q?Marek=20Beh=C3=BAn?= To: Stefan Roese Cc: u-boot@lists.denx.de, =?UTF-8?q?Pali=20Roh=C3=A1r?= , =?UTF-8?q?Marek=20Beh=C3=BAn?= Subject: [PATCH u-boot-marvell 01/10] pci: pci_mvebu: Wait 100ms for Link Up in mvebu_pcie_probe() Date: Thu, 11 Nov 2021 16:35:40 +0100 Message-Id: <20211111153549.29111-2-kabel@kernel.org> X-Mailer: git-send-email 2.32.0 In-Reply-To: <20211111153549.29111-1-kabel@kernel.org> References: <20211111153549.29111-1-kabel@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean From: Pali Rohár Function mvebu_pcie_probe() configures PCIe controller and sometimes it takes some time for PCIe card to bring link up. Delay mvebu_pcie_probe() for 100ms to ensure that PCIe link is up after function finish. In the case when no card is connected to the PCIe slot, this will delay probe time by 100ms, which should not be problematic. This change fixes detection and initialization of some QCA98xx cards on the first serdes when configured in x1 mode. Default configuration of the first serdes on A385 is x4 mode, so it looks as if some delay is required when x4 is changed to x1 and card correctly links with A385. Other PCIe serdes ports on A385 are x1-only, and so they don't have this problem. (We need this patch because in the following patch we are moving the configuration change from x4 to x1 from serdes driver to PCIe mvebu driver, because the corresponding register lives in the address space of the PCIe controller. Without that this explicit timeout is not needed, because there is an implicit timeout between change from x4 to x1 and probe of PCIe mvebu driver, due to the first being run in SPL and the second in U-Boot proper.) Signed-off-by: Pali Rohár Signed-off-by: Marek Behún --- drivers/pci/pci_mvebu.c | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/drivers/pci/pci_mvebu.c b/drivers/pci/pci_mvebu.c index 14cd82db6f..a3364d5a59 100644 --- a/drivers/pci/pci_mvebu.c +++ b/drivers/pci/pci_mvebu.c @@ -22,6 +22,7 @@ #include #include #include +#include #include #include #include @@ -70,6 +71,9 @@ DECLARE_GLOBAL_DATA_PTR; #define PCIE_DEBUG_CTRL 0x1a60 #define PCIE_DEBUG_SOFT_RESET BIT(20) +#define LINK_WAIT_RETRIES 100 +#define LINK_WAIT_TIMEOUT 1000 + struct mvebu_pcie { struct pci_controller hose; void __iomem *base; @@ -106,6 +110,23 @@ static inline bool mvebu_pcie_link_up(struct mvebu_pcie *pcie) return !(val & PCIE_STAT_LINK_DOWN); } +static void mvebu_pcie_wait_for_link(struct mvebu_pcie *pcie) +{ + int retries; + + /* check if the link is up or not */ + for (retries = 0; retries < LINK_WAIT_RETRIES; retries++) { + if (mvebu_pcie_link_up(pcie)) { + printf("%s: Link up\n", pcie->name); + return; + } + + udelay(LINK_WAIT_TIMEOUT); + } + + printf("%s: Link down\n", pcie->name); +} + static void mvebu_pcie_set_local_bus_nr(struct mvebu_pcie *pcie, int busno) { u32 stat; @@ -477,6 +498,8 @@ static int mvebu_pcie_probe(struct udevice *dev) pcie->cfgcache[(PCI_PREF_MEMORY_BASE - 0x10) / 4] = PCI_PREF_RANGE_TYPE_64 | (PCI_PREF_RANGE_TYPE_64 << 16); + mvebu_pcie_wait_for_link(pcie); + return 0; } -- 2.32.0