Re: Problem with OHCI on OMAP4430
Alan, On Tue, Oct 30, 2012 at 9:34 PM, Alan Stern st...@rowland.harvard.edu wrote: On Tue, 30 Oct 2012, Mohan V wrote: Device not getting detected when connected--- / # [ 135.621002] usbhs_wakeup: Enabling clocks [ 135.625762] usbhs_runtime_resume:++ [ 135.630371] usbhs_runtime_resume:-- [ 135.638183] USB IO PAD Wakeup event triggered## [ 135.644958] usbhs_runtime_suspend:++ [ 135.649749] usbhs_runtime_suspend:- It appears that ohci_irq() didn't run. Did ohci_finish_controller_resume() get called? This function is not used in ohci-omap3.c and is used only in ohci-omap.c. Is it necessary to call this function? It is necessary if the driver supports suspend/resume. As far as I can tell, the ohci-omap3 driver does not have this support (at least, not in the 3.6 kernel) whereas the ohci-omap driver does. What driver produced the usbhs_runtime_suspend and usbhs_runtime_resume messages above? (No such messages are present in ohci-omap3.c.) Apparently that driver _does_ support suspend/resume. This driver is USBHS core driver for OMAP EHCI and OHCI (drivers/mfd/omap-usb-host.c) Okay. I don't understand why the usbhs_runtime_suspend routine ever got called. Since ohci-omap3 never allows the OHCI controller to be suspended, the parent platform device should never get suspended either. Sorry for the delay in confirmation. In the android kernel, it seems that somehow the OHCI interrupts are not propagated to ARM interrupt controller. So, reading one of the OHCI registers in usbhs_runtime_resume() seems to resolve the issue. Thanks, Mohan What do the various files in the /sys/devices/.../ohci-omap3.0/power directory show? What about the corresponding files in the power subdirectory of the parent device? Alan Stern -- 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: Problem with OHCI on OMAP4430
Alan, On Mon, Oct 29, 2012 at 8:54 PM, Alan Stern st...@rowland.harvard.edu wrote: On Mon, 29 Oct 2012, Mohan V wrote: I'm not going to be able to help very much with an Android kernel. Does the same problem occur with a vanilla non-Android 3.6 kernel? If it doesn't, that indicates the problem was caused by some Android-specific changes. With the vanilla 3.6 kernel, the device connected to OHCI port is not even detected. The below messages are seen: [5.343780] usb 2-2: new low-speed USB device number 5 using ohci-omap3 [5.351776] ohci-omap3 ohci-omap3.0: urb ee7f83c0 path 2 ep0out 5ec2 cc 5 -- status -62 [5.570770] ohci-omap3 ohci-omap3.0: urb ee7f83c0 path 2 ep0out 5ec2 cc 5 -- status -62 [5.789062] usb 2-2: device not accepting address 5, error -62 [5.795288] hub 2-0:1.0: unable to enumerate USB device on port 2 It looks like the device was detected just fine but the host was unable to communicate with it. I don't know why; maybe a clock or power line wasn't turned on properly or a PHY wasn't enabled. We think it may not be hardware issue, since the device gets detected on android-3.0 kernel. The support for OHCI on OMAP4430 SDP board seems to be missing in Linux mainline (3.6). We ported some OMAP specific patches from android kernel, with this the device gets detected only if it is connected at boot. If the system is booted and then device is connected, it doesn't get detected. Doesn't get detected, or does get detected but then doesn't communicate? The device does not get detected. Perhaps you should send some questions to the maintainers of the various ohci-omap drivers or the Android maintainers. Keshava, can you please comment? Are you referring to this part of the log? Device not getting detected when connected--- / # [ 135.621002] usbhs_wakeup: Enabling clocks [ 135.625762] usbhs_runtime_resume:++ [ 135.630371] usbhs_runtime_resume:-- [ 135.638183] USB IO PAD Wakeup event triggered## [ 135.644958] usbhs_runtime_suspend:++ [ 135.649749] usbhs_runtime_suspend:- It appears that ohci_irq() didn't run. Did ohci_finish_controller_resume() get called? This function is not used in ohci-omap3.c and is used only in ohci-omap.c. Is it necessary to call this function? It is necessary if the driver supports suspend/resume. As far as I can tell, the ohci-omap3 driver does not have this support (at least, not in the 3.6 kernel) whereas the ohci-omap driver does. What driver produced the usbhs_runtime_suspend and usbhs_runtime_resume messages above? (No such messages are present in ohci-omap3.c.) Apparently that driver _does_ support suspend/resume. This driver is USBHS core driver for OMAP EHCI and OHCI (drivers/mfd/omap-usb-host.c) Thanks, Mohan -- 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: Problem with OHCI on OMAP4430
On Tue, 30 Oct 2012, Mohan V wrote: Device not getting detected when connected--- / # [ 135.621002] usbhs_wakeup: Enabling clocks [ 135.625762] usbhs_runtime_resume:++ [ 135.630371] usbhs_runtime_resume:-- [ 135.638183] USB IO PAD Wakeup event triggered## [ 135.644958] usbhs_runtime_suspend:++ [ 135.649749] usbhs_runtime_suspend:- It appears that ohci_irq() didn't run. Did ohci_finish_controller_resume() get called? This function is not used in ohci-omap3.c and is used only in ohci-omap.c. Is it necessary to call this function? It is necessary if the driver supports suspend/resume. As far as I can tell, the ohci-omap3 driver does not have this support (at least, not in the 3.6 kernel) whereas the ohci-omap driver does. What driver produced the usbhs_runtime_suspend and usbhs_runtime_resume messages above? (No such messages are present in ohci-omap3.c.) Apparently that driver _does_ support suspend/resume. This driver is USBHS core driver for OMAP EHCI and OHCI (drivers/mfd/omap-usb-host.c) Okay. I don't understand why the usbhs_runtime_suspend routine ever got called. Since ohci-omap3 never allows the OHCI controller to be suspended, the parent platform device should never get suspended either. What do the various files in the /sys/devices/.../ohci-omap3.0/power directory show? What about the corresponding files in the power subdirectory of the parent device? Alan Stern -- 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: Problem with OHCI on OMAP4430
Alan,
On Fri, Oct 26, 2012 at 8:49 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Fri, 26 Oct 2012, Mohan V wrote:
When the USB bus is in suspend, a device connected to OHCI port does
not get detected, whereas the device connected to EHCI port is getting
detected.
Can you provide a dmesg log showing the OHCI problem with
CONFIG_USB_DEBUG enabled?
Please find the attached log (ohci-detect.log), where the device is
disconnected from the
OHCI port and then does not get detected when connected again.
We are using android 3.0 kernel.
I'm not going to be able to help very much with an Android kernel.
Does the same problem occur with a vanilla non-Android 3.6 kernel? If
it doesn't, that indicates the problem was caused by some
Android-specific changes.
With the vanilla 3.6 kernel, the device connected to OHCI port is not even
detected. The below messages are seen:
[5.343780] usb 2-2: new low-speed USB device number 5 using ohci-omap3
[5.351776] ohci-omap3 ohci-omap3.0: urb ee7f83c0 path 2 ep0out
5ec2 cc 5 -- status -62
[5.570770] ohci-omap3 ohci-omap3.0: urb ee7f83c0 path 2 ep0out
5ec2 cc 5 -- status -62
[5.789062] usb 2-2: device not accepting address 5, error -62
[5.795288] hub 2-0:1.0: unable to enumerate USB device on port 2
-
We think it may not be hardware issue, since the device gets detected on
android-3.0 kernel. The support for OHCI on OMAP4430 SDP board
seems to be missing in Linux mainline (3.6).
We ported some OMAP specific patches from android kernel, with this the
device gets detected only if it is connected at boot.
If the system is booted and then device is connected, it doesn't get detected.
Are you referring to this part of the log?
Device not getting detected when
connected---
/ # [ 135.621002] usbhs_wakeup: Enabling clocks
[ 135.625762] usbhs_runtime_resume:++
[ 135.630371] usbhs_runtime_resume:--
[ 135.638183] USB IO PAD Wakeup event triggered##
[ 135.644958] usbhs_runtime_suspend:++
[ 135.649749] usbhs_runtime_suspend:-
It appears that ohci_irq() didn't run. Did
ohci_finish_controller_resume() get called?
This function is not used in ohci-omap3.c and is used only in ohci-omap.c.
Is it necessary to call this function?
My guess is your usbhs_runtime_resume() routine has a bug. Maybe the
usbhs_runtime_suspend() routine does too.
We sometime see the crash in ohci_hub_status_data function. So, when
we add the
below check at the entry of the function, there is no crash. Please
find attached crash log.
(ohci-crash.log)
I don't understand the crash log. What is the cause of the crash? Is
there some error involving spin_lock_irqrestore() in
ohci_hub_status_data()
if (!HC_IS_RUNNING(hcd-state)) {
return 0;
}
But the device does not get detected subsequently with this change. There is
a similar check in ehci-hub.c.
No, there isn't. Not since the 3.1 kernel. In any case, ehci-hcd is
different from ohci-hcd; you shouldn't expect their hub_status_data
routines to be the same.
Ok, I understand.
Thanks,
Mohan
--
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: Problem with OHCI on OMAP4430
On Mon, 29 Oct 2012, Mohan V wrote: I'm not going to be able to help very much with an Android kernel. Does the same problem occur with a vanilla non-Android 3.6 kernel? If it doesn't, that indicates the problem was caused by some Android-specific changes. With the vanilla 3.6 kernel, the device connected to OHCI port is not even detected. The below messages are seen: [5.343780] usb 2-2: new low-speed USB device number 5 using ohci-omap3 [5.351776] ohci-omap3 ohci-omap3.0: urb ee7f83c0 path 2 ep0out 5ec2 cc 5 -- status -62 [5.570770] ohci-omap3 ohci-omap3.0: urb ee7f83c0 path 2 ep0out 5ec2 cc 5 -- status -62 [5.789062] usb 2-2: device not accepting address 5, error -62 [5.795288] hub 2-0:1.0: unable to enumerate USB device on port 2 It looks like the device was detected just fine but the host was unable to communicate with it. I don't know why; maybe a clock or power line wasn't turned on properly or a PHY wasn't enabled. We think it may not be hardware issue, since the device gets detected on android-3.0 kernel. The support for OHCI on OMAP4430 SDP board seems to be missing in Linux mainline (3.6). We ported some OMAP specific patches from android kernel, with this the device gets detected only if it is connected at boot. If the system is booted and then device is connected, it doesn't get detected. Doesn't get detected, or does get detected but then doesn't communicate? Perhaps you should send some questions to the maintainers of the various ohci-omap drivers or the Android maintainers. Are you referring to this part of the log? Device not getting detected when connected--- / # [ 135.621002] usbhs_wakeup: Enabling clocks [ 135.625762] usbhs_runtime_resume:++ [ 135.630371] usbhs_runtime_resume:-- [ 135.638183] USB IO PAD Wakeup event triggered## [ 135.644958] usbhs_runtime_suspend:++ [ 135.649749] usbhs_runtime_suspend:- It appears that ohci_irq() didn't run. Did ohci_finish_controller_resume() get called? This function is not used in ohci-omap3.c and is used only in ohci-omap.c. Is it necessary to call this function? It is necessary if the driver supports suspend/resume. As far as I can tell, the ohci-omap3 driver does not have this support (at least, not in the 3.6 kernel) whereas the ohci-omap driver does. What driver produced the usbhs_runtime_suspend and usbhs_runtime_resume messages above? (No such messages are present in ohci-omap3.c.) Apparently that driver _does_ support suspend/resume. Alan Stern -- 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: Problem with OHCI on OMAP4430
On Fri, 26 Oct 2012, Mohan V wrote:
When the USB bus is in suspend, a device connected to OHCI port does
not get detected, whereas the device connected to EHCI port is getting
detected.
Can you provide a dmesg log showing the OHCI problem with
CONFIG_USB_DEBUG enabled?
Please find the attached log (ohci-detect.log), where the device is
disconnected from the
OHCI port and then does not get detected when connected again.
We are using android 3.0 kernel.
I'm not going to be able to help very much with an Android kernel.
Does the same problem occur with a vanilla non-Android 3.6 kernel? If
it doesn't, that indicates the problem was caused by some
Android-specific changes.
Are you referring to this part of the log?
Device not getting detected when
connected---
/ # [ 135.621002] usbhs_wakeup: Enabling clocks
[ 135.625762] usbhs_runtime_resume:++
[ 135.630371] usbhs_runtime_resume:--
[ 135.638183] USB IO PAD Wakeup event triggered##
[ 135.644958] usbhs_runtime_suspend:++
[ 135.649749] usbhs_runtime_suspend:-
It appears that ohci_irq() didn't run. Did
ohci_finish_controller_resume() get called?
My guess is your usbhs_runtime_resume() routine has a bug. Maybe the
usbhs_runtime_suspend() routine does too.
We sometime see the crash in ohci_hub_status_data function. So, when
we add the
below check at the entry of the function, there is no crash. Please
find attached crash log.
(ohci-crash.log)
I don't understand the crash log. What is the cause of the crash? Is
there some error involving spin_lock_irqrestore() in
ohci_hub_status_data()
if (!HC_IS_RUNNING(hcd-state)) {
return 0;
}
But the device does not get detected subsequently with this change. There is
a similar check in ehci-hub.c.
No, there isn't. Not since the 3.1 kernel. In any case, ehci-hcd is
different from ohci-hcd; you shouldn't expect their hub_status_data
routines to be the same.
Alan Stern
--
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
