Re: [PATCH 1/2] dt-bindings: pci: tegra: Update for per-lane PHYs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 03/08/2016 08:48 AM, Thierry Reding wrote:
From: Thierry Reding <treding@xxxxxxxxxx>

Changes to the pad controller device tree binding have required that
each lane be associated with a separate PHY.

I still don't think this has anything to do with DT bindings. Rather, the definition of a PHY (in HW and the Linux PHY subsystem) is a single lane. That fact then requires drivers to support a PHY per lane rather than a single multi-lane PHY, and equally means the DT bindings must be written according to the correct definition of a PHY.

Still, I suppose the commit description is fine as is.

Update the PCI host bridge
device tree binding to allow each root port to define the list of PHYs
required to drive the lanes associated with it.

diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt

+Required properties for Tegra124 and later:
+- phys: Must contain an phandle to a PHY for each entry in phy-names.
+- phy-names: Must include an entry for each active lane. Note that the number
+  of entries does not have to (though usually will) be equal to the specified
+  number of lanes in the nvidia,num-lanes property. Entries are of the form
+  "pcie-N": where N ranges from 0 to the value specified in nvidia,num-lanes.

When would the number of PHYs not equal the number of lanes? I thought the whole point of this patch was to switch to per-lane PHYs? Perhaps I'm just misremembering some exception, so there may be no need to change this.

  Example:

  SoC DTSI:
@@ -169,6 +179,9 @@ SoC DTSI:
  			ranges;

  			nvidia,num-lanes = <2>;
+
+			phys = <&{/padctl@0,7009f000/pads/pcie/pcie-4}>;
+			phy-names = "pcie-0";
  		};

The example shows a Tegra20 PCIe controller, yet includes Tegra124-or-greater properties. That seems a bit odd. Should the changes to the example be dropped, or does "Required properties for Tegra124 and later" mean "Required for T124+, optional for earlier chips"?

Conceptually this change is fine by me though.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux