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, 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 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.