linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Nagarjuna Kristam <nkristam@nvidia.com>
Cc: balbi@kernel.org, gregkh@linuxfoundation.org,
	jonathanh@nvidia.com, mark.rutland@arm.com, robh+dt@kernel.org,
	linux-tegra@vger.kernel.org, linux-usb@vger.kernel.org,
	devicetree@vger.kernel.org
Subject: Re: [Patch V3 4/8] dt-bindings: usb: Add  NVIDIA Tegra XUSB device mode controller binding
Date: Thu, 23 May 2019 12:13:59 +0200	[thread overview]
Message-ID: <20190523101359.GD30331@ulmo> (raw)
In-Reply-To: <1557988772-15406-5-git-send-email-nkristam@nvidia.com>

[-- Attachment #1: Type: text/plain, Size: 5681 bytes --]

On Thu, May 16, 2019 at 12:09:28PM +0530, Nagarjuna Kristam wrote:
> Add device-tree binding documentation for the XUSB device mode controller
> present on Tegra210 SoC. This controller supports the USB 3.0
> specification.
> 
> Signed-off-by: Nagarjuna Kristam <nkristam@nvidia.com>
> ---
>  .../devicetree/bindings/usb/nvidia,tegra-xudc.txt  | 101 +++++++++++++++++++++
>  1 file changed, 101 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.txt
> 
> diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.txt b/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.txt
> new file mode 100644
> index 0000000..d78b436
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.txt
> @@ -0,0 +1,101 @@
> +Device tree binding for NVIDIA Tegra XUSB device mode controller (XUDC)
> +=======================================================================
> +
> +The Tegra XUDC controller supports both USB 2.0 HighSpeed/FullSpeed and
> +USB 3.0 SuperSpeed protocols.
> +
> +Required properties:
> +--------------------
> +- compatible: For Tegra210, must contain "nvidia,tegra210-xudc".
> +- reg: Must contain the base and length of the XUSB device registers, XUSB device
> +  PCI Config registers and XUSB device controller registers.
> +- interrupts: Must contain the XUSB device interrupt.
> +- clocks: Must contain an entry for all clocks used.
> +  See ../clock/clock-bindings.txt for details.
> +- clock-names: Must include the following entries:
> +   - dev: Clock to enable core XUSB dev clock.
> +   - ss: Clock to enable XUSB super speed clock.
> +   - ss_src: Clock to enable XUSB super speed dev clock.
> +   - hs_src: Clock to enable XUSB high Speed dev clock.
> +   - fs_src: Clock to enable XUSB full Speed dev clock.

You use inconsistent spelling for "speed" here.

> +- nvidia,xusb-padctl: phandle to the XUSB pad controller that is used to
> +  configure the USB pads used by the XUDC controller.
> +- power-domains: A list of PM domain specifiers that reference each power-domain
> +  used by the XUSB device mode controller. This list must comprise of a specifier
> +  for the XUSBA and XUSBB power-domains. See ../power/power_domain.txt and
> +  ../arm/tegra/nvidia,tegra20-pmc.txt for details.
> +- power-domain-names: A list of names that represent each of the specifiers in
> +  the 'power-domains' property. Must include 'ss' and 'dev'.
> +
> +For Tegra210:
> +- avddio-usb-supply: PCIe/USB3 analog logic power supply. Must supply 1.05 V.
> +- hvdd-usb-supply: USB controller power supply. Must supply 3.3 V.
> +
> +- phys: Must contain an entry for each entry in phy-names.
> +  See ../phy/phy-bindings.txt for details.
> +- phy-names: Should include an entry for each PHY used by the controller.
> +  Names must be "usb2", and "usb3" if support SuperSpeed device mode.
> +  - "usb3" phy, SuperSpeed (SSTX+/SSTX-/SSRX+/SSRX-) data lines.
> +  - "usb2" phy, USB 2.0 (D+/D-) data lines.
> +
> +- extcon: Must contains an extcon entry which detects USB VBUS pin.
> +  See ../extcon/extcon-usb-gpio.txt for details.

Do the phys, phy-names and extcon properties only apply to Tegra210? It
sounds like those would also apply to other generations, so they should
go before the "For Tegra210:" line.

> +
> +Example:
> +--------
> +	pmc: pmc@7000e400 {
> +		compatible = "nvidia,tegra210-pmc";
> +		reg = <0x0 0x7000e400 0x0 0x400>;
> +		clocks = <&tegra_car TEGRA210_CLK_PCLK>, <&clk32k_in>;
> +		clock-names = "pclk", "clk32k_in";
> +
> +		powergates {
> +			pd_xusbss: xusba {
> +				clocks = <&tegra_car TEGRA210_CLK_XUSB_SS>;
> +				resets = <&tegra_car TEGRA210_CLK_XUSB_SS>;

We typically use the literal number here to be consistent with the cases
where the clock ID differs from the reset ID.

> +				#power-domain-cells = <0>;
> +			};
> +
> +			pd_xusbdev: xusbb {
> +				clocks = <&tegra_car TEGRA210_CLK_XUSB_DEV>;
> +				resets = <&tegra_car 95>;

It seems like don't follow that rule exactly since this is the same
thing we have for XUSB already. I think it'd be best to stick with the
literal number (like here) and remove the odd ones out. I can prepare
patches to convert over the existing oddballs.

> +				#power-domain-cells = <0>;
> +			};
> +		};
> +	};
> +
> +	xudc@700d0000 {
> +		compatible = "nvidia,tegra210-xudc";
> +		reg = <0x0 0x700d0000 0x0 0x8000>,
> +			<0x0 0x700d8000 0x0 0x1000>,
> +			<0x0 0x700d9000 0x0 0x1000>;

Use tabs, followed by spaces to properly align with the first entry,
like you do for clock-names below.

> +
> +		interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
> +
> +		clocks = <&tegra_car TEGRA210_CLK_XUSB_DEV>,
> +			<&tegra_car TEGRA210_CLK_XUSB_SS>,
> +			<&tegra_car TEGRA210_CLK_XUSB_SSP_SRC>,
> +			<&tegra_car TEGRA210_CLK_XUSB_HS_SRC>,
> +			<&tegra_car TEGRA210_CLK_XUSB_FS_SRC>;

Ditto.

> +		clock-names = "dev", "ss", "ss_src",
> +			      "hs_src", "fs_src";
> +
> +		power-domains = <&pd_xusbdev>, <&pd_xusbss>;
> +		power-domain-names = "dev", "ss";
> +
> +		nvidia,xusb-padctl = <&padctl>;
> +
> +		phys = <&{/padctl@7009f000/pads/usb2/lanes/usb2-0}>;
> +		phy-names = "usb2;

Does it perhaps make sense to include the pad controller snippet in here
as well?

Thierry

> +
> +		avddio-usb-supply = <&vdd_pex_1v05>;
> +		hvdd-usb-supply = <&vdd_3v3_sys>;
> +
> +		extcon = <&extcon_usb>;
> +	};
> +
> +	extcon_usb: extcon_vbus {
> +		compatible = "linux,extcon-usb-gpio";
> +		vbus-gpio = <&gpio TEGRA_GPIO(Z, 0) GPIO_ACTIVE_LOW>;
> +	};
> +
> -- 
> 2.7.4
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2019-05-23 10:14 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-16  6:39 [Patch V3 0/8] Tegra XUSB gadget driver support Nagarjuna Kristam
2019-05-16  6:39 ` [Patch V3 1/8] phy: tegra: xusb: t210: add XUSB dual mode support Nagarjuna Kristam
2019-05-21  2:16   ` jckuo
2019-05-23  9:39   ` Thierry Reding
2019-05-16  6:39 ` [Patch V3 2/8] phy: tegra: xusb: t210: add usb3 port fake support Nagarjuna Kristam
2019-05-21  3:00   ` jckuo
2019-05-23 11:16     ` Nagarjuna Kristam
2019-05-23 10:01   ` Thierry Reding
2019-05-23 11:24     ` Nagarjuna Kristam
2019-05-16  6:39 ` [Patch V3 3/8] phy: tegra: xusb: t210: add vbus override support Nagarjuna Kristam
2019-05-21  4:34   ` jckuo
2019-05-23 11:15     ` Nagarjuna Kristam
2019-05-23 10:03   ` Thierry Reding
2019-05-23 11:13     ` Nagarjuna Kristam
2019-05-16  6:39 ` [Patch V3 4/8] dt-bindings: usb: Add NVIDIA Tegra XUSB device mode controller binding Nagarjuna Kristam
2019-05-21  6:08   ` JC Kuo
2019-05-23 10:13   ` Thierry Reding [this message]
2019-05-23 11:41     ` Nagarjuna Kristam
2019-06-13 21:32   ` Rob Herring
2019-06-18  6:18     ` Nagarjuna Kristam
2019-05-16  6:39 ` [Patch V3 5/8] arm64: tegra: Add xudc node for Tegra210 Nagarjuna Kristam
2019-05-21  6:08   ` JC Kuo
2019-05-23 10:15   ` Thierry Reding
2019-05-16  6:39 ` [Patch V3 6/8] arm64: tegra: Enable xudc on Jetson TX1 Nagarjuna Kristam
2019-05-21  6:11   ` JC Kuo
2019-05-16  6:39 ` [Patch V3 7/8] usb: gadget: Add UDC driver for tegra XUSB device mode controller Nagarjuna Kristam
2019-05-16  9:08   ` Chunfeng Yun
2019-05-24  6:50     ` Nagarjuna Kristam
2019-05-29  8:06       ` Chunfeng Yun
2019-05-23 10:26   ` Thierry Reding
2019-05-23 10:28   ` Thierry Reding
2019-05-16  6:39 ` [Patch V3 8/8] arm64: defconfig: Enable tegra XUDC driver Nagarjuna Kristam
2019-05-23 10:30   ` Thierry Reding
2019-05-24  8:01     ` Nagarjuna Kristam

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=20190523101359.GD30331@ulmo \
    --to=thierry.reding@gmail.com \
    --cc=balbi@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jonathanh@nvidia.com \
    --cc=linux-tegra@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=nkristam@nvidia.com \
    --cc=robh+dt@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).