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, 6 Aug 2014 10:38:19 -0400 [thread overview]
Message-ID: <53E23DDB.4010803@ti.com> (raw)
In-Reply-To: <20140730200513.GA11918@obsidianresearch.com>
On 07/30/2014 04:05 PM, Jason Gunthorpe wrote:
> On Wed, Jul 30, 2014 at 03:34:44PM -0400, Murali Karicheri wrote:
>
>> • Maximum remote read request size of 256 bytes
>
> The PCI spec simply does not permit a completer to impose this
> limitation.
>
> See spec 2.3.1.1
>
> It is not an option to error a read request because it is too
> long. All requests must be completed. All completions must be segmented
> according to the RCB and Max_Payload_Size.
>
>> 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" ?
>
> You just said it. Segmenting up to only 256 bytes is not a limitation
> the completer can impose. Such a device is non-conformant.
>
>>> 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?
>
> It increases read request traffic and read response latency on the bus
> for large transfers.
>
> The MRSS is intented as a performance tuning knob, it is not something
> that ever needs to be set properly for correct bus operation.
>
> Jason
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Jason, Bjorn,
It appears that Keystone PCI has a hardware limitation that can't
handle read request size of greater than 256 bytes and a quirk is the
way to handle this hardware limitation. I will be sending a patch to
address this
Murali
next prev parent reply other threads:[~2014-08-06 14:39 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
2014-07-30 20:05 ` Jason Gunthorpe
2014-08-06 14:38 ` Murali Karicheri [this message]
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=53E23DDB.4010803@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).