From: Murali Karicheri <m-karicheri2@ti.com>
To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
Richard Zhu <r65037@freescale.com>, Marek Vasut <marex@denx.de>,
Randy Dunlap <rdunlap@infradead.org>,
Russell King <linux@arm.linux.org.uk>,
Pawel Moll <pawel.moll@arm.com>, Arnd Bergmann <arnd@arndb.de>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
<linux-pci@vger.kernel.org>, Jingoo Han <jg1.han@samsung.com>,
<linux-kernel@vger.kernel.org>,
Kishon Vijay Abraham I <kishon@ti.com>,
Rob Herring <robh+dt@kernel.org>,
Santosh Shilimkar <santosh.shilimkar@ti.com>,
Kumar Gala <galak@codeaurora.org>,
Grant Likely <grant.likely@linaro.org>,
Mark Rutland <mark.rutland@arm.com>,
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v7 4/5] PCI: add PCI controller for keystone PCIe h/w
Date: Wed, 30 Jul 2014 15:34:44 -0400 [thread overview]
Message-ID: <53D948D4.6080603@ti.com> (raw)
In-Reply-To: <20140723174228.GB11270@obsidianresearch.com>
On 07/23/2014 01:42 PM, Jason Gunthorpe wrote:
> On Tue, Jul 22, 2014 at 05:52:00PM -0600, Bjorn Helgaas wrote:
>> If there is a hardware defect, a PCI quirk is a reasonable way to work
>> around it, since that's the main purpose of quirks. fixup_mpss_256()
>> is an example of something that sounds superficially similar.
>
> It was my suggestion to engage the PCI-E tuning code. By my
> understanding the HW bug is that read response segmentation at the
> host bridge does not work - so all read requests from any downstream
> device must have responses that fit within a single packet.
>
In the case of Keystone PCI, when I set the MRSS to 256 in the EP, PCI
controller is able to function properly. Keystone spec says.
• Maximum outbound payload size of 128 bytes
• Maximum inbound payload size of 256 bytes
• Maximum remote read request size of 256 bytes
I am interpreting the "Maximum remote read request size" to indicate it
can's handle if it exceeds the limit. It has an outbound payload size of
128 bytes. So in this case a read request would results in 2 completion
packets. So it seems to be able to segment up to maximum 256 bytes of
read request. Where do I find the requirement in PCI spec that "read
response segmentation at the host bridge does not work" ?
> This is completely against how the spec envisions things working,
> segmentation is a mandatory function. As you point out there is no
> parameter bounding the maximum read request size that a completer will
> accept.
>
> So, the only fix is that every downstream device must always have a
> MRSS set to less than the MPS of the host bridge.
Why this can't be the default behavior in the PCI core? Any cons?
Murali
>
> Which means the tuning code must be involved somehow, as that code
> controls the MRSS of unrelated devices...
>
> Regards,
> Jason
next prev parent reply other threads:[~2014-07-30 19:36 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-21 16:58 [PATCH v7 0/5] Add Keystone PCIe controller driver Murali Karicheri
2014-07-21 16:58 ` [PATCH v7 1/5] PCI: designware: add rd[wr]_other_conf API Murali Karicheri
2014-07-21 16:58 ` [PATCH v7 2/5] PCI: designware: refactor MSI code to work with v3.65 dw hardware Murali Karicheri
2014-07-21 16:58 ` [PATCH v7 3/5] PCI: designware: enhance dw_pcie_host_init() to support v3.65 DW hardware Murali Karicheri
2014-07-23 1:27 ` Jingoo Han
2014-07-21 16:58 ` [PATCH v7 4/5] PCI: add PCI controller for keystone PCIe h/w Murali Karicheri
2014-07-22 22:35 ` Bjorn Helgaas
2014-07-22 22:52 ` Murali Karicheri
2014-07-22 23:52 ` Bjorn Helgaas
2014-07-23 17:42 ` Jason Gunthorpe
2014-07-30 19:34 ` Murali Karicheri [this message]
2014-07-30 20:05 ` Jason Gunthorpe
2014-08-06 14:38 ` Murali Karicheri
2014-07-21 16:58 ` [PATCH v7 5/5] PCI: keystone: Update maintainer information Murali Karicheri
2014-07-22 22:57 ` [PATCH v7 0/5] Add Keystone PCIe controller driver Bjorn Helgaas
2014-07-23 15:27 ` Murali Karicheri
2014-07-23 16:43 ` Bjorn Helgaas
2014-07-23 16:56 ` Murali Karicheri
2014-08-18 14:58 ` Murali Karicheri
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=53D948D4.6080603@ti.com \
--to=m-karicheri2@ti.com \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=galak@codeaurora.org \
--cc=grant.likely@linaro.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=jg1.han@samsung.com \
--cc=jgunthorpe@obsidianresearch.com \
--cc=kishon@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=marex@denx.de \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=r65037@freescale.com \
--cc=rdunlap@infradead.org \
--cc=robh+dt@kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).