Re: musb: dsps: make it work with two instances
* Ezequiel Garcia | 2013-07-06 18:39:50 [-0300]: Hi Sebastian, Hi Ezequiel, After some minor DT tweaking on the current patchset, I've managed to detect an USB mass storage device in the second instance (host / usb1) using a Beaglebone black board. Beaglebone black, that one has a different device tree which is not mainline, right? However, after I unplug the device, it's not recognized when I replug it. Maybe you can take a look at this; i'll do some more testings and see what I can come up with. I figured out why my Host is not recognized on the second plug: At module load time, musb_start() is executed and it sets the MUSB_DEVCTL_SESSION in devctl. After the device is unplugged dsps_musb_try_idle() schedules a timer which executes the local otg_timer() function. Since the phy is in OTG_STATE_A_WAIT_BCON state, the MUSB_DEVCTL_SESSION bit gets removed. If the removal of the bit is ignored, the device is recognized after a re-plug. Now a question: I see that am35x and anothers also remove that flag in thsi case. How is the flag supposed to come back? I see that blackfin removes that bit and stuffs it back in. Any idea what should be done here? Also, FWIW, I think that having a separate USB phy for am35xx would be much better. So you would prefer a new file with 90% copy of what we already have in the nop_phy? Sebastian -- 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: dsps: make it work with two instances
Hi Sebastian, On Wed, Jul 17, 2013 at 07:12:29PM +0200, Sebastian Andrzej Siewior wrote: After some minor DT tweaking on the current patchset, I've managed to detect an USB mass storage device in the second instance (host / usb1) using a Beaglebone black board. Beaglebone black, that one has a different device tree which is not mainline, right? Beaglebone black it is. But I'm almost sure I just used the ambone.dts file that's mainlined. I just changed the mode or something like that, very minor tweaking indeed, altough right now I don't remember exactly which changes. However, after I unplug the device, it's not recognized when I replug it. Maybe you can take a look at this; i'll do some more testings and see what I can come up with. I figured out why my Host is not recognized on the second plug: At module load time, musb_start() is executed and it sets the MUSB_DEVCTL_SESSION in devctl. After the device is unplugged dsps_musb_try_idle() schedules a timer which executes the local otg_timer() function. Since the phy is in OTG_STATE_A_WAIT_BCON state, the MUSB_DEVCTL_SESSION bit gets removed. If the removal of the bit is ignored, the device is recognized after a re-plug. Mmmm... okey. Interesting insight, thanks! Also, FWIW, I think that having a separate USB phy for am35xx would be much better. So you would prefer a new file with 90% copy of what we already have in the nop_phy? No, of course not. -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- 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: dsps: make it work with two instances
On 07/06/2013 11:39 PM, Ezequiel Garcia wrote: Hi Sebastian, Hello Ezequiel, On Fri, Jul 5, 2013 at 10:32 AM, Sebastian Andrzej Siewior bige...@linutronix.de wrote: This enables the two musb instances on am335x to work. I like a lot the idea of splitting the DT representation of the two USB instances. The DT binding looks much better this way. After some minor DT tweaking on the current patchset, I've managed to detect an USB mass storage device in the second instance (host / usb1) using a Beaglebone black board. Forgot that. Will update the .dts However, after I unplug the device, it's not recognized when I replug it. Maybe you can take a look at this; i'll do some more testings and see what I can come up with. I've seen that. If I remember correctly this isn't happening if runtime-pm is enabled. However if I reload the driver it works again. I will look at this. Also, FWIW, I think that having a separate USB phy for am35xx would be much better. George Cherian said that he is writing a phy driver. So my phy is just temporary but I think he keep the device nodes just remove the nop-phy code. Nice job! Sebastian -- 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: dsps: make it work with two instances
Hi Sebastian, On Fri, Jul 5, 2013 at 10:32 AM, Sebastian Andrzej Siewior bige...@linutronix.de wrote: This enables the two musb instances on am335x to work. I like a lot the idea of splitting the DT representation of the two USB instances. The DT binding looks much better this way. After some minor DT tweaking on the current patchset, I've managed to detect an USB mass storage device in the second instance (host / usb1) using a Beaglebone black board. However, after I unplug the device, it's not recognized when I replug it. Maybe you can take a look at this; i'll do some more testings and see what I can come up with. Also, FWIW, I think that having a separate USB phy for am35xx would be much better. Nice job! -- Ezequiel -- 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: dsps: make it work with two instances
This enables the two musb instances on am335x to work.
Could someone explain what
ti,hwmods = usb_otg_hs;
doing? I would want to have something like
| musb {
|/* glue /*
| {
| musb child node
|}
| }
and this twice. This would put the glue layer into the right position and
remove this nonsense and the += 0x400 chicken dance (look for
musb_core_offset).
Sebastian
--
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
