| Message ID | 20200430080625.26070-1-pali@kernel.org |
|---|---|
| Headers | show |
| Series | PCI: aardvark: Fix support for Turris MOX and Compex wifi cards | expand |
On Thursday 30 April 2020 10:06:18 Pali Rohár wrote: > +static void advk_pcie_issue_perst(struct advk_pcie *pcie) > +{ > + u32 reg; > + > + if (!pcie->reset_gpio) > + return; > + > + /* PERST does not work for some cards when link training is enabled */ > + reg = advk_readl(pcie, PCIE_CORE_CTRL0_REG); > + reg &= ~LINK_TRAINING_EN; > + advk_writel(pcie, reg, PCIE_CORE_CTRL0_REG); > + > + /* 10ms delay is needed for some cards */ > + dev_info(&pcie->pdev->dev, "issuing PERST via reset GPIO for 10ms\n"); > + gpiod_set_value_cansleep(pcie->reset_gpio, 1); > + usleep_range(10000, 11000); > + gpiod_set_value_cansleep(pcie->reset_gpio, 0); > +} Just note about delay between changing GPIO reset: In V2 there as only 1ms, but be figured out that it is not enough for WLE900VX cards when they were already initialized in u-boot. I tried to find in PCI specs if there is a defined timeout for this operation. I found following 3 delay definitions which could be related: TPVPERL - PERST# must remain active at least this long after power becomes valid TPERST - When asserted, PERST# must remain asserted at least this long TPERSTCLK - PERST# must remain active at least this long after any supplied reference clock is stable In another spec they have defined also minimal values: TPVPERL - Power stable to PERST# inactive - Min 100 ms TPERST - PERST# active time - Min 100 us TPERSTCLK - REFCLK stable before PERST# inactive - Min 100 us After experimenting with those Compex WLE900VX cards, I know that 100us delay is not enough. And I'm not sure if TPVPERL is really relevant for this case. I understood that TPVPERL is needed when initializing power again. And because delaying boot by another 100ms is does not have to be acceptable if there is not strict reason for it, I rather decided to stay with just 10ms delay. If you know what is the correct timeout between changing GPIO reset, please let me know and in future I can fix/reimplement it.
On Thu, 30 Apr 2020 10:06:14 +0200, =?UTF-8?q?Pali=20Roh=C3=A1r?= wrote: > Adding even 100ms (PCI_PM_D3COLD_WAIT) delay between enabling link > training and starting link training causes detection issues with some > buggy cards (such as Compex WLE900VX). > > Move the code which enables link training immediately before the one > which starts link traning. > > This fixes detection issues of Compex WLE900VX card on Turris MOX after > cold boot. > > Fixes: f4c7d053d7f7 ("PCI: aardvark: Wait for endpoint to be ready...") > Signed-off-by: Pali Rohár <pali@kernel.org> > --- > drivers/pci/controller/pci-aardvark.c | 15 +++++++++------ > 1 file changed, 9 insertions(+), 6 deletions(-) > Acked-by: Rob Herring <robh@kernel.org>
On Thu, 30 Apr 2020 10:06:15 +0200, =?UTF-8?q?Pali=20Roh=C3=A1r?= wrote: > Trying to change Link Status register does not have any effect as this > is a read-only register. Trying to overwrite bits for Negotiated Link > Width does not make sense. > > In future proper change of link width can be done via Lane Count Select > bits in PCIe Control 0 register. > > Trying to unconditionally enable ASPM L0s via ASPM Control bits in Link > Control register is wrong. There should be at least some detection if > endpoint supports L0s as isn't mandatory. > > Moreover ASPM Control bits in Link Control register are controlled by > pcie/aspm.c code which sets it according to system ASPM settings, > immediately after aardvark driver probes. So setting these bits by > aardvark driver has no long running effect. > > Remove code which touches ASPM L0s bits from this driver and let > kernel's ASPM implementation to set ASPM state properly. > > Some users are reporting issues that this code is problematic for some > Intel wifi cards and removing it fixes them, see e.g.: > https://bugzilla.kernel.org/show_bug.cgi?id=196339 > > If problems with Intel wifi cards occur even after this commit, then > pcie/aspm.c code could be modified / hooked to not enable ASPM L0s state > for affected problematic cards. > > Signed-off-by: Pali Rohár <pali@kernel.org> > --- > drivers/pci/controller/pci-aardvark.c | 4 ---- > 1 file changed, 4 deletions(-) > Acked-by: Rob Herring <robh@kernel.org>
On Thu, 30 Apr 2020 10:06:16 +0200, =?UTF-8?q?Pali=20Roh=C3=A1r?= wrote: > Interpret zero value of max-link-speed property as invalid, > as the device tree bindings documentation specifies. > > Signed-off-by: Pali Rohár <pali@kernel.org> > --- > drivers/pci/of.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Acked-by: Rob Herring <robh@kernel.org>
On Thu, 30 Apr 2020 10:06:17 +0200, =?UTF-8?q?Pali=20Roh=C3=A1r?= wrote: > From: Marek Behún <marek.behun@nic.cz> > > Currently the aardvark driver trains link in PCIe gen2 mode. This may > cause some buggy gen1 cards (such as Compex WLE900VX) to be unstable or > even not detected. Moreover when ASPM code tries to retrain link second > time, these cards may stop responding and link goes down. If gen1 is > used this does not happen. > > Unconditionally forcing gen1 is not a good solution since it may have > performance impact on gen2 cards. > > To overcome this, read 'max-link-speed' property (as defined in PCI > device tree bindings) and use this as max gen mode. Then iteratively try > link training at this mode or lower until successful. After successful > link training choose final controller gen based on Negotiated Link Speed > from Link Status register, which should match card speed. > > Signed-off-by: Pali Rohár <pali@kernel.org> > Signed-off-by: Marek Behún <marek.behun@nic.cz> > --- > drivers/pci/controller/pci-aardvark.c | 114 ++++++++++++++++++++------ > 1 file changed, 89 insertions(+), 25 deletions(-) > Reviewed-by: Rob Herring <robh@kernel.org>
On Thu, Apr 30, 2020 at 10:22:45AM +0200, Pali Rohár wrote: > On Thursday 30 April 2020 10:06:18 Pali Rohár wrote: > > +static void advk_pcie_issue_perst(struct advk_pcie *pcie) > > +{ > > + u32 reg; > > + > > + if (!pcie->reset_gpio) > > + return; > > + > > + /* PERST does not work for some cards when link training is enabled */ > > + reg = advk_readl(pcie, PCIE_CORE_CTRL0_REG); > > + reg &= ~LINK_TRAINING_EN; > > + advk_writel(pcie, reg, PCIE_CORE_CTRL0_REG); > > + > > + /* 10ms delay is needed for some cards */ > > + dev_info(&pcie->pdev->dev, "issuing PERST via reset GPIO for 10ms\n"); > > + gpiod_set_value_cansleep(pcie->reset_gpio, 1); > > + usleep_range(10000, 11000); > > + gpiod_set_value_cansleep(pcie->reset_gpio, 0); > > +} > > Just note about delay between changing GPIO reset: > > In V2 there as only 1ms, but be figured out that it is not enough for > WLE900VX cards when they were already initialized in u-boot. > > I tried to find in PCI specs if there is a defined timeout for this > operation. I found following 3 delay definitions which could be related: > > TPVPERL - PERST# must remain active at least this long after power becomes valid > TPERST - When asserted, PERST# must remain asserted at least this long > TPERSTCLK - PERST# must remain active at least this long after any supplied reference clock is stable > > In another spec they have defined also minimal values: > > TPVPERL - Power stable to PERST# inactive - Min 100 ms > TPERST - PERST# active time - Min 100 us > TPERSTCLK - REFCLK stable before PERST# inactive - Min 100 us > > After experimenting with those Compex WLE900VX cards, I know that 100us > delay is not enough. And I'm not sure if TPVPERL is really relevant for > this case. I understood that TPVPERL is needed when initializing power > again. And because delaying boot by another 100ms is does not have to be > acceptable if there is not strict reason for it, I rather decided to > stay with just 10ms delay. > > If you know what is the correct timeout between changing GPIO reset, > please let me know and in future I can fix/reimplement it. I don't know, but seems like something each driver author shouldn't be making up. Rob
On Thu, 30 Apr 2020 10:06:19 +0200, =?UTF-8?q?Pali=20Roh=C3=A1r?= wrote: > This register is applicable only when the controller is configured for > Endpoint mode, which is not the case for the current version of this > driver. > > Attempting to remove this code though caused some ath10k cards to stop > working, so for some unknown reason it is needed here. > > This should be investigated and a comment explaining this should be put > before the code, so we add a FIXME comment for now. > > Signed-off-by: Pali Rohár <pali@kernel.org> > --- > drivers/pci/controller/pci-aardvark.c | 7 +++++++ > 1 file changed, 7 insertions(+) > Acked-by: Rob Herring <robh@kernel.org>
On Thu, 30 Apr 2020 10:06:20 +0200, =?UTF-8?q?Pali=20Roh=C3=A1r?= wrote: > From: Marek Behún <marek.behun@nic.cz> > > With recent proposed changes for U-Boot it is possible that bootloader > won't initialize the PHY for this controller (currently the PHY is > initialized regardless whether PCI is used in U-Boot, but with these > proposed changes the PHY is initialized only on request). > > Since the mvebu-a3700-comphy driver by Miquèl Raynal supports enabling > PCIe PHY, and since Linux' functionality should be independent on what > bootloader did, add code for enabling generic PHY if found in device OF > node. > > The mvebu-a3700-comphy driver does PHY powering via SMC calls to ARM > Trusted Firmware. The corresponding code in ARM Trusted Firmware skips > one register write which U-Boot does not: step 7 ("Enable TX"), see [1]. > Instead ARM Trusted Firmware expects PCIe driver to do this step, > probably because the register is in PCIe controller address space, > instead of PHY address space. We therefore add this step into the > advk_pcie_setup_hw function. > > [1] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/drivers/marvell/comphy/phy-comphy-3700.c?h=v2.3-rc2#n836 > > Signed-off-by: Marek Behún <marek.behun@nic.cz> > Cc: Miquèl Raynal <miquel.raynal@bootlin.com> > --- > drivers/pci/controller/pci-aardvark.c | 69 +++++++++++++++++++++++++++ > 1 file changed, 69 insertions(+) > Reviewed-by: Rob Herring <robh@kernel.org>
On Thu, 30 Apr 2020 10:06:21 +0200, =?UTF-8?q?Pali=20Roh=C3=A1r?= wrote: > PCI-E capability macros are already defined in linux/pci_regs.h. > Remove their reimplementation in pcie-aardvark. > > Signed-off-by: Pali Rohár <pali@kernel.org> > --- > drivers/pci/controller/pci-aardvark.c | 41 ++++++++++++--------------- > 1 file changed, 18 insertions(+), 23 deletions(-) > Reviewed-by: Rob Herring <robh@kernel.org>
W dniu 30.04.2020 o 10:06, Pali Rohár pisze: > Hello, > > this is the fourth version of the patch series for Armada 3720 PCIe > controller (aardvark). It's main purpose is to fix some bugs regarding > buggy ath10k cards, but we also found out some suspicious stuff about > the driver and the SOC itself, which we try to address. > > Patches are available also in my git branch pci-aardvark: > https://git.kernel.org/pub/scm/linux/kernel/git/pali/linux.git/log/?h=pci-aardvark > > Changes since v3: > - do not change return value of of_pci_get_max_link_speed() function > - mark zero 'max-link-speed' as invalid > - silently use gen3 speed when 'max-link-speed' as invalid > > Changes since v2: > - move PCIe max-link-speed property to armada-37xx.dtsi > - replace custom macros by standard linux/pci_regs.h macros > - increase PERST delay to 10ms (needed for initialized Compex WLE900VX) > - disable link training before PERST (needed for Compex WLE900VX) > - change of_pci_get_max_link_speed() function to signal -ENOENT > - handle errors from of_pci_get_max_link_speed() function > - updated comments, commit titles and messages > > Changes since v1: > - commit titles and messages were reviewed and some of them were rewritten > - patches 1 and 5 from v1 which touch PCIe speed configuration were > reworked into one patch > - patch 2 from v1 was removed, it is not needed anymore > - patch 7 from v1 now touches the device tree of armada-3720-db > - a patch was added that tries to enable PCIe PHY via generic-phy API > (if a phandle to the PHY is found in the device tree) > - a patch describing the new PCIe node DT properties was added > - a patch was added that moves the PHY phandle from board device trees > to armada-37xx.dtsi > > Marek and Pali > > Marek Behún (5): > PCI: aardvark: Improve link training > PCI: aardvark: Add PHY support > dt-bindings: PCI: aardvark: Describe new properties > arm64: dts: marvell: armada-37xx: Set pcie_reset_pin to gpio function > arm64: dts: marvell: armada-37xx: Move PCIe comphy handle property > > Pali Rohár (7): > PCI: aardvark: Train link immediately after enabling training > PCI: aardvark: Don't blindly enable ASPM L0s and don't write to > read-only register > PCI: of: Zero max-link-speed value is invalid > PCI: aardvark: Issue PERST via GPIO > PCI: aardvark: Add FIXME comment for PCIE_CORE_CMD_STATUS_REG access > PCI: aardvark: Replace custom macros by standard linux/pci_regs.h > macros > arm64: dts: marvell: armada-37xx: Move PCIe max-link-speed property Hi. The PCI interface seems to work fine as in the first series, so Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com>
On Thursday 30 April 2020 10:06:13 Pali Rohár wrote: > Hello, > > this is the fourth version of the patch series for Armada 3720 PCIe > controller (aardvark). It's main purpose is to fix some bugs regarding > buggy ath10k cards, but we also found out some suspicious stuff about > the driver and the SOC itself, which we try to address. > > Patches are available also in my git branch pci-aardvark: > https://git.kernel.org/pub/scm/linux/kernel/git/pali/linux.git/log/?h=pci-aardvark Hello! Thanks everybody for review and testing of this patch series. I would like to ask, is there something needed to fix / modify in this patch series? If everything is OK, would you Bjorn or Lorenzo take this patch series into your tree?
On Wed, May 13, 2020 at 01:16:51PM +0200, Pali Rohár wrote: > On Thursday 30 April 2020 10:06:13 Pali Rohár wrote: > > Hello, > > > > this is the fourth version of the patch series for Armada 3720 PCIe > > controller (aardvark). It's main purpose is to fix some bugs regarding > > buggy ath10k cards, but we also found out some suspicious stuff about > > the driver and the SOC itself, which we try to address. > > > > Patches are available also in my git branch pci-aardvark: > > https://git.kernel.org/pub/scm/linux/kernel/git/pali/linux.git/log/?h=pci-aardvark > > Hello! Thanks everybody for review and testing of this patch series. > > I would like to ask, is there something needed to fix / modify in this > patch series? If everything is OK, would you Bjorn or Lorenzo take this > patch series into your tree? We need Thomas' ACK on the series. We don't have this HW and we comment on the generic code, Thomas owns it and must check that what you are changing is sound. On patch 5 I share Rob's concerns - it does not make much sense to have something driver specific there, need to look further. Lorenzo
Hello, On Thu, 30 Apr 2020 10:06:13 +0200 Pali Rohár <pali@kernel.org> wrote: > Marek Behún (5): > PCI: aardvark: Improve link training > PCI: aardvark: Add PHY support > dt-bindings: PCI: aardvark: Describe new properties > arm64: dts: marvell: armada-37xx: Set pcie_reset_pin to gpio function > arm64: dts: marvell: armada-37xx: Move PCIe comphy handle property > > Pali Rohár (7): > PCI: aardvark: Train link immediately after enabling training > PCI: aardvark: Don't blindly enable ASPM L0s and don't write to > read-only register > PCI: of: Zero max-link-speed value is invalid > PCI: aardvark: Issue PERST via GPIO > PCI: aardvark: Add FIXME comment for PCIE_CORE_CMD_STATUS_REG access > PCI: aardvark: Replace custom macros by standard linux/pci_regs.h > macros > arm64: dts: marvell: armada-37xx: Move PCIe max-link-speed property Thanks a lot for this work. For a number of reasons, I'm less involved in Marvell platform support in Linux, but I reviewed your series and followed the discussions around it, and I'm happy to give my: Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> for the whole series. The changes all seem sensible, and have been tested by several folks. Thanks! Thomas
On Wednesday 13 May 2020 12:33:14 Lorenzo Pieralisi wrote: > On Wed, May 13, 2020 at 01:16:51PM +0200, Pali Rohár wrote: > > On Thursday 30 April 2020 10:06:13 Pali Rohár wrote: > > > Hello, > > > > > > this is the fourth version of the patch series for Armada 3720 PCIe > > > controller (aardvark). It's main purpose is to fix some bugs regarding > > > buggy ath10k cards, but we also found out some suspicious stuff about > > > the driver and the SOC itself, which we try to address. > > > > > > Patches are available also in my git branch pci-aardvark: > > > https://git.kernel.org/pub/scm/linux/kernel/git/pali/linux.git/log/?h=pci-aardvark > > > > Hello! Thanks everybody for review and testing of this patch series. > > > > I would like to ask, is there something needed to fix / modify in this > > patch series? If everything is OK, would you Bjorn or Lorenzo take this > > patch series into your tree? > > We need Thomas' ACK on the series. We don't have this HW and > we comment on the generic code, Thomas owns it and must check that > what you are changing is sound. Ok, we will wait for Thomas ACK/review. > On patch 5 I share Rob's concerns - it does not make much sense > to have something driver specific there, need to look further. I fully understand yours concerns. I wanted to solve it. Problem is that I really do not know which timeout is there applicable. I read information about PERST# more times but I was not able to clearly deduce that minimal timeout/delay needed for this reset scenario. So what I was able to do are just experiments. I found out what is the minimal needed time to correctly initialize wifi cars which I used for testing. You can look into my previous email [1] where I wrote which timeouts are used by which drivers. Basically every driver is using its own custom timeout and this is something which should be fixed / improved. In my opinion authors tested their own (wifi) cards and measured minimal timeout needed for initializing them. So somebody with deeper PCI knowledge should look at this PERST# problem and try to address it. After it happens I see there two scenarios: 1) Timeout according to specification/authority is lower than what we currently use. In this case it would mean that we have buggy wifi cards (and we already know that people reported issues with Compex cards) and we would have to stay with higher timeout. Probably we can define common macro with timeout value and use it. 2) Timeout according to specification/authority is bigger then what we currently use. In this case there is no problem to increase it, card would be just longer in reset state. What could be problematic for somebody is that this increase boot / initialization time. [1] - https://lore.kernel.org/linux-pci/20200424092546.25p3hdtkehohe3xw@pali/
Hello, > Hello, > > On Thu, 30 Apr 2020 10:06:13 +0200 > Pali Rohár <pali@kernel.org> wrote: > >> Marek Behún (5): >> PCI: aardvark: Improve link training >> PCI: aardvark: Add PHY support >> dt-bindings: PCI: aardvark: Describe new properties >> arm64: dts: marvell: armada-37xx: Set pcie_reset_pin to gpio function >> arm64: dts: marvell: armada-37xx: Move PCIe comphy handle property >> >> Pali Rohár (7): >> PCI: aardvark: Train link immediately after enabling training >> PCI: aardvark: Don't blindly enable ASPM L0s and don't write to >> read-only register >> PCI: of: Zero max-link-speed value is invalid >> PCI: aardvark: Issue PERST via GPIO >> PCI: aardvark: Add FIXME comment for PCIE_CORE_CMD_STATUS_REG access >> PCI: aardvark: Replace custom macros by standard linux/pci_regs.h >> macros >> arm64: dts: marvell: armada-37xx: Move PCIe max-link-speed property > > Thanks a lot for this work. For a number of reasons, I'm less involved > in Marvell platform support in Linux, but I reviewed your series and > followed the discussions around it, and I'm happy to give my: > > Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> With this acked-by for the series, the reviewed-by from Rob on the binding and the tested-by, I am pretty confident so I applied the patches 10, 11 and 12 on mvebu/dt64. Thanks, Gregory > > for the whole series. The changes all seem sensible, and have been > tested by several folks. > > Thanks! > > Thomas > -- > Thomas Petazzoni, CTO, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com
On Sunday 17 May 2020 17:57:02 Gregory CLEMENT wrote: > Hello, > > > Hello, > > > > On Thu, 30 Apr 2020 10:06:13 +0200 > > Pali Rohár <pali@kernel.org> wrote: > > > >> Marek Behún (5): > >> PCI: aardvark: Improve link training > >> PCI: aardvark: Add PHY support > >> dt-bindings: PCI: aardvark: Describe new properties > >> arm64: dts: marvell: armada-37xx: Set pcie_reset_pin to gpio function > >> arm64: dts: marvell: armada-37xx: Move PCIe comphy handle property > >> > >> Pali Rohár (7): > >> PCI: aardvark: Train link immediately after enabling training > >> PCI: aardvark: Don't blindly enable ASPM L0s and don't write to > >> read-only register > >> PCI: of: Zero max-link-speed value is invalid > >> PCI: aardvark: Issue PERST via GPIO > >> PCI: aardvark: Add FIXME comment for PCIE_CORE_CMD_STATUS_REG access > >> PCI: aardvark: Replace custom macros by standard linux/pci_regs.h > >> macros > >> arm64: dts: marvell: armada-37xx: Move PCIe max-link-speed property > > > > Thanks a lot for this work. For a number of reasons, I'm less involved > > in Marvell platform support in Linux, but I reviewed your series and > > followed the discussions around it, and I'm happy to give my: > > > > Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> > > With this acked-by for the series, the reviewed-by from Rob on the > binding and the tested-by, I am pretty confident so I applied the > patches 10, 11 and 12 on mvebu/dt64. > > Thanks, > > Gregory Thank you! Lorenzo, would you now take remaining patches? > > > > > for the whole series. The changes all seem sensible, and have been > > tested by several folks. > > > > Thanks! > > > > Thomas > > -- > > Thomas Petazzoni, CTO, Bootlin > > Embedded Linux and Kernel engineering > > https://bootlin.com > > -- > Gregory Clement, Bootlin > Embedded Linux and Kernel engineering > http://bootlin.com
On Mon, May 18, 2020 at 12:30:04PM +0200, Pali Rohár wrote: > On Sunday 17 May 2020 17:57:02 Gregory CLEMENT wrote: > > Hello, > > > > > Hello, > > > > > > On Thu, 30 Apr 2020 10:06:13 +0200 > > > Pali Rohár <pali@kernel.org> wrote: > > > > > >> Marek Behún (5): > > >> PCI: aardvark: Improve link training > > >> PCI: aardvark: Add PHY support > > >> dt-bindings: PCI: aardvark: Describe new properties > > >> arm64: dts: marvell: armada-37xx: Set pcie_reset_pin to gpio function > > >> arm64: dts: marvell: armada-37xx: Move PCIe comphy handle property > > >> > > >> Pali Rohár (7): > > >> PCI: aardvark: Train link immediately after enabling training > > >> PCI: aardvark: Don't blindly enable ASPM L0s and don't write to > > >> read-only register > > >> PCI: of: Zero max-link-speed value is invalid > > >> PCI: aardvark: Issue PERST via GPIO > > >> PCI: aardvark: Add FIXME comment for PCIE_CORE_CMD_STATUS_REG access > > >> PCI: aardvark: Replace custom macros by standard linux/pci_regs.h > > >> macros > > >> arm64: dts: marvell: armada-37xx: Move PCIe max-link-speed property > > > > > > Thanks a lot for this work. For a number of reasons, I'm less involved > > > in Marvell platform support in Linux, but I reviewed your series and > > > followed the discussions around it, and I'm happy to give my: > > > > > > Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> > > > > With this acked-by for the series, the reviewed-by from Rob on the > > binding and the tested-by, I am pretty confident so I applied the > > patches 10, 11 and 12 on mvebu/dt64. > > > > Thanks, > > > > Gregory > > Thank you! > > Lorenzo, would you now take remaining patches? Yes - even though I have reservations about patch (5) and the problem is related to a complete lack of programming model for these host controllers and a clear separation between what's done in the OS vs bootloader, PERST handling in this host bridge is *really* a mess. I applied 1-9 to pci/aardvark. Lorenzo
On Mon, 18 May 2020 14:46:14 +0100 Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote: > On Mon, May 18, 2020 at 12:30:04PM +0200, Pali Rohár wrote: > > On Sunday 17 May 2020 17:57:02 Gregory CLEMENT wrote: > > > Hello, > > > > > > > Hello, > > > > > > > > On Thu, 30 Apr 2020 10:06:13 +0200 > > > > Pali Rohár <pali@kernel.org> wrote: > > > > > > > >> Marek Behún (5): > > > >> PCI: aardvark: Improve link training > > > >> PCI: aardvark: Add PHY support > > > >> dt-bindings: PCI: aardvark: Describe new properties > > > >> arm64: dts: marvell: armada-37xx: Set pcie_reset_pin to gpio function > > > >> arm64: dts: marvell: armada-37xx: Move PCIe comphy handle property > > > >> > > > >> Pali Rohár (7): > > > >> PCI: aardvark: Train link immediately after enabling training > > > >> PCI: aardvark: Don't blindly enable ASPM L0s and don't write to > > > >> read-only register > > > >> PCI: of: Zero max-link-speed value is invalid > > > >> PCI: aardvark: Issue PERST via GPIO > > > >> PCI: aardvark: Add FIXME comment for PCIE_CORE_CMD_STATUS_REG access > > > >> PCI: aardvark: Replace custom macros by standard linux/pci_regs.h > > > >> macros > > > >> arm64: dts: marvell: armada-37xx: Move PCIe max-link-speed property > > > > > > > > Thanks a lot for this work. For a number of reasons, I'm less involved > > > > in Marvell platform support in Linux, but I reviewed your series and > > > > followed the discussions around it, and I'm happy to give my: > > > > > > > > Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> > > > > > > With this acked-by for the series, the reviewed-by from Rob on the > > > binding and the tested-by, I am pretty confident so I applied the > > > patches 10, 11 and 12 on mvebu/dt64. > > > > > > Thanks, > > > > > > Gregory > > > > Thank you! > > > > Lorenzo, would you now take remaining patches? > > Yes - even though I have reservations about patch (5) and the > problem is related to a complete lack of programming model for > these host controllers and a clear separation between what's > done in the OS vs bootloader, PERST handling in this host > bridge is *really* a mess. > > I applied 1-9 to pci/aardvark. > > Lorenzo Hooray, thanks, Lorenzo (and everyone else).
Hello, this is the fourth version of the patch series for Armada 3720 PCIe controller (aardvark). It's main purpose is to fix some bugs regarding buggy ath10k cards, but we also found out some suspicious stuff about the driver and the SOC itself, which we try to address. Patches are available also in my git branch pci-aardvark: https://git.kernel.org/pub/scm/linux/kernel/git/pali/linux.git/log/?h=pci-aardvark Changes since v3: - do not change return value of of_pci_get_max_link_speed() function - mark zero 'max-link-speed' as invalid - silently use gen3 speed when 'max-link-speed' as invalid Changes since v2: - move PCIe max-link-speed property to armada-37xx.dtsi - replace custom macros by standard linux/pci_regs.h macros - increase PERST delay to 10ms (needed for initialized Compex WLE900VX) - disable link training before PERST (needed for Compex WLE900VX) - change of_pci_get_max_link_speed() function to signal -ENOENT - handle errors from of_pci_get_max_link_speed() function - updated comments, commit titles and messages Changes since v1: - commit titles and messages were reviewed and some of them were rewritten - patches 1 and 5 from v1 which touch PCIe speed configuration were reworked into one patch - patch 2 from v1 was removed, it is not needed anymore - patch 7 from v1 now touches the device tree of armada-3720-db - a patch was added that tries to enable PCIe PHY via generic-phy API (if a phandle to the PHY is found in the device tree) - a patch describing the new PCIe node DT properties was added - a patch was added that moves the PHY phandle from board device trees to armada-37xx.dtsi Marek and Pali Marek Behún (5): PCI: aardvark: Improve link training PCI: aardvark: Add PHY support dt-bindings: PCI: aardvark: Describe new properties arm64: dts: marvell: armada-37xx: Set pcie_reset_pin to gpio function arm64: dts: marvell: armada-37xx: Move PCIe comphy handle property Pali Rohár (7): PCI: aardvark: Train link immediately after enabling training PCI: aardvark: Don't blindly enable ASPM L0s and don't write to read-only register PCI: of: Zero max-link-speed value is invalid PCI: aardvark: Issue PERST via GPIO PCI: aardvark: Add FIXME comment for PCIE_CORE_CMD_STATUS_REG access PCI: aardvark: Replace custom macros by standard linux/pci_regs.h macros arm64: dts: marvell: armada-37xx: Move PCIe max-link-speed property .../devicetree/bindings/pci/aardvark-pci.txt | 4 + .../arm64/boot/dts/marvell/armada-3720-db.dts | 3 + .../dts/marvell/armada-3720-espressobin.dtsi | 2 +- .../dts/marvell/armada-3720-turris-mox.dts | 6 - arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 4 +- drivers/pci/controller/pci-aardvark.c | 263 +++++++++++++++--- drivers/pci/of.c | 2 +- 7 files changed, 231 insertions(+), 53 deletions(-)