linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Phil Edworthy <phil.edworthy@renesas.com>
Cc: Marek Vasut <marek.vasut@gmail.com>,
	Bjorn Helgaas <helgaas@kernel.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Marek Vasut <marek.vasut+renesas@gmail.com>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Simon Horman <horms+renesas@verge.net.au>,
	Wolfram Sang <wsa@the-dreams.de>,
	"linux-renesas-soc@vger.kernel.org"
	<linux-renesas-soc@vger.kernel.org>
Subject: Re: [PATCH V2 4/5] PCI: rcar: Support runtime PM, link state L1 handling
Date: Mon, 20 Aug 2018 15:47:33 +0100	[thread overview]
Message-ID: <20180820144733.GA24413@red-moon> (raw)
In-Reply-To: <TY1PR01MB176994051783997958BAB14AF5320@TY1PR01MB1769.jpnprd01.prod.outlook.com>

On Mon, Aug 20, 2018 at 01:44:48PM +0000, Phil Edworthy wrote:

[...]

> However, both before and after this patch, the RP does not transition L1
> when the endpoints change to L1.
> This patch only transitions the RP to L1 during accessing a card's
> config registers, if the RP is not in L1 link state and has received
> PM_ENTER_L1 DLLP (e.g. resume). After this, the hardware will handle
> the transition out of L1.
> 
> The relevant part of the rcar manual says: "After a recovery to L0, if
> the device is in the Non-D0 state and PM_Enter_L1 DLLP is transmitted
> from the downstream device, software should confirm that hardware is
> in the L0 state (PMSR.PMSTATE = L0) and initiate the L1 transition
> sequence again (write 1 to PMCTLR.L1IATN). In this case, the sequence
> is: L0 → L1 → L0 recovery → L1 again."

Can you map these FSM steps to this patch code please ? I would like
to understand what Link state maps to which command written and when.

> I don’t think the potential issue that Bjorn talked about can happen
> because the RP does go into L1. I could be wrong though...

I do not understand this paragraph, mind elaborating on it ?

> The driver should also have a runtime-PM hook to transition to L1 on 
> suspend in order to save power. However, that is somewhat separate
> to the problem the patch fixes.

Yes that's a separate patch.

Thanks for chiming in, let's try to get to the bottom of this thread.

Lorenzo

  reply	other threads:[~2018-08-20 14:47 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-10 21:58 [PATCH V2 0/5] PCI: rcar: Add suspend/resume support Marek Vasut
2017-11-10 21:58 ` [PATCH V2 1/5] PCI: rcar: Poll more often in rcar_pcie_wait_for_dl() Marek Vasut
2017-11-13  7:03   ` Simon Horman
2017-11-10 21:58 ` [PATCH V2 2/5] PCI: rcar: Clean up the macros Marek Vasut
2017-11-13  7:03   ` Simon Horman
2017-11-13 18:11     ` Marek Vasut
2017-11-15 13:28       ` Simon Horman
2017-11-22 11:20         ` Marek Vasut
2017-11-10 21:58 ` [PATCH V2 3/5] PCI: rcar: Add the initialization of PCIe link in resume_noirq Marek Vasut
2017-11-13  7:05   ` Simon Horman
2017-11-10 21:58 ` [PATCH V2 4/5] PCI: rcar: Support runtime PM, link state L1 handling Marek Vasut
2017-11-13  7:05   ` Simon Horman
2017-11-17 17:49   ` Lorenzo Pieralisi
2018-06-10 13:57     ` Marek Vasut
2018-06-11 13:59       ` Bjorn Helgaas
2018-06-12 23:54         ` Marek Vasut
2018-06-13 13:53           ` Bjorn Helgaas
2018-06-13 15:52             ` Lorenzo Pieralisi
2018-06-13 17:25               ` Bjorn Helgaas
2018-06-14 11:43                 ` Lorenzo Pieralisi
2018-07-25 21:08                 ` Marek Vasut
2018-08-08 13:29                   ` Marek Vasut
2018-08-20 13:44                     ` Phil Edworthy
2018-08-20 14:47                       ` Lorenzo Pieralisi [this message]
2018-08-21  8:58                         ` Phil Edworthy
2018-08-21 15:32                           ` Lorenzo Pieralisi
2018-08-22  9:20                             ` Phil Edworthy
2018-08-14 16:25                 ` Lorenzo Pieralisi
2017-11-10 21:58 ` [PATCH V2 5/5] PCI: rcar: Add the suspend/resume for pcie-rcar driver Marek Vasut
2017-11-15 13:27   ` Simon Horman

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=20180820144733.GA24413@red-moon \
    --to=lorenzo.pieralisi@arm.com \
    --cc=geert+renesas@glider.be \
    --cc=helgaas@kernel.org \
    --cc=horms+renesas@verge.net.au \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=marek.vasut+renesas@gmail.com \
    --cc=marek.vasut@gmail.com \
    --cc=phil.edworthy@renesas.com \
    --cc=wsa@the-dreams.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).