From: Om Prakash Singh <omp@nvidia.com>
To: Vidya Sagar <vidyas@nvidia.com>, Bjorn Helgaas <helgaas@kernel.org>
Cc: <jingoohan1@gmail.com>, <gustavo.pimentel@synopsys.com>,
<lorenzo.pieralisi@arm.com>, <amurray@thegoodpenguin.co.uk>,
<bhelgaas@google.com>, <kishon@ti.com>,
<thierry.reding@gmail.com>, <Jisheng.Zhang@synaptics.com>,
<jonathanh@nvidia.com>, <linux-pci@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <kthota@nvidia.com>,
<mmaddireddy@nvidia.com>, <oop.singh@gmail.com>
Subject: Re: [PATCH] PCI: tegra: Disable PTM capabilities for EP mode
Date: Mon, 8 Mar 2021 16:12:55 +0530 [thread overview]
Message-ID: <26834aba-4d45-6da4-0548-1fb61e684b59@nvidia.com> (raw)
In-Reply-To: <81c84df2-e52b-7713-5026-c3e0a27376bd@nvidia.com>
On 3/5/2021 11:43 PM, Vidya Sagar wrote:
>
>
> On 3/5/2021 5:49 PM, Bjorn Helgaas wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> On Fri, Mar 05, 2021 at 01:42:34PM +0530, Om Prakash Singh wrote:
>>> PCIe EP compliance expect PTM capabilities (ROOT_CAPABLE, RES_CAPABLE,
>>> CLK_GRAN) to be disabled.
>>
>> I guess this is just enforcing the PCIe spec requirements that only
>> Root Ports, RCRBs, and Switches are allowed to set the PTM Responder
>> Capable bit, and that the Local Clock Granularity is RsvdP if PTM Root
>> Capable is zero? (PCIe r5.0, sec 7.9.16.2)
>>
>> Should this be done more generally somewhere in the dwc code as
>> opposed to in the tegra code?
> Agree.
>
I'll take care of this in next patch version
>>
>>> Signed-off-by: Om Prakash Singh <omp@nvidia.com>
>>> ---
>>> drivers/pci/controller/dwc/pcie-tegra194.c | 17 ++++++++++++++++-
>>> include/uapi/linux/pci_regs.h | 1 +
>>> 2 files changed, 17 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c b/drivers/pci/controller/dwc/pcie-tegra194.c
>>> index 6fa216e..a588312 100644
>>> --- a/drivers/pci/controller/dwc/pcie-tegra194.c
>>> +++ b/drivers/pci/controller/dwc/pcie-tegra194.c
>>> @@ -1639,7 +1639,7 @@ static void pex_ep_event_pex_rst_deassert(struct tegra_pcie_dw *pcie)
>>> struct dw_pcie *pci = &pcie->pci;
>>> struct dw_pcie_ep *ep = &pci->ep;
>>> struct device *dev = pcie->dev;
>>> - u32 val;
>>> + u32 val, ptm_cap_base = 0;
>>
>> Unnecessary init.
>>
>>> int ret;
>>>
>>> if (pcie->ep_state == EP_STATE_ENABLED)
>>> @@ -1760,6 +1760,21 @@ static void pex_ep_event_pex_rst_deassert(struct tegra_pcie_dw *pcie)
>>> PCI_CAP_ID_EXP);
>>> clk_set_rate(pcie->core_clk, GEN4_CORE_CLK_FREQ);
>>>
>>> + /* Disable PTM root and responder capability */
>>> + ptm_cap_base = dw_pcie_find_ext_capability(&pcie->pci,
>>> + PCI_EXT_CAP_ID_PTM);
>>> + if (ptm_cap_base) {
>>> + dw_pcie_dbi_ro_wr_en(pci);
>>> + val = dw_pcie_readl_dbi(pci, ptm_cap_base + PCI_PTM_CAP);
>>> + val &= ~PCI_PTM_CAP_ROOT;
>>> + dw_pcie_writel_dbi(pci, ptm_cap_base + PCI_PTM_CAP, val);
>>> +
>>> + val = dw_pcie_readl_dbi(pci, ptm_cap_base + PCI_PTM_CAP);
>>> + val &= ~(PCI_PTM_CAP_RES | PCI_PTM_GRANULARITY_MASK);
> Why can't this be clubbed with "val &= ~PCI_PTM_CAP_ROOT;" ?
>
This cannot be clubbed as PTM root capability needs to disable first before disabling responded capability
>>> + dw_pcie_writel_dbi(pci, ptm_cap_base + PCI_PTM_CAP, val);
>>> + dw_pcie_dbi_ro_wr_dis(pci);
>>> + }
>>> +
>>> val = (ep->msi_mem_phys & MSIX_ADDR_MATCH_LOW_OFF_MASK);
>>> val |= MSIX_ADDR_MATCH_LOW_OFF_EN;
>>> dw_pcie_writel_dbi(pci, MSIX_ADDR_MATCH_LOW_OFF, val);
>>> diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
>>> index e709ae8..9dd6f8d 100644
>>> --- a/include/uapi/linux/pci_regs.h
>>> +++ b/include/uapi/linux/pci_regs.h
>>> @@ -1050,6 +1050,7 @@
>>> /* Precision Time Measurement */
>>> #define PCI_PTM_CAP 0x04 /* PTM Capability */
>>> #define PCI_PTM_CAP_REQ 0x00000001 /* Requester capable */
>>> +#define PCI_PTM_CAP_RES 0x00000002 /* Responder capable */
>>> #define PCI_PTM_CAP_ROOT 0x00000004 /* Root capable */
>>> #define PCI_PTM_GRANULARITY_MASK 0x0000FF00 /* Clock granularity */
>>> #define PCI_PTM_CTRL 0x08 /* PTM Control */
>>> --
>>> 2.7.4
>>>
prev parent reply other threads:[~2021-03-08 10:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-05 8:12 Om Prakash Singh
2021-03-05 12:19 ` Bjorn Helgaas
2021-03-05 18:13 ` Vidya Sagar
2021-03-08 10:42 ` Om Prakash Singh [this message]
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=26834aba-4d45-6da4-0548-1fb61e684b59@nvidia.com \
--to=omp@nvidia.com \
--cc=Jisheng.Zhang@synaptics.com \
--cc=amurray@thegoodpenguin.co.uk \
--cc=bhelgaas@google.com \
--cc=gustavo.pimentel@synopsys.com \
--cc=helgaas@kernel.org \
--cc=jingoohan1@gmail.com \
--cc=jonathanh@nvidia.com \
--cc=kishon@ti.com \
--cc=kthota@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=mmaddireddy@nvidia.com \
--cc=oop.singh@gmail.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
Powered by JetHome