[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <515C7E07.4040505@wwwdotorg.org>
Date: Wed, 03 Apr 2013 13:07:51 -0600
From: Stephen Warren <swarren@...dotorg.org>
To: Venu Byravarasu <vbyravarasu@...dia.com>
CC: gregkh@...uxfoundation.org, balbi@...com,
stern@...land.harvard.edu, linux-tegra@...r.kernel.org,
linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/7] ARM: tegra: finalize USB EHCI and PHY bindings
On 04/03/2013 02:41 AM, Venu Byravarasu wrote:
> The existing Tegra USB bindings have a few issues:
...
> This patch fixes the binding definition to resolve these issues.
> diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt b/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt
> Required properties :
...
> + - vbus-supply: regulator for VBUS
Doesn't the driver only need to control VBUS if the port is in OTG mode?
If there is no VBUS control, and the HW provides VBUS, I think that the
port can only operate in host mode.
If there is no VBUS control, and the HW does not provide VBUS, I think
that the port can only operate in peripheral mode.
If there is VBUS control, then shouldn't the port always operate in OTG
mode, or are there other reasons to control VBUS even in host-only mode?
If VBUS control is only useful for OTG mode, then I think the
vbus-supply property should be documented in a "Required properties for
dr_mode == otg" section.
I assume that VBUS control makes no sense for a peripheral-mode-only
port, so if VBUS control is useful for host-only mode as well as OTG
mode, then I think the vbus-supply property should be documented in a
"Required properties for dr_mode != peripheral" section.
Is the following table correct?
Port operating mode: host peripheral otg
-------------------- ---- ---------- ---
VBUS control required: no no yes
VBUS control useful: yes[1]? no yes
[1] perhaps for power-saving/suspend???
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists