Re: [linux-sunxi] Re: sunxi otg usb code for mainline (wip) available now
Hi, On 21-03-15 13:02, Eric D. wrote: Hi, I found this reference to axp209 gpio in u-boot code http://code.metager.de/source/xref/denx/u-boot/drivers/power/axp209.c Could we port this code to linux kernel ? Not really as is, we need to add a gpio-chip to the ap209 mfd driver in the kernel which is not that hard, but looks a lot different then the u-boot code. We know how the hardware works and what needs to be done, it is just a matter of someone sitting down and doing the work. Regards, Hans Regards, Eric On Saturday, March 21, 2015 at 12:42:56 PM UTC+1, Hans de Goede wrote: Hi, On 20-03-15 21:31, Karsten Merker wrote: On Fri, Mar 20, 2015 at 09:19:46PM +0100, Karsten Merker wrote: I have just tried to take a look at the LeMaker Banana Pi schematics on lemaker.org and am a bit confused... According to them, the OTG VBUS power supply is controlled by a SY6280 switch, whose enable pin is driven by the USB0-DRV line. This USB0-DRV line appears to be connected to both PB9 on the SoC as well as to GPIO2 on the AXP209. Any idea why it goes to _both_ the A20 and the AXP209? Sorry, I misread the schematics - it goes to N_VBUSEN on the AXP209, not to GPIO2, so it is only controlled from the A20 via PB9. Thanks for figuring this out, unfortunately vbus-det is connected to gpio1 of the axp209, and not to PH5 as the fex file says, so we need axp209 gpio support in the kernel before we can get otg support going on the bananapi. Regards, Hans -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: sunxi otg usb code for mainline (wip) available now
Hi, I found this reference to axp209 gpio in u-boot code http://code.metager.de/source/xref/denx/u-boot/drivers/power/axp209.c Could we port this code to linux kernel ? Regards, Eric On Saturday, March 21, 2015 at 12:42:56 PM UTC+1, Hans de Goede wrote: > > Hi, > > On 20-03-15 21:31, Karsten Merker wrote: > > On Fri, Mar 20, 2015 at 09:19:46PM +0100, Karsten Merker wrote: > > > >> I have just tried to take a look at the LeMaker Banana Pi schematics > >> on lemaker.org and am a bit confused... > >> > >> According to them, the OTG VBUS power supply is controlled by a SY6280 > >> switch, whose enable pin is driven by the USB0-DRV line. This USB0-DRV > >> line appears to be connected to both PB9 on the SoC as well as to GPIO2 > >> on the AXP209. Any idea why it goes to _both_ the A20 and the AXP209? > > > > Sorry, I misread the schematics - it goes to N_VBUSEN on the AXP209, > > not to GPIO2, so it is only controlled from the A20 via PB9. > > Thanks for figuring this out, unfortunately vbus-det is connected to > gpio1 of the axp209, and not to PH5 as the fex file says, so we need > axp209 gpio support in the kernel before we can get otg support going > on the bananapi. > > Regards, > > Hans > -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: sunxi otg usb code for mainline (wip) available now
Hi, On 20-03-15 21:31, Karsten Merker wrote: On Fri, Mar 20, 2015 at 09:19:46PM +0100, Karsten Merker wrote: I have just tried to take a look at the LeMaker Banana Pi schematics on lemaker.org and am a bit confused... According to them, the OTG VBUS power supply is controlled by a SY6280 switch, whose enable pin is driven by the USB0-DRV line. This USB0-DRV line appears to be connected to both PB9 on the SoC as well as to GPIO2 on the AXP209. Any idea why it goes to _both_ the A20 and the AXP209? Sorry, I misread the schematics - it goes to N_VBUSEN on the AXP209, not to GPIO2, so it is only controlled from the A20 via PB9. Thanks for figuring this out, unfortunately vbus-det is connected to gpio1 of the axp209, and not to PH5 as the fex file says, so we need axp209 gpio support in the kernel before we can get otg support going on the bananapi. Regards, Hans -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: sunxi otg usb code for mainline (wip) available now
Hi, On 18-03-15 14:04, Eric Dillmann wrote: Hi, I take a look at your patch, and would like to give it a try on my /bananapi/. vbus is tied to +5V, is there a simple dts patch I could try ? Are you sure that vbus is tied to +5v and not gpio controllable ? I've seen the same on the original cubieboard and I still need to figure out how to get things working with that unfortunate setup. Regards, Hans Reagrds, Eric On Friday, February 13, 2015 at 8:25:59 PM UTC+1, Hans de Goede 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. 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 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 After this you should see 2 messages like this: [ 3528.872816] g_serial gadget: Gadget Serial v2.4 [ 3528.877377] g_serial gadget: g_serial ready And then the controller should work either as a usb serial port (ttyGS0 on cubietruck side, ttyACM0 on pc version) or as a usb host, depending on what you plug in, and you should be able to switch on the fly. I use the following on the cubietruck side to start a getty on the usb serial, this assumes you use systemd :) systemctl start serial-getty@ttyGS0.service If you put this in say rc.local, then you can use it to get a console on a tablet over the otg connector, which is very useful for debugging stuff. Regards, Hans -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: sunxi otg usb code for mainline (wip) available now
Hi, I take a look at your patch, and would like to give it a try on my /bananapi/. vbus is tied to +5V, is there a simple dts patch I could try ? Reagrds, Eric On Friday, February 13, 2015 at 8:25:59 PM UTC+1, Hans de Goede 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. > > 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 > 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 > > After this you should see 2 messages like this: > > [ 3528.872816] g_serial gadget: Gadget Serial v2.4 > [ 3528.877377] g_serial gadget: g_serial ready > > And then the controller should work either as a usb serial > port (ttyGS0 on cubietruck side, ttyACM0 on pc version) > or as a usb host, depending on what you plug in, and you should > be able to switch on the fly. > > I use the following on the cubietruck side to start a getty > on the usb serial, this assumes you use systemd :) > > systemctl start serial-getty@ttyGS0.service > > If you put this in say rc.local, then you can use it to > get a console on a tablet over the otg connector, which is > very useful for debugging stuff. > > Regards, > > Hans > -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: sunxi otg usb code for mainline (wip) available now
Hi, On Thu, Feb 19, 2015 at 11:00 PM, Hans de Goede 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 >> 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: sunxi otg usb code for mainline (wip) available now
Hi, On 16-02-15 10:46, Chen-Yu Tsai wrote: Hi, On Sat, Feb 14, 2015 at 3:25 AM, Hans de Goede 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. 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? Regards, Hans -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: sunxi otg usb code for mainline (wip) available now
Hi, On 17-02-15 14:58, Maxime Ripard wrote: Hi Hans, On Fri, Feb 13, 2015 at 08:25:46PM +0100, Hans de Goede wrote: 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. 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 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 After this you should see 2 messages like this: [ 3528.872816] g_serial gadget: Gadget Serial v2.4 [ 3528.877377] g_serial gadget: g_serial ready And then the controller should work either as a usb serial port (ttyGS0 on cubietruck side, ttyACM0 on pc version) or as a usb host, depending on what you plug in, and you should be able to switch on the fly. I use the following on the cubietruck side to start a getty on the usb serial, this assumes you use systemd :) systemctl start serial-getty@ttyGS0.service If you put this in say rc.local, then you can use it to get a console on a tablet over the otg connector, which is very useful for debugging stuff. Very nice, thanks! Last time I tried musb, there was some issue with the switch from host to peripheral after a random number of switches. Did you encounter such a thing during your tests? Not while explicitly testing things, I've seen it not registering as a device with my desktop once during actual use, a simple unplug / replug fixed this. Regards, Hans -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: sunxi otg usb code for mainline (wip) available now
Hi Hans, On Fri, Feb 13, 2015 at 08:25:46PM +0100, Hans de Goede wrote: > 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. > > 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 > 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 > > After this you should see 2 messages like this: > > [ 3528.872816] g_serial gadget: Gadget Serial v2.4 > [ 3528.877377] g_serial gadget: g_serial ready > > And then the controller should work either as a usb serial > port (ttyGS0 on cubietruck side, ttyACM0 on pc version) > or as a usb host, depending on what you plug in, and you should > be able to switch on the fly. > > I use the following on the cubietruck side to start a getty > on the usb serial, this assumes you use systemd :) > > systemctl start serial-getty@ttyGS0.service > > If you put this in say rc.local, then you can use it to > get a console on a tablet over the otg connector, which is > very useful for debugging stuff. Very nice, thanks! Last time I tried musb, there was some issue with the switch from host to peripheral after a random number of switches. Did you encounter such a thing during your tests? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
[linux-sunxi] Re: sunxi otg usb code for mainline (wip) available now
Hi, On Mon, Feb 16, 2015 at 5:46 PM, Chen-Yu Tsai wrote: > Hi, > > On Sat, Feb 14, 2015 at 3:25 AM, Hans de Goede 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. > >> 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. > >> 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? > > Anyway, I cherry-picked your patches onto sunxi-next and have it > working on my A13 tablet if built as modules. See > > https://github.com/wens/linux/commits/hans-sunxi-otg So for ease of use I am actually using builtin driver with host mode only. Setting Kconfig to host mode only, while having the DT say "otg" triggers some sort of oops (likely a NULL pointer reference). This was on my tablet, and I haven't looked into it. But I think it should be easy for anyone to reproduce. ChenYu >> After this you should see 2 messages like this: >> >> [ 3528.872816] g_serial gadget: Gadget Serial v2.4 >> [ 3528.877377] g_serial gadget: g_serial ready >> >> And then the controller should work either as a usb serial >> port (ttyGS0 on cubietruck side, ttyACM0 on pc version) >> or as a usb host, depending on what you plug in, and you should >> be able to switch on the fly. >> >> I use the following on the cubietruck side to start a getty >> on the usb serial, this assumes you use systemd :) >> >> systemctl start serial-getty@ttyGS0.service >> >> If you put this in say rc.local, then you can use it to >> get a console on a tablet over the otg connector, which is >> very useful for debugging stuff. >> >> Regards, >> >> Hans -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: sunxi otg usb code for mainline (wip) available now
Hi, On Sat, Feb 14, 2015 at 3:25 AM, Hans de Goede 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. > 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. > 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? Anyway, I cherry-picked your patches onto sunxi-next and have it working on my A13 tablet if built as modules. See https://github.com/wens/linux/commits/hans-sunxi-otg Regards ChenYu > After this you should see 2 messages like this: > > [ 3528.872816] g_serial gadget: Gadget Serial v2.4 > [ 3528.877377] g_serial gadget: g_serial ready > > And then the controller should work either as a usb serial > port (ttyGS0 on cubietruck side, ttyACM0 on pc version) > or as a usb host, depending on what you plug in, and you should > be able to switch on the fly. > > I use the following on the cubietruck side to start a getty > on the usb serial, this assumes you use systemd :) > > systemctl start serial-getty@ttyGS0.service > > If you put this in say rc.local, then you can use it to > get a console on a tablet over the otg connector, which is > very useful for debugging stuff. > > Regards, > > Hans -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: sunxi otg usb code for mainline (wip) available now
> 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. Yay! Stefan -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: sunxi otg usb code for mainline (wip) available now
Hi, On 15-02-15 11:49, tandresen1...@gmail.com wrote: Hi, thanks for your work - these are very good news :) Just one question - i think NOP_USB_XCEIV should be selected to make it work or am i wrong? You're right, I should fix this in the Kconfig rules. Regards, Hans Tobias Am Freitag, 13. Februar 2015 20:25:59 UTC+1 schrieb Hans de Goede: 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. 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 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 After this you should see 2 messages like this: [ 3528.872816] g_serial gadget: Gadget Serial v2.4 [ 3528.877377] g_serial gadget: g_serial ready And then the controller should work either as a usb serial port (ttyGS0 on cubietruck side, ttyACM0 on pc version) or as a usb host, depending on what you plug in, and you should be able to switch on the fly. I use the following on the cubietruck side to start a getty on the usb serial, this assumes you use systemd :) systemctl start serial-getty@ttyGS0.service If you put this in say rc.local, then you can use it to get a console on a tablet over the otg connector, which is very useful for debugging stuff. Regards, Hans -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: sunxi otg usb code for mainline (wip) available now
Hi, thanks for your work - these are very good news :) Just one question - i think NOP_USB_XCEIV should be selected to make it work or am i wrong? Tobias Am Freitag, 13. Februar 2015 20:25:59 UTC+1 schrieb Hans de Goede: > > 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. > > 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 > 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 > > After this you should see 2 messages like this: > > [ 3528.872816] g_serial gadget: Gadget Serial v2.4 > [ 3528.877377] g_serial gadget: g_serial ready > > And then the controller should work either as a usb serial > port (ttyGS0 on cubietruck side, ttyACM0 on pc version) > or as a usb host, depending on what you plug in, and you should > be able to switch on the fly. > > I use the following on the cubietruck side to start a getty > on the usb serial, this assumes you use systemd :) > > systemctl start serial-getty@ttyGS0.service > > If you put this in say rc.local, then you can use it to > get a console on a tablet over the otg connector, which is > very useful for debugging stuff. > > Regards, > > Hans > -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
