All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marek.vasut@gmail.com>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Bjorn Helgaas <helgaas@kernel.org>
Cc: linux-pci@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Wolfram Sang <wsa@the-dreams.de>,
	Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
	linux-renesas-soc@vger.kernel.org, pali@kernel.org
Subject: Re: [PATCH V6] PCI: rcar: Add L1 link state fix into data abort hook
Date: Mon, 19 Jul 2021 17:38:59 +0200	[thread overview]
Message-ID: <59d5a3bd-9b31-0203-ca99-46a92ffc9895@gmail.com> (raw)
In-Reply-To: <20210719085953.GA17481@lpieralisi>

On 7/19/21 10:59 AM, Lorenzo Pieralisi wrote:
> [+Pali]
> 
> On Sat, Jul 17, 2021 at 12:33:34PM -0500, Bjorn Helgaas wrote:
>> On Fri, May 14, 2021 at 10:05:49PM +0200, marek.vasut@gmail.com wrote:
>>> From: Marek Vasut <marek.vasut+renesas@gmail.com>
>>>
>>> The R-Car PCIe controller is capable of handling L0s/L1 link states.
>>> While the controller can enter and exit L0s link state, and exit L1
>>> link state, without any additional action from the driver, to enter
>>> L1 link state, the driver must complete the link state transition by
>>> issuing additional commands to the controller.
>>>
>>> The problem is, this transition is not atomic. The controller sets
>>> PMEL1RX bit in PMSR register upon reception of PM_ENTER_L1 DLLP from
>>> the PCIe card, but then the controller enters some sort of inbetween
>>> state. The driver must detect this condition and complete the link
>>> state transition, by setting L1IATN bit in PMCTLR and waiting for
>>> the link state transition to complete.
>>>
>>> If a PCIe access happens inside this window, where the controller
>>> is between L0 and L1 link states, the access generates a fault and
>>> the ARM 'imprecise external abort' handler is invoked.
>>>
>>> Just like other PCI controller drivers, here we hook the fault handler,
>>> perform the fixup to help the controller enter L1 link state, and then
>>> restart the instruction which triggered the fault. Since the controller
>>> is in L1 link state now, the link can exit from L1 link state to L0 and
>>> successfully complete the access.
>>>
>>> While it was suggested to disable L1 link state support completely on
>>> the controller level, this would not prevent the L1 link state entry
>>> initiated by the link partner. This happens e.g. in case a PCIe card
>>> enters D3Hot state, which could be initiated from pci_set_power_state()
>>> if the card indicates D3Hot support, which in turn means link must enter
>>> L1 state. So instead, fix up the L1 link state after all.
>>>
>>> Note that this fixup is applicable only to Aarch32 R-Car controllers,
>>> the Aarch64 R-Car perform the same fixup in TFA, see TFA commit [1]
>>> 0969397f2 ("rcar_gen3: plat: Prevent PCIe hang during L1X config access")
>>> [1] https://github.com/ARM-software/arm-trusted-firmware/commit/0969397f295621aa26b3d14b76dd397d22be58bf
>>
>> This patch is horribly ugly but it's working around a horrible
>> hardware problem, and I don't have any better suggestions, so I guess
>> we don't really have much choice.
> 
> Pali is doing some work on the matter (in particular [1] above) and I
> was following that up to see if there was any outcome before merging
> this code, I could not follow up myself for lack of time.

arm32 r-car does NOT use atf, so this does not apply here.

  reply	other threads:[~2021-07-19 16:29 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-14 20:05 [PATCH V6] PCI: rcar: Add L1 link state fix into data abort hook marek.vasut
2021-05-17  7:39 ` Geert Uytterhoeven
2021-07-17 17:33 ` Bjorn Helgaas
2021-07-17 18:14   ` Marek Vasut
2021-07-19  8:59   ` Lorenzo Pieralisi
2021-07-19 15:38     ` Marek Vasut [this message]
2021-07-19 17:23     ` Pali Rohár
2021-07-19 18:39       ` Marek Vasut
2021-07-22 20:31         ` Pali Rohár
2021-07-19 22:06       ` Bjorn Helgaas
2021-07-27 16:11       ` Lorenzo Pieralisi
2021-07-27 16:16         ` Geert Uytterhoeven
2021-07-26 14:47   ` Geert Uytterhoeven
2021-07-26 17:49     ` Bjorn Helgaas
2021-07-27 16:32       ` Lorenzo Pieralisi
2021-08-05 18:30         ` Pali Rohár
2021-07-27 17:08       ` Marek Vasut
2021-08-04 11:06         ` Lorenzo Pieralisi

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=59d5a3bd-9b31-0203-ca99-46a92ffc9895@gmail.com \
    --to=marek.vasut@gmail.com \
    --cc=bhelgaas@google.com \
    --cc=geert+renesas@glider.be \
    --cc=helgaas@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=pali@kernel.org \
    --cc=wsa@the-dreams.de \
    --cc=yoshihiro.shimoda.uh@renesas.com \
    /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 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.