Hi, On Thu, Feb 19, 2015 at 11:00 PM, Hans de Goede <[email protected]> wrote: > Hi, > > On 16-02-15 10:46, Chen-Yu Tsai wrote: >> >> Hi, >> >> On Sat, Feb 14, 2015 at 3:25 AM, Hans de Goede <[email protected]> >> wrote: >>> >>> Hi All, >>> >>> I'm happy to report that after a lot of poking at the Allwinner >>> musb code I've it working reliable in both host and peripheral mode, >>> as well as automatically switching between the 2 depending on which >>> cable gets plugged. >> >> >> Many thanks for finishing this. > > > You're welcome. Thanks for starting this :) > >>> My wip code is available here: >>> >>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-wip >>> >>> Functionality wise this is complete and I expect / hope there will be >>> no functional changes before it goes upstream. >>> >>> There are 2 things which need to be done before it can be submitted >>> upstream though: >>> >>> 1) All the ForceVbus / ForceID stuff needs to be cleaned up >>> 2) Currently this is not suitable for multiplatform kernels as it >>> puts a #ifdef MACH_SUNXI in musb_regs.h, this needs to be fixed. >>> >>> 1) is just a matter of removing a whole lot of unnecessary indirection >>> in the code, and giving the relevant defines better names >> >> >> There's the issue of the glue registers being in the address space >> of the usb phy driver. That part could be part of a usb-phy device, >> but would require some notifier between the usb-phy and musb. I got >> stuck trying to figure out that bit. But I think it's doable. > > > Yeah, I've a plan for this we will need one sunxi specific phy call, > but should be ok, others have platform specific phy calls too.
We should keep in mind that some boards use the AXP's function to detect VBUS. Maybe the omap (?) phy companion stuff can be reused for this? I've not looked into this too much though. Don't have notes from my previous attempt either. :( >>> 2) I've a plan for, I just need some time for this. >>> >>> I've so far only tested this on a cubietruck, I started development on >>> a cubieboard, but the cubieboard has the Vusb hardwired to the 5V of the >>> board (or at least mine does) meaning that the Vusb enable gpio does not >>> do anything, and Vusb-detect always reads as 1, I think my current code >>> may work despite this, but I need to test. >>> >>> Note that the dts modifications for the cubietruck / cubieboard enable >>> the musb controller in otg mode, which means that it will not "start" >>> until a gadget driver is loaded. For testing I use: >>> >>> insmod libcomposite.ko >>> insmod u_serial.ko >>> insmod usb_f_acm.ko >>> insmod g_serial.ko >> >> >> I don't suppose there is a way to get it working with the gadget >> driver builtin? > > > I'm glad that you ask, that is how I started myself, but indeed it > does not work, the problem is in drivers/usb/gadget/udc/udc-core.c > usb_gadget_probe_driver() this function walks a list of already > registered udc-s (usb device controllers) and attaches the driver > (e.g. g_serial) to the first free one. > > But if there is no udc registered yet this function is a nop, if > instead it would put the driver on a list of drivers waiting for > an udc to show up, and check that list when the udc registers, > then things should work fine when built-in too. This *should* > not be hard to fix. > > Perhaps you can write a patch for that? I did some digging last week and saw 2 related patch series on LKML. I don't have the links on hand. One was deferred binding for udc <-> gadget drivers. The other was a new bus type for udc / gadgets, and allows specifying binding through sysfs. What you proposed above is like the first one. Regards ChenYu -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
