Re: [PATCH 2/2] USB: musb: omap2430: add mode change from A to B
On Thu, 22 Jul 2010 19:40:44 +0300, Felipe Balbi wrote: > On 07/22/2010 06:16 PM, Kan-Ru Chen wrote: > > Just curious about how to do this in a more automatic way. > > > > I think setup a daemon to monitor the musb_hdrc mode and try to alter > > it's state via sysfs interface will work, but it may be error prone and > > not always desirable solution. > > > > Can we query the id pin state periodically in the kernel and change to > > corresponding role? > > the transceiver has an interrupt for id pin changes. You can use that > instead of polling. Thanks, I see. The twl4030_usb transceiver did get the id pin chanegs <7>twl4030_usb twl4030_usb: HW_CONDITIONS 0x50/80; link 1 <7>twl4030_usb twl4030_usb: HW_CONDITIONS 0x54/84; link 3 So the problem is when OTG enter a_host mode then disconnected, it becomes idle. Plug the peripheral device back would not trigger new session unless I do "echo otg > /sys/devices/platform/musb_hdrc/mode" -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] USB: musb: omap2430: add mode change from A to B
On 07/22/2010 06:16 PM, Kan-Ru Chen wrote: > Just curious about how to do this in a more automatic way. > > I think setup a daemon to monitor the musb_hdrc mode and try to alter > it's state via sysfs interface will work, but it may be error prone and > not always desirable solution. > > Can we query the id pin state periodically in the kernel and change to > corresponding role? the transceiver has an interrupt for id pin changes. You can use that instead of polling. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] USB: musb: omap2430: add mode change from A to B
--text follows this line-- Hi, On Mon, 15 Mar 2010 18:23:42 +0800, Wang Hui wrote: > On omap2/3 series platforms, the musb can't raise id pin change > detection interrupt, so we must change otg mode through sysfs > interface manually. Currently when the musb is in B mode, if we > want musb to be changed to A mode, we should plug a mini-A cable > and then execute echo host > /sys/devices/platform/musb_hdrc/mode. > But if the musb is in A mode, we can't change it to B mode through > this method. > To solve this problem, add a process for sending end session request. > This process works like this, if the musb is in A mode, it will send > an end session request first, then it will follow original routine: > start a new session, during this session, it will identify whether > A or B is plugging in the socket, then it will init controller to A > or B mode according to its identification. Just curious about how to do this in a more automatic way. I think setup a daemon to monitor the musb_hdrc mode and try to alter it's state via sysfs interface will work, but it may be error prone and not always desirable solution. Can we query the id pin state periodically in the kernel and change to corresponding role? Regards, Kanru > > Usage: change cable as you desired, >change musb mode by #>echo host[peripheral] > /sys/devices/\ >platform/musb_hdrc/mode, >then you will get required musb mode. > > Signed-off-by: Wang Hui > --- > drivers/usb/musb/omap2430.c |5 + > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c > index 3fe1686..b02897e 100644 > --- a/drivers/usb/musb/omap2430.c > +++ b/drivers/usb/musb/omap2430.c > @@ -194,6 +194,11 @@ int musb_platform_set_mode(struct musb *musb, u8 > musb_mode) > { > u8 devctl = musb_readb(musb->mregs, MUSB_DEVCTL); > > + if ((devctl & MUSB_DEVCTL_BDEVICE) == 0x0) { > + devctl &= ~MUSB_DEVCTL_SESSION; > + musb_writeb(musb->mregs, MUSB_DEVCTL, devctl); > + } > + > devctl |= MUSB_DEVCTL_SESSION; > musb_writeb(musb->mregs, MUSB_DEVCTL, devctl); > > -- > 1.5.6.5 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] USB: musb: omap2430: add mode change from A to B
Hi, On Tue, Mar 16, 2010 at 06:13:50PM +0800, wanghui wrote: > Thank you for your comments. > It is right that in this function, we should only change id pin rules > according to user's choice, and > leave mode transition to the ISR. > But things are different on omap platforms, because the id pin change > can't trigger ISR. > For example, when we configure the kernel, we choose musb working as OTG > mode. Then we plug a mini-A or a mini-B cable in the socket, after > that we execute insmod g_ether.ko, at this time, the musb will > initialize to A or B working mode. how to change > its working mode from A to B or B to A at this time? I think if the > platform can support id detection ISR, your method > is workable. But on omap platforms, we must change cable(id pin state) > manually first, then let the controller to re-initiate a session forcibly. > This action (clear/set session bit) don't 100% equal to send a SRP, and > i don't really want to send a SRP too. > > If without this function for omap platforms, we can change musb working > mode only through rebooting kernel or rmmod/insmod gadget driver module. it should be doable with the transceiver ISR. When you get id pin irq, you should put the transceiver into A_IDLE state and power up vbus. MUSB changes to host mode automatically. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] USB: musb: omap2430: add mode change from A to B
Felipe Balbi wrote: On Mon, Mar 15, 2010 at 02:22:38PM +0300, Sergei Shtylyov wrote: The whole musb_platform_set_mode() seems to be implemented incorrectly on OMAPs -- it shouldn't touch the DevCtl.Session bit. This correct. It should be changing the id pin rules just like in tusb6010.c function should control the ID pin override instead -- if the controller supports it. SRP must be initiated thru other means, i.e. 'srp' file in sysfs. via musb_gadget_wakeup() Thank you for your comments. It is right that in this function, we should only change id pin rules according to user's choice, and leave mode transition to the ISR. But things are different on omap platforms, because the id pin change can't trigger ISR. For example, when we configure the kernel, we choose musb working as OTG mode. Then we plug a mini-A or a mini-B cable in the socket, after that we execute insmod g_ether.ko, at this time, the musb will initialize to A or B working mode. how to change its working mode from A to B or B to A at this time? I think if the platform can support id detection ISR, your method is workable. But on omap platforms, we must change cable(id pin state) manually first, then let the controller to re-initiate a session forcibly. This action (clear/set session bit) don't 100% equal to send a SRP, and i don't really want to send a SRP too. If without this function for omap platforms, we can change musb working mode only through rebooting kernel or rmmod/insmod gadget driver module. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] USB: musb: omap2430: add mode change from A to B
On Mon, Mar 15, 2010 at 02:22:38PM +0300, Sergei Shtylyov wrote: >The whole musb_platform_set_mode() seems to be implemented > incorrectly on OMAPs -- it shouldn't touch the DevCtl.Session bit. This correct. It should be changing the id pin rules just like in tusb6010.c > function should control the ID pin override instead -- if the controller > supports it. SRP must be initiated thru other means, i.e. 'srp' file in > sysfs. via musb_gadget_wakeup() -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] USB: musb: omap2430: add mode change from A to B
Hello. Wang Hui wrote: On omap2/3 series platforms, the musb can't raise id pin change detection interrupt, so we must change otg mode through sysfs interface manually. Currently when the musb is in B mode, if we want musb to be changed to A mode, we should plug a mini-A cable and then execute echo host > /sys/devices/platform/musb_hdrc/mode. But if the musb is in A mode, we can't change it to B mode through this method. To solve this problem, add a process for sending end session request. This process works like this, if the musb is in A mode, it will send an end session request first, then it will follow original routine: start a new session, during this session, it will identify whether A or B is plugging in the socket, then it will init controller to A or B mode according to its identification. Usage: change cable as you desired, change musb mode by #>echo host[peripheral] > /sys/devices/\ platform/musb_hdrc/mode, then you will get required musb mode. Signed-off-by: Wang Hui --- drivers/usb/musb/omap2430.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c index 3fe1686..b02897e 100644 --- a/drivers/usb/musb/omap2430.c +++ b/drivers/usb/musb/omap2430.c @@ -194,6 +194,11 @@ int musb_platform_set_mode(struct musb *musb, u8 musb_mode) { u8 devctl = musb_readb(musb->mregs, MUSB_DEVCTL); + if ((devctl & MUSB_DEVCTL_BDEVICE) == 0x0) { + devctl &= ~MUSB_DEVCTL_SESSION; + musb_writeb(musb->mregs, MUSB_DEVCTL, devctl); + } + devctl |= MUSB_DEVCTL_SESSION; musb_writeb(musb->mregs, MUSB_DEVCTL, devctl); The whole musb_platform_set_mode() seems to be implemented incorrectly on OMAPs -- it shouldn't touch the DevCtl.Session bit. This function should control the ID pin override instead -- if the controller supports it. SRP must be initiated thru other means, i.e. 'srp' file in sysfs. WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html