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, linux-tegra@vger.kernel.org,
	linux-usb@vger.kernel.org
Subject: [3/8] dt-bindings: phy: tegra-xusb-padctl: Add nvidia,usb3-port-fake entry
Date: Wed, 13 Feb 2019 14:16:19 +0100	[thread overview]
Message-ID: <20190213131619.GK647@ulmo> (raw)

On Wed, Feb 13, 2019 at 01:56:24PM +0100, Thierry Reding wrote:
> On Wed, Feb 13, 2019 at 04:08:15PM +0530, Nagarjuna Kristam wrote:
> > 
> > 
> > On 04-02-2019 17:18, Thierry Reding wrote:
> > > On Thu, Jan 03, 2019 at 03:34:54PM +0530, Nagarjuna Kristam wrote:
> > >> Add binding details regarding nvidia,usb3-port-fake
> > >>
> > >> Signed-off-by: Nagarjuna Kristam <nkristam@nvidia.com>
> > >> ---
> > >>  Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt | 3 +++
> > >>  1 file changed, 3 insertions(+)
> > >>
> > >> diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt b/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt
> > >> index 3742c15..21a5541 100644
> > >> --- a/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt
> > >> +++ b/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt
> > >> @@ -158,6 +158,9 @@ Optional properties:
> > >>    is internal. In the absence of this property the port is considered to be
> > >>    external.
> > >>  - vbus-supply: phandle to a regulator supplying the VBUS voltage.
> > >> +- nvidia,usb3-port-fake: A integer property whose presense informs that a
> > >> +  fake USB3 port needs to be mapped for corresponding USB2 port. This entry
> > >> +  is applicable only for Tegra210 based platforms which has USB2 only ports.
> > > 
> > > You don't provide a rationale fo why this fake USB3 port needs to be
> > > specified. Doesn't the OTG port work without the fake USB3 port? Why
> > > does it need to be specified and which one should be used as fake?
> > > 
> > 
> > Yes, on Tegra210 based platforms, USB2 only device/OTG ports don't work
> > 
> > > You mention elsewhere that an unused USB3 port is used on Jetson TX1,
> > > but what if there are no unused ports on a platform? Can we use any
> > > USB3 port for this purpose?
> > > 
> > 
> > If we dont have any unused port, we cannot get device mode working on USB2 only port.
> > We cannot use any USB3 port, we need to use an un-used USB3 port, so that we can
> > fake that corresponding USB2 only port as USB2 and USB3 port.
> 
> Hm... seems to me like we should be able to do this without an extra
> device tree property. Surely we can determine at runtime which of the
> ports are actually unused and pick one? If it doesn't matter which one,
> we can just pick the first one that's unused, or an unused one at
> random.

It's slightly more complicated than I thought because there's an
optimization in tegra_xusb_add_usb3_port() that will cause only used
ports to get registered. But I think we can do something like this
(untested) to get hold of an unused one, since we only need the index
of the port:

	static int tegra_xusb_find_unused_usb3_port(struct tegra_xusb_padctl *padctl)
	{
		struct device_node *np;
		unsigned int i;

		for (i = 0; i < padctl->soc->ports.usb3.count; i++) {
			np = tegra_xusb_find_port_node(padctl, "usb3", i);
			if (!np || !of_device_is_available(np))
				return index;
		}

		return -ENODEV;
	}

Thierry

             reply	other threads:[~2019-02-13 13:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-13 13:16 Thierry Reding [this message]
  -- strict thread matches above, loose matches on Subject: below --
2019-02-15  1:39 [3/8] dt-bindings: phy: tegra-xusb-padctl: Add nvidia,usb3-port-fake entry jckuo
2019-02-14 15:01 Nagarjuna Kristam
2019-02-14  8:59 Thierry Reding
2019-02-14  5:28 Nagarjuna Kristam
2019-02-13 12:56 Thierry Reding
2019-02-13 10:38 Nagarjuna Kristam
2019-02-04 11:48 Thierry Reding
2019-01-03 10:04 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=20190213131619.GK647@ulmo \
    --to=thierry.reding@gmail.com \
    --cc=balbi@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jonathanh@nvidia.com \
    --cc=linux-tegra@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=nkristam@nvidia.com \
    /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).