that's sure. thank you Dan.
And - what do you think guys if I try to implement something like a sysfs file
to change dynamically the buffer size? Yes, it seems not so simple, but I might
try, following th Bjorn example in the cdc_ncm driver.
I might try at some point.
Enrico.
On Wed, 18 Jun 2014
Hi,
Looks like commit ca88fc2ef0d7 (usb: musb: add a work_struct
to recover from babble errors) causes MUSB gadgets to stop
enumerating at least on omap3. Reverting the the commit fixes
the issue.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body o
(+ George)
On 06/19/2014 11:56 AM, Tony Lindgren wrote:
> Looks like commit ca88fc2ef0d7 (usb: musb: add a work_struct
> to recover from babble errors) causes MUSB gadgets to stop
> enumerating at least on omap3. Reverting the the commit fixes
> the issue.
Hmm, so do you see babble errors occurin
* Daniel Mack [140619 03:10]:
> (+ George)
>
> On 06/19/2014 11:56 AM, Tony Lindgren wrote:
> > Looks like commit ca88fc2ef0d7 (usb: musb: add a work_struct
> > to recover from babble errors) causes MUSB gadgets to stop
> > enumerating at least on omap3. Reverting the the commit fixes
> > the iss
Hi Tony,
On 06/19/2014 12:31 PM, Tony Lindgren wrote:
> * Daniel Mack [140619 03:10]:
>> On 06/19/2014 11:56 AM, Tony Lindgren wrote:
>>> Looks like commit ca88fc2ef0d7 (usb: musb: add a work_struct
>>> to recover from babble errors) causes MUSB gadgets to stop
>>> enumerating at least on omap3.
* Daniel Mack [140619 03:38]:
> Hi Tony,
>
> On 06/19/2014 12:31 PM, Tony Lindgren wrote:
> > * Daniel Mack [140619 03:10]:
> >> On 06/19/2014 11:56 AM, Tony Lindgren wrote:
> >>> Looks like commit ca88fc2ef0d7 (usb: musb: add a work_struct
> >>> to recover from babble errors) causes MUSB gadget
* George Cherian [140526 02:25]:
> 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.
Please get this into mainline kernel for v3.16-rc
On 06/19/2014 12:43 PM, Tony Lindgren wrote:
> * Daniel Mack [140619 03:38]:
>> On 06/19/2014 12:31 PM, Tony Lindgren wrote:
>>> * Daniel Mack [140619 03:10]:
On 06/19/2014 11:56 AM, Tony Lindgren wrote:
>>> But that also raises a question: Were these patches merged for
>>> v3.16 ever even
* Daniel Mack [140619 03:51]:
> On 06/19/2014 12:43 PM, Tony Lindgren wrote:
> > * Daniel Mack [140619 03:38]:
> >> On 06/19/2014 12:31 PM, Tony Lindgren wrote:
> >>> * Daniel Mack [140619 03:10]:
> On 06/19/2014 11:56 AM, Tony Lindgren wrote:
>
> >>> But that also raises a question: Were
On Fri, Jun 06, 2014 at 04:32:03PM +0530, Vivek Gautam wrote:
> Hi,
>
> On Fri, Jun 6, 2014 at 12:41 PM, Antoine Ténart
> wrote:
> > Hi,
> >
> > On Fri, Jun 06, 2014 at 12:09:06PM +0530, Vivek Gautam wrote:
> >> On Thu, Jun 5, 2014 at 9:18 PM, Antoine Ténart
> >> wrote:
> >> > Add the driver dri
On Fri, Jun 13, 2014 at 11:36:24AM +, David Laight wrote:
> From: Robert Baldyga
> > usb_gadget_disconnect() shouldn't be called under spinlock to avoid
> > spinlock recursion. Function usb_gadget_disconnect() calls pullup(),
> > which is callback from UDC driver, usually calling composite_disc
On Thu, Jun 05, 2014 at 03:52:58PM +0300, Heikki Krogerus wrote:
> On some platforms a PHY may need to be handled also in the
> host controller driver. Exynos5420 SoC requires some "PHY
> tuning" based on the USB speed. This patch delivers dwc3's
> PHYs to the xhci platform device when it's created
On Thu, 19 Jun 2014, Wang, Yu Y wrote:
> > I'm not sure of the right way to solve this problem. Probably
> > xhci_resume() should check the root-hub statuses to see if either root hub
> > really needs to be resumed before calling usb_hcd_resume_root_hub(); I think
> > that will work.
>
> [Yu:] I
On Wed, Jun 18, 2014 at 1:52 PM, Fabio Estevam wrote:
> MPC does not use it only because no one has converted it yet :-)
Okay. That makes sense :-)
> Take a look at the existing bindings of i.MX. You probably only needs
> to add the drivers/usb/chipidea/ci_hdrc_imx.c equivalent for MPC.
That d
On Thu, 19 Jun 2014, Jörg Otte wrote:
> on resume with 3.16-rc1 I get the following error messages in dmesg
> which are alltogether not present in 3.15:
>
> [ 43.518116] dpm_run_callback(): 0xa53c4120 returns -13
> [ 43.518119] PM: Device 1-1 failed to resume async: error -13
> [ 43
On Wed, Jun 18, 2014 at 02:24:49PM +0200, Andrzej Pietrasiewicz wrote:
> Function's interface directories need to be created when the function
> directory is created, but interface numbers are not known until
> the gadget is ready and bound to udc, so we cannot use numbers
> as part of interface di
On Wed, Jun 18, 2014 at 11:36:43AM +0200, Daniel Mack wrote:
> On 06/18/2014 11:32 AM, David Laight wrote:
> > From: Of Daniel Mack
> >> Sent: 18 June 2014 10:28
> >> To: ba...@ti.com; george.cher...@ti.com; bige...@linutronix.de
> >> Cc: sebastian.reim...@googlemail.com; linux-usb@vger.kernel.org;
On Mon, Jun 16, 2014 at 10:20:36AM +0200, Robert Baldyga wrote:
> This field allows to mark ep as claimed in more clear way. Claiming
> endpoint by setting driver_data to non-null value is leaky solution
> and makes code unreadable.
how come ? How can it be unreadable ? how can it be leaky ?
--
On Thu, May 22, 2014 at 04:57:31PM +0200, Jean-Jacques Hiblot wrote:
> 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 issu
On 06/19/2014 05:07 PM, Felipe Balbi wrote:
> On Wed, Jun 18, 2014 at 11:36:43AM +0200, Daniel Mack wrote:
>> On 06/18/2014 11:32 AM, David Laight wrote:
>>> From: Of Daniel Mack
Sent: 18 June 2014 10:28
To: ba...@ti.com; george.cher...@ti.com; bige...@linutronix.de
Cc: sebastian.rei
Hello.
On 06/19/2014 07:14 AM, David Mosberger wrote:
From: David Mosberger-Tang
Signed-off-by: Davidm Mosberger
Davidm? :-)
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info
From: Daniel Mack [mailto:dan...@zonque.org]
> On 06/19/2014 05:07 PM, Felipe Balbi wrote:
> > On Wed, Jun 18, 2014 at 11:36:43AM +0200, Daniel Mack wrote:
> >> On 06/18/2014 11:32 AM, David Laight wrote:
> >>> From: Of Daniel Mack
> Sent: 18 June 2014 10:28
> To: ba...@ti.com; george.che
Hi,
On Thu, Jun 19, 2014 at 03:44:42AM -0700, Tony Lindgren wrote:
> * George Cherian [140526 02:25]:
> > 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 condit
I don't know how to do this.
Thanks, Jörg
2014-06-19 17:02 GMT+02:00 Alan Stern :
> On Thu, 19 Jun 2014, Jörg Otte wrote:
>
>> on resume with 3.16-rc1 I get the following error messages in dmesg
>> which are alltogether not present in 3.15:
>>
>> [ 43.518116] dpm_run_callback(): 0xa53c4
On Wed, Jun 18, 2014 at 07:13:19PM +0800, 刘磊 wrote:
>
> dear linuxfoundation:
> Because of the usb driver parameters error that leads to failed in
> reconnect. now i want to modify the error parameter and
> move device pid fffe from zte_ev.c back to option.c for our company.
These are tw
On Thu, 19 Jun 2014, Jörg Otte wrote:
> I don't know how to do this.
To enable dynamic debugging (as root):
echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control
echo 'module ehci_hcd =p' >/sys/kernel/debug/dynamic_debug/control
Do this before you carry out the suspend, and
The various devm_ functions allocate memory that is released when a
driver detaches. This patch uses dmam_alloc_coherent, devm_ioremap
devm_clk_get etc. for data that is allocated in the probe function of
platform device and is only freed in the remove function. The
corresponding free functions are
From: David Mosberger-Tang
Bit fields are not MP-safe.
Signed-off-by: David Mosberger
---
drivers/usb/host/max3421-hcd.c | 45 ++--
1 file changed, 20 insertions(+), 25 deletions(-)
diff --git a/drivers/usb/host/max3421-hcd.c b/drivers/usb/host/max3421-hc
From: David Mosberger-Tang
Signed-off-by: David Mosberger
---
drivers/usb/host/max3421-hcd.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/host/max3421-hcd.c b/drivers/usb/host/max3421-hcd.c
index f8ecd7d..6dbf1e9 100644
--- a/drivers/usb/host/max3421-hcd.c
+++ b/drivers/us
As far as kzalloc() is called with spinlock held,
we have to pass GFP_ATOMIC regardless of mem_flags argument.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
drivers/usb/host/max3421-hcd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-
On Thu, Jun 19, 2014 at 1:44 PM, Alexey Khoroshilov
wrote:
> As far as kzalloc() is called with spinlock held,
> we have to pass GFP_ATOMIC regardless of mem_flags argument.
Good catch, thanks!
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov
On Tue, 17 Jun 2014, Dennis New wrote:
> On Thu, 12 Jun 2014 10:20:54 -0400 (EDT), Alan Stern wrote:
> > Dennis and Matteo:
> >
> > I promised to send both of you a patch changing the way ohci-hcd
> > handles hardware bugs. Well, it's finally ready for testing. There's
> > only a limited amount
On Wed, 4 Jun 2014, Alan Stern wrote:
> Dennis and Matteo:
>
> I promised to send both of you a patch changing the way ohci-hcd
> handles hardware bugs. Well, it's finally ready for testing. There's
> only a limited amount I can do on my own machine, so now it's up to you
> guys.
>
> The patch
On Thu, 19 Jun 2014 17:03:55 -0400 (EDT), Alan Stern wrote:
> On Tue, 17 Jun 2014, Dennis New wrote:
>
> > On Thu, 12 Jun 2014 10:20:54 -0400 (EDT), Alan Stern wrote:
> > > Dennis and Matteo:
> > >
> > > I promised to send both of you a patch changing the way ohci-hcd
> > > handles hardware bugs.
On Thu, 19 Jun 2014, Dennis New wrote:
> On Thu, 19 Jun 2014 17:03:55 -0400 (EDT), Alan Stern wrote:
> > On Tue, 17 Jun 2014, Dennis New wrote:
> >
> > > On Thu, 12 Jun 2014 10:20:54 -0400 (EDT), Alan Stern wrote:
> > > > Dennis and Matteo:
> > > >
> > > > I promised to send both of you a patch
On 06/19/2014 05:53 PM, David Laight wrote:
> From: Daniel Mack [mailto:dan...@zonque.org]
>> On 06/19/2014 05:07 PM, Felipe Balbi wrote:
>>> On Wed, Jun 18, 2014 at 11:36:43AM +0200, Daniel Mack wrote:
On 06/18/2014 11:32 AM, David Laight wrote:
> You can't really mean nanoseconds?
Hi,
I've been debugging issues with musb in host mode and both full-speed
and high-speed USB audio devices with cppi41 DMA mode enabled.
The effect that was observed with full-speed devices was that CPU load
went up to 100% due to the dma channels dma_completion work struct.
For FS devices, the M
This reverts commit 1af54b7a4.
The commit tried to address cases in which isochronous transfers are 'not
reliable', most probably in the tests conducted, polling for the
MUSB_TXCSR_TXPKTRDY bit in MUSB_TXCSR is done too late.
Hence, it installs a work struct which basically busy-polls for the bit
The musb/cppi41 code installs a hrtimer to work around DMA completion
interrupts that have fired too early on AM335x hardware. This timer
is currently programmed to first fire 140 microseconds after the DMA
completion callback. According to the commit which introduced it
(a655f481d83, "usb: musb: m
> On Thu, 19 Jun 2014, Wang, Yu Y wrote:
>
> > > I'm not sure of the right way to solve this problem. Probably
> > > xhci_resume() should check the root-hub statuses to see if either
> > > root hub really needs to be resumed before calling
> > > usb_hcd_resume_root_hub(); I think that will work.
On 6/19/2014 4:54 PM, Tony Lindgren wrote:
* Daniel Mack [140619 03:51]:
On 06/19/2014 12:43 PM, Tony Lindgren wrote:
* Daniel Mack [140619 03:38]:
On 06/19/2014 12:31 PM, Tony Lindgren wrote:
* Daniel Mack [140619 03:10]:
On 06/19/2014 11:56 AM, Tony Lindgren wrote:
But that also raises
On 6/20/2014 3:50 AM, Daniel Mack wrote:
Hi,
I've been debugging issues with musb in host mode and both full-speed
and high-speed USB audio devices with cppi41 DMA mode enabled.
The effect that was observed with full-speed devices was that CPU load
went up to 100% due to the dma channels dma_co
* George Cherian [140619 20:43]:
> On 6/19/2014 4:54 PM, Tony Lindgren wrote:
> >* Daniel Mack [140619 03:51]:
> >>On 06/19/2014 12:43 PM, Tony Lindgren wrote:
> >>>* Daniel Mack [140619 03:38]:
> On 06/19/2014 12:31 PM, Tony Lindgren wrote:
> >* Daniel Mack [140619 03:10]:
> >>On 0
43 matches
Mail list logo
