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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A823BC04A6A for ; Thu, 3 Aug 2023 02:24:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:CC:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=JTKhO7V39i6/63EWm59246mRHzOqa8NbkzYL+D8oAAw=; b=JdHXXSh1baqAoa gbA4PzLH+KzhKl0snzcaLL63754aLqkTE2de+T8R1Gegl58Q29K9PO8i8PEzrTTh5FkhJ/T+1H+/8 8zwUL94+1STm6uiTVkzdDo1T6GmYYwWwqXvLjB2Z0z/WSeTBsIaFWKvQkS3wIrx0DVwLVmWmOeS/o dHfXpd31RzvcF+1XblVUe2KoRoQVxtj0/byqyv84e6V6BUtEBxFI/UA+xlGBtaHoJxeQOoBXlNgCc vqA+twjXPzdZUlpjbMenZ6nwk74T4SunlwxJR9AUhZWHUkbd3PWd6zl0dFNcPWmKUT2ISvORPYqXY oefGpB4YoaKcoS26on6A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qRO1A-006RUX-1X; Thu, 03 Aug 2023 02:24:48 +0000 Received: from fd01.gateway.ufhost.com ([61.152.239.71]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qRO15-006RQE-1O for linux-riscv@lists.infradead.org; Thu, 03 Aug 2023 02:24:46 +0000 Received: from EXMBX166.cuchost.com (unknown [175.102.18.54]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "EXMBX166", Issuer "EXMBX166" (not verified)) by fd01.gateway.ufhost.com (Postfix) with ESMTP id 4E8277FF9; Thu, 3 Aug 2023 10:23:49 +0800 (CST) Received: from EXMBX172.cuchost.com (172.16.6.92) by EXMBX166.cuchost.com (172.16.6.76) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Thu, 3 Aug 2023 10:23:49 +0800 Received: from [192.168.125.136] (183.27.98.54) by EXMBX172.cuchost.com (172.16.6.92) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Thu, 3 Aug 2023 10:23:47 +0800 Message-ID: <1c546489-40dd-25c5-3ac2-9e3b3fd5a670@starfivetech.com> Date: Thu, 3 Aug 2023 10:23:47 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [PATCH v1 8/9] PCI: PLDA: starfive: Add JH7110 PCIe controller Content-Language: en-US To: Bjorn Helgaas CC: Minda Chen , Daire McNamara , Conor Dooley , Rob Herring , Krzysztof Kozlowski , Bjorn Helgaas , Lorenzo Pieralisi , =?UTF-8?Q?Krzysztof_Wilczy=c5=84ski?= , Emil Renner Berthing , , , , , Paul Walmsley , "Palmer Dabbelt" , Albert Ou , "Philipp Zabel" , Mason Huo , Leyfoon Tan , Mika Westerberg , "Maciej W. Rozycki" , =?UTF-8?Q?Pali_Roh=c3=a1r?= , =?UTF-8?Q?Marek_Beh=c3=ban?= References: <20230802171805.GA62238@bhelgaas> From: Kevin Xie In-Reply-To: <20230802171805.GA62238@bhelgaas> X-Originating-IP: [183.27.98.54] X-ClientProxiedBy: EXCAS066.cuchost.com (172.16.6.26) To EXMBX172.cuchost.com (172.16.6.92) X-YovoleRuleAgent: yovoleflag X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230802_192443_836611_16B321EA X-CRM114-Status: GOOD ( 23.79 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On 2023/8/3 1:18, Bjorn Helgaas wrote: > On Tue, Aug 01, 2023 at 03:05:46PM +0800, Kevin Xie wrote: >> On 2023/8/1 7:12, Bjorn Helgaas wrote: >> ... > >> > The delay required by sec 6.6.1 is a minimum of 100ms following exit >> > from reset or, for fast links, 100ms after link training completes. >> > >> > The comment at the call of advk_pcie_wait_for_link() [2] says it is >> > the delay required by sec 6.6.1, but that doesn't seem right to me. >> > >> > For one thing, I don't think 6.6.1 says anything about "link up" being >> > the end of a delay. So if we want to do the delay required by 6.6.1, >> > "wait_for_link()" doesn't seem like quite the right name. >> > >> > For another, all the *_wait_for_link() functions can return success >> > after 0ms, 90ms, 180ms, etc. They're unlikely to return after 0ms, >> > but 90ms is quite possible. If we avoided the 0ms return and >> > LINK_WAIT_USLEEP_MIN were 100ms instead of 90ms, that should be enough >> > for slow links, where we need 100ms following "exit from reset." >> > >> > But it's still not enough for fast links where we need 100ms "after >> > link training completes" because we don't know when training >> > completed. If training completed 89ms into *_wait_for_link(), we only >> > delay 1ms after that. >> >> That's the point, we will add a extra 100ms after PERST# de-assert >> in the patch-v3 according to Base Spec r6.0 - 6.6.1: >> msleep(100); >> gpiod_set_value_cansleep(pcie->reset_gpio, 0); >> >> + /* As the requirement in PCIe base spec r6.0, system must wait a >> + * minimum of 100 ms following exit from a Conventional Reset >> + * before sending a Configuration Request to the device.*/ >> + msleep(100); >> + >> if (starfive_pcie_host_wait_for_link(pcie)) >> return -EIO; > > For fast links (links that support > 5.0 GT/s), the 100ms starts > *after* link training completes. The above looks OK if starfive only > supports slow links, but then I'm not sure why we would need > starfive_pcie_host_wait_for_link(). > Yes, the maximum speed of JH7110 PCIe is 5.0 GT/s (Gen2x1). About starfive_pcie_host_wait_for_link(): JH7110 SoC only has one root port in each PCIe controller (2 in total) and they do not support hot-plug yet. Thus, We add starfive_pcie_host_wait_for_link() to poll if it is a empty slot. If nothing here, we will exit the probe() of this controller, and it will not go into pci_host_probe() too. This may not be a very standard logic, should we remove it or rewrite in a better way? > Bjorn _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id ACD8AC04A6A for ; Thu, 3 Aug 2023 02:39:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233192AbjHCCj2 (ORCPT ); Wed, 2 Aug 2023 22:39:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57864 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232506AbjHCCjL (ORCPT ); Wed, 2 Aug 2023 22:39:11 -0400 Received: from fd01.gateway.ufhost.com (fd01.gateway.ufhost.com [61.152.239.71]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5E67019A0; Wed, 2 Aug 2023 19:39:09 -0700 (PDT) Received: from EXMBX166.cuchost.com (unknown [175.102.18.54]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "EXMBX166", Issuer "EXMBX166" (not verified)) by fd01.gateway.ufhost.com (Postfix) with ESMTP id 4E8277FF9; Thu, 3 Aug 2023 10:23:49 +0800 (CST) Received: from EXMBX172.cuchost.com (172.16.6.92) by EXMBX166.cuchost.com (172.16.6.76) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Thu, 3 Aug 2023 10:23:49 +0800 Received: from [192.168.125.136] (183.27.98.54) by EXMBX172.cuchost.com (172.16.6.92) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Thu, 3 Aug 2023 10:23:47 +0800 Message-ID: <1c546489-40dd-25c5-3ac2-9e3b3fd5a670@starfivetech.com> Date: Thu, 3 Aug 2023 10:23:47 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [PATCH v1 8/9] PCI: PLDA: starfive: Add JH7110 PCIe controller Content-Language: en-US To: Bjorn Helgaas CC: Minda Chen , Daire McNamara , Conor Dooley , Rob Herring , Krzysztof Kozlowski , Bjorn Helgaas , Lorenzo Pieralisi , =?UTF-8?Q?Krzysztof_Wilczy=c5=84ski?= , Emil Renner Berthing , , , , , Paul Walmsley , "Palmer Dabbelt" , Albert Ou , "Philipp Zabel" , Mason Huo , Leyfoon Tan , Mika Westerberg , "Maciej W. Rozycki" , =?UTF-8?Q?Pali_Roh=c3=a1r?= , =?UTF-8?Q?Marek_Beh=c3=ban?= References: <20230802171805.GA62238@bhelgaas> From: Kevin Xie In-Reply-To: <20230802171805.GA62238@bhelgaas> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [183.27.98.54] X-ClientProxiedBy: EXCAS066.cuchost.com (172.16.6.26) To EXMBX172.cuchost.com (172.16.6.92) X-YovoleRuleAgent: yovoleflag Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2023/8/3 1:18, Bjorn Helgaas wrote: > On Tue, Aug 01, 2023 at 03:05:46PM +0800, Kevin Xie wrote: >> On 2023/8/1 7:12, Bjorn Helgaas wrote: >> ... > >> > The delay required by sec 6.6.1 is a minimum of 100ms following exit >> > from reset or, for fast links, 100ms after link training completes. >> > >> > The comment at the call of advk_pcie_wait_for_link() [2] says it is >> > the delay required by sec 6.6.1, but that doesn't seem right to me. >> > >> > For one thing, I don't think 6.6.1 says anything about "link up" being >> > the end of a delay. So if we want to do the delay required by 6.6.1, >> > "wait_for_link()" doesn't seem like quite the right name. >> > >> > For another, all the *_wait_for_link() functions can return success >> > after 0ms, 90ms, 180ms, etc. They're unlikely to return after 0ms, >> > but 90ms is quite possible. If we avoided the 0ms return and >> > LINK_WAIT_USLEEP_MIN were 100ms instead of 90ms, that should be enough >> > for slow links, where we need 100ms following "exit from reset." >> > >> > But it's still not enough for fast links where we need 100ms "after >> > link training completes" because we don't know when training >> > completed. If training completed 89ms into *_wait_for_link(), we only >> > delay 1ms after that. >> >> That's the point, we will add a extra 100ms after PERST# de-assert >> in the patch-v3 according to Base Spec r6.0 - 6.6.1: >> msleep(100); >> gpiod_set_value_cansleep(pcie->reset_gpio, 0); >> >> + /* As the requirement in PCIe base spec r6.0, system must wait a >> + * minimum of 100 ms following exit from a Conventional Reset >> + * before sending a Configuration Request to the device.*/ >> + msleep(100); >> + >> if (starfive_pcie_host_wait_for_link(pcie)) >> return -EIO; > > For fast links (links that support > 5.0 GT/s), the 100ms starts > *after* link training completes. The above looks OK if starfive only > supports slow links, but then I'm not sure why we would need > starfive_pcie_host_wait_for_link(). > Yes, the maximum speed of JH7110 PCIe is 5.0 GT/s (Gen2x1). About starfive_pcie_host_wait_for_link(): JH7110 SoC only has one root port in each PCIe controller (2 in total) and they do not support hot-plug yet. Thus, We add starfive_pcie_host_wait_for_link() to poll if it is a empty slot. If nothing here, we will exit the probe() of this controller, and it will not go into pci_host_probe() too. This may not be a very standard logic, should we remove it or rewrite in a better way? > Bjorn