All of lore.kernel.org
 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: 59+ 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 ` Nagarjuna Kristam
2019-05-16  6:39 ` [Patch V3 1/8] phy: tegra: xusb: t210: add XUSB dual mode support Nagarjuna Kristam
2019-05-16  6:39   ` Nagarjuna Kristam
2019-05-21  2:16   ` jckuo
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-16  6:39   ` Nagarjuna Kristam
2019-05-21  3:00   ` jckuo
2019-05-21  3:00     ` jckuo
2019-05-23 11:16     ` Nagarjuna Kristam
2019-05-23 11:16       ` Nagarjuna Kristam
2019-05-23 10:01   ` Thierry Reding
2019-05-23 11:24     ` Nagarjuna Kristam
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-16  6:39   ` Nagarjuna Kristam
2019-05-21  4:34   ` jckuo
2019-05-21  4:34     ` jckuo
2019-05-23 11:15     ` Nagarjuna Kristam
2019-05-23 11:15       ` Nagarjuna Kristam
2019-05-23 10:03   ` Thierry Reding
2019-05-23 11:13     ` Nagarjuna Kristam
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-16  6:39   ` Nagarjuna Kristam
2019-05-21  6:08   ` JC Kuo
2019-05-21  6:08     ` JC Kuo
2019-05-23 10:13   ` Thierry Reding [this message]
2019-05-23 11:41     ` Nagarjuna Kristam
2019-05-23 11:41       ` Nagarjuna Kristam
2019-06-13 21:32   ` Rob Herring
2019-06-18  6:18     ` Nagarjuna Kristam
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-16  6:39   ` Nagarjuna Kristam
2019-05-21  6:08   ` JC Kuo
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-16  6:39   ` Nagarjuna Kristam
2019-05-21  6:11   ` JC Kuo
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  6:39   ` Nagarjuna Kristam
2019-05-16  9:08   ` Chunfeng Yun
2019-05-16  9:08     ` Chunfeng Yun
2019-05-24  6:50     ` Nagarjuna Kristam
2019-05-24  6:50       ` Nagarjuna Kristam
2019-05-29  8:06       ` Chunfeng Yun
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-16  6:39   ` Nagarjuna Kristam
2019-05-23 10:30   ` Thierry Reding
2019-05-24  8:01     ` Nagarjuna Kristam
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 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.