* 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
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
* 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 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: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
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: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
(+ 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
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
> Hello,
>
> On 21.2.2014 15:09, Michal Šmucr wrote:
> >
> > I tried both patches separately on 3.14-rc3 and second patch alone
> > helped here. I wasn't able to reproduce babble interrupt anymore, no
> > matter, what i did with my hub and USB peripherals. Great!
> >
>
> Unfortunately i found ano
: M2TECH
[ 102.788459] usb 2-1: config 0 descriptor??
[ 103.046836] usbcore: registered new interface driver snd-usb-hiface
[ 126.292477] CAUTION: musb: Babble Interrupt Occurred
[ 155.381764] [ cut here ]
[ 155.386721] WARNING: CPU: 0 PID: 2303 at drivers/usb/musb/musb_
Hi Roger,
thanks for those patches, actually i briefly approached them during my
googling, but at first i didn't relate subject with Babble situation.
Closely reading description about SUSPENDM bit behavior during resume
makes sense.
On 21.2.2014 13:03, Roger Quadros wrote:
Could you please
Hi Michal,
On 02/21/2014 01:44 PM, Michal Šmucr wrote:
> Thank you for reply,
>
> On 21.2.2014 2:03, Felipe Balbi wrote:
>>
>> heh, you can drop the Mr. ;-)
>>
> :-)
>
>>
>> We have another version in TI's tree (git.ti.com) which will be sent
>> soonish for mainline. Just hashing out a few extra
Thank you for reply,
On 21.2.2014 2:03, Felipe Balbi wrote:
heh, you can drop the Mr. ;-)
:-)
We have another version in TI's tree (git.ti.com) which will be sent
soonish for mainline. Just hashing out a few extra details.
That sounds great and i didn't know about that repository. I'll ch
On Thu, Feb 20, 2014 at 10:19:27PM +0100, Michal Šmucr wrote:
> On 19.2.2014 15:46, Daniel Mack wrote:
> >On 02/18/2014 02:44 AM, Michal Šmucr wrote:
> >>during searching for solution to problem with Beaglebone Black USB
> >>unreliable reconnections, which i had, when i tried to reconnect devices
>
On 19.2.2014 15:46, Daniel Mack wrote:
On 02/18/2014 02:44 AM, Michal Šmucr wrote:
during searching for solution to problem with Beaglebone Black USB
unreliable reconnections, which i had, when i tried to reconnect devices
to external powered hub, I came to that older patch from Ravi Babu,
which
On 02/18/2014 02:44 AM, Michal Šmucr wrote:
> during searching for solution to problem with Beaglebone Black USB
> unreliable reconnections, which i had, when i tried to reconnect devices
> to external powered hub, I came to that older patch from Ravi Babu,
> which restarts musb after babble int
Hello,
during searching for solution to problem with Beaglebone Black USB
unreliable reconnections, which i had, when i tried to reconnect devices
to external powered hub, I came to that older patch from Ravi Babu,
which restarts musb after babble interrupt,
https://lkml.org/lkml/2013/5/29/24
Hi,
On Mon, Nov 11, 2013 at 07:38:14PM +0800, Yingchun Li wrote:
> Hi, On my board, my musb works as host. my kernel version is 3.4.0.
> The host cannot enumerate some low speed mouse normally,but if I add
> an extersion cord (abour 1.5m) between the host and device, the mouse
> can work normally.
Hi, On my board, my musb works as host. my kernel version is 3.4.0.
The host cannot enumerate some low speed mouse normally,but if I
add an extersion cord (abour 1.5m) between the host and device, the
mouse can work normally.
If the enumeration fails, there is always a babble interrupt happen just
20 matches
Mail list logo