From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Manikanta Maddireddy <mmaddireddy@nvidia.com>
Cc: thierry.reding@gmail.com, bhelgaas@google.com,
jonathanh@nvidia.com, vidyas@nvidia.com, mperttunen@nvidia.com,
linux-tegra@vger.kernel.org, linux-pci@vger.kernel.org,
kthota@nvidia.com
Subject: Re: [PATCH V3 12/12] PCI: tegra: Update flow control threshold in Tegra210
Date: Tue, 12 Dec 2017 17:43:29 +0000 [thread overview]
Message-ID: <20171212174329.GA22418@red-moon> (raw)
In-Reply-To: <1509371843-22931-13-git-send-email-mmaddireddy@nvidia.com>
On Mon, Oct 30, 2017 at 07:27:23PM +0530, Manikanta Maddireddy wrote:
> Recommended update FC threshold in Tegra210 is 0x60 for best performance
> of x1 link. Setting this to 0x60 provides the best balance between number
> of UpdateFC and read data sent over the link.
>
> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
> ---
> V3:
> * changed soc parameter name
> V2:
> * no change in this patch
>
> drivers/pci/host/pci-tegra.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
> index b29329226e3d..812d32cfdd0e 100644
> --- a/drivers/pci/host/pci-tegra.c
> +++ b/drivers/pci/host/pci-tegra.c
> @@ -223,6 +223,7 @@
> #define RP_VEND_XP_OPPORTUNISTIC_ACK (1 << 27)
> #define RP_VEND_XP_OPPORTUNISTIC_UPDATEFC (1 << 28)
> #define RP_VEND_XP_UPDATE_FC_THRESHOLD_MASK (0xff << 18)
> +#define RP_VEND_XP_UPDATE_FC_THRESHOLD_T210 (0x60 << 18)
You define a SOC specific threshold and a update_fc_threshold bool
variable to update it ? And what are you going to do if that's needed
on something that it is not a T210 ? Should not this be a(nother)
struct tegra_pcie_soc parameter instead than a macro ?
Not that I am happy about it but this deviates from the current
approach.
> #define RP_VEND_CTL0 0xf44
> #define RP_VEND_CTL0_DSK_RST_PULSE_WIDTH_MASK (0xf << 12)
> @@ -323,6 +324,7 @@ struct tegra_pcie_soc {
> bool update_clamp_threshold;
> bool raw_violation_fixup;
> bool program_deskew_time;
> + bool update_fc_threshold;
> };
>
> static inline struct tegra_msi *to_tegra_msi(struct msi_controller *chip)
> @@ -2231,6 +2233,13 @@ static void tegra_pcie_apply_sw_fixup(struct tegra_pcie_port *port)
> value |= RP_VEND_CTL0_DSK_RST_PULSE_WIDTH;
> writel(value, port->base + RP_VEND_CTL0);
> }
> +
> + if (soc->update_fc_threshold) {
> + value = readl(port->base + RP_VEND_XP);
> + value &= ~RP_VEND_XP_UPDATE_FC_THRESHOLD_MASK;
> + value |= RP_VEND_XP_UPDATE_FC_THRESHOLD_T210;
> + writel(value, port->base + RP_VEND_XP);
> + }
If, say, a platform requires update_fc_threshold and raw_violation_fixup
what takes precedence (ie they required programming the _same_
registers) ? update_fc_threshold takes precedence, since it is applied
last - but I would like you to think about this and realize that this
per-SoC mechanism does not scale anymore.
You should a) enforce some firmware initialization - most of the
parameters in struct tegra_pcie_soc could have been pre-programmed
by FW and b) think about adding some DT properties to handle the PCI
host bridge set-up.
Lorenzo
> }
> /*
> * FIXME: If there are no PCIe cards attached, then calling this function
> @@ -2371,6 +2380,7 @@ static const struct tegra_pcie_soc tegra20_pcie = {
> .update_clamp_threshold = false,
> .raw_violation_fixup = false,
> .program_deskew_time = false,
> + .update_fc_threshold = false,
> };
>
> static const struct tegra_pcie_soc tegra30_pcie = {
> @@ -2391,6 +2401,7 @@ static const struct tegra_pcie_soc tegra30_pcie = {
> .update_clamp_threshold = false,
> .raw_violation_fixup = false,
> .program_deskew_time = false,
> + .update_fc_threshold = false,
> };
>
> static const struct tegra_pcie_soc tegra124_pcie = {
> @@ -2410,6 +2421,7 @@ static const struct tegra_pcie_soc tegra124_pcie = {
> .update_clamp_threshold = true,
> .raw_violation_fixup = true,
> .program_deskew_time = false,
> + .update_fc_threshold = false,
> };
>
> static const struct tegra_pcie_soc tegra210_pcie = {
> @@ -2437,6 +2449,7 @@ static const struct tegra_pcie_soc tegra210_pcie = {
> .update_clamp_threshold = true,
> .raw_violation_fixup = false,
> .program_deskew_time = true,
> + .update_fc_threshold = true,
> };
>
> static const struct tegra_pcie_soc tegra186_pcie = {
> @@ -2457,6 +2470,7 @@ static const struct tegra_pcie_soc tegra186_pcie = {
> .update_clamp_threshold = false,
> .raw_violation_fixup = false,
> .program_deskew_time = false,
> + .update_fc_threshold = false,
> };
>
> static const struct of_device_id tegra_pcie_of_match[] = {
> --
> 2.1.4
>
next prev parent reply other threads:[~2017-12-12 17:42 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-30 13:57 [PATCH V3 00/12] Enable Tegra root port features and apply SW fixups Manikanta Maddireddy
2017-10-30 13:57 ` [PATCH V3 01/12] PCI: tegra: Start LTSSM after programming root port Manikanta Maddireddy
2017-12-12 11:32 ` Lorenzo Pieralisi
2017-12-13 11:50 ` Manikanta Maddireddy
2017-12-13 14:08 ` Lorenzo Pieralisi
2017-12-13 16:32 ` Manikanta Maddireddy
2017-12-13 18:34 ` Lorenzo Pieralisi
2017-12-13 19:27 ` Manikanta Maddireddy
2017-12-14 9:57 ` Lorenzo Pieralisi
2018-03-07 12:00 ` Lorenzo Pieralisi
2018-03-07 17:10 ` Manikanta Maddireddy
2017-10-30 13:57 ` [PATCH V3 02/12] PCI: tegra: Move REFCLK pad settings out of phy_power_on() Manikanta Maddireddy
2017-12-12 11:45 ` Lorenzo Pieralisi
2017-12-13 12:02 ` Manikanta Maddireddy
2017-12-13 14:23 ` Lorenzo Pieralisi
2017-12-13 1:16 ` Mikko Perttunen
2017-12-14 15:14 ` Thierry Reding
2017-12-19 12:40 ` Lorenzo Pieralisi
2017-10-30 13:57 ` [PATCH V3 03/12] PCI: tegra: Retrain link for Gen2 speed Manikanta Maddireddy
2017-12-12 14:32 ` Lorenzo Pieralisi
2017-12-13 17:54 ` Manikanta Maddireddy
2017-12-13 18:51 ` Lorenzo Pieralisi
2017-12-13 19:10 ` Bjorn Helgaas
2017-12-21 19:48 ` Ley Foon Tan
2017-10-30 13:57 ` [PATCH V3 04/12] PCI: tegra: Advertise PCIe Advanced Error Reporting (AER) capability Manikanta Maddireddy
2017-12-14 15:29 ` Thierry Reding
2017-10-30 13:57 ` [PATCH V3 05/12] PCI: tegra: Program UPHY electrical settings in Tegra210 Manikanta Maddireddy
2017-12-14 15:28 ` Thierry Reding
2017-10-30 13:57 ` [PATCH V3 06/12] PCI: tegra: Enable opportunistic update FC and ACK Manikanta Maddireddy
2017-12-14 15:30 ` Thierry Reding
2017-10-30 13:57 ` [PATCH V3 07/12] PCI: tegra: Disable AFI dynamic clock gating Manikanta Maddireddy
2017-12-14 15:32 ` Thierry Reding
2017-10-30 13:57 ` [PATCH V3 08/12] PCI: tegra: Wait for DLLP to finish before entering L1 or L2 Manikanta Maddireddy
2017-12-14 15:34 ` Thierry Reding
2017-10-30 13:57 ` [PATCH V3 09/12] PCI: tegra: Enable PCIe xclk clock clamping Manikanta Maddireddy
2017-12-14 15:58 ` Thierry Reding
2017-10-30 13:57 ` [PATCH V3 10/12] PCI: tegra: Add SW fixup for RAW violations Manikanta Maddireddy
2017-12-14 16:00 ` Thierry Reding
2017-10-30 13:57 ` [PATCH V3 11/12] PCI: tegra: Increase the deskew retry time Manikanta Maddireddy
2017-12-14 16:02 ` Thierry Reding
2017-10-30 13:57 ` [PATCH V3 12/12] PCI: tegra: Update flow control threshold in Tegra210 Manikanta Maddireddy
2017-12-12 17:43 ` Lorenzo Pieralisi [this message]
2017-12-14 16:13 ` Thierry Reding
2017-12-14 16:14 ` Thierry Reding
2017-11-25 19:59 ` [PATCH V3 00/12] Enable Tegra root port features and apply SW fixups Manikanta Maddireddy
2017-11-27 18:09 ` Lorenzo Pieralisi
2017-11-27 18:27 ` Manikanta Maddireddy
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=20171212174329.GA22418@red-moon \
--to=lorenzo.pieralisi@arm.com \
--cc=bhelgaas@google.com \
--cc=jonathanh@nvidia.com \
--cc=kthota@nvidia.com \
--cc=linux-pci@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=mmaddireddy@nvidia.com \
--cc=mperttunen@nvidia.com \
--cc=thierry.reding@gmail.com \
--cc=vidyas@nvidia.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).