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
>
WARNING: multiple messages have this Message-ID (diff)
From: Lorenzo Pieralisi <lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>
To: Manikanta Maddireddy
<mmaddireddy-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cc: thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org,
vidyas-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org,
mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
kthota-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org
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-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
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-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> 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: 89+ 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 ` Manikanta Maddireddy
2017-10-30 13:57 ` [PATCH V3 01/12] PCI: tegra: Start LTSSM after programming root port Manikanta Maddireddy
2017-10-30 13:57 ` Manikanta Maddireddy
2017-12-12 11:32 ` Lorenzo Pieralisi
2017-12-12 11:32 ` Lorenzo Pieralisi
2017-12-13 11:50 ` Manikanta Maddireddy
2017-12-13 11:50 ` Manikanta Maddireddy
2017-12-13 14:08 ` Lorenzo Pieralisi
2017-12-13 14:08 ` Lorenzo Pieralisi
2017-12-13 16:32 ` Manikanta Maddireddy
2017-12-13 16:32 ` Manikanta Maddireddy
2017-12-13 18:34 ` Lorenzo Pieralisi
2017-12-13 18:34 ` Lorenzo Pieralisi
2017-12-13 19:27 ` Manikanta Maddireddy
2017-12-13 19:27 ` Manikanta Maddireddy
2017-12-14 9:57 ` Lorenzo Pieralisi
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-10-30 13:57 ` Manikanta Maddireddy
2017-12-12 11:45 ` Lorenzo Pieralisi
2017-12-12 11:45 ` Lorenzo Pieralisi
2017-12-13 12:02 ` Manikanta Maddireddy
2017-12-13 12:02 ` Manikanta Maddireddy
2017-12-13 14:23 ` Lorenzo Pieralisi
2017-12-13 1:16 ` Mikko Perttunen
2017-12-13 1:16 ` Mikko Perttunen
2017-12-14 15:14 ` Thierry Reding
2017-12-19 12:40 ` Lorenzo Pieralisi
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-10-30 13:57 ` Manikanta Maddireddy
2017-12-12 14:32 ` Lorenzo Pieralisi
2017-12-12 14:32 ` Lorenzo Pieralisi
2017-12-13 17:54 ` Manikanta Maddireddy
2017-12-13 17:54 ` Manikanta Maddireddy
2017-12-13 18:51 ` Lorenzo Pieralisi
2017-12-13 18:51 ` Lorenzo Pieralisi
2017-12-13 19:10 ` Bjorn Helgaas
2017-12-13 19:10 ` Bjorn Helgaas
2017-12-21 19:48 ` Ley Foon Tan
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-10-30 13:57 ` Manikanta Maddireddy
2017-12-14 15:29 ` Thierry Reding
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-10-30 13:57 ` Manikanta Maddireddy
2017-12-14 15:28 ` Thierry Reding
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-10-30 13:57 ` Manikanta Maddireddy
2017-12-14 15:30 ` Thierry Reding
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-10-30 13:57 ` Manikanta Maddireddy
2017-12-14 15:32 ` Thierry Reding
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-10-30 13:57 ` Manikanta Maddireddy
2017-12-14 15:34 ` Thierry Reding
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-10-30 13:57 ` Manikanta Maddireddy
2017-12-14 15:58 ` Thierry Reding
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-10-30 13:57 ` Manikanta Maddireddy
2017-12-14 16:00 ` Thierry Reding
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-10-30 13:57 ` 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-10-30 13:57 ` Manikanta Maddireddy
2017-12-12 17:43 ` Lorenzo Pieralisi [this message]
2017-12-12 17:43 ` Lorenzo Pieralisi
2017-12-14 16:13 ` Thierry Reding
2017-12-14 16:13 ` Thierry Reding
2017-12-14 16:14 ` 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-25 19:59 ` Manikanta Maddireddy
2017-11-27 18:09 ` Lorenzo Pieralisi
2017-11-27 18:09 ` Lorenzo Pieralisi
2017-11-27 18:27 ` Manikanta Maddireddy
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 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.