For DSPS platform usb_phy_vbus(_off/_on) are NOPs.
So during musb_platform_reset() call usb_phy(_shutdown/_init)
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/musb/musb_dsps.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
BABBLE and RESET share the same interrupt. The interrupt
is considered to be RESET if MUSB is in peripheral mode and
as a BABBLE if MUSB is in HOST mode.
Handle babble condition iff MUSB is in HOST mode.
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/musb/musb_core.c | 2 +-
Currently musb_platform_reset() is only used by dsps.
In case of BABBLE interrupt for other platforms the musb_platform_reset()
is a NOP. In such situations no need to re-initialize the endpoints.
Also in the latest silicon revision of AM335x, we do have a babble recovery
mechanism without
Add sw_babble_control() logic to differentiate between transient
babble and real babble condition. Also add the SW babble control
register definitions.
Babble control register logic is implemented in the latest
revision of AM335x.
Signed-off-by: George Cherian george.cher...@ti.com
---
Find whether we are running on newer silicon. The babble control
register reads 0x4 by default in newer silicon as opposed to 0
in old versions of AM335x. Based on this enable the sw babble
control logic.
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/musb/musb_dsps.c | 38
Series add support for SW babble control logic found in
new silicon versions of AM335x. Runtime differentiation of
silicon version is done by checking the BABBLE_CTL register.
For newer silicon the register default value read is 0x4 and
for older versions its 0x0.
Patch 1 - Handle Babble only if
During babble condition both first disconnect of devices are
initiated. Make sure MUSB controller is reset and re-initialized
after all disconnects.
To acheive this schedule a delayed work for babble rrecovery.
While at that convert udelay to usleep_range.
Refer
On 21.05.2014, Alan Stern wrote:
In that case, I have no idea what else could be causing the problem.
Thanks for your efforts!
If somebody of the developers is interested in debugging this, I'm
willing to provide/give away the device for free. Send me
an email with your postal adress in this
On Wed, May 21, 2014 at 05:23:33PM +0800, krishnamurthy holla wrote:
Hello,
I am using Linux kernel 3.10.28 - MIPS processor (BIG Endian)
I see that XHCI fails during xhci_device_alloc() because of
wait_for_completion_interruptible_timeout () when I connect a device.
So, I thought of
Since v2.6.39 there are checks for CONFIG_MSP_HAS_DUAL_USB and checks
for CONFIG_MSP_HAS_TSMAC in the code. The related Kconfig symbols have
never been added. These checks have evaluated to false for three years
now. Remove them and the code they have been hiding.
Signed-off-by: Paul Bolle
TEST 12 unlinks the URB write request for N times. When host and
gadget both initialize pattern 1 (mod 63) data series to transfer, the
gadget side will complain the wrong data which is not expected.
Because in host side, usbtest doesn't fill the data buffer as mod 63
and this patch fixed it.
TEST 11 unlinks the URB read request for N times. When host and gadget
both initialize pattern 1 (mod 63) data series to do IN transfer, the
host side function should check the data buffer if it is as mod 63
series, because the data packet which host receivced will follow
pattern 1. So this patch
hi all:
I see usb_interrupt_msg do nothing but call usb_bulk_msg.
Why we still keep usb_interrupt_msg?
for old api compatibility?
thanks for your help in advance,
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More
Hi all,
Although I don't think this is a new issue, booting mainline on my vexpress
a9x4 (Quad ARMv7 Cortex-A9 board) with USB and PM_RUNTIME results in each
CPU being constantly 20-50% loaded. A bit of investigation shows that this
is due to the runtime-pm callbacks trying to autosuspend USB,
OTG3 and EH Compliance Plan 1.0 talks about Super Speed OTG Verification
system (SS-OVS) which consists of an excersizer and analyzer.
USB Compliance Suite from Lecroy or Ellisys can act as such SS-OVS for
Link Layer Validation (LVS).
Some modifications are needed for an embedded Linux USB host
USB3503 chip supports 8 values of reference clock. The value is
specified by REF_SEL[1:0] pins and INT_N line. This patch add support
for getting 'refclk' clock, enabling it and setting INT_N line according
to the value of the gathered clock. If no clock has been specified,
driver defaults to the
Hello.
On 22-05-2014 10:29, George Cherian wrote:
Add sw_babble_control() logic to differentiate between transient
babble and real babble condition. Also add the SW babble control
register definitions.
Babble control register logic is implemented in the latest
revision of AM335x.
On 22-05-2014 10:29, George Cherian wrote:
Add sw_babble_control() logic to differentiate between transient
babble and real babble condition. Also add the SW babble control
register definitions.
Babble control register logic is implemented in the latest
revision of AM335x.
Signed-off-by:
Hello.
On 22-05-2014 10:29, George Cherian wrote:
Find whether we are running on newer silicon. The babble control
register reads 0x4 by default in newer silicon as opposed to 0
in old versions of AM335x. Based on this enable the sw babble
control logic.
Signed-off-by: George Cherian
The spinlock hsotg-lock is intialized at the end of the probe. However it
may be used from within dwc2_hcd_init(). This patch moves the
initialization before the call to dwc2_hcd_init(). This make the locking
correctness validator happy.
Signed-off-by: Jean-Jacques Hiblot jjhib...@traphandler.com
Hello,
I read the USB spec, understand when to prefer bulk vs. isochronous pipes.
My usecase requires controlled jitter guaranteed bandwidth.
But when discussing this with multiple peer engineers, rumor goes isochronous
mode has 'issues' (sic), they advise me against using it altogether.
But
On 5/22/2014 5:28 PM, Sergei Shtylyov wrote:
Hello.
On 22-05-2014 10:29, George Cherian wrote:
Find whether we are running on newer silicon. The babble control
register reads 0x4 by default in newer silicon as opposed to 0
in old versions of AM335x. Based on this enable the sw babble
control
On Thu, May 22, 2014 at 11:34:51AM +0200, Paul Bolle wrote:
Since v2.6.39 there are checks for CONFIG_MSP_HAS_DUAL_USB and checks
for CONFIG_MSP_HAS_TSMAC in the code. The related Kconfig symbols have
never been added. These checks have evaluated to false for three years
now. Remove them and
On Wed, May 21, 2014 at 03:53:22PM +0200, Gregory CLEMENT wrote:
On 19/05/2014 13:09, Paul Bolle wrote:
On Fri, 2014-05-16 at 15:07 -0400, Jason Cooper wrote:
On Thu, May 15, 2014 at 12:17:35PM +0200, Gregory CLEMENT wrote:
This patch adds the selection of the config symbol needed to build
On Thu, 22 May 2014, Heinz Diehl wrote:
On 21.05.2014, Alan Stern wrote:
In that case, I have no idea what else could be causing the problem.
Thanks for your efforts!
If somebody of the developers is interested in debugging this, I'm
willing to provide/give away the device for
On Thu, 22 May 2014, vichy wrote:
hi all:
I see usb_interrupt_msg do nothing but call usb_bulk_msg.
Why we still keep usb_interrupt_msg?
for old api compatibility?
That's right. Also because it gives an indication to the reader about
what type of transfer is being performed.
Alan Stern
Hi,
curiosity: do you have Host-only or the DRD core ?
On Wed, May 21, 2014 at 02:53:33PM +0530, krishnamurthy holla wrote:
Hello,
I am using Linux kernel 3.10.28 - MIPS processor (BIG Endian)
I see that XHCI fails during xhci_device_alloc() because of
On Thu, 22 May 2014, Yves Martens wrote:
Hello,
I read the USB spec, understand when to prefer bulk vs. isochronous pipes.
My usecase requires controlled jitter guaranteed bandwidth.
But when discussing this with multiple peer engineers, rumor goes isochronous
mode has 'issues' (sic),
From: Alan Stern
On Thu, 22 May 2014, Heinz Diehl wrote:
On 21.05.2014, Alan Stern wrote:
In that case, I have no idea what else could be causing the problem.
Thanks for your efforts!
If somebody of the developers is interested in debugging this, I'm
willing to provide/give
On Thu, 22 May 2014, Russel Hughes wrote:
Does the Linux USB implementation supports both equally well? And also the
scheduling of a mixture of both pipe types? For both USB 2 and 3?
Do you have an idea why many commercial devices (e.g. AV applications)
still would go for bulk?
On Thu, 22 May 2014, Will Deacon wrote:
Hi all,
Although I don't think this is a new issue, booting mainline on my vexpress
a9x4 (Quad ARMv7 Cortex-A9 board) with USB and PM_RUNTIME results in each
CPU being constantly 20-50% loaded. A bit of investigation shows that this
is due to the
With CONFIG_PREEMPT_RT_FULL the tty_flip_buffer_push(..) actions are executed
immeditely (same behaviour as if low_latency flag was set). We thus have to
release port_lock before callng tty_flip_buffer_push().
This issue resultst of commits:
44a0c019: USB: g_serial: don't set low_latency flag
I've been trying to use the musb host controller for devices other
than USB mass storage like Wifi-Sticks and USB audio cards, and ran
into a larger number of nasty issues. After staring at hexdumps for
the better part of the last couple of days, I finally fixed all of
them. I used an external
When a 0-length packet is received on the bus, desc-pd6 contains 1, and
the current residue calculation reports back that 1 byte has been
transferred. This is not according to what the datasheet says, but it's
been the case on an AM335x board, very reproducible.
Fix this by looking at bit 19 in
On AM33xx platforms, unplugging a device in the middle of an active
transfer leads to a drop of MUSB_DEVCTL_HM in MUSB_DEVCTL before the
system is informed about a disconnect. This consequently makes the musb
core call the gadget code to handle the interrupt request, which then
crashes the kernel
There's no point in casting these return value to void.
Remove it.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/usb/musb/musb_host.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index
The datasheet says that MUSB_TXCSR_FLUSHFIFO is only valid when
MUSB_CSR0_TXPKTRDY is set as well. Also, clear the MUSB_TXCSR_H_RXSTALL
which drivers are not supposed to write, according to the docs.
With this patch applied, the warning in this function does no longer
kicks in when an USB
When a DMA request is continued and a new inbound packet is requested,
make sure we're operating on the right endpooint. Otherwise, no new
packet is requested and the stream starves.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/usb/musb/musb_cppi41.c | 1 +
1 file changed, 1
The fixup for Advisory 1.0.13 (USB: data may be lost when USB subsystem
is operating in DMA mode and more than one endpoint is transferring
data) reads the USB data toggle each time a packet is given back from
the DMA controller. It does so in order to detect mismatches and
restoring the DATA1
The musb/cppi41 glue layer is capable of handling transactions that span
over more than one USB packet by reloading the DMA descriptors
partially. An urb is considered completed when either its transfer
buffer has been filled entirely (actual_length ==
transfer_buffer_length) or if a packet in the
On Mon, May 19, 2014 at 09:21:17AM +0100, Jon Medhurst (Tixy) wrote:
On Fri, 2014-05-16 at 18:40 +0100, Catalin Marinas wrote:
On Fri, May 16, 2014 at 06:08:45PM +0100, Jon Medhurst (Tixy) wrote:
On Fri, 2014-05-16 at 13:55 +0100, Catalin Marinas wrote:
[...]
It could if arm64 would
On Thu, 2014-05-22 at 16:59 +0100, Catalin Marinas wrote:
On Mon, May 19, 2014 at 09:21:17AM +0100, Jon Medhurst (Tixy) wrote:
On Fri, 2014-05-16 at 18:40 +0100, Catalin Marinas wrote:
On Fri, May 16, 2014 at 06:08:45PM +0100, Jon Medhurst (Tixy) wrote:
On Fri, 2014-05-16 at 13:55 +0100,
On Thu, 22 May 2014, Huang Rui wrote:
TEST 11 unlinks the URB read request for N times. When host and gadget
both initialize pattern 1 (mod 63) data series to do IN transfer, the
host side function should check the data buffer if it is as mod 63
series, because the data packet which host
Hi Alan,
On Thu, May 22, 2014 at 04:02:06PM +0100, Alan Stern wrote:
On Thu, 22 May 2014, Will Deacon wrote:
Consequently, I see a kworker thread on each CPU consuming a significant
amount of the system resources. Worse, if I enable something like kmemleak
(which adds more work to the
On Thu, 22 May 2014, Pratyush Anand wrote:
OTG3 and EH Compliance Plan 1.0 talks about Super Speed OTG Verification
system (SS-OVS) which consists of an excersizer and analyzer.
USB Compliance Suite from Lecroy or Ellisys can act as such SS-OVS for
Link Layer Validation (LVS).
Some
On Thu, 22 May 2014, Will Deacon wrote:
Anyway, there are two possible ways of handling this. One is to avoid
changing the error code to -EBUSY when the device in question is a root
hub. Just let it go into a runtime-PM error state; it won't matter
since the controller doesn't
From: Jean-Jacques Hiblot [mailto:jjhib...@traphandler.com]
Sent: Thursday, May 22, 2014 5:10 AM
The spinlock hsotg-lock is intialized at the end of the probe. However it
may be used from within dwc2_hcd_init(). This patch moves the
initialization before the call to dwc2_hcd_init(). This
Hi, I was hoping you can help me with some questions.
I have been investigating a network issue with bursts of network traffic
over USB CDC-NCM, the issue is that the kernel is dropping packets
because sk_rcvqueues_full() returns true due to skb2-truesize is always
32960 instead of
From: Jim Baxter jim_bax...@mentor.com
Date: Thu, 22 May 2014 20:07:41 +0100
My questions are:
1) Which buffer size does truesize represent, is it the total buffer or
just the data related to the relevant skb?
2) If truesize is for the skb it is contained within should it be
updated
On 05/22/2014 03:07 PM, Jim Baxter wrote:
Hi, I was hoping you can help me with some questions.
I have been investigating a network issue with bursts of network traffic
over USB CDC-NCM, the issue is that the kernel is dropping packets
because sk_rcvqueues_full() returns true due to
On 22/05/14 20:25, Vlad Yasevich wrote:
On 05/22/2014 03:07 PM, Jim Baxter wrote:
skb2 = skb_clone(skb, GFP_ATOMIC);
if (skb2 == NULL)
goto err;
if (!skb_pull(skb2, index)) {
ret = -EOVERFLOW;
goto err;
}
This assumes that you original 16K
On Thu, 2014-05-22 at 20:39 +0100, Jim Baxter wrote:
I now think that the correct solution here is to create a new smaller
skb and copy the data from the sub packets into it.
For low speed devices, this is indeed the best way.
(this is called copybreak in some nic drivers)
--
To
I was puzzled why uas didn't accept to bind to tcm_usb_gadget via dummy_hcd.
Debugging showed that recent commit (14aec589327a6fc4035f5327d90ac5548f501c4c)
added the field can_do_streams to hcd structure but only set it to 1 in the
xhci driver.
dummy_hcd seems to support superspeed and streams
On 22/05/14 20:21, David Miller wrote:
From: Jim Baxter jim_bax...@mentor.com
Date: Thu, 22 May 2014 20:07:41 +0100
My questions are:
1) Which buffer size does truesize represent, is it the total buffer or
just the data related to the relevant skb?
2) If truesize is for the skb it is
On Thu, 2014-05-22 at 21:21 +0100, Jim Baxter wrote:
OK, so it is the value of the memory that has been allocated for the SKB.
If there are multiple clones for an skb all pointing at the same data,
will that distort the memory used when they all have the same truesize?
Its always better to
On 22/05/14 20:59, Eric Dumazet wrote:
On Thu, 2014-05-22 at 20:39 +0100, Jim Baxter wrote:
I now think that the correct solution here is to create a new smaller
skb and copy the data from the sub packets into it.
For low speed devices, this is indeed the best way.
(this is called
Hi George,
On Mon, May 19, 2014 at 11:32 PM, George Cherian george.cher...@ti.com wrote:
Hi Bin,
On 5/19/2014 9:24 PM, Bin Liu wrote:
Hi,
On Mon, May 19, 2014 at 8:39 AM, George Cherian george.cher...@ti.com
wrote:
BABBLE and RESET share the same interrupt. The interrupt
is considered
On Thu, 2014-05-22 at 20:07 +0100, Jim Baxter wrote:
I have been investigating a network issue with bursts of network traffic
over USB CDC-NCM, the issue is that the kernel is dropping packets
because sk_rcvqueues_full() returns true due to skb2-truesize is always
32960 instead of
From: Jim Baxter jim_bax...@mentor.com
Date: Thu, 22 May 2014 21:21:55 +0100
If there are multiple clones for an skb all pointing at the same data,
will that distort the memory used when they all have the same truesize?
What is distorted about it?
Each clone references exactly that much
On Thu, 2014-05-22 at 13:58 -0700, Eric Dumazet wrote:
I would set rx_max (rx_urb_size) to SKB_MAX_HEAD(0) so that you do not
use high order allocations.
Correction, that would need SKB_MAX_HEAD(NET_SKB_PAD + NET_IP_ALIGN),
because drivers/net/usb/usbnet.c calls __netdev_alloc_skb_ip_align().
From: Eric Dumazet eric.duma...@gmail.com
Date: Thu, 22 May 2014 14:03:21 -0700
On Thu, 2014-05-22 at 13:58 -0700, Eric Dumazet wrote:
I would set rx_max (rx_urb_size) to SKB_MAX_HEAD(0) so that you do not
use high order allocations.
Correction, that would need SKB_MAX_HEAD(NET_SKB_PAD +
Hi,
I messed up the register names in the commit log. Will fix in v2.
On 05/22/2014 05:30 PM, Daniel Mack wrote:
When a 0-length packet is received on the bus, desc-pd6 contains 1, and
... 'desc-pd0' ...
the current residue calculation reports back that 1 byte has been
transferred. This is
Fixed the ERROR thrown off by checkpatch.pl.
Signed-off-by: Chaitanya Hazarey c...@24.io
---
drivers/staging/media/sn9c102/sn9c102_tas5130d1b.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/media/sn9c102/sn9c102_tas5130d1b.c
Hi Greg,
This patch set creates usb/common for usb common things, and moves otg
fsm implementation from usb/phy/ to usb/common/. I have a discussion with
Felipe about it at below link:
http://www.spinics.net/lists/linux-usb/msg106357.html
Thanks.
Changes for v2:
- Fix one typo
Hi Greg,
No big changes for these three patches, just cleanup, refine, update
TODO list.
Besides, I haven't seen my last 3.16 patch set in your next tree, do
I need to re-send them (together with this one)?
http://marc.info/?l=linux-usbm=139917105404965w=2
Thanks.
Peter Chen (3):
usb:
Update TODO list
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/chipidea/core.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 128b92b..95b4dd7 100644
---
Delete useless code
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/chipidea/udc.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index d683968..69425b3 100644
--- a/drivers/usb/chipidea/udc.c
The otg queue work include operations: one is disable interrupt,
another one is call kernel queue work API. Many codes do this
operation, using one inline function to instead of them.
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/chipidea/core.c|6 +--
On Fri, May 23, 2014 at 01:16:37AM +, Peter Chen wrote:
Hi Greg,
This patch set creates usb/common for usb common things, and moves otg
fsm implementation from usb/phy/ to usb/common/. I have a discussion with
Felipe about it at below link:
hi Alan:
2014-05-22 22:14 GMT+08:00 Alan Stern st...@rowland.harvard.edu:
On Thu, 22 May 2014, vichy wrote:
hi all:
I see usb_interrupt_msg do nothing but call usb_bulk_msg.
Why we still keep usb_interrupt_msg?
for old api compatibility?
That's right. Also because it gives an indication
On Wed, May 21, 2014 at 05:28:31PM -0500, Felipe Balbi wrote:
Hi Greg,
Here's my big dump for v3.16 merge window. Even though we have a lot of
patches, most of them are just doing cleanups and small bug fixes.
Consider merging it to your usb-next branch. There will be a conflict
with
On Fri, May 23, 2014 at 08:12:46AM +0800, Peter Chen wrote:
Hi Greg,
No big changes for these three patches, just cleanup, refine, update
TODO list.
Besides, I haven't seen my last 3.16 patch set in your next tree, do
I need to re-send them (together with this one)?
No big changes for these three patches, just cleanup, refine, update
TODO list.
Besides, I haven't seen my last 3.16 patch set in your next tree, do I
need to re-send them (together with this one)?
http://marc.info/?l=linux-usbm=139917105404965w=2
Sorry, been on the road, now
hi all:
I have some questions:
1. is it possible to know period bandwidth for ehci controller from
sys or other additional configuration?
2. is it possible to know S/C bit in QHs which are linked in a frame?
thanks for your help in advance,
--
To unsubscribe from this list: send the line
Hi Alan,
On Fri, May 23, 2014 at 01:54:01AM +0800, Alan Stern wrote:
On Thu, 22 May 2014, Pratyush Anand wrote:
OTG3 and EH Compliance Plan 1.0 talks about Super Speed OTG Verification
system (SS-OVS) which consists of an excersizer and analyzer.
USB Compliance Suite from Lecroy or
75 matches
Mail list logo
