Linux-PCI Archive on lore.kernel.org
 help / color / Atom feed
From: Manikanta Maddireddy <mmaddireddy@nvidia.com>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: <bhelgaas@google.com>, <robh+dt@kernel.org>,
	<mark.rutland@arm.com>, <jonathanh@nvidia.com>,
	<lorenzo.pieralisi@arm.com>, <vidyas@nvidia.com>,
	<linux-tegra@vger.kernel.org>, <linux-pci@vger.kernel.org>,
	<devicetree@vger.kernel.org>
Subject: Re: [PATCH 26/30] dt-bindings: pci: tegra: Document nvidia,plat-gpios optional prop
Date: Wed, 17 Apr 2019 23:56:24 +0530
Message-ID: <be8d689f-73f7-5418-600a-53a2032aef37@nvidia.com> (raw)
In-Reply-To: <20190417151956.GF26626@ulmo>



On 17-Apr-19 8:49 PM, Thierry Reding wrote:
> On Wed, Apr 17, 2019 at 04:52:46PM +0530, Manikanta Maddireddy wrote:
>>
>> On 16-Apr-19 9:04 PM, Thierry Reding wrote:
>>> On Mon, Apr 15, 2019 at 11:28:29PM +0530, Manikanta Maddireddy wrote:
>>>> On 15-Apr-19 7:46 PM, Thierry Reding wrote:
>>>>> On Thu, Apr 11, 2019 at 10:33:51PM +0530, Manikanta Maddireddy wrote:
>>>>>> Document "nvidia,plat-gpios" optional property which supports configuring
>>>>>> of platform specific gpios.
>>>>>>
>>>>>> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
>>>>>> ---
>>>>>>  Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt | 3 +++
>>>>>>  1 file changed, 3 insertions(+)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
>>>>>> index fbbd3bcb3435..dca8393b86d1 100644
>>>>>> --- a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
>>>>>> +++ b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
>>>>>> @@ -73,6 +73,8 @@ Optional properties:
>>>>>>    pinctrl phandle to allow driver to explicitly put PCIe IO in DPD state.
>>>>>>  - pinctrl-1: PCIe IO(bias & REFCLK) deep power down(DPD) enable state.
>>>>>>    Pass pinctrl phandle to allow driver bring PCIe IO out of DPD state.
>>>>>> +- nvidia,plat-gpios: A list of platform specific gpios which controls
>>>>>> +  endpoint's internal regulator or PCIe logic.
>>>>> We discussed this with Vidya during review of the Tegra194 PCIe device
>>>>> tree bindings and arrived at the conclusion that all of the GPIOs that
>>>>> need to be controlled for PCI to work can be modelled as proper device
>>>>> nodes (I think regulator and GPIO-controlled muxes were the only two
>>>>> use-cases for which we need this).
>>>>>
>>>>> Can the same be done for this PCI controller? What use-cases are we
>>>>> talking about?
>>>> In Tegra194 case it is apt to use regulator framework because gpios are used
>>>> to control regulators. However I published this patch to control vendor defined
>>>> gpios in endpoints. For ex: isolate gpio in RTL8111. Since I am not sure if
>>>> regulator framework is apt, I published as gpio patch.
>>>>>>  Required properties on Tegra124 and later (deprecated):
>>>>>>  - phys: Must contain an entry for each entry in phy-names.
>>>>>> @@ -567,6 +569,7 @@ Board DTS:
>>>>>>  		pci@2,0 {
>>>>>>  			phys = <&{/padctl@7009f000/pads/pcie/lanes/pcie-4}>;
>>>>>>  			phy-names = "pcie-0";
>>>>>> +			nvidia,plat-gpios = <&gpio TEGRA_GPIO(X, 3) GPIO_ACTIVE_HIGH>;
>>>>>>  			status = "okay";
>>>>>>  		};
>>>>>>  	};
>>>>> I recall this being the setup for Jetson Nano and the X.3 GPIO going to
>>>>> an Ethernet device. Let's find out what exactly this GPIO is used for
>>>>> and why we need it to be set up as part of the PCI controller driver
>>>>> rather than the Ethernet device.
>>>>>
>>>>> If it turns out we can't model this other than with a generic GPIO type
>>>>> of property we need a better explanation than the above, and the Jetson
>>>>> Nano use-case would provide that explanation.
>>>>>
>>>>> And if indeed we cannot model this more accurately, I think we should
>>>>> use something like the gpio-hog binding rather than some custom PCI
>>>>> controller property.
>>>>>
>>>>> Thierry
>>>> Yes, in Jetson Nano gpio x.3 is controlling isolate pin of RTL8111.
>>>> RTL8111 datasheet available online says that as long as isolate
>>>> pin is asserted it'll not sample RX lanes and doesn't drive TX lanes.
>>>> Since RTL8111 PCIe IP should be active when PCIe host driver is
>>>> attempting link up, this gpio can be controlled by host driver only.
>>>>
>>>> I didn't go for gpio-hog because this gpio should be asserted
>>>> during suspend, to enable wake on LAN.
>>> I don't see code in gpiolib that would cause this to be deasserted
>>> during suspend.
>>>
>>> Is there ever a need to manipulate this GPIO at all? Or do we just
>>> need to make sure that it's always asserted?
>> Following steps
>> 1) ISOLATEB gpio should be deasserted during boot to enable PCIe section
>> of RTL8111
>> 2) PCIe host driver enumerates RTL8111
>> 3) When suspend is initiated, ISOLATEB gpio should be asserted after PCIe
>> host controller suspend is completed to disable PCIe section of RTL8111
>> and enable Wake on LAN
>> 4) During resume, first ISOLATE gpio should be deasserted to get PCIe link up
> I think it's important that we be very clear here. If ISOLATEB is
> asserted, does that mean the PCIe link is down? Or does it only mean
> that the RTL8111 cannot be enumerated.
>
> If the PCIe link remains down as long as ISOLATEB is asserted, then it
> sounds like there's more going on than this GPIO just keeping the
> RTL8111 from talking on the PCI bus. In that case we would probably have
> to model this as some sort of power regulator for the bus.
>
> However, if the PCIe link can be brought up if the RTL8111 is isolated,
> but if the device can only not be enumerated, then we could still have
> the RTL8111 driver deassert ISOLATEB early during resume. We only have
> to make sure that it happens before any PCI requests are sent to the
> device.
>
> Thierry

