On Fri, Mar 24, 2017 at 04:10:26AM -0500, Pordán Szabolcs wrote: > Hi guys! > > I've found your name on github in musb, I hope you can help me. I think I've > got a bug but not sure. > I have an arm board, called c.h.i.p. It has one normal usb and micro USB port. > The microUSB connector is used to provide power. I have (a tablet) otg power y Is it microA, microB or microAB connector? Do you have the schematics of the board? > cable which connects to microusb and the 2A power supply of tablet. Any detail of the cable? Link to a picture of it? It sounds like an Acccessory Charger Adapter (ACA), isn't it? Can you please measure the ID pin resistance of the cable? I haven't touch the BC Specs for years and forgot how the ID pin resistance could be implemented, so please measure the ID in following two cases. - plug the adapter to the wall power outlet, but don't connect the cable to your arm board; - plug the adapter to the wall power outlet, and connect the cable to your arm board. > If the otg cable is empty (only power supply connected) I have these errors: > musb_bus_suspend 2603: trying to suspend as a_idle while active I don't think the 'a_idle' state is expected, but not 100% sure. > and the board cannot reach login. But if something is also connected to the But does the uart respond when you press Enter on your keyboard? I am wondering if CPU is 100% loaded now. > otg, eg a pendrive, there isn't any error and everything works well and i can > login. > Have you experienced this issue yet? No. > I hope there's already a fix for it but now the board uses the official 4.4.13 > kernel of the board. It's not mainline, it's a custom kernel as I know. > > Could a newer kernel solve this issue? Is there a fix for this problem since > 4.4? I doubt it. I don't understand 1) how it got in a_idle state, 2) what causes not reaching login, busy loop? > I hope I don't need to build an own custom kernel because I'm a begginer in > linux. I hope there's an easiest solution but i'll try to do it if you suggest > a new kernel solves this. You likely have to rebuild the kernel if you really want to solve the issue, we need your help to debug what is happening ;) > What is your advice? One thing you could try is to add 'usbcore.autosuspend=-1' into kernel boot parameters. If you use u-boot, add it in u-boot bootargs. Regards, -Bin. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
