From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Cc: "Neil Greatorex" <neil@fatboyfat.co.uk>, "Willy Tarreau" <w@1wt.eu>, "Matthew Minter" <matthew_minter@xyratex.com>, "Gerlando Falauto" <gerlando.falauto@keymile.com>, linux-arm-kernel@lists.infradead.org, "Jason Cooper" <jason@lakedaemon.net>, "Gregory Clément" <gregory.clement@free-electrons.com>, "Ezequiel Garcia" <ezequiel.garcia@free-electrons.com>, "Andrew Lunn" <andrew@lunn.ch>, linux-pci@vger.kernel.org, "Tawfik Bayouk" <tawfik@marvell.com>, "Lior Amsalem" <alior@marvell.com> Subject: Re: Fixing PCIe issues on Armada XP Date: Fri, 18 Apr 2014 15:02:44 +0200 [thread overview] Message-ID: <20140418150244.4b3d5229@skate> (raw) In-Reply-To: <20140411163129.GA20565@obsidianresearch.com> Dear Jason Gunthorpe, On Fri, 11 Apr 2014 10:31:29 -0600, Jason Gunthorpe wrote: > > Moreover, I am not entirely convinced that a PHY reset is needed here. > > In my tests, doing just a wait after setting the local dev number was > > sufficient. The fact is works with earlyprintk also indicates that we > > don't need to do any specific action with the PHY, just to wait a bit > > of time. I am worried that resetting the PHY might actually take more > > time than what is needed, and may have other consequences that we don't > > necessarily understand at this point. > > I really disagree - clearly the fundamental problem is suspending one > side of the PEX link while the other remains operating. That isn't > specified to work and really shouldn't work. > > If you suspend one side of the PEX you *MUST* reset the > link. Absolutely. No Doubt In My Mind. > > Remember, PCI-E is a serial shared state protocol. The two sides must > remain in sync or a link reset is required to recover the shared > state. Halting one side obviously destroys this invariant. > > I think in many cases the reset happens autonomously. The remote side > will force it to happen. This is what the debugging from Neil shows - > the link just resets at some inconvenient point. Now we know why. > > The timing sensitivity also makes sense, if you suspend for a very > short time window the other side might not notice. If you suspend for > longer the other side will reset the link autonomously and your local > side will quickly notice the reset once it comes back. > > If you suspend for a little bit the link might not retrain immediately > but the shared state can become corrupted (eg sequence number > mismatch) this will eventually trigger a reset, after the local PEX > has been operating again. > > The LinkUp bit after resume is also clearly a lie - most likely the > PEX takes some time to detect the change in remote state to trigger a > link down. After all, it was suspended while the remote was busy > trying to recover. Ok, fair enough. However, Neil's patch (which is basically your patch with longer delays) isn't working here, as I just reported in a separate e-mail. So we don't have a solution right now. Do you have another proposal to try ? > The fundamental problem here is the clock driver. It should not be > gating PEX clocks so naively. A PEX suspend needs to be sequenced to > ensure the link is cleanly brought down before the PEX is put to > sleep. That way it can cleanly and unambiguously be started up when it > resumes. No risk of glitching/corrupting the far side with some kind > of crap on the serial bus. > > In any event, the most important required patch here is one that fixes > socid. It must not turn off the PEX clock. Then we can talk about how > to fix pci-mvebu to work as a module... I don't really understand this: all clocks are gated at boot time, so regardless of mvebu-soc-id behavior, the PCIe driver should take care of doing all the necessary initialization without making the assumptions that the clocks were left turned on from the bootloader time. This is needed if we want to support pci-mvebu as a module, so I don't see why hacking mvebu-soc-id is going to solve this. Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
WARNING: multiple messages have this Message-ID (diff)
From: thomas.petazzoni@free-electrons.com (Thomas Petazzoni) To: linux-arm-kernel@lists.infradead.org Subject: Fixing PCIe issues on Armada XP Date: Fri, 18 Apr 2014 15:02:44 +0200 [thread overview] Message-ID: <20140418150244.4b3d5229@skate> (raw) In-Reply-To: <20140411163129.GA20565@obsidianresearch.com> Dear Jason Gunthorpe, On Fri, 11 Apr 2014 10:31:29 -0600, Jason Gunthorpe wrote: > > Moreover, I am not entirely convinced that a PHY reset is needed here. > > In my tests, doing just a wait after setting the local dev number was > > sufficient. The fact is works with earlyprintk also indicates that we > > don't need to do any specific action with the PHY, just to wait a bit > > of time. I am worried that resetting the PHY might actually take more > > time than what is needed, and may have other consequences that we don't > > necessarily understand at this point. > > I really disagree - clearly the fundamental problem is suspending one > side of the PEX link while the other remains operating. That isn't > specified to work and really shouldn't work. > > If you suspend one side of the PEX you *MUST* reset the > link. Absolutely. No Doubt In My Mind. > > Remember, PCI-E is a serial shared state protocol. The two sides must > remain in sync or a link reset is required to recover the shared > state. Halting one side obviously destroys this invariant. > > I think in many cases the reset happens autonomously. The remote side > will force it to happen. This is what the debugging from Neil shows - > the link just resets at some inconvenient point. Now we know why. > > The timing sensitivity also makes sense, if you suspend for a very > short time window the other side might not notice. If you suspend for > longer the other side will reset the link autonomously and your local > side will quickly notice the reset once it comes back. > > If you suspend for a little bit the link might not retrain immediately > but the shared state can become corrupted (eg sequence number > mismatch) this will eventually trigger a reset, after the local PEX > has been operating again. > > The LinkUp bit after resume is also clearly a lie - most likely the > PEX takes some time to detect the change in remote state to trigger a > link down. After all, it was suspended while the remote was busy > trying to recover. Ok, fair enough. However, Neil's patch (which is basically your patch with longer delays) isn't working here, as I just reported in a separate e-mail. So we don't have a solution right now. Do you have another proposal to try ? > The fundamental problem here is the clock driver. It should not be > gating PEX clocks so naively. A PEX suspend needs to be sequenced to > ensure the link is cleanly brought down before the PEX is put to > sleep. That way it can cleanly and unambiguously be started up when it > resumes. No risk of glitching/corrupting the far side with some kind > of crap on the serial bus. > > In any event, the most important required patch here is one that fixes > socid. It must not turn off the PEX clock. Then we can talk about how > to fix pci-mvebu to work as a module... I don't really understand this: all clocks are gated at boot time, so regardless of mvebu-soc-id behavior, the PCIe driver should take care of doing all the necessary initialization without making the assumptions that the clocks were left turned on from the bootloader time. This is needed if we want to support pci-mvebu as a module, so I don't see why hacking mvebu-soc-id is going to solve this. Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
next prev parent reply other threads:[~2014-04-18 13:02 UTC|newest] Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-04-10 16:19 Fixing PCIe issues on Armada XP Thomas Petazzoni 2014-04-10 16:19 ` Thomas Petazzoni 2014-04-10 16:57 ` Jason Gunthorpe 2014-04-10 16:57 ` Jason Gunthorpe 2014-04-10 18:01 ` Thomas Petazzoni 2014-04-10 18:01 ` Thomas Petazzoni 2014-04-10 20:12 ` Jason Gunthorpe 2014-04-10 20:12 ` Jason Gunthorpe 2014-04-10 21:04 ` Thomas Petazzoni 2014-04-10 21:04 ` Thomas Petazzoni 2014-04-10 21:56 ` Neil Greatorex 2014-04-10 21:56 ` Neil Greatorex 2014-04-10 22:06 ` Jason Gunthorpe 2014-04-10 22:06 ` Jason Gunthorpe 2014-04-10 22:15 ` Neil Greatorex 2014-04-10 22:15 ` Neil Greatorex 2014-04-11 10:23 ` Thomas Petazzoni 2014-04-11 10:23 ` Thomas Petazzoni 2014-04-11 16:31 ` Jason Gunthorpe 2014-04-11 16:31 ` Jason Gunthorpe 2014-04-11 17:21 ` Matthew Minter 2014-04-11 17:21 ` Matthew Minter 2014-04-11 17:29 ` Jason Gunthorpe 2014-04-11 17:29 ` Jason Gunthorpe 2014-04-18 13:02 ` Thomas Petazzoni [this message] 2014-04-18 13:02 ` Thomas Petazzoni 2014-04-22 17:34 ` Jason Gunthorpe 2014-04-22 17:34 ` Jason Gunthorpe 2014-04-18 12:58 ` Thomas Petazzoni 2014-04-18 12:58 ` Thomas Petazzoni 2014-04-22 17:56 ` Jason Gunthorpe 2014-04-22 17:56 ` Jason Gunthorpe 2014-04-10 17:10 ` Willy Tarreau 2014-04-10 17:10 ` Willy Tarreau 2014-04-10 18:02 ` Thomas Petazzoni 2014-04-10 18:02 ` Thomas Petazzoni 2014-04-10 23:13 ` Willy Tarreau 2014-04-10 23:13 ` Willy Tarreau 2014-04-10 23:40 ` Jason Gunthorpe 2014-04-10 23:40 ` Jason Gunthorpe 2014-04-11 6:23 ` Willy Tarreau 2014-04-11 6:23 ` Willy Tarreau 2014-04-10 18:20 ` Neil Greatorex 2014-04-10 18:20 ` Neil Greatorex 2014-04-10 21:07 ` Thomas Petazzoni 2014-04-10 21:07 ` Thomas Petazzoni 2014-04-11 14:32 ` Thomas Petazzoni 2014-04-11 14:32 ` Thomas Petazzoni 2014-04-11 15:57 ` Neil Greatorex 2014-04-11 15:57 ` Neil Greatorex
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=20140418150244.4b3d5229@skate \ --to=thomas.petazzoni@free-electrons.com \ --cc=alior@marvell.com \ --cc=andrew@lunn.ch \ --cc=ezequiel.garcia@free-electrons.com \ --cc=gerlando.falauto@keymile.com \ --cc=gregory.clement@free-electrons.com \ --cc=jason@lakedaemon.net \ --cc=jgunthorpe@obsidianresearch.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-pci@vger.kernel.org \ --cc=matthew_minter@xyratex.com \ --cc=neil@fatboyfat.co.uk \ --cc=tawfik@marvell.com \ --cc=w@1wt.eu \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.