From: Sinan Kaya <okaya@codeaurora.org>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linux-pci@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
Michael Neuling <michael.neuling@au1.ibm.com>,
linux-pci-owner@vger.kernel.org
Subject: Re: PCIe resets/restore and lack of CRS wait
Date: Thu, 22 Mar 2018 08:58:06 -0500 [thread overview]
Message-ID: <172f0ea9-7eba-1505-bb79-1ee31cc4d692@codeaurora.org> (raw)
In-Reply-To: <1521726371.16434.307.camel@kernel.crashing.org>
On 3/22/2018 8:46 AM, Benjamin Herrenschmidt wrote:
> On Thu, 2018-03-22 at 07:25 -0400, okaya@codeaurora.org wrote:
>>>>>
>>>
>>> That tells me that there is no guarantee by spec that we'll get
>>> ffff's, instead we might get HW stalls, or other really nasty
>>> effects when probing a register other than 0 (VID/DID) for CRS.
>>
>> AFAIK, spec also mentions that sw needs to observe 0xffffffff for all
>> other registers other than vendor id during CRS period.
>
> This isnt what's in the 3.1a spec at least ... section 2.3.2 explains
> the specified behaviour which is, for any register other than 0
> (VID/DID), to re-issue the request...
>
I don't have any hard preference on this. Bjorn wanted code to work for
systems with and without CRS capability. That was the reason we stayed
away from 0xffff0001.
CRS just gives you HW implementation defined retries for non vendor-id
register like you mentioned. If device does not reply in this period
of polling time, you should get all 1s eventually back.
All 1s is the spec way of saying device doesn't exist for config
transactions.
Some HW can poll indefinitely or other HW can return immediately.
If CRS visibility is supported & enabled, polling indefinitely and
hogging the CPU wouldn't be the best HW implementation.
> Now, it can have a timeout, and thus might be completed as a failed
> transaction after a while, but it's a sub-optimal way (ie, we'll end up
> hogging the CPU on loads) and it's not 100% clear that a failed
> transaction returns as all 1's (it should but ...).
>
> I can make sure it happens the way the code expects on powerpc, I'm not
> too worried about that, but I think for such a generic function, it
> would make sense to stick a bit closer to the spec.
> Cheers,
> Ben.
>
>
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
next prev parent reply other threads:[~2018-03-22 13:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-22 4:03 PCIe resets/restore and lack of CRS wait Benjamin Herrenschmidt
2018-03-22 4:36 ` okaya
2018-03-22 5:12 ` Benjamin Herrenschmidt
2018-03-22 6:24 ` Benjamin Herrenschmidt
2018-03-22 11:25 ` okaya
2018-03-22 13:46 ` Benjamin Herrenschmidt
2018-03-22 13:58 ` Sinan Kaya [this message]
2018-03-22 14:14 ` Bjorn Helgaas
2018-03-22 17:54 ` Sinan Kaya
2018-03-22 22:02 ` Benjamin Herrenschmidt
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=172f0ea9-7eba-1505-bb79-1ee31cc4d692@codeaurora.org \
--to=okaya@codeaurora.org \
--cc=benh@kernel.crashing.org \
--cc=bhelgaas@google.com \
--cc=linux-pci-owner@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=michael.neuling@au1.ibm.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.