RTL8111 will not drive PCIe outputs(except WAKE#) and will not sample PCIe
input as long as ISOLATEB is asserted. So PCIe link up doesn't happen if
ISOLATEB is asserted.

Manikanta

>
>>> The problem with adding this to nvidia,plat-gpios in the PCI root port
>>> node is that there's no context at all, so the PCI host driver can't
>>> really do anything with this, other than perhaps exactly one fixed
>>> operation, but then it's pretty much equivalent to a gpio-hog.
>>>
>>> If we do need control over the pin, I think it might be worth looking at
>>> adding support to gpiolib for initial pin configuration (so that it does
>>> not hog the GPIO, but still configures it). That would allow us to take
>>> the PCI device out of isolation initially and once the device has been
>>> probed we can control the GPIO from the PCI device. That way the device
>>> driver has the necessary context to assert and deassert the pin at the
>>> appropriate time, while still giving us the possibility to make the
>>> device appear on the PCI bus.
>> ISOLATEB gpio disables the PCIe section in RTL8111(Rx is not sampled &
>> doesn't drive Tx), if PCI client driver controls it, then it has
>> to do it after host controller suspend_noirq callback is completed.
>> Only suspend callback available after suspend_noirq is syscore_ops.
>> I didn't go with it because it is take void arguments, so client
>> driver has to maintain global pointers and I see only core drivers
>> like irqchip, clk, etc are using it.
>>
>> Manikanta
>>
>>> As a side-note, I think it would've been better if the ISOLATEB signal
>>> was wired up such that it would've been active by default. That would
>>> mean that if the bootloader and/or OS were not aware of the ISOLATEB
>>> signal, they would still be able to use the Ethernet device. I think
>>> that would've been a more sensible default, especially if the bus that
>>> the device is on requires the signal to be controlled without even
>>> knowing that the device exists.
>>>
>>> Thierry


  reply index

Thread overview: 106+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-11 17:03 [PATCH 00/30] Enable Tegra PCIe root port features Manikanta Maddireddy
2019-04-11 17:03 ` [PATCH 01/30] soc/tegra: pmc: Export tegra_powergate_power_on() Manikanta Maddireddy
2019-04-11 17:03 ` [PATCH 02/30] PCI: tegra: Fix PCIe host power up sequence Manikanta Maddireddy
2019-04-15 11:01   ` Thierry Reding
2019-04-15 14:11     ` Manikanta Maddireddy
2019-04-15 14:30       ` Thierry Reding
2019-04-15 18:14         ` Manikanta Maddireddy
2019-04-11 17:03 ` [PATCH 03/30] PCI: tegra: Move REFCLK pad settings out of phy_power_on() Manikanta Maddireddy
2019-04-15 11:06   ` Thierry Reding
2019-04-15 14:20     ` Manikanta Maddireddy
2019-04-11 17:03 ` [PATCH 04/30] PCI: tegra: Add PCIe Gen2 link speed support Manikanta Maddireddy
2019-04-15 11:21   ` Thierry Reding
2019-04-15 14:47     ` Manikanta Maddireddy
2019-04-15 15:36       ` Thierry Reding
2019-04-15 15:53         ` Manikanta Maddireddy
2019-04-11 17:03 ` [PATCH 05/30] PCI: tegra: Advertise PCIe Advanced Error Reporting (AER) capability Manikanta Maddireddy
2019-04-15 11:23   ` Thierry Reding
2019-04-15 14:49     ` Manikanta Maddireddy
2019-04-11 17:03 ` [PATCH 06/30] PCI: tegra: Program UPHY electrical settings for Tegra210 Manikanta Maddireddy
2019-04-15 11:29   ` Thierry Reding
2019-04-15 14:55     ` Manikanta Maddireddy
2019-04-15 15:38       ` Thierry Reding
2019-04-11 17:03 ` [PATCH 07/30] PCI: tegra: Enable opportunistic update FC and ACK Manikanta Maddireddy
2019-04-15 11:30   ` Thierry Reding
2019-04-11 17:03 ` [PATCH 08/30] PCI: tegra: Disable AFI dynamic clock gating Manikanta Maddireddy
2019-04-15 11:32   ` Thierry Reding
2019-04-11 17:03 ` [PATCH 09/30] PCI: tegra: Process pending DLL transactions before entering L1 or L2 Manikanta Maddireddy
2019-04-15 11:33   ` Thierry Reding
2019-04-11 17:03 ` [PATCH 10/30] PCI: tegra: Enable PCIe xclk clock clamping Manikanta Maddireddy
2019-04-15 11:37   ` Thierry Reding
2019-04-15 14:58     ` Manikanta Maddireddy
2019-04-11 17:03 ` [PATCH 11/30] PCI: tegra: Increase the deskew retry time Manikanta Maddireddy
2019-04-15 11:39   ` Thierry Reding
2019-04-15 14:58     ` Manikanta Maddireddy
2019-04-11 17:03 ` [PATCH 12/30] PCI: tegra: Add SW fixup for RAW violations Manikanta Maddireddy
2019-04-11 20:01   ` Bjorn Helgaas
2019-04-12  5:59     ` Manikanta Maddireddy
2019-04-15 11:41       ` Thierry Reding
2019-04-15 11:45   ` Thierry Reding
2019-04-15 15:02     ` Manikanta Maddireddy
2019-04-11 17:03 ` [PATCH 13/30] PCI: tegra: Update flow control threshold in Tegra210 Manikanta Maddireddy
2019-04-15 11:47   ` Thierry Reding
2019-04-15 15:05     ` Manikanta Maddireddy
2019-04-23  9:27       ` Manikanta Maddireddy
2019-04-11 17:03 ` [PATCH 14/30] PCI: tegra: Set target speed as Gen1 before link up Manikanta Maddireddy
2019-04-11 20:04   ` Bjorn Helgaas
2019-04-12  6:44     ` Manikanta Maddireddy
2019-04-12 14:35       ` Bjorn Helgaas
2019-04-15 10:43         ` Manikanta Maddireddy
2019-04-15 11:52   ` Thierry Reding
2019-04-15 15:12     ` Manikanta Maddireddy
2019-04-11 17:03 ` [PATCH 15/30] PCI: tegra: Fix PLLE powerdown issue due to CLKREQ# signal Manikanta Maddireddy
2019-04-15 13:17   ` Thierry Reding
2019-04-15 15:14     ` Manikanta Maddireddy
2019-04-11 17:03 ` [PATCH 16/30] PCI: tegra: Program AFI_CACHE* registers only for Tegra20 Manikanta Maddireddy
2019-04-15 13:20   ` Thierry Reding
2019-04-16 10:47     ` Manikanta Maddireddy
2019-04-16 16:11       ` Thierry Reding
2019-04-11 17:03 ` [PATCH 17/30] PCI: tegra: Use switch statements in tegra_pcie_isr() Manikanta Maddireddy
2019-04-15 13:25   ` Thierry Reding
2019-04-15 15:25     ` Manikanta Maddireddy
2019-04-11 17:03 ` [PATCH 18/30] PCI: tegra: Change PRSNT_SENSE irq log to debug Manikanta Maddireddy
2019-04-11 17:03 ` [PATCH 19/30] PCI: tegra: Use legacy irq for port service drivers Manikanta Maddireddy
2019-04-15 13:35   ` Thierry Reding
2019-04-11 17:03 ` [PATCH 20/30] PCI: tegra: Add AFI_PEX2_CTRL reg offset as part of soc struct Manikanta Maddireddy
2019-04-15 13:31   ` Thierry Reding
2019-04-11 17:03 ` [PATCH 21/30] PCI: tegra: Add "pci" type check before parsing child device tree node Manikanta Maddireddy
2019-04-15 13:37   ` Thierry Reding
2019-04-15 15:30     ` Manikanta Maddireddy
2019-04-15 15:42       ` Thierry Reding
2019-04-11 17:03 ` [PATCH 22/30] PCI: tegra: Access endpoint config only if PCIe link is up Manikanta Maddireddy
2019-04-11 20:15   ` Bjorn Helgaas
2019-04-12  7:00     ` Manikanta Maddireddy
2019-04-12 14:50       ` Bjorn Helgaas
2019-04-15 11:36         ` Manikanta Maddireddy
2019-04-15 13:45           ` Thierry Reding
2019-04-15 13:52             ` Thierry Reding
2019-04-15 14:04           ` Bjorn Helgaas
2019-04-15 15:43             ` Manikanta Maddireddy
2019-04-23 20:24               ` Bjorn Helgaas
2019-04-11 17:03 ` [PATCH 23/30] dt-bindings: pci: tegra: Document PCIe DPD pinctrl optional prop Manikanta Maddireddy
2019-04-15 14:07   ` Thierry Reding
2019-04-15 15:48     ` Manikanta Maddireddy
2019-04-11 17:03 ` [PATCH 24/30] arm64: tegra: Add PEX DPD states as pinctrl properties Manikanta Maddireddy
2019-04-11 17:03 ` [PATCH 25/30] PCI: tegra: Put PEX CLK & BIAS pads in DPD mode Manikanta Maddireddy
2019-04-15 14:11   ` Thierry Reding
2019-04-11 17:03 ` [PATCH 26/30] dt-bindings: pci: tegra: Document nvidia,plat-gpios optional prop Manikanta Maddireddy
2019-04-11 20:18   ` Bjorn Helgaas
2019-04-12  7:01     ` Manikanta Maddireddy
2019-04-15 14:16   ` Thierry Reding
2019-04-15 17:58     ` Manikanta Maddireddy
2019-04-16 15:34       ` Thierry Reding
2019-04-17 11:22         ` Manikanta Maddireddy
2019-04-17 15:19           ` Thierry Reding
2019-04-17 18:26             ` Manikanta Maddireddy [this message]
2019-04-11 17:03 ` [PATCH 27/30] PCI: tegra: Add support to configure platform GPIOs Manikanta Maddireddy
2019-04-11 17:03 ` [PATCH 28/30] dt-bindings: pci: tegra: Document nvidia,rst-gpio optional prop Manikanta Maddireddy
2019-04-15 14:20   ` Thierry Reding
2019-04-15 18:01     ` Manikanta Maddireddy
2019-04-29 18:33     ` Rob Herring
2019-04-11 17:03 ` [PATCH 29/30] PCI: tegra: Add support for GPIO based PCIe reset Manikanta Maddireddy
2019-04-15 14:20   ` Thierry Reding
2019-04-15 18:03     ` Manikanta Maddireddy
2019-04-11 17:03 ` [PATCH 30/30] PCI: tegra: Change link retry log level to INFO Manikanta Maddireddy
2019-04-15 14:23   ` Thierry Reding
2019-04-15 18:05     ` Manikanta Maddireddy

Reply instructions:

You may reply publically 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=be8d689f-73f7-5418-600a-53a2032aef37@nvidia.com \
    --to=mmaddireddy@nvidia.com \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jonathanh@nvidia.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@kernel.org \
    --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

Linux-PCI Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-pci/0 linux-pci/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-pci linux-pci/ https://lore.kernel.org/linux-pci \
		linux-pci@vger.kernel.org linux-pci@archiver.kernel.org
	public-inbox-index linux-pci


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-pci


AGPL code for this site: git clone https://public-inbox.org/ public-inbox