Re: [PATCH v1 0/9] Support UDC on Tegra 20/30/114/124

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jul 06, 2017 at 01:04:40PM +0000, Marcel Ziswiler wrote:
> On Thu, 2017-07-06 at 14:03 +0200, Thierry Reding wrote:
> > On Thu, Jul 06, 2017 at 02:20:04AM +0300, Dmitry Osipenko wrote:
> > > On 06.07.2017 01:54, Stephen Warren wrote:
> > > > On 07/05/2017 04:13 PM, Dmitry Osipenko wrote:
> > > > > On 05.07.2017 23:31, Stephen Warren wrote:
> > > > > > On 07/05/2017 11:19 AM, Dmitry Osipenko wrote:
> > > > > > > Some time ago Thierry Reding sent out patches that enabled
> > > > > > > UDC on NVIDIA
> > > > > > > Tegra, unfortunately they haven't got enough traction to
> > > > > > > get into the
> > > > > > > kernel. I've rebased those patches and added a fix for the
> > > > > > > Ethernet USB
> > > > > > > Gadget on Tegra20, Marc Dietrich tested UDC driver on AC100
> > > > > > > and Nicolas
> > > > > > > Chauvet on TK1. Like an original patchset, this series adds
> > > > > > > support for
> > > > > > > the peripheral mode only.
> > > > > > 
> > > > > > Does this mean that the relevant ports no longer support host
> > > > > > mode? That's going
> > > > > > to be a user-visible regression, which doesn't sound like a
> > > > > > good idea. Isn't OTG
> > > > > > possible instead?
> > > > > 
> > > > > We are going to switch only AC100 and TrimSlice to use the UDC
> > > > > driver.
> > > > 
> > > > Really? I saw patches in the series for Beaver, Dalmore, and
> > > > Jetson TK1 too.
> > > > 
> > > 
> > > Yes, the "PHY" and "EHCI" nodes are disabled on those boards in DT.
> > > 
> > > > > Do you
> > > > > know whether that port is working in a host mode with the
> > > > > tegra-ehci driver on
> > > > > these devices?
> > > > 
> > > > If any USB port is enabled in the DT, it was certainly validated
> > > > at some point.
> > > > IIRC, we only have host mode enabled at present. So, yes, I'd
> > > > expect this port
> > > > to work in host mode currently without any issue.
> > > > 
> > > 
> > > Okay, so we have to decide whether it's reasonable to switch AC100
> > > and TrimSlice
> > > to the peripheral mode. I think realistically chances that someone
> > > uses that
> > > port in a host mode are quite low, while it works fine and probably
> > > more useful
> > > in a device mode.
> > 
> > Judging by this:
> > 
> > 	http://trimslice.com/download/documentation/trim-slice-man.pdf
> > 
> > at least TrimSlice doesn't seem to implement OTG, so we'd have to
> > make a
> > choice to support either host or peripheral mode. I guess technically
> > it
> > would need to be peripheral mode because pin 4 is not connected.
> > 
> > Does a similar document exist for AC100?
> 
> Judging by the Compal PAZ00 schematics it does indeed have an ID pin
> which is connected to the mini USB socket.
> 
> USB1_ID1: From Connector
> 
> USB1_ID2: From EC
> 
> So an alternative possibility to switch device/host mode would be from
> the EC (;-p).

According to the TRM, there's a USB PHY register that can be used to
query the ID/VBUS pins. They can optionally also be connected to a pair
of GPIO lines. Apparently it's even possible to hook them up to the PMU
and use a PMU specific mechanism. Most of that information can be found
in downstream kernel code.

Using U-Boot I can monitor the USB1_IF_USB_PHY_VBUS_WAKEUP_ID_0 register
(address 0x7d000408) and I see that bit ID_STS changes, and can
presumably trigger an interrupt when ID_INT_EN is set.

According to the downstream kernel this isn't supposed to work on the
Jetson TK1 up to and including the D revision, but it seems to work in
U-Boot at least on the C revision that I have. For earlier revisions
there is a sysfs attribute that can be used to force the port into the
desired mode.

Can anyone check whether or not the above register (on Tegra20, the
physical address of the register should be 0xc5000408) changes when
switching between micro A and micro B cables on TrimSlice and/or
PAZ00? Note that I wasn't able to see a difference after unplugging a
micro B cable. It only toggles after plugging in the micro A or after
unplugging the micro B, which I think really only means that by default
the port will be in peripheral mode. This can probably also be
influenced by setting or clearing the ID_PU field (pull-up on ID pin).

If this works reliably, we may be able to implement a very simple form
of detecting host/peripheral mode.

Thierry

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [ARM Kernel]     [Linux ARM]     [Linux ARM MSM]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux