All of lore.kernel.org
 help / color / mirror / Atom feed
From: robh@kernel.org (Rob Herring)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 2/2] phy: zynqmp: Add dt bindings for ZynqMP phy
Date: Mon, 10 Sep 2018 15:30:59 -0500	[thread overview]
Message-ID: <20180910203059.GA7055@bogus> (raw)
In-Reply-To: <1536165747-6405-3-git-send-email-anurag.kumar.vulisha@xilinx.com>

On Wed, Sep 05, 2018 at 10:12:27PM +0530, Anurag Kumar Vulisha wrote:
> This patch adds the document describing dt bindings for ZynqMP
> phy. ZynqMP SOC has a High Speed Processing System Gigabit
> Transceiver which provides PHY capabilties to USB, SATA,
> PCIE, Display Port and Ehernet SGMII controllers.
> 
> Signed-off-by: Anurag Kumar Vulisha <anurag.kumar.vulisha@xilinx.com>
> ---
>  Changes in v3:
> 	1. Corrected the Documentation as suggested by Vivek Gautam
> 
>  Changes in v2:
> 	1. None
>  .../devicetree/bindings/phy/phy-zynqmp.txt         | 104 +++++++++++++++++++++
>  1 file changed, 104 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/phy-zynqmp.txt
> 
> diff --git a/Documentation/devicetree/bindings/phy/phy-zynqmp.txt b/Documentation/devicetree/bindings/phy/phy-zynqmp.txt
> new file mode 100644
> index 0000000..65007c4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-zynqmp.txt
> @@ -0,0 +1,104 @@
> +Xilinx ZynqMP PHY binding
> +
> +This binding describes a ZynqMP PHY device that is used to control ZynqMP
> +High Speed Gigabit Transceiver(GT). ZynqMP PS GTR provides four lanes
> +and are used by USB, SATA, PCIE, Display port and Ethernet SGMMI controllers.
> +
> +Phy provider node
> +=================
> +
> +Required properties:
> +- compatible	: Can be "xlnx,zynqmp-psgtr-v1.1" or "xlnx,zynqmp-psgtr"
> +
> +- reg           : Address and length of register sets for each device in
> +                  "reg-names"
> +
> +- reg-names     : The names of the register addresses corresponding to the
> +		  registers filled in "reg":
> +			- serdes: SERDES block register set
> +			- siou: SIOU block register set
> +
> +Optional properties:
> +- xlnx,tx_termination_fix : Include this for fixing functional issue with the

s/_/-/

> +		  TX termination resistance in GT, which can be out of spec for
> +		  the XCZU9EG silicon version. This property is not required for
> +		  "xlnx,zynqmp-psgtr-v1.1"
> +
> +Required nodes	:  A sub-node is required for each lane the controller
> +		   provides.
> +
> +Phy sub-nodes
> +=============
> +
> +Required properties:
> +lane0:

lane0 or lane at 0? If you need or care about numbering then add a reg 
property.

> +- #phy-cells	: Should be 4
> +
> +lane1:
> +- #phy-cells	: Should be 4
> +
> +lane2:
> +- #phy-cells	: Should be 4
> +
> +lane3:
> +- #phy-cells	: Should be 4
> +
> +Example:
> +	zynqmp_phy: phy at fd400000 {
> +		compatible = "xlnx,zynqmp-psgtr-v1.1";
> +		status = "okay";
> +		reg = <0x0 0xfd400000 0x0 0x40000>, <0x0 0xfd3d0000 0x0 0x1000>;
> +		reg-names = "serdes", "siou";
> +
> +		lane0: lane at 0 {
> +			#phy-cells = <4>;
> +		};
> +		lane1: lane at 1 {
> +			#phy-cells = <4>;
> +		};
> +		lane2: lane at 2 {
> +			#phy-cells = <4>;
> +		};
> +		lane3: lane at 3 {
> +			#phy-cells = <4>;
> +		};
> +	};
> +
> +Specifying phy control of devices
> +=================================
> +
> +Device nodes should specify the configuration required in their "phys"
> +property, containing a phandle to the phy port node and a device type.
> +
> +phys = <PHANDLE CONTROLLER_TYPE CONTROLLER_INSTANCE LANE_NUM LANE_FREQ>;
> +
> +PHANDLE                 = &lane0 or &lane1 or &lane2 or &lane3
> +CONTROLLER_TYPE         = PHY_TYPE_PCIE or PHY_TYPE_SATA or PHY_TYPE_USB
> +			  or PHY_TYPE_DP or PHY_TYPE_SGMII
> +CONTROLLER_INSTANCE     = Depends on controller type used, can be any of
> +				PHY_TYPE_PCIE : 0 or 1 or 2 or 3
> +				PHY_TYPE_SATA : 0 or 1
> +				PHY_TYPE_USB  : 0 or 1
> +				PHY_TYPE_DP   : 0 or 1
> +				PHY_TYPE_SGMII: 0 or 1 or 2 or 3
> +LANE_NUM                = Depends on which lane clock is used as ref clk, can be
> +			  0 or 1 or 2 or 3

I'm not really clear about what this is.

> +LANE_FREQ               = Frequency that controller can operate, can be any of
> +			  19.2Mhz,20Mhz,24Mhz,26Mhz,27Mhz,28.4Mhz,40Mhz,52Mhz,
> +			  100Mhz,108Mhz,125Mhz,135Mhz,150Mhz

This can't be implied by the mode/type? I wouldn't expect any frequency 
can be used for each mode.

> +
> +Example:
> +
> +#include <dt-bindings/phy/phy.h>
> +
> +	usb at fe200000 {
> +		...
> +		phys	  = <&lane2 PHY_TYPE_USB3 0 2 2600000>;
> +		...
> +	};
> +
> +	ahci at fd0c0000 {
> +		...
> +		phys	  = <&lane3 PHY_TYPE_SATA 1 1 125000000>;
> +		...
> +	};

What if you are doing multiple lanes for 1 device? That would be more 
useful 2nd example if that's supported.

> -- 
> 2.1.1
> 

WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org>
To: Anurag Kumar Vulisha <anurag.kumar.vulisha@xilinx.com>
Cc: kishon@ti.com, michal.simek@xilinx.com, mark.rutland@arm.com,
	vivek.gautam@codeaurora.org, v.anuragkumar@gmail.com,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v3 2/2] phy: zynqmp: Add dt bindings for ZynqMP phy
Date: Mon, 10 Sep 2018 15:30:59 -0500	[thread overview]
Message-ID: <20180910203059.GA7055@bogus> (raw)
In-Reply-To: <1536165747-6405-3-git-send-email-anurag.kumar.vulisha@xilinx.com>

On Wed, Sep 05, 2018 at 10:12:27PM +0530, Anurag Kumar Vulisha wrote:
> This patch adds the document describing dt bindings for ZynqMP
> phy. ZynqMP SOC has a High Speed Processing System Gigabit
> Transceiver which provides PHY capabilties to USB, SATA,
> PCIE, Display Port and Ehernet SGMII controllers.
> 
> Signed-off-by: Anurag Kumar Vulisha <anurag.kumar.vulisha@xilinx.com>
> ---
>  Changes in v3:
> 	1. Corrected the Documentation as suggested by Vivek Gautam
> 
>  Changes in v2:
> 	1. None
>  .../devicetree/bindings/phy/phy-zynqmp.txt         | 104 +++++++++++++++++++++
>  1 file changed, 104 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/phy-zynqmp.txt
> 
> diff --git a/Documentation/devicetree/bindings/phy/phy-zynqmp.txt b/Documentation/devicetree/bindings/phy/phy-zynqmp.txt
> new file mode 100644
> index 0000000..65007c4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-zynqmp.txt
> @@ -0,0 +1,104 @@
> +Xilinx ZynqMP PHY binding
> +
> +This binding describes a ZynqMP PHY device that is used to control ZynqMP
> +High Speed Gigabit Transceiver(GT). ZynqMP PS GTR provides four lanes
> +and are used by USB, SATA, PCIE, Display port and Ethernet SGMMI controllers.
> +
> +Phy provider node
> +=================
> +
> +Required properties:
> +- compatible	: Can be "xlnx,zynqmp-psgtr-v1.1" or "xlnx,zynqmp-psgtr"
> +
> +- reg           : Address and length of register sets for each device in
> +                  "reg-names"
> +
> +- reg-names     : The names of the register addresses corresponding to the
> +		  registers filled in "reg":
> +			- serdes: SERDES block register set
> +			- siou: SIOU block register set
> +
> +Optional properties:
> +- xlnx,tx_termination_fix : Include this for fixing functional issue with the

s/_/-/

> +		  TX termination resistance in GT, which can be out of spec for
> +		  the XCZU9EG silicon version. This property is not required for
> +		  "xlnx,zynqmp-psgtr-v1.1"
> +
> +Required nodes	:  A sub-node is required for each lane the controller
> +		   provides.
> +
> +Phy sub-nodes
> +=============
> +
> +Required properties:
> +lane0:

lane0 or lane@0? If you need or care about numbering then add a reg 
property.

> +- #phy-cells	: Should be 4
> +
> +lane1:
> +- #phy-cells	: Should be 4
> +
> +lane2:
> +- #phy-cells	: Should be 4
> +
> +lane3:
> +- #phy-cells	: Should be 4
> +
> +Example:
> +	zynqmp_phy: phy@fd400000 {
> +		compatible = "xlnx,zynqmp-psgtr-v1.1";
> +		status = "okay";
> +		reg = <0x0 0xfd400000 0x0 0x40000>, <0x0 0xfd3d0000 0x0 0x1000>;
> +		reg-names = "serdes", "siou";
> +
> +		lane0: lane@0 {
> +			#phy-cells = <4>;
> +		};
> +		lane1: lane@1 {
> +			#phy-cells = <4>;
> +		};
> +		lane2: lane@2 {
> +			#phy-cells = <4>;
> +		};
> +		lane3: lane@3 {
> +			#phy-cells = <4>;
> +		};
> +	};
> +
> +Specifying phy control of devices
> +=================================
> +
> +Device nodes should specify the configuration required in their "phys"
> +property, containing a phandle to the phy port node and a device type.
> +
> +phys = <PHANDLE CONTROLLER_TYPE CONTROLLER_INSTANCE LANE_NUM LANE_FREQ>;
> +
> +PHANDLE                 = &lane0 or &lane1 or &lane2 or &lane3
> +CONTROLLER_TYPE         = PHY_TYPE_PCIE or PHY_TYPE_SATA or PHY_TYPE_USB
> +			  or PHY_TYPE_DP or PHY_TYPE_SGMII
> +CONTROLLER_INSTANCE     = Depends on controller type used, can be any of
> +				PHY_TYPE_PCIE : 0 or 1 or 2 or 3
> +				PHY_TYPE_SATA : 0 or 1
> +				PHY_TYPE_USB  : 0 or 1
> +				PHY_TYPE_DP   : 0 or 1
> +				PHY_TYPE_SGMII: 0 or 1 or 2 or 3
> +LANE_NUM                = Depends on which lane clock is used as ref clk, can be
> +			  0 or 1 or 2 or 3

I'm not really clear about what this is.

> +LANE_FREQ               = Frequency that controller can operate, can be any of
> +			  19.2Mhz,20Mhz,24Mhz,26Mhz,27Mhz,28.4Mhz,40Mhz,52Mhz,
> +			  100Mhz,108Mhz,125Mhz,135Mhz,150Mhz

This can't be implied by the mode/type? I wouldn't expect any frequency 
can be used for each mode.

> +
> +Example:
> +
> +#include <dt-bindings/phy/phy.h>
> +
> +	usb@fe200000 {
> +		...
> +		phys	  = <&lane2 PHY_TYPE_USB3 0 2 2600000>;
> +		...
> +	};
> +
> +	ahci@fd0c0000 {
> +		...
> +		phys	  = <&lane3 PHY_TYPE_SATA 1 1 125000000>;
> +		...
> +	};

What if you are doing multiple lanes for 1 device? That would be more 
useful 2nd example if that's supported.

> -- 
> 2.1.1
> 

  reply	other threads:[~2018-09-10 20:30 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-05 16:42 [PATCH v3 0/2] phy: zynqmp: Add phy driver for xilinx zynqmp phy core Anurag Kumar Vulisha
2018-09-05 16:42 ` Anurag Kumar Vulisha
2018-09-05 16:42 ` Anurag Kumar Vulisha
2018-09-05 16:42 ` [PATCH v3 1/2] " Anurag Kumar Vulisha
2018-09-05 16:42   ` Anurag Kumar Vulisha
2018-09-05 16:42   ` Anurag Kumar Vulisha
2018-09-10 20:15   ` Rob Herring
2018-09-10 20:15     ` Rob Herring
2018-09-11  8:04     ` Anurag Kumar Vulisha
2018-09-11  8:04       ` Anurag Kumar Vulisha
2018-11-01 17:01   ` sundeep subbaraya
2018-11-01 17:01     ` sundeep subbaraya
2018-11-01 17:31     ` Anurag Kumar Vulisha
2018-11-01 17:31       ` Anurag Kumar Vulisha
2018-09-05 16:42 ` [PATCH v3 2/2] phy: zynqmp: Add dt bindings for ZynqMP phy Anurag Kumar Vulisha
2018-09-05 16:42   ` Anurag Kumar Vulisha
2018-09-05 16:42   ` Anurag Kumar Vulisha
2018-09-10 20:30   ` Rob Herring [this message]
2018-09-10 20:30     ` Rob Herring
2018-09-11  8:07     ` Anurag Kumar Vulisha
2018-09-11  8:07       ` Anurag Kumar Vulisha
2018-09-11  8:07       ` Anurag Kumar Vulisha

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=20180910203059.GA7055@bogus \
    --to=robh@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.