From: Stefan Roese <sr@denx.de>
To: "Pali Rohár" <pali@kernel.org>
Cc: "Marek Behún" <kabel@kernel.org>,
u-boot@lists.denx.de, "Marek Behún" <marek.behun@nic.cz>
Subject: Re: [PATCH u-boot-marvell 01/10] pci: pci_mvebu: Wait 100ms for Link Up in mvebu_pcie_probe()
Date: Fri, 12 Nov 2021 17:07:51 +0100 [thread overview]
Message-ID: <596206f8-7521-85e3-81c7-d7ba5dd8eacb@denx.de> (raw)
In-Reply-To: <20211112154423.exvxswqygxm2qbh3@pali>
On 11/12/21 16:44, Pali Rohár wrote:
> On Friday 12 November 2021 14:59:31 Stefan Roese wrote:
>> On 11/11/21 16:35, Marek Behún wrote:
>>> From: Pali Rohár <pali@kernel.org>
>>>
>>> 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.
>>
>> Where does this 100ms come from? From tests with your PCIe devices /
>> card?
>
> pci-aardvark.c has similar wait timeout, but up to the 1s.
>
> In PCIe base spec 4.0 in section 6.6.1 Conventional Reset is written:
> With a Downstream Port that does not support Link speeds greater than
> 5.0 GT/s, software must wait a minimum of 100 ms before sending a
> Configuration Request to the device immediately below that Port.
>
> So I think that waiting 100ms is reasonable... But I do not know what
> should be correct here as proper initialization needs more steps...
> For more details see my email sent to linux-pci:
> https://lore.kernel.org/linux-pci/20211022183808.jdeo7vntnagqkg7g@pali/
>
> I saw that more drivers in kernel are using different timeouts at
> different levels and they are between 1ms-150ms. It is just mess.
Agreed. So let's tick with this 100ms for now.
Thanks,
Stefan
>> Please see another comment below...
>>
>>> 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 <pali@kernel.org>
>>> Signed-off-by: Marek Behún <marek.behun@nic.cz>
>>> ---
>>> 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 <asm/arch/cpu.h>
>>> #include <asm/arch/soc.h>
>>> #include <linux/bitops.h>
>>> +#include <linux/delay.h>
>>> #include <linux/errno.h>
>>> #include <linux/ioport.h>
>>> #include <linux/mbus.h>
>>> @@ -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
>>
>> Wouldn't it be easier read, if this was defines like this:
>>
>> #define LINK_TIMEOUT_MS 100
>> #define LINK_WAIT_TIMEOUT_US 1000
>> #define LINK_WAIT_RETRIES ((LINK_TIMEOUT_MS * 1000) / LINK_WAIT_TIMEOUT_US)
>>
>> Other than this:
>>
>> Reviewed-by: Stefan Roese <sr@denx.de>
>>
>> Thanks,
>> Stefan
>>
>>> +
>>> 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;
>>> }
>>>
>>
>> Viele Grüße,
>> Stefan Roese
>>
>> --
>> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
>> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>> Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr@denx.de
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr@denx.de
next prev parent reply other threads:[~2021-11-12 16:08 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-11 15:35 [PATCH u-boot-marvell 00/10] PCI mvebu and aardvark changes Marek Behún
2021-11-11 15:35 ` [PATCH u-boot-marvell 01/10] pci: pci_mvebu: Wait 100ms for Link Up in mvebu_pcie_probe() Marek Behún
2021-11-12 13:59 ` Stefan Roese
2021-11-12 15:44 ` Pali Rohár
2021-11-12 16:07 ` Stefan Roese [this message]
2021-11-18 18:06 ` Pali Rohár
2021-11-11 15:35 ` [PATCH u-boot-marvell 02/10] arm: mvebu: a38x: serdes: Move non-serdes PCIe code to pci_mvebu.c Marek Behún
2021-11-12 14:01 ` Stefan Roese
2021-11-18 18:01 ` Pali Rohár
2021-11-19 6:55 ` Stefan Roese
2021-11-23 15:59 ` Pali Rohár
2021-11-29 7:46 ` Stefan Roese
2021-11-29 9:06 ` Pali Rohár
2021-11-29 9:22 ` Stefan Roese
2021-11-29 11:47 ` Pali Rohár
2021-11-29 12:30 ` Stefan Roese
2021-11-29 13:27 ` Pali Rohár
2021-11-29 14:28 ` Pali Rohár
2021-11-29 16:07 ` Stefan Roese
2021-11-29 17:09 ` Marek Behún
2021-12-10 11:07 ` Pali Rohár
2021-12-10 14:23 ` Pali Rohár
2021-12-13 7:36 ` Stefan Roese
2021-12-13 10:28 ` Pali Rohár
2021-11-11 15:35 ` [PATCH u-boot-marvell 03/10] pci: pci_mvebu: Move setup for BAR[0] where other BARs are setup Marek Behún
2021-11-12 14:02 ` Stefan Roese
2021-12-21 8:22 ` Stefan Roese
2021-11-11 15:35 ` [PATCH u-boot-marvell 04/10] pci: pci_mvebu: Replace MBUS_PCI_*_SIZE by resource_size() Marek Behún
2021-11-12 14:03 ` Stefan Roese
2021-12-21 8:23 ` Stefan Roese
2021-11-11 15:35 ` [PATCH u-boot-marvell 05/10] pci: pci_mvebu, pci_aardvark: Fix size of configuration cache Marek Behún
2021-11-12 14:04 ` Stefan Roese
2021-12-15 10:57 ` Stefan Roese
2021-11-11 15:35 ` [PATCH u-boot-marvell 06/10] pci: pci_mvebu: Do not allow setting ROM BAR on PCI Bridge Marek Behún
2021-11-12 14:05 ` Stefan Roese
2021-12-15 10:57 ` Stefan Roese
2021-11-11 15:35 ` [PATCH u-boot-marvell 07/10] pci: pci_mvebu: Fix PCIe MEM and IO resources assignment and mbus mapping Marek Behún
2021-11-12 14:18 ` Stefan Roese
2021-11-18 17:46 ` Pali Rohár
2021-11-19 6:27 ` Stefan Roese
2021-11-11 15:35 ` [PATCH u-boot-marvell 08/10] pci: pci_mvebu: Remove unused DECLARE_GLOBAL_DATA_PTR Marek Behún
2021-11-12 14:19 ` Stefan Roese
2021-12-21 8:23 ` Stefan Roese
2021-11-11 15:35 ` [PATCH u-boot-marvell 09/10] arm: a37xx: pci: Do not allow setting ROM BAR on PCI Bridge Marek Behún
2021-11-12 14:19 ` Stefan Roese
2021-11-11 15:35 ` [PATCH u-boot-marvell 10/10] arm: mvebu: turris_mox: Remove extra newline after module topology Marek Behún
2021-11-12 14:20 ` Stefan Roese
2021-12-21 8:23 ` Stefan Roese
2021-12-12 11:23 ` [PATCH u-boot-marvell 00/10] PCI mvebu and aardvark changes Pali Rohár
2021-12-13 7:41 ` Stefan Roese
2021-12-13 10:27 ` Pali Rohár
2021-12-15 8:10 ` Stefan Roese
2021-12-16 10:28 ` Pali Rohár
2021-12-18 13:53 ` Stefan Roese
2021-12-20 13:30 ` Pali Rohár
2021-12-21 8:19 ` Stefan Roese
2021-12-21 10:57 ` Pali Rohár
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=596206f8-7521-85e3-81c7-d7ba5dd8eacb@denx.de \
--to=sr@denx.de \
--cc=kabel@kernel.org \
--cc=marek.behun@nic.cz \
--cc=pali@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).