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?

>  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