From: Murali Karicheri <m-karicheri2@ti.com>
To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"Strashko, Grygorii" <grygorii.strashko@ti.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Jingoo Han <jg1.han@samsung.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Shilimkar, Santosh" <santosh.shilimkar@ti.com>,
Mohit Kumar <mohit.kumar@st.com>,
Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH v1 5/5] pci: keystone: add pcie driver based on designware core driver
Date: Wed, 21 May 2014 19:32:58 -0400 [thread overview]
Message-ID: <537D37AA.5030303@ti.com> (raw)
In-Reply-To: <20140520170221.GA5130@obsidianresearch.com>
On 5/20/2014 1:02 PM, Jason Gunthorpe wrote:
> On Fri, May 16, 2014 at 08:29:56PM +0000, Karicheri, Muralidharan wrote:
>
>> But pcie_bus_configure_settings just make sure the mrrs for a device
>> is not greater than the max payload size.
> Not quite, it first scans the network checking the Maximum Payload Size
> Supported (MPSS) for each device, and chooses the highest supported by
> all as the MPS for all.
Why highest? It should be lowest so that all on the bus can handle it??
>
> PCI-E requires that an end point support all packets up to the MPS, so
> if your bridge can't generate a 512 byte read response packet, then it
> must not advertise a MPSS greater than 256 bytes.
What is MPSS? Is it the payload size in a message TLP? I read the PCIe
spec and find
MRSS is the maxumum read request size. So memory reads completion data
size is limited
to this size, right? So for DMA from EP to RC can't be greater than what
RC publishes.
Not sure how they are related?
I have checked that root port is advertising 256 bytes for mrrs and 128
bytes for mps
in the config space. So keystone pcie bridge is doing as expected.
In Keystone case, what I see is after adding
pcie_bus_configure_settings() with pci=pcie_bus_safe,
I get following log.
[ 1.988851] pcie_bus_configure_settings, config 1
[ 1.988860] pcie_bus_configure_set
[ 1.988879] pcieport 0000:00:00.0: Max Payload Size set to 256/ 256
(was 128), Max Read Rq 512
[ 1.988887] pcie_bus_configure_set
[ 1.988921] pci 0000:01:00.0: Max Payload Size set to 256/ 256 (was
128), Max Read Rq 512
[ 1.988928] pcie_bus_configure_set
[ 1.988961] pci 0000:01:00.1: Max Payload Size set to 256/ 256 (was
128), Max Read Rq 512
So it is not limiting MRRS to 256 bytes.
With pci=pcie_bus_perf
[ 1.985777] pcie_bus_configure_settings, config 2
[ 1.985783] pcie_bus_configure_set
[ 1.985810] pcieport 0000:00:00.0: Max Payload Size set to 256/ 256
(was 128), Max Read Rq 256
[ 1.985818] pcie_bus_configure_set
[ 1.985875] pci 0000:01:00.0: Max Payload Size set to 256/ 256 (was
128), Max Read Rq 256
[ 1.985882] pcie_bus_configure_set
[ 1.985939] pci 0000:01:00.1: Max Payload Size set to 256/ 256 (was
128), Max Read Rq 256
Is this log what you expect?
>
> Setting your MPSS to 128, 256, then using the
> pcie_bus_configure_settings to run the standard algorithm should
> properly limit the readrq to 256 and be able to properly support all
> the fun edge cases like hot plug.
> If the config space in your root port bridge is correct and already
> declares a MPSS of 256 then you have nothing else to do but make sure
> pcie_bus_configure_settings gets calls.
>
> If it is broken and claims a higher MPSS than it can support then you
> need to use a quirk only for the root port bridge or edit the config
> reply in the driver only to fix the MPSS
If MRSS is clamped to lowest, then this would work with out a quirk, and
has to
be unconditional (all cases, safe, performance etc).
I would like to go with the quirk approach until this discussion
concludes the next
step to fix this issue. May be someone can take owner ship of this
change at PCI
core level?
My quirk can be removed once the fix is accepted into the tree. Is that
an acceptable path forward?
Murali
>
> Jason
next prev parent reply other threads:[~2014-05-21 23:33 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-15 16:01 [PATCH v1 0/5] Add Keystone PCIe controller driver Murali Karicheri
2014-05-15 16:01 ` [PATCH v1 1/5] ARM: keystone: add pcie related options Murali Karicheri
2014-05-16 0:27 ` Jingoo Han
2014-05-16 14:36 ` Karicheri, Muralidharan
2014-05-15 16:01 ` [PATCH v1 2/5] pci: designware: enhancements to support keystone pcie Murali Karicheri
2014-05-16 2:40 ` Jingoo Han
2014-05-16 20:46 ` Karicheri, Muralidharan
2014-05-16 22:15 ` Kumar Gala
2014-05-16 22:49 ` Murali Karicheri
2014-05-15 16:01 ` [PATCH v1 3/5] phy: pci serdes phy driver for keystone Murali Karicheri
2014-05-15 16:14 ` Arnd Bergmann
2014-05-23 17:14 ` Murali Karicheri
2014-05-23 19:23 ` Arnd Bergmann
2014-05-27 16:46 ` Murali Karicheri
2014-05-27 18:36 ` Arnd Bergmann
2014-06-02 6:16 ` Kishon Vijay Abraham I
2014-06-02 6:45 ` Jingoo Han
2014-06-02 14:28 ` Murali Karicheri
2014-05-15 16:01 ` [PATCH v1 4/5] pci: dw: add common functions to support old hw based pci driver Murali Karicheri
2014-05-16 20:47 ` Karicheri, Muralidharan
2014-05-15 16:01 ` [PATCH v1 5/5] pci: keystone: add pcie driver based on designware core driver Murali Karicheri
2014-05-15 16:23 ` Arnd Bergmann
2014-05-15 17:45 ` Murali Karicheri
2014-05-15 18:20 ` Arnd Bergmann
2014-05-15 18:39 ` Jason Gunthorpe
2014-05-15 20:04 ` Murali Karicheri
2014-05-15 20:52 ` Jason Gunthorpe
2014-05-16 20:29 ` Karicheri, Muralidharan
2014-05-20 17:02 ` Jason Gunthorpe
2014-05-20 17:22 ` Bjorn Helgaas
2014-05-20 17:42 ` Jason Gunthorpe
2014-05-21 23:32 ` Murali Karicheri [this message]
2014-05-22 0:55 ` Jason Gunthorpe
[not found] ` <537E7823.5060609@ti.com>
2014-05-26 23:31 ` Jason Gunthorpe
2014-05-16 20:26 ` Murali Karicheri
2014-05-19 12:06 ` Arnd Bergmann
2014-05-19 21:10 ` Murali Karicheri
2014-05-20 7:55 ` Arnd Bergmann
2014-05-20 17:17 ` Bjorn Helgaas
2014-05-29 15:34 ` Murali Karicheri
2014-05-15 16:28 ` Arnd Bergmann
2014-05-16 22:44 ` Murali Karicheri
2014-05-19 12:12 ` Arnd Bergmann
2014-05-16 20:47 ` Karicheri, Muralidharan
2014-05-16 0:48 ` [PATCH v1 0/5] Add Keystone PCIe controller driver Jingoo Han
2014-05-16 20:40 ` Karicheri, Muralidharan
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=537D37AA.5030303@ti.com \
--to=m-karicheri2@ti.com \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=grygorii.strashko@ti.com \
--cc=jg1.han@samsung.com \
--cc=jgunthorpe@obsidianresearch.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mohit.kumar@st.com \
--cc=santosh.shilimkar@ti.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox