Re: musb - babble interrupt recovery
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 another appearance of Babble and this time without any workaround. Recently I tested HiFace USB audio interface (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/sound/usb/hiface), mainly because it using bulk transfers instead of isochronous ones and i was curious, if it will be also affected by high CPU utilization issue, which i reported in my other posts. After connection to Beaglebone it seems to be correctly enumerated (albeit with one warning about its reported standard violating maxpacket length, but it shouldn't be lethal). Then after initiating of audio playback, Babble interrupt occurs and this is the end. Force cancellation of playback emits couple of warnings in dmesg, but this is probably sign of unfinished urbs. Just for completeness, audio interface works well on Intel NUC board with same kernel version. Best regards, Michal Bus 002 Device 002: ID 04b4:930b Cypress Semiconductor Corp. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize064 idVendor 0x04b4 Cypress Semiconductor Corp. idProduct 0x930b bcdDevice0.01 iManufacturer 1 M2TECH iProduct2 USB-SPDIF iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 0 iConfiguration 0 bmAttributes 0x60 (Missing must-be-set bit!) Self Powered Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 Device Qualifier (for other device speed): bLength10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize064 bNumConfigurations 1 Device Status: 0x0002 (Bus Powered) Remote Wakeup Enabled [0.00] Booting Linux on physical CPU 0x0 [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.14.0-rc4-bone0 (msmucr@vmdebian-ct) (gcc version 4.8.3 20140106 (prerelease) (crosstool-NG linaro-1.13.1-4.8-2014.01 - Linaro GCC 2013.11) ) #1 SMP Sun Mar 2 15:10:51 CET 2014 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine model: TI AM335x BeagleBone [0.00] cma: CMA: reserved 16 MiB at 9e80 [0.00] Memory policy: Data cache writeback [0.00] On node 0 totalpages: 130816 [0.00] free_area_init_node: node 0, pgdat c0b09000, node_mem_map dfaf2000 [0.00] Normal zone: 1024 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 130816 pages, LIFO batch:31 [0.00] CPU: All CPU(s) started in SVC mode. [0.00] AM335X ES2.0 (sgx neon ) [0.00] PERCPU: Embedded 9 pages/cpu @dfad7000 s14400 r8192 d14272 u36864 [0.00] pcpu-alloc: s14400 r8192 d14272 u36864 alloc=9*4096 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 129792 [0.00] Kernel command line: console=ttyO0,115200n8 capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait fixrtc ip= [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00]
Re: musb - babble interrupt recovery
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 check patches there and possibly try it on BBB, maybe there is also something, that could also address other issue, i'm having with musb (DMA errors and high CPU load) and then possibly post some field report. George and Roger have been involved in all the work and deserve all the credit for getting all of that working fine (well, plus Ravi, Sebastian and few others). As an user I also would like to join with thanks for work there. Best regards, Michal -- 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 at http://vger.kernel.org/majordomo-info.html
Re: musb - babble interrupt recovery
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 details. That sounds great and i didn't know about that repository. I'll check patches there and possibly try it on BBB, maybe there is also something, that could also address other issue, i'm having with musb (DMA errors and high CPU load) and then possibly post some field report. George and Roger have been involved in all the work and deserve all the credit for getting all of that working fine (well, plus Ravi, Sebastian and few others). As an user I also would like to join with thanks for work there. Could you please try the 2 patches posted here [1] for the babble problem, esp. patch 2. This is not about babble recovery but to prevent the babble from happening in the first place. The patches are on their way to linux-next and 3.14-rc as well. [1] - http://thread.gmane.org/gmane.linux.kernel/1640032 cheers, -roger -- 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 at http://vger.kernel.org/majordomo-info.html
Re: musb - babble interrupt recovery
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 try the 2 patches posted here [1] for the babble problem, esp. patch 2. This is not about babble recovery but to prevent the babble from happening in the first place. 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! Best regards, Michal -- 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 at http://vger.kernel.org/majordomo-info.html
Re: musb - babble interrupt recovery
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 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/247 To be honest, I don't exactly know, why that situation happens on SoC and if is it hardware related, but it was working well for me and solved that omnipresent issue. Patch isn't applied to current kernels and i believe it will be very helpful to either use it or provide similar mechanism for recovery. The most appropriate way to get this merged is probably to just resend the patch. Use git send-email so the patch authorship is properly taken care for, and make sure to take the musb maintainer in Cc:. Thanks, Daniel Thank you for advice, before doing that, i actually found, that maintainer Mr. Balbi was at heh, you can drop the Mr. ;-) initial conversation about patch and had comments about introduction of new specific things in recovery process instead of usage of all possible generic things. It wasn't modified then. So that is the reason, why it wasn't accepted. I hope, it won't be too inappropriate to rather wakeup conversation about that by CCing both. Because i think, mechanism is really usable and quite a few BBB users, who had issues with reconnection according to several discussions, also appreciate it. 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. George and Roger have been involved in all the work and deserve all the credit for getting all of that working fine (well, plus Ravi, Sebastian and few others). -- balbi signature.asc Description: Digital signature
Re: musb - babble interrupt recovery
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 interrupt, https://lkml.org/lkml/2013/5/29/247 To be honest, I don't exactly know, why that situation happens on SoC and if is it hardware related, but it was working well for me and solved that omnipresent issue. Patch isn't applied to current kernels and i believe it will be very helpful to either use it or provide similar mechanism for recovery. The most appropriate way to get this merged is probably to just resend the patch. Use git send-email so the patch authorship is properly taken care for, and make sure to take the musb maintainer in Cc:. Thanks, Daniel -- 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 at http://vger.kernel.org/majordomo-info.html
musb - babble interrupt recovery
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/247 To be honest, I don't exactly know, why that situation happens on SoC and if is it hardware related, but it was working well for me and solved that omnipresent issue. Patch isn't applied to current kernels and i believe it will be very helpful to either use it or provide similar mechanism for recovery. Best regards, Michal Smucr -- 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 at http://vger.kernel.org/majordomo-info.html
