Hi Peter,
>>
>> > Do you have any components at VBUS?
>>
>> There were ESD protection diodes that connected D+/D- with VBUS. We
>> removed those from the PCB and the problem is gone meaning VBUS
>> discharges as expected, the controller runtime-suspends and ultimately
>> systemd-networkd rep
Alan Stern wrote:
> On Thu, 4 Jul 2019, EJ Hsu wrote:
>
> > Based on my initial debugging, USB CV TD 9.13 will consecutively set device
> to configuration #1 by sending "Set Configuration" transfer.
> > So, in set_config() function, it will try to disable each interface first
> > and then
> set u
This is the fifth version of series "Tegra XUSB gadget driver support"
Patches 1-3 are phy driver changes to add support for device
mode.
Patches 4-7 are changes related to XUSB device mode
controller driver.
Patch 8 is to enable XUDC driver in defconfig
Test Steps(USB 2.0):
- Enable "USB Gadget
On Tegra210, usb2 only otg/peripheral ports dont work in device mode.
They need an assosciated usb3 port to work in device mode. Identify
an unused usb3 port and assign it as a fake USB3 port to USB2 only
port whose mode is otg/peripheral.
Based on work by BH Hsieh .
Signed-off-by: Nagarjuna Kris
Configure the port capabilities based on usb_dr_mode settings.
Based on work by JC Kuo .
Signed-off-by: Nagarjuna Kristam
Reviewed-by: JC Kuo
Acked-by: Thierry Reding
---
drivers/phy/tegra/xusb-tegra210.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git
Tegra210 has one XUSB device mode controller, which can be operated
HS and SS modes. Add DT support for XUSB device mode controller.
Signed-off-by: Nagarjuna Kristam
Reviewed-by: JC Kuo
---
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff
This patch adds UDC driver for tegra XUSB 3.0 device mode controller.
XUSB device mode controller supports SS, HS and FS modes
Based on work by:
Mark Kuo
Hui Fu
Andrew Bresticker
Signed-off-by: Nagarjuna Kristam
Acked-by: Thierry Reding
---
drivers/usb/gadget/udc/Kconfig | 11 +
Tegra XUSB device control driver needs to control vbus override
during its operations, add API for the support.
Signed-off-by: Nagarjuna Kristam
---
drivers/phy/tegra/xusb-tegra210.c | 57 +++
drivers/phy/tegra/xusb.c | 22 +++
drivers/phy
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
Reviewed-by: JC Kuo
---
.../devicetree/bindings/usb/nvidia,tegra-xudc.txt | 110 +
1 file
Enable XUSB device mode driver for USB0 slot on Jetson TX1.
Signed-off-by: Nagarjuna Kristam
Reviewed-by: JC Kuo
---
arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi | 29 ++
1 file changed, 29 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
b/a
Enable support for Nvidia XUSB device mode controller driver.
Signed-off-by: Nagarjuna Kristam
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 0e58ef0..9ee581c 100644
--- a/arch/arm64/configs/d
On Fri, 2019-07-05 at 10:49 +, EJ Hsu wrote:
>
> Yes, looks like we are facing the same issue.
>
> The change of Ben is similar to mine, but the priority of
> FSG_STATE_CONFIG_CHANGE in his patch is higher than FSG_STATE_CONFIG_CLEAR.
> So, it will not hit the USB CV TD 9.13 failure as above
On Fri, 2019-07-05 at 10:49 +, EJ Hsu wrote:
> The change for my previous patch is as follows, and it works well on my local
> test.
>
> Thanks,
> EJ
>
> diff --git a/drivers/usb/gadget/function/f_mass_storage.c
> b/drivers/usb/gadget/function/f_mass_storage.c
> index 982c3e8..b5f1e1e 10064
(following our conversation)
Here's a completely untested alternative patch (it replaces my previous
one) that fixes it a bit differently.
This time it should handle the case of a disconnect happening
before we have dequeued a config change.
This assumes that it's correct to never call
usb_compo
On Fri, 5 Jul 2019, Benjamin Herrenschmidt wrote:
> > > > As for f_mass_storage, repeatedly attempting to queue an OUT transfer
> > > > is normal behavior. The fact that one attempt gets an error doesn't
> > > > stop the driver from making more attempts; the only thing that would
> > > > stop it
On Fri, 5 Jul 2019, Benjamin Herrenschmidt wrote:
> On Thu, 2019-07-04 at 21:37 -0400, Alan Stern wrote:
> > >
> > > Talking of which... do we need this ?
> > >
> > > --- a/drivers/usb/gadget/composite.c
> > > +++ b/drivers/usb/gadget/composite.c
> > > @@ -1976,6 +1976,7 @@ void composite_discon
On Fri, 5 Jul 2019, Benjamin Herrenschmidt wrote:
> On Fri, 2019-07-05 at 10:49 +, EJ Hsu wrote:
> >
> > Yes, looks like we are facing the same issue.
> >
> > The change of Ben is similar to mine, but the priority of
> > FSG_STATE_CONFIG_CHANGE in his patch is higher than FSG_STATE_CONFIG_C
On Fri, 5 Jul 2019, Benjamin Herrenschmidt wrote:
> (following our conversation)
>
> Here's a completely untested alternative patch (it replaces my previous
> one) that fixes it a bit differently.
>
> This time it should handle the case of a disconnect happening
> before we have dequeued a confi
On Wed, 3 Jul 2019, Mayuresh Kulkarni wrote:
> As you had mentioned in one of the comment before, the only addition to
> the patch I have locally is -
> usbfs_notify_resume() has usbfs_mutex lock around list traversal.
>
> Could you please send the patch for review? Please note, I think I am
> no
On Fri, 2019-07-05 at 10:08 -0400, Alan Stern wrote:
> On Fri, 5 Jul 2019, Benjamin Herrenschmidt wrote:
>
> > > > > As for f_mass_storage, repeatedly attempting to queue an OUT transfer
> > > > > is normal behavior. The fact that one attempt gets an error doesn't
> > > > > stop the driver from m
On Fri, 2019-07-05 at 10:20 -0400, Alan Stern wrote:
>
> > Right. I do see the resume coming in, but I don't forward it to the
> > gadget because here's what happens in that order:
> >
> > 1- Host gets shutdown (or cable disconnected)
> >
> > 2- Upstream bus suspend: I call ->suspend on the ga
On Fri, 2019-07-05 at 10:30 -0400, Alan Stern wrote:
> I haven't looked at the new patches yet.
>
> Still, what I originally had in mind for this situation was that the
> _last_ event should always take precedence. This goes against the idea
> of having separate FSG_STATE_* levels for disconnec
On Fri, 2019-07-05 at 14:28 -0400, Alan Stern wrote:
> On Fri, 5 Jul 2019, Benjamin Herrenschmidt wrote:
>
> > (following our conversation)
> >
> > Here's a completely untested alternative patch (it replaces my previous
> > one) that fixes it a bit differently.
> >
> > This time it should handle
On Tue, 2019-07-02 at 21:17 +1000, Benjamin Herrenschmidt wrote:
> This bit should be only set when the port enable goes down, for
> example, on errors. Not when it gets set after a port reset. MacOS
> seems sensitive to this and fails enumeration.
>
> Signed-off-by: Benjamin Herrenschmidt
Note:
If fsg_disable() and fsg_set_alt() are called too closely to each
other (for example due to a quick reset/reconnect), what can happen
is that fsg_set_alt sets common->new_fsg from an interrupt while
handle_exception is trying to process the config change caused by
fsg_disable():
fsg_disabl
In some cases, one can get out of suspend with a reset or
a disconnect followed by a reconnect. Previously we would
leave a stale suspended flag set.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/usb/gadget/composite.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/gadget/co
We had some dodgy code using the speed setting to decide whether a
port reset would reset the device or just enable it.
Instead, if the device is disabled and has a gadget attached, a
reset will enable it. If it's already enabled, a reset will
reset it.
Signed-off-by: Benjamin Herrenschmidt
---
When nuking requests, it's useful to display how many were
actually nuked. It has proven handy when debugging issues
where EP0 went in a wrong state.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/usb/gadget/udc/aspeed-vhub/core.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
The state bit in the hub is sufficient
Signed-off-by: Benjamin Herrenschmidt
---
drivers/usb/gadget/udc/aspeed-vhub/dev.c | 4
drivers/usb/gadget/udc/aspeed-vhub/vhub.h | 1 -
2 files changed, 5 deletions(-)
diff --git a/drivers/usb/gadget/udc/aspeed-vhub/dev.c
b/drivers/usb/gadget/udc/a
Signed-off-by: Benjamin Herrenschmidt
---
include/linux/usb/hcd.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index bb57b5af4700..094ae7c71198 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -587,6 +587,10 @@ exte
We just accept them instead of stalling and return
zeros on GetTTState.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/usb/gadget/udc/aspeed-vhub/hub.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/usb/gadget/udc/aspeed-vhub/hub.c
b/drivers/usb/gadget/udc/aspeed-vhub/hub.
When stalling EP0, we need to wait for an ACK interrupt,
otherwise we may get out of sync on the next setup packet
data phase. Also we need to ignore the direction when
processing that interrupt as the HW reports a potential
mismatch.
Implement this by adding a stall state to EP0. This fixes
some
A disconnect may just suspend the hub in absence of a physical
disconnect detection. If we start rejecting requests, the mass
storage function gets into a spin trying to requeue the same
request for ever and hangs.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/usb/gadget/udc/aspeed-vhub/dev.
So I finally got back an Aspeed eval board, and thus resumed maintaining
and handling bug reports for this driver.
This is a series that fixes a number of enumeration related issues with
a variety of hosts, OSes, and circumstances (ie, plugging/unplugging at
funny times, etc...).
I also added dum
This bit should be only set when the port enable goes down, for
example, on errors. Not when it gets set after a port reset. Some
USB stacks seem to be sensitive to this and fails enumeration.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/usb/gadget/udc/aspeed-vhub/hub.c | 9 -
1 fil
Otherwise, we can have a stale state after a disconnect and reconnect
causing errors on the first SETUP packet to the device.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/usb/gadget/udc/aspeed-vhub/dev.c | 3 +++
drivers/usb/gadget/udc/aspeed-vhub/ep0.c | 9 +
drivers/usb/gadget/u
.. before calling them
Signed-off-by: Benjamin Herrenschmidt
---
drivers/usb/gadget/udc/aspeed-vhub/dev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/udc/aspeed-vhub/dev.c
b/drivers/usb/gadget/udc/aspeed-vhub/dev.c
index 71e2416858fd..5f7e3b6de531
Hi all
xhci_msi_irq is the interrupt handler for xhci, the controller it self
is a PCI device, on my system it is a Intel chip. I have multiple USB
device connect to this USB host controller, xhci_msi_irq is interrupt
handler for the PCI device(USB Host controller).
Is it possible to have multip
On Fri, Jul 05, 2019 at 07:50:28PM -0700, yunhua li wrote:
> Hi all
>
> xhci_msi_irq is the interrupt handler for xhci, the controller it self
> is a PCI device, on my system it is a Intel chip. I have multiple USB
> device connect to this USB host controller, xhci_msi_irq is interrupt
> handler
39 matches
Mail list logo
