Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case

Hi Felipe, On lun., déc. 07 2015, Felipe Balbi wrote: > Hi, > > Gregory CLEMENT writes: >> Hi Felipe, >> >> I am going back on this subject (again :) ) >> >> On mar., oct. 20 2015, Gregory CLEMENT >>

Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case

Felipe, On 12/08/2015 08:20 AM, Felipe Balbi wrote: Hi, Gregory CLEMENT writes: if it is the case then it didn't fix the issue I had. I activated the following debug line: [musb_hdrc]musb_interrupt =_ "** IRQ %s usb%04x tx%04x rx%04x\012"

Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case

Hi, Bin Liu writes: > Felipe, > > On 12/08/2015 08:20 AM, Felipe Balbi wrote: >> >> Hi, >> >> Gregory CLEMENT writes: >> if it is the case then it didn't fix the issue I had. >> >> I activated the following debug line: >> >>

Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case

Hi, Gregory CLEMENT writes: if it is the case then it didn't fix the issue I had. I activated the following debug line: [musb_hdrc]musb_interrupt =_ "** IRQ %s usb%04x tx%04x rx%04x\012" [musb_dsps]dsps_interrupt =p "usbintr (%x)

Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case

On 12/08/2015 08:35 AM, Felipe Balbi wrote: Hi, Bin Liu writes: Felipe, On 12/08/2015 08:20 AM, Felipe Balbi wrote: Hi, Gregory CLEMENT writes: if it is the case then it didn't fix the issue I had. I activated the following debug

Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case

Hi, Bin Liu writes: > "This bit should be set high prior to setting bit 0 and cleared after bit > 0 > is cleared." > > and on the other side: > "Both the soft_reset and soft_reset_isolation bits should be asserted > simultaneously." > > The hang

Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case

Hi Felipe, I am going back on this subject (again :) ) On mar., oct. 20 2015, Gregory CLEMENT wrote: > Hi Felipe, > > On lun., oct. 05 2015, Felipe Balbi wrote: > > >>> So after many tests on different devices, 200ms is enough for most

Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case

Hi, Gregory CLEMENT writes: > Hi Felipe, > > I am going back on this subject (again :) ) > > On mar., oct. 20 2015, Gregory CLEMENT > wrote: > >> Hi Felipe, >> >> On lun., oct. 05 2015, Felipe Balbi

Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case

Hi Felipe, On lun., oct. 05 2015, Felipe Balbi wrote: >> So after many tests on different devices, 200ms is enough for most of >> them, but for one, 2000ms (2s) was needed! >> >> I see several option: >> - adding a sysfs entry to setup the time >> - adding a debugs entry entry

Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case

Gregory CLEMENT writes: > Hi Felipe, > > On ven., août 21 2015, Gregory CLEMENT > wrote: >>> According to the OTG specification after a timeout of >>> OTG_TIME_A_WAIT_VRISE (the maximum value is 100ms) the driver must

Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case

Hi Felipe, On ven., août 21 2015, Gregory CLEMENT wrote: >> According to the OTG specification after a timeout of >> OTG_TIME_A_WAIT_VRISE (the maximum value is 100ms) the driver must >> move from the state a_wait_vrise to the state a_wait_bcon. However, >>

Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case

Hi all, On 20/08/2015 18:12, Gregory CLEMENT wrote: According to the OTG specification after a timeout of OTG_TIME_A_WAIT_VRISE (the maximum value is 100ms) the driver must move from the state a_wait_vrise to the state a_wait_bcon. However, the dsps version of musb does not handle this case.

[PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case

According to the OTG specification after a timeout of OTG_TIME_A_WAIT_VRISE (the maximum value is 100ms) the driver must move from the state a_wait_vrise to the state a_wait_bcon. However, the dsps version of musb does not handle this case. Without it, the driver could remain stuck in the