Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue
Hi, On 06/22/2012 05:43 PM, Munegowda, Keshava wrote: On Fri, Jun 22, 2012 at 7:41 PM, Kevin Hilman khil...@ti.com wrote: Munegowda, Keshava keshava_mgo...@ti.com writes: [...] You are not reading what I write. To repeat: your patch fixes the oops during boot, and the suspend hang and now I see CORE hit retention in *suspend*. thanks ! However, CORE does still not hit retention during *idle*. here is the problem. usb host retention in idle is not supported till now. in current code, usb host cuts clock only in driver suspend not in bus suspend ( auto suspend). usb host driver need to use the io daisy chain framework through io wakeup. I will post the patches once ehci remote wakeup features stabilized in omap3, omap4 and omap5 too. We are talking about CORE retention support during idle. How is IO daisy chaining related to that? Doesn't IO daisy chain only apply when device hits OFF? regards, -roger -- 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
On Mon, Jul 23, 2012 at 2:03 PM, Roger Quadros rog...@ti.com wrote: Hi, On 06/22/2012 05:43 PM, Munegowda, Keshava wrote: On Fri, Jun 22, 2012 at 7:41 PM, Kevin Hilman khil...@ti.com wrote: Munegowda, Keshava keshava_mgo...@ti.com writes: [...] You are not reading what I write. To repeat: your patch fixes the oops during boot, and the suspend hang and now I see CORE hit retention in *suspend*. thanks ! However, CORE does still not hit retention during *idle*. here is the problem. usb host retention in idle is not supported till now. in current code, usb host cuts clock only in driver suspend not in bus suspend ( auto suspend). usb host driver need to use the io daisy chain framework through io wakeup. I will post the patches once ehci remote wakeup features stabilized in omap3, omap4 and omap5 too. We are talking about CORE retention support during idle. How is IO daisy chaining related to that? Doesn't IO daisy chain only apply when device hits OFF? when we see the usb bus suspend, then we disable the clocks of usb host to enable to enable the retention in cpu idle; since we have disabled the clock of usb host , we will not see the device connection at the controller level, instead the irq chain handler can detect it and corresponding irq can set the clocks. this same use case holds good for device OFF too. regards keshava -- 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
On Fri, Jul 20, 2012 at 4:25 AM, Greg KH gre...@linuxfoundation.org wrote: On Thu, Jul 19, 2012 at 03:54:05PM -0700, Greg KH wrote: On Thu, Jul 19, 2012 at 01:20:14PM +0300, Felipe Balbi wrote: Hi, On Thu, Jun 21, 2012 at 07:12:12PM +0530, Keshava Munegowda wrote: This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) is causing the usb hub and device detection fails in beagle XM causeing NFS not functional. This affects the core retention too. The same commit logic needs to be revisted adhering to hwmod and device tree framework. for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) reverted. This patch is validated on BeagleXM with NFS support over usb ethernet and USB mass storage and other device detection. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Acked-by: Felipe Balbi ba...@ti.com turns out this is causing other issues and another version of the patch will be provided. Greg, Alan, this is basically a git revert of the commit id listed above. Ok, I'll queue it up for 3.6-rc1 and add a -stable mark to it to get into 3.5.1, ok? Hm, that doesn't work as it doesn't apply to my tree :( Can someone please update this against usb-next and send it to me? Felipe? Hi Greg yes, I will do this I will send the v2 of this patch ASAP regards keshava -- 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
On Thu, Jul 12, 2012 at 12:11 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Wed, Jul 11, 2012 at 7:53 PM, Kevin Hilman khil...@ti.com wrote: Munegowda, Keshava keshava_mgo...@ti.com writes: On Wed, Jul 11, 2012 at 3:59 PM, Samuel Ortiz sa...@linux.intel.com wrote: Hi Keshava, Kevin, On Fri, Jul 06, 2012 at 05:29:00PM +0530, Munegowda, Keshava wrote: Samuel I have sent that patch to disable the ehci in omap2plus_defconfig; after merging that please merge this patch too. This will fix the crashes in during boot with NFS in beagleXM I'm going to apply and push this patch for 3.5, and the defconfig patch can be pushed through Tony's tree. Kevin, could you please ACK it ? Cheers, Samuel. Thanks Samuel Kevin, need your ack for this. You never answered earlier questions from myself or Russ Dill about the more targetted patches from Russ: ARM: OMAP: USB: Fixup ehci_hcd_omap_probe error path Fix OMAP EHCI suspend/resume failure (i693) '354ab856' causes Also, your current $SUBJECT patch is large and not well described. e.g. what is not correct and why. Why does it fix the problems mentioned? The original changelog mentions the core retention issue but this patch does nothing to address that. If you want an Ack from me, especially because I'm not an expert in this IP, you'll have to describe things in a way that I can understand. IMO, at this point of the dev cycle (trying to stabilize v3.5), the full cleanup/fix of this feature will need to be done for v3.6. For v3.5, I think the two patches from Russ Dill should be merged. They are targetted fixes and very well described. Kevin Hi Kevin The usb2 host of omap3/4/5 silicons has the following ips 1. UHH ( /drivers/mfd/omap-usb-host.c ) -- platform driver 2. TLL( /drivers/mfd/omap-usb-host.c ) 3. ehci( /drivers/usb/host/ehci-omap.c) - platform driver 4. ohci ( /drivers/usb/host/ohci-omap3.c ) - platform drivers The 3 platform drivers exists to make the ehci/ohci functional. The UHH-TLL or usb host core driver is the parent platform driver of ehci and ohci. This parent driver doe the clock enable/disable which common for both ehci and ohci. takes care of common port setting and clocks during suspend and resume and ensures that there is no overwrites by ehci and ohci platform drivers. The commit id 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) was handling the clocks in the ehci driver it self, instead it should be handled by usb host core driver as per above explanation. so, the UHH-TLL Driver should handle the changes done by 354ab8567ae3107a8cbe7228c3181990ba598aac. hence this patch removes the changed done by the commit id 354ab8567ae3107a8cbe7228c3181990ba598aac suppose if this patch is not included, then it will cause the following two problems 1. crash during the system boot - observed in beagle xm , with NFS file system the Ethernet is through ehci driver , since the ehci ports clocks are not handled properly by this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac, it leads to crash 2. crash during suspend/resume - observed in beagle xm with ram fs if the ehci is driver is included and if it tries to suspend it leads to crash regards keshava hi Felipe I request you to ack this patch; this will enable the boot issue in beagle xm with NFS. I will rework the patch with commit id 354ab8567ae3107a8cbe7228c3181990ba598aac by Anand gadiyar after the TLL driver gets merged. regards keshava -- 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
Hi, On Thu, Jun 21, 2012 at 07:12:12PM +0530, Keshava Munegowda wrote: This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) is causing the usb hub and device detection fails in beagle XM causeing NFS not functional. This affects the core retention too. The same commit logic needs to be revisted adhering to hwmod and device tree framework. for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) reverted. This patch is validated on BeagleXM with NFS support over usb ethernet and USB mass storage and other device detection. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Acked-by: Felipe Balbi ba...@ti.com turns out this is causing other issues and another version of the patch will be provided. Greg, Alan, this is basically a git revert of the commit id listed above. -- balbi signature.asc Description: Digital signature
Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue
On Thu, Jul 19, 2012 at 3:50 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Thu, Jun 21, 2012 at 07:12:12PM +0530, Keshava Munegowda wrote: This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) is causing the usb hub and device detection fails in beagle XM causeing NFS not functional. This affects the core retention too. The same commit logic needs to be revisted adhering to hwmod and device tree framework. for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) reverted. This patch is validated on BeagleXM with NFS support over usb ethernet and USB mass storage and other device detection. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Acked-by: Felipe Balbi ba...@ti.com turns out this is causing other issues and another version of the patch will be provided. Greg, Alan, this is basically a git revert of the commit id listed above. -- balbi Thanks Felipe regards keshava -- 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
On Thu, 19 Jul 2012, Felipe Balbi wrote: Hi, On Thu, Jun 21, 2012 at 07:12:12PM +0530, Keshava Munegowda wrote: This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) is causing the usb hub and device detection fails in beagle XM causeing NFS not functional. This affects the core retention too. The same commit logic needs to be revisted adhering to hwmod and device tree framework. for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) reverted. This patch is validated on BeagleXM with NFS support over usb ethernet and USB mass storage and other device detection. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Acked-by: Felipe Balbi ba...@ti.com turns out this is causing other issues and another version of the patch will be provided. Greg, Alan, this is basically a git revert of the commit id listed above. I have no objection to reverting the patch. But on a related note, have you had a chance to read my comment: http://marc.info/?l=linux-usbm=134098423528415w=2 ? 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: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue
On Thu, Jul 19, 2012 at 01:20:14PM +0300, Felipe Balbi wrote: Hi, On Thu, Jun 21, 2012 at 07:12:12PM +0530, Keshava Munegowda wrote: This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) is causing the usb hub and device detection fails in beagle XM causeing NFS not functional. This affects the core retention too. The same commit logic needs to be revisted adhering to hwmod and device tree framework. for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) reverted. This patch is validated on BeagleXM with NFS support over usb ethernet and USB mass storage and other device detection. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Acked-by: Felipe Balbi ba...@ti.com turns out this is causing other issues and another version of the patch will be provided. Greg, Alan, this is basically a git revert of the commit id listed above. Ok, I'll queue it up for 3.6-rc1 and add a -stable mark to it to get into 3.5.1, ok? thanks, greg k-h -- 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
On Thu, Jul 19, 2012 at 03:54:05PM -0700, Greg KH wrote: On Thu, Jul 19, 2012 at 01:20:14PM +0300, Felipe Balbi wrote: Hi, On Thu, Jun 21, 2012 at 07:12:12PM +0530, Keshava Munegowda wrote: This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) is causing the usb hub and device detection fails in beagle XM causeing NFS not functional. This affects the core retention too. The same commit logic needs to be revisted adhering to hwmod and device tree framework. for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) reverted. This patch is validated on BeagleXM with NFS support over usb ethernet and USB mass storage and other device detection. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Acked-by: Felipe Balbi ba...@ti.com turns out this is causing other issues and another version of the patch will be provided. Greg, Alan, this is basically a git revert of the commit id listed above. Ok, I'll queue it up for 3.6-rc1 and add a -stable mark to it to get into 3.5.1, ok? Hm, that doesn't work as it doesn't apply to my tree :( Can someone please update this against usb-next and send it to me? Felipe? thanks, greg k-h -- 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
On Wed, Jul 11, 2012 at 7:53 PM, Kevin Hilman khil...@ti.com wrote: Munegowda, Keshava keshava_mgo...@ti.com writes: On Wed, Jul 11, 2012 at 3:59 PM, Samuel Ortiz sa...@linux.intel.com wrote: Hi Keshava, Kevin, On Fri, Jul 06, 2012 at 05:29:00PM +0530, Munegowda, Keshava wrote: Samuel I have sent that patch to disable the ehci in omap2plus_defconfig; after merging that please merge this patch too. This will fix the crashes in during boot with NFS in beagleXM I'm going to apply and push this patch for 3.5, and the defconfig patch can be pushed through Tony's tree. Kevin, could you please ACK it ? Cheers, Samuel. Thanks Samuel Kevin, need your ack for this. You never answered earlier questions from myself or Russ Dill about the more targetted patches from Russ: ARM: OMAP: USB: Fixup ehci_hcd_omap_probe error path Fix OMAP EHCI suspend/resume failure (i693) '354ab856' causes Also, your current $SUBJECT patch is large and not well described. e.g. what is not correct and why. Why does it fix the problems mentioned? The original changelog mentions the core retention issue but this patch does nothing to address that. If you want an Ack from me, especially because I'm not an expert in this IP, you'll have to describe things in a way that I can understand. IMO, at this point of the dev cycle (trying to stabilize v3.5), the full cleanup/fix of this feature will need to be done for v3.6. For v3.5, I think the two patches from Russ Dill should be merged. They are targetted fixes and very well described. Kevin Hi Kevin The usb2 host of omap3/4/5 silicons has the following ips 1. UHH ( /drivers/mfd/omap-usb-host.c ) -- platform driver 2. TLL( /drivers/mfd/omap-usb-host.c ) 3. ehci( /drivers/usb/host/ehci-omap.c) - platform driver 4. ohci ( /drivers/usb/host/ohci-omap3.c ) - platform drivers The 3 platform drivers exists to make the ehci/ohci functional. The UHH-TLL or usb host core driver is the parent platform driver of ehci and ohci. This parent driver doe the clock enable/disable which common for both ehci and ohci. takes care of common port setting and clocks during suspend and resume and ensures that there is no overwrites by ehci and ohci platform drivers. The commit id 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) was handling the clocks in the ehci driver it self, instead it should be handled by usb host core driver as per above explanation. so, the UHH-TLL Driver should handle the changes done by 354ab8567ae3107a8cbe7228c3181990ba598aac. hence this patch removes the changed done by the commit id 354ab8567ae3107a8cbe7228c3181990ba598aac suppose if this patch is not included, then it will cause the following two problems 1. crash during the system boot - observed in beagle xm , with NFS file system the Ethernet is through ehci driver , since the ehci ports clocks are not handled properly by this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac, it leads to crash 2. crash during suspend/resume - observed in beagle xm with ram fs if the ehci is driver is included and if it tries to suspend it leads to crash regards keshava -- 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
Hi Keshava, Kevin, On Fri, Jul 06, 2012 at 05:29:00PM +0530, Munegowda, Keshava wrote: Samuel I have sent that patch to disable the ehci in omap2plus_defconfig; after merging that please merge this patch too. This will fix the crashes in during boot with NFS in beagleXM I'm going to apply and push this patch for 3.5, and the defconfig patch can be pushed through Tony's tree. Kevin, could you please ACK it ? Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
On Wed, Jul 11, 2012 at 3:59 PM, Samuel Ortiz sa...@linux.intel.com wrote: Hi Keshava, Kevin, On Fri, Jul 06, 2012 at 05:29:00PM +0530, Munegowda, Keshava wrote: Samuel I have sent that patch to disable the ehci in omap2plus_defconfig; after merging that please merge this patch too. This will fix the crashes in during boot with NFS in beagleXM I'm going to apply and push this patch for 3.5, and the defconfig patch can be pushed through Tony's tree. Kevin, could you please ACK it ? Cheers, Samuel. Thanks Samuel Kevin, need your ack for this. The commit id 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693), is handling the clocks in ehci driver which is not correct, it will be through the usb host driver ( /mfd/omap-usb_host.c ) exporting APIs to ehci driver to handler the port clocks. for now, this patch is necessary to remove the commit id 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693), regards keshava -- 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
Munegowda, Keshava keshava_mgo...@ti.com writes: On Wed, Jul 11, 2012 at 3:59 PM, Samuel Ortiz sa...@linux.intel.com wrote: Hi Keshava, Kevin, On Fri, Jul 06, 2012 at 05:29:00PM +0530, Munegowda, Keshava wrote: Samuel I have sent that patch to disable the ehci in omap2plus_defconfig; after merging that please merge this patch too. This will fix the crashes in during boot with NFS in beagleXM I'm going to apply and push this patch for 3.5, and the defconfig patch can be pushed through Tony's tree. Kevin, could you please ACK it ? Cheers, Samuel. Thanks Samuel Kevin, need your ack for this. You never answered earlier questions from myself or Russ Dill about the more targetted patches from Russ: ARM: OMAP: USB: Fixup ehci_hcd_omap_probe error path Fix OMAP EHCI suspend/resume failure (i693) '354ab856' causes Also, your current $SUBJECT patch is large and not well described. e.g. what is not correct and why. Why does it fix the problems mentioned? The original changelog mentions the core retention issue but this patch does nothing to address that. If you want an Ack from me, especially because I'm not an expert in this IP, you'll have to describe things in a way that I can understand. IMO, at this point of the dev cycle (trying to stabilize v3.5), the full cleanup/fix of this feature will need to be done for v3.6. For v3.5, I think the two patches from Russ Dill should be merged. They are targetted fixes and very well described. Kevin The commit id 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693), is handling the clocks in ehci driver which is not correct, it will be through the usb host driver ( /mfd/omap-usb_host.c ) exporting APIs to ehci driver to handler the port clocks. for now, this patch is necessary to remove the commit id 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693), regards keshava -- 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
On Thu, Jul 5, 2012 at 4:49 PM, Samuel Ortiz sa...@linux.intel.com wrote: Hi Kevin, Keshava, On Wed, Jul 04, 2012 at 06:33:35AM -0700, Kevin Hilman wrote: Munegowda, Keshava keshava_mgo...@ti.com writes: On Tue, Jul 3, 2012 at 12:17 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Mon, Jul 2, 2012 at 10:24 PM, Kevin Hilman khil...@ti.com wrote: Felipe, Keshava, Kevin Hilman khil...@ti.com writes: Felipe Balbi ba...@ti.com writes: [...] Keshava is reverting a fix for a HW errata. I can't accept it as it will cause regressions. Granted, regression by regression, there's no change, but I simply can't knowingly cause a regression to the driver just to have PM working. We need a real fix for this issue. Sure, as long as there is a fix in this -rc cycle. This driver intoduced changes in v3.5 that break PM for the whole SoC (by preventing CORE retention.) These changes were clearly not tested with PM. If you cannot fix this during the -rc cycle, then you need to revert the driver PM changes that broke PM for the *whole* SoC. What's the status of this regression? This is still broken in v3.5-rc and is preventing CORE retention for the *whole* SoC. Please fix this, either with a proper fix, or a revert for 3.5-rc. The proper fix for this is implement ion of ehci remote wakeup through I/O chain handler; it takes time. As Felipe also mentioned, This patch is OK for now. Sorry, Felipe still insist not to revert this patch, but to change this patch requires quite more changes in the usbhs core and we need to see the how the hub control changes need to be brought in to usbhs core. so , reverting is the best solution to time being. Its observed that ehci was enabled after linux kernal version 3.3 ; before that even though driver was there the ehci deriver was disabled by defaults; and it is expected the people who want to use NFS then can enable it explicitly. so, the solution is 1. Use this patch ( reverting the hw errata ) to fix the NFS Boot and suspend/resume crash Or, use the patches from Russ Dill where were more targetted fixes. Either way, I'm OK with that. Keshava, I'll wait for your decision here to know which patch you want me to take. 2. Disable the ehci driver to make the pm work in idle case ; This configuration should exist till the ehci remote wakeup implementation completes. Yes. Please disabled it by default. Until PM in this driver can work without breaking PM for the whole SoC, it should remain disabled. So, I should expect another patch here as well. FYI, I was planning to send a pull request for MFD 3.5 fixes to Linus tomorrow, but I'll wait for you. Hopefully I should be able to send it on Monday. Cheers, Samuel. Thanks Samuel I will send the patches today. regards keshava -- 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
On Fri, Jul 6, 2012 at 3:30 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Thu, Jul 5, 2012 at 4:49 PM, Samuel Ortiz sa...@linux.intel.com wrote: Hi Kevin, Keshava, On Wed, Jul 04, 2012 at 06:33:35AM -0700, Kevin Hilman wrote: Munegowda, Keshava keshava_mgo...@ti.com writes: On Tue, Jul 3, 2012 at 12:17 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Mon, Jul 2, 2012 at 10:24 PM, Kevin Hilman khil...@ti.com wrote: Felipe, Keshava, Kevin Hilman khil...@ti.com writes: Felipe Balbi ba...@ti.com writes: [...] Keshava is reverting a fix for a HW errata. I can't accept it as it will cause regressions. Granted, regression by regression, there's no change, but I simply can't knowingly cause a regression to the driver just to have PM working. We need a real fix for this issue. Sure, as long as there is a fix in this -rc cycle. This driver intoduced changes in v3.5 that break PM for the whole SoC (by preventing CORE retention.) These changes were clearly not tested with PM. If you cannot fix this during the -rc cycle, then you need to revert the driver PM changes that broke PM for the *whole* SoC. What's the status of this regression? This is still broken in v3.5-rc and is preventing CORE retention for the *whole* SoC. Please fix this, either with a proper fix, or a revert for 3.5-rc. The proper fix for this is implement ion of ehci remote wakeup through I/O chain handler; it takes time. As Felipe also mentioned, This patch is OK for now. Sorry, Felipe still insist not to revert this patch, but to change this patch requires quite more changes in the usbhs core and we need to see the how the hub control changes need to be brought in to usbhs core. so , reverting is the best solution to time being. Its observed that ehci was enabled after linux kernal version 3.3 ; before that even though driver was there the ehci deriver was disabled by defaults; and it is expected the people who want to use NFS then can enable it explicitly. so, the solution is 1. Use this patch ( reverting the hw errata ) to fix the NFS Boot and suspend/resume crash Or, use the patches from Russ Dill where were more targetted fixes. Either way, I'm OK with that. Keshava, I'll wait for your decision here to know which patch you want me to take. 2. Disable the ehci driver to make the pm work in idle case ; This configuration should exist till the ehci remote wakeup implementation completes. Yes. Please disabled it by default. Until PM in this driver can work without breaking PM for the whole SoC, it should remain disabled. So, I should expect another patch here as well. FYI, I was planning to send a pull request for MFD 3.5 fixes to Linus tomorrow, but I'll wait for you. Hopefully I should be able to send it on Monday. Cheers, Samuel. Thanks Samuel I will send the patches today. regards keshava Samuel I have sent that patch to disable the ehci in omap2plus_defconfig; after merging that please merge this patch too. This will fix the crashes in during boot with NFS in beagleXM regards keshava -- 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
Hi Kevin, Keshava, On Wed, Jul 04, 2012 at 06:33:35AM -0700, Kevin Hilman wrote: Munegowda, Keshava keshava_mgo...@ti.com writes: On Tue, Jul 3, 2012 at 12:17 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Mon, Jul 2, 2012 at 10:24 PM, Kevin Hilman khil...@ti.com wrote: Felipe, Keshava, Kevin Hilman khil...@ti.com writes: Felipe Balbi ba...@ti.com writes: [...] Keshava is reverting a fix for a HW errata. I can't accept it as it will cause regressions. Granted, regression by regression, there's no change, but I simply can't knowingly cause a regression to the driver just to have PM working. We need a real fix for this issue. Sure, as long as there is a fix in this -rc cycle. This driver intoduced changes in v3.5 that break PM for the whole SoC (by preventing CORE retention.) These changes were clearly not tested with PM. If you cannot fix this during the -rc cycle, then you need to revert the driver PM changes that broke PM for the *whole* SoC. What's the status of this regression? This is still broken in v3.5-rc and is preventing CORE retention for the *whole* SoC. Please fix this, either with a proper fix, or a revert for 3.5-rc. The proper fix for this is implement ion of ehci remote wakeup through I/O chain handler; it takes time. As Felipe also mentioned, This patch is OK for now. Sorry, Felipe still insist not to revert this patch, but to change this patch requires quite more changes in the usbhs core and we need to see the how the hub control changes need to be brought in to usbhs core. so , reverting is the best solution to time being. Its observed that ehci was enabled after linux kernal version 3.3 ; before that even though driver was there the ehci deriver was disabled by defaults; and it is expected the people who want to use NFS then can enable it explicitly. so, the solution is 1. Use this patch ( reverting the hw errata ) to fix the NFS Boot and suspend/resume crash Or, use the patches from Russ Dill where were more targetted fixes. Either way, I'm OK with that. Keshava, I'll wait for your decision here to know which patch you want me to take. 2. Disable the ehci driver to make the pm work in idle case ; This configuration should exist till the ehci remote wakeup implementation completes. Yes. Please disabled it by default. Until PM in this driver can work without breaking PM for the whole SoC, it should remain disabled. So, I should expect another patch here as well. FYI, I was planning to send a pull request for MFD 3.5 fixes to Linus tomorrow, but I'll wait for you. Hopefully I should be able to send it on Monday. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
Munegowda, Keshava keshava_mgo...@ti.com writes: On Tue, Jul 3, 2012 at 12:17 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Mon, Jul 2, 2012 at 10:24 PM, Kevin Hilman khil...@ti.com wrote: Felipe, Keshava, Kevin Hilman khil...@ti.com writes: Felipe Balbi ba...@ti.com writes: [...] Keshava is reverting a fix for a HW errata. I can't accept it as it will cause regressions. Granted, regression by regression, there's no change, but I simply can't knowingly cause a regression to the driver just to have PM working. We need a real fix for this issue. Sure, as long as there is a fix in this -rc cycle. This driver intoduced changes in v3.5 that break PM for the whole SoC (by preventing CORE retention.) These changes were clearly not tested with PM. If you cannot fix this during the -rc cycle, then you need to revert the driver PM changes that broke PM for the *whole* SoC. What's the status of this regression? This is still broken in v3.5-rc and is preventing CORE retention for the *whole* SoC. Please fix this, either with a proper fix, or a revert for 3.5-rc. The proper fix for this is implement ion of ehci remote wakeup through I/O chain handler; it takes time. As Felipe also mentioned, This patch is OK for now. Sorry, Felipe still insist not to revert this patch, but to change this patch requires quite more changes in the usbhs core and we need to see the how the hub control changes need to be brought in to usbhs core. so , reverting is the best solution to time being. Its observed that ehci was enabled after linux kernal version 3.3 ; before that even though driver was there the ehci deriver was disabled by defaults; and it is expected the people who want to use NFS then can enable it explicitly. so, the solution is 1. Use this patch ( reverting the hw errata ) to fix the NFS Boot and suspend/resume crash Or, use the patches from Russ Dill where were more targetted fixes. Either way, I'm OK with that. 2. Disable the ehci driver to make the pm work in idle case ; This configuration should exist till the ehci remote wakeup implementation completes. Yes. Please disabled it by default. Until PM in this driver can work without breaking PM for the whole SoC, it should remain disabled. Please queue up all of these fixes ASAP for the v3.5 Kevin -- 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
On Tue, Jul 3, 2012 at 5:44 AM, Kevin Hilman khil...@ti.com wrote: Kevin Hilman khil...@ti.com writes: Felipe, Keshava, Kevin Hilman khil...@ti.com writes: Felipe Balbi ba...@ti.com writes: [...] Keshava is reverting a fix for a HW errata. I can't accept it as it will cause regressions. Granted, regression by regression, there's no change, but I simply can't knowingly cause a regression to the driver just to have PM working. We need a real fix for this issue. Sure, as long as there is a fix in this -rc cycle. This driver intoduced changes in v3.5 that break PM for the whole SoC (by preventing CORE retention.) These changes were clearly not tested with PM. If you cannot fix this during the -rc cycle, then you need to revert the driver PM changes that broke PM for the *whole* SoC. What's the status of this regression? This is still broken in v3.5-rc and is preventing CORE retention for the *whole* SoC. Please fix this, either with a proper fix, or a revert for 3.5-rc. BTW, a related issue with this driver (but not sure it's a regression) is that USB ethernet does not seem to survive a suspend/resume. If I'm using a NFS rootfs, after suspend/resume, the NFS servers stops responding, and I get these errors: nfs: server X.X.X.X not responding, still trying This issue because of two issues: 1. The phy goes to bad state and ehci ports goes out the suspend Fix was made by resetting the phy and re-power the ehci ports; but Alan has commented on this. it stil requires a reworks 2. The usb-serial driver does not have reset-resume, so it gets the different ip address but NFS wont be functional nothing can be done in the ehci driver, debugging is requried at usb serial driver. regards keshava -- 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
On Mon, Jul 2, 2012 at 10:24 PM, Kevin Hilman khil...@ti.com wrote: Felipe, Keshava, Kevin Hilman khil...@ti.com writes: Felipe Balbi ba...@ti.com writes: [...] Keshava is reverting a fix for a HW errata. I can't accept it as it will cause regressions. Granted, regression by regression, there's no change, but I simply can't knowingly cause a regression to the driver just to have PM working. We need a real fix for this issue. Sure, as long as there is a fix in this -rc cycle. This driver intoduced changes in v3.5 that break PM for the whole SoC (by preventing CORE retention.) These changes were clearly not tested with PM. If you cannot fix this during the -rc cycle, then you need to revert the driver PM changes that broke PM for the *whole* SoC. What's the status of this regression? This is still broken in v3.5-rc and is preventing CORE retention for the *whole* SoC. Please fix this, either with a proper fix, or a revert for 3.5-rc. The proper fix for this is implement ion of ehci remote wakeup through I/O chain handler; it takes time. As Felipe also mentioned, This patch is OK for now. -- 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
On Tue, Jul 3, 2012 at 12:17 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Mon, Jul 2, 2012 at 10:24 PM, Kevin Hilman khil...@ti.com wrote: Felipe, Keshava, Kevin Hilman khil...@ti.com writes: Felipe Balbi ba...@ti.com writes: [...] Keshava is reverting a fix for a HW errata. I can't accept it as it will cause regressions. Granted, regression by regression, there's no change, but I simply can't knowingly cause a regression to the driver just to have PM working. We need a real fix for this issue. Sure, as long as there is a fix in this -rc cycle. This driver intoduced changes in v3.5 that break PM for the whole SoC (by preventing CORE retention.) These changes were clearly not tested with PM. If you cannot fix this during the -rc cycle, then you need to revert the driver PM changes that broke PM for the *whole* SoC. What's the status of this regression? This is still broken in v3.5-rc and is preventing CORE retention for the *whole* SoC. Please fix this, either with a proper fix, or a revert for 3.5-rc. The proper fix for this is implement ion of ehci remote wakeup through I/O chain handler; it takes time. As Felipe also mentioned, This patch is OK for now. Sorry, Felipe still insist not to revert this patch, but to change this patch requires quite more changes in the usbhs core and we need to see the how the hub control changes need to be brought in to usbhs core. so , reverting is the best solution to time being. Its observed that ehci was enabled after linux kernal version 3.3 ; before that even though driver was there the ehci deriver was disabled by defaults; and it is expected the people who want to use NFS then can enable it explicitly. so, the solution is 1. Use this patch ( reverting the hw errata ) to fix the NFS Boot and suspend/resume crash 2. Disable the ehci driver to make the pm work in idle case ; This configuration should exist till the ehci remote wakeup implementation completes. regards keshava -- 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
Felipe, Keshava, Kevin Hilman khil...@ti.com writes: Felipe Balbi ba...@ti.com writes: [...] Keshava is reverting a fix for a HW errata. I can't accept it as it will cause regressions. Granted, regression by regression, there's no change, but I simply can't knowingly cause a regression to the driver just to have PM working. We need a real fix for this issue. Sure, as long as there is a fix in this -rc cycle. This driver intoduced changes in v3.5 that break PM for the whole SoC (by preventing CORE retention.) These changes were clearly not tested with PM. If you cannot fix this during the -rc cycle, then you need to revert the driver PM changes that broke PM for the *whole* SoC. What's the status of this regression? This is still broken in v3.5-rc and is preventing CORE retention for the *whole* SoC. Please fix this, either with a proper fix, or a revert for 3.5-rc. Kevin -- 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
On Mon, Jul 2, 2012 at 9:54 AM, Kevin Hilman khil...@ti.com wrote: Felipe, Keshava, Kevin Hilman khil...@ti.com writes: Felipe Balbi ba...@ti.com writes: [...] Keshava is reverting a fix for a HW errata. I can't accept it as it will cause regressions. Granted, regression by regression, there's no change, but I simply can't knowingly cause a regression to the driver just to have PM working. We need a real fix for this issue. Sure, as long as there is a fix in this -rc cycle. This driver intoduced changes in v3.5 that break PM for the whole SoC (by preventing CORE retention.) These changes were clearly not tested with PM. If you cannot fix this during the -rc cycle, then you need to revert the driver PM changes that broke PM for the *whole* SoC. What's the status of this regression? This is still broken in v3.5-rc and is preventing CORE retention for the *whole* SoC. Please fix this, either with a proper fix, or a revert for 3.5-rc. Were you able to merge my patches that at least fix the oops on boot and get EHCI working again on omap-3xxx? -- 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
Russ Dill russ.d...@gmail.com writes: On Mon, Jul 2, 2012 at 9:54 AM, Kevin Hilman khil...@ti.com wrote: Felipe, Keshava, Kevin Hilman khil...@ti.com writes: Felipe Balbi ba...@ti.com writes: [...] Keshava is reverting a fix for a HW errata. I can't accept it as it will cause regressions. Granted, regression by regression, there's no change, but I simply can't knowingly cause a regression to the driver just to have PM working. We need a real fix for this issue. Sure, as long as there is a fix in this -rc cycle. This driver intoduced changes in v3.5 that break PM for the whole SoC (by preventing CORE retention.) These changes were clearly not tested with PM. If you cannot fix this during the -rc cycle, then you need to revert the driver PM changes that broke PM for the *whole* SoC. What's the status of this regression? This is still broken in v3.5-rc and is preventing CORE retention for the *whole* SoC. Please fix this, either with a proper fix, or a revert for 3.5-rc. Were you able to merge my patches that at least fix the oops on boot and get EHCI working again on omap-3xxx? I didn't try your patches specifically, but those are not the problems I'm most worried about. I'm mostly worried about the fact that when EHCI is enabled (and working), it prevents the CORE powerdomain from hitting retention in idle, and thus prevents the whole chip from hitting retention in idle. I'm also worried that the owners of this code are running out of time to fix these several serious regresions for v3.5. Kevin -- 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
Hi Kevin, On Mon, Jul 02, 2012 at 10:55:39AM -0700, Kevin Hilman wrote: I'm also worried that the owners of this code are running out of time to fix these several serious regresions for v3.5. FYI, I only have one omap-usb fix queued for 3.5 in my for-linus branch, see http://git.kernel.org/?p=linux/kernel/git/sameo/mfd-2.6.git;a=shortlog;h=refs/heads/for-linus Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
Kevin Hilman khil...@ti.com writes: Felipe, Keshava, Kevin Hilman khil...@ti.com writes: Felipe Balbi ba...@ti.com writes: [...] Keshava is reverting a fix for a HW errata. I can't accept it as it will cause regressions. Granted, regression by regression, there's no change, but I simply can't knowingly cause a regression to the driver just to have PM working. We need a real fix for this issue. Sure, as long as there is a fix in this -rc cycle. This driver intoduced changes in v3.5 that break PM for the whole SoC (by preventing CORE retention.) These changes were clearly not tested with PM. If you cannot fix this during the -rc cycle, then you need to revert the driver PM changes that broke PM for the *whole* SoC. What's the status of this regression? This is still broken in v3.5-rc and is preventing CORE retention for the *whole* SoC. Please fix this, either with a proper fix, or a revert for 3.5-rc. BTW, a related issue with this driver (but not sure it's a regression) is that USB ethernet does not seem to survive a suspend/resume. If I'm using a NFS rootfs, after suspend/resume, the NFS servers stops responding, and I get these errors: nfs: server X.X.X.X not responding, still trying The result is that I have to use an initramfs on BB-xM in order to do suspend/resume testing. Kevin -- 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
Felipe Balbi ba...@ti.com writes: [...] Keshava is reverting a fix for a HW errata. I can't accept it as it will cause regressions. Granted, regression by regression, there's no change, but I simply can't knowingly cause a regression to the driver just to have PM working. We need a real fix for this issue. Sure, as long as there is a fix in this -rc cycle. This driver intoduced changes in v3.5 that break PM for the whole SoC (by preventing CORE retention.) These changes were clearly not tested with PM. If you cannot fix this during the -rc cycle, then you need to revert the driver PM changes that broke PM for the *whole* SoC. Kevin -- 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
On Fri, Jun 22, 2012 at 12:32 AM, Kevin Hilman khil...@ti.com wrote: Munegowda, Keshava keshava_mgo...@ti.com writes: On Thu, Jun 21, 2012 at 7:12 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) is causing the usb hub and device detection fails in beagle XM causeing NFS not functional. This affects the core retention too. The same commit logic needs to be revisted adhering to hwmod and device tree framework. for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) reverted. This patch is validated on BeagleXM with NFS support over usb ethernet and USB mass storage and other device detection. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com [...] hi kevin here is pm count log on beagle XM with the above patch: What are you meaning to show by this log? This dump shows that neither PER or CORE are hitting retention in idle. Which sounds to me like you have not enabled UART runtime suspend: echo 3000 /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.3/power/autosuspend_delay_ms My test with your patch shows that it fixes the oops during boot, and doesn't hang during suspend, but that USB host is still preventing CORE retention during idle (after UART runtime suspend is enabled.) This happens on 3530/Overo, 3630/Beagle-xM and 3730/Overo Setting CONFIG_MFD_OMAP_USB_HOST=n allows CORE to hit retention again. Kevin Hi kevin It woks. only the log was wrong. I was using no_console_suspend in boot args. i removed it. now I can see the core retention hits with USB host in Beagle XM. below is the log: Please press Enter to activate this console. / # / # / # echo mem /sys/power/state [ 18.730499] PM: Syncing filesystems ... done. [ 18.735076] PM: Preparing system for mem sleep [ 18.777343] Freezing user space processes ... (elapsed 0.02 seconds) done. [ 18.808410] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 18.816131] PM: Entering mem sleep [ 18.819702] Suspending console(s) (use no_console_suspend to debug) [ 18.832000] usb 1-2.1: usb suspend, wakeup 0 [ 18.855285] hub 1-2:1.0: hub_suspend [ 18.855529] usb 1-2: unlink qh256-0001/dec8ca40 start 1 [1/0 us] [ 18.855957] usb 1-2: usb suspend, wakeup 0 [ 18.878417] hub 1-0:1.0: hub_suspend [ 18.878479] usb usb1: bus suspend, wakeup 0 [ 18.878479] ehci-omap ehci-omap.0: suspend root hub [ 18.991302] PM: suspend of devices complete after 161.865 msecs [ 18.993865] PM: late suspend of devices complete after 2.502 msecs [ 18.998443] PM: noirq suspend of devices complete after 4.547 msecs [ 18.998504] Disabling non-boot CPUs ... [ 19.257965] Successfully put all powerdomains to target state [ 19.260253] PM: noirq resume of devices complete after 2.105 msecs [ 19.263336] PM: early resume of devices complete after 1.739 msecs [ 19.571258] usb usb1: usb resume [ 19.571258] ehci-omap ehci-omap.0: resume root hub after power loss [ 19.614288] hub 1-0:1.0: hub_resume [ 19.614501] hub 1-0:1.0: port 2: status change [ 19.615020] hub 1-0:1.0: port 2 status . after resume, -19 [ 19.615020] usb 1-2: can't resume, status -19 [ 19.615020] hub 1-0:1.0: logical disconnect on port 2 [ 19.615600] PM: resume of devices complete after 352.111 msecs [ 19.735168] PM: Finishing wakeup. [ 19.739715] hub 1-0:1.0: state 7 ports 3 chg 0004 evt [ 19.745544] hub 1-0:1.0: port 2, status , change , 12 Mb/s [ 19.752105] usb 1-2: USB disconnect, device number 2 [ 19.757385] usb 1-2.1: USB disconnect, device number 3 [ 19.762817] usb 1-2.1: unregistering device [ 19.767211] usb 1-2.1: unregistering interface 1-2.1:1.0 [ 19.783142] Restarting tasks ... done. / # [ 19.798645] usb 1-2.1: usb_disable_device nuking all URBs [ 19.813323] usb 1-2: unregistering device [ 19.817718] usb 1-2: unregistering interface 1-2:1.0 [ 19.841735] usb 1-2: usb_disable_device nuking all URBs / # [ 22.200866] hub 1-0:1.0: hub_suspend [ 22.204864] usb usb1: bus auto-suspend, wakeup 1 [ 22.209838] ehci-omap ehci-omap.0: suspend root hub / # / # / # mkdir /debug mount -t debugfs debugfs / # mount -t debugfs debugfs /debug / # / # / # echo mem /sys/power/state [ 74.603454] PM: Syncing filesystems ... done. [ 74.608215] PM: Preparing system for mem sleep [ 74.637695] Freezing user space processes ... (elapsed 0.02 seconds) done. [ 74.661132] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. [ 74.668853] PM: Entering mem sleep [ 74.672424] Suspending console(s) (use no_console_suspend to debug) [ 74.685516] usb usb1: usb auto-resume [
Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue
Hi, On Fri, Jun 22, 2012 at 01:00:39PM +0530, Munegowda, Keshava wrote: On Fri, Jun 22, 2012 at 12:32 AM, Kevin Hilman khil...@ti.com wrote: Munegowda, Keshava keshava_mgo...@ti.com writes: On Thu, Jun 21, 2012 at 7:12 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) is causing the usb hub and device detection fails in beagle XM causeing NFS not functional. This affects the core retention too. The same commit logic needs to be revisted adhering to hwmod and device tree framework. for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) reverted. This patch is validated on BeagleXM with NFS support over usb ethernet and USB mass storage and other device detection. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com [...] hi kevin here is pm count log on beagle XM with the above patch: What are you meaning to show by this log? This dump shows that neither PER or CORE are hitting retention in idle. Which sounds to me like you have not enabled UART runtime suspend: echo 3000 /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.3/power/autosuspend_delay_ms My test with your patch shows that it fixes the oops during boot, and doesn't hang during suspend, but that USB host is still preventing CORE retention during idle (after UART runtime suspend is enabled.) This happens on 3530/Overo, 3630/Beagle-xM and 3730/Overo Setting CONFIG_MFD_OMAP_USB_HOST=n allows CORE to hit retention again. Kevin Hi kevin It woks. only the log was wrong. I was using no_console_suspend in boot args. i removed it. now I can see the core retention hits with USB host in Beagle XM. below is the log: the fact is that we can't really survive without that workaround. Kevin, Paul what are the suggestions here ? We _MUST_ reparent the clock at that specific location as a HW workaround. -- balbi signature.asc Description: Digital signature
Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue
Munegowda, Keshava keshava_mgo...@ti.com writes: [...] hi kevin here is pm count log on beagle XM with the above patch: What are you meaning to show by this log? This dump shows that neither PER or CORE are hitting retention in idle. Which sounds to me like you have not enabled UART runtime suspend: echo 3000 /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.3/power/autosuspend_delay_ms My test with your patch shows that it fixes the oops during boot, and doesn't hang during suspend, but that USB host is still preventing CORE retention during idle (after UART runtime suspend is enabled.) This happens on 3530/Overo, 3630/Beagle-xM and 3730/Overo Setting CONFIG_MFD_OMAP_USB_HOST=n allows CORE to hit retention again. Kevin Hi kevin It woks. only the log was wrong. I was using no_console_suspend in boot args. i removed it. now I can see the core retention hits with USB host in Beagle XM. below is the log: You are not reading what I write. To repeat: your patch fixes the oops during boot, and the suspend hang and now I see CORE hit retention in *suspend*. However, CORE does still not hit retention during *idle*. Setting CONFIG_MFD_OMAP_USB_HOST=n allows CORE to hit retention again. Please investgate the *idle* problems caused by this driver. As I said way back in the beginning this thread. The runtime PM of this driver is leaving the device enabled. To test idle retention, ensure the UART auto-suspend is enable for all UARTS: echo 3000 /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.3/power/autosuspend_delay_ms Then wait 3 seconds and 'cat /debug/pm_debug/count'. Kevin -- 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
Felipe Balbi ba...@ti.com writes: Hi, On Fri, Jun 22, 2012 at 01:00:39PM +0530, Munegowda, Keshava wrote: On Fri, Jun 22, 2012 at 12:32 AM, Kevin Hilman khil...@ti.com wrote: Munegowda, Keshava keshava_mgo...@ti.com writes: On Thu, Jun 21, 2012 at 7:12 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) is causing the usb hub and device detection fails in beagle XM causeing NFS not functional. This affects the core retention too. The same commit logic needs to be revisted adhering to hwmod and device tree framework. for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) reverted. This patch is validated on BeagleXM with NFS support over usb ethernet and USB mass storage and other device detection. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com [...] hi kevin here is pm count log on beagle XM with the above patch: What are you meaning to show by this log? This dump shows that neither PER or CORE are hitting retention in idle. Which sounds to me like you have not enabled UART runtime suspend: echo 3000 /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.3/power/autosuspend_delay_ms My test with your patch shows that it fixes the oops during boot, and doesn't hang during suspend, but that USB host is still preventing CORE retention during idle (after UART runtime suspend is enabled.) This happens on 3530/Overo, 3630/Beagle-xM and 3730/Overo Setting CONFIG_MFD_OMAP_USB_HOST=n allows CORE to hit retention again. Kevin Hi kevin It woks. only the log was wrong. I was using no_console_suspend in boot args. i removed it. now I can see the core retention hits with USB host in Beagle XM. below is the log: the fact is that we can't really survive without that workaround. Kevin, I don't know what workaround you're talking about.Are you talking about the revert proposed in $SUBJECT patch? I don't have a problem with that revert. The problem I have is that it does not fix the problem I initially reported: USB host prevents CORE retention in *idle*. Kevin Paul what are the suggestions here ? We _MUST_ reparent the clock at that specific location as a HW workaround. -- 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
On Fri, 22 Jun 2012, Kevin Hilman wrote: As I said way back in the beginning this thread. The runtime PM of this driver is leaving the device enabled. To test idle retention, ensure the UART auto-suspend is enable for all UARTS: echo 3000 /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.3/power/autosuspend_delay_ms Then wait 3 seconds and 'cat /debug/pm_debug/count'. This is probably a foolish question, but have you checked that the power/control attribute is set to auto? 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: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue
On Fri, Jun 22, 2012 at 7:41 PM, Kevin Hilman khil...@ti.com wrote: Munegowda, Keshava keshava_mgo...@ti.com writes: [...] hi kevin here is pm count log on beagle XM with the above patch: What are you meaning to show by this log? This dump shows that neither PER or CORE are hitting retention in idle. Which sounds to me like you have not enabled UART runtime suspend: echo 3000 /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.3/power/autosuspend_delay_ms My test with your patch shows that it fixes the oops during boot, and doesn't hang during suspend, but that USB host is still preventing CORE retention during idle (after UART runtime suspend is enabled.) This happens on 3530/Overo, 3630/Beagle-xM and 3730/Overo Setting CONFIG_MFD_OMAP_USB_HOST=n allows CORE to hit retention again. Kevin Hi kevin It woks. only the log was wrong. I was using no_console_suspend in boot args. i removed it. now I can see the core retention hits with USB host in Beagle XM. below is the log: You are not reading what I write. To repeat: your patch fixes the oops during boot, and the suspend hang and now I see CORE hit retention in *suspend*. thanks ! However, CORE does still not hit retention during *idle*. here is the problem. usb host retention in idle is not supported till now. in current code, usb host cuts clock only in driver suspend not in bus suspend ( auto suspend). usb host driver need to use the io daisy chain framework through io wakeup. I will post the patches once ehci remote wakeup features stabilized in omap3, omap4 and omap5 too. regards keshava -- 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
On Fri, Jun 22, 2012 at 7:14 AM, Kevin Hilman khil...@ti.com wrote: Felipe Balbi ba...@ti.com writes: Hi, On Fri, Jun 22, 2012 at 01:00:39PM +0530, Munegowda, Keshava wrote: On Fri, Jun 22, 2012 at 12:32 AM, Kevin Hilman khil...@ti.com wrote: Munegowda, Keshava keshava_mgo...@ti.com writes: On Thu, Jun 21, 2012 at 7:12 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) is causing the usb hub and device detection fails in beagle XM causeing NFS not functional. This affects the core retention too. The same commit logic needs to be revisted adhering to hwmod and device tree framework. for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) reverted. This patch is validated on BeagleXM with NFS support over usb ethernet and USB mass storage and other device detection. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com [...] hi kevin here is pm count log on beagle XM with the above patch: What are you meaning to show by this log? This dump shows that neither PER or CORE are hitting retention in idle. Which sounds to me like you have not enabled UART runtime suspend: echo 3000 /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.3/power/autosuspend_delay_ms My test with your patch shows that it fixes the oops during boot, and doesn't hang during suspend, but that USB host is still preventing CORE retention during idle (after UART runtime suspend is enabled.) This happens on 3530/Overo, 3630/Beagle-xM and 3730/Overo Setting CONFIG_MFD_OMAP_USB_HOST=n allows CORE to hit retention again. Kevin Hi kevin It woks. only the log was wrong. I was using no_console_suspend in boot args. i removed it. now I can see the core retention hits with USB host in Beagle XM. below is the log: the fact is that we can't really survive without that workaround. Kevin, I don't know what workaround you're talking about. Are you talking about the revert proposed in $SUBJECT patch? I don't have a problem with that revert. The problem I have is that it does not fix the problem I initially reported: USB host prevents CORE retention in *idle*. I already have a pair of patches posted to linux-omap and linux that fixes the oops on boot caused by the i693 errata patch. The first fixes the bad error path that causes the oops, the second allows the dummy clocks on omap3xxx to be grabbed by the ehci-host driver as is being done with real clocks on the omap44xx. -- 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
On Fri, Jun 22, 2012 at 8:33 PM, Russ Dill russ.d...@gmail.com wrote: On Fri, Jun 22, 2012 at 7:14 AM, Kevin Hilman khil...@ti.com wrote: Felipe Balbi ba...@ti.com writes: Hi, On Fri, Jun 22, 2012 at 01:00:39PM +0530, Munegowda, Keshava wrote: On Fri, Jun 22, 2012 at 12:32 AM, Kevin Hilman khil...@ti.com wrote: Munegowda, Keshava keshava_mgo...@ti.com writes: On Thu, Jun 21, 2012 at 7:12 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) is causing the usb hub and device detection fails in beagle XM causeing NFS not functional. This affects the core retention too. The same commit logic needs to be revisted adhering to hwmod and device tree framework. for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) reverted. This patch is validated on BeagleXM with NFS support over usb ethernet and USB mass storage and other device detection. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com [...] hi kevin here is pm count log on beagle XM with the above patch: What are you meaning to show by this log? This dump shows that neither PER or CORE are hitting retention in idle. Which sounds to me like you have not enabled UART runtime suspend: echo 3000 /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.3/power/autosuspend_delay_ms My test with your patch shows that it fixes the oops during boot, and doesn't hang during suspend, but that USB host is still preventing CORE retention during idle (after UART runtime suspend is enabled.) This happens on 3530/Overo, 3630/Beagle-xM and 3730/Overo Setting CONFIG_MFD_OMAP_USB_HOST=n allows CORE to hit retention again. Kevin Hi kevin It woks. only the log was wrong. I was using no_console_suspend in boot args. i removed it. now I can see the core retention hits with USB host in Beagle XM. below is the log: the fact is that we can't really survive without that workaround. Kevin, I don't know what workaround you're talking about. Are you talking about the revert proposed in $SUBJECT patch? I don't have a problem with that revert. The problem I have is that it does not fix the problem I initially reported: USB host prevents CORE retention in *idle*. I already have a pair of patches posted to linux-omap and linux that fixes the oops on boot caused by the i693 errata patch. The first fixes the bad error path that causes the oops, the second allows the dummy clocks on omap3xxx to be grabbed by the ehci-host driver as is being done with real clocks on the omap44xx. I request please resend the patches ! cc me (keshava_mgo...@ti.com) in all your patches. regards keshava -- 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
Munegowda, Keshava keshava_mgo...@ti.com writes: On Fri, Jun 22, 2012 at 7:41 PM, Kevin Hilman khil...@ti.com wrote: Munegowda, Keshava keshava_mgo...@ti.com writes: [...] hi kevin here is pm count log on beagle XM with the above patch: What are you meaning to show by this log? This dump shows that neither PER or CORE are hitting retention in idle. Which sounds to me like you have not enabled UART runtime suspend: echo 3000 /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.3/power/autosuspend_delay_ms My test with your patch shows that it fixes the oops during boot, and doesn't hang during suspend, but that USB host is still preventing CORE retention during idle (after UART runtime suspend is enabled.) This happens on 3530/Overo, 3630/Beagle-xM and 3730/Overo Setting CONFIG_MFD_OMAP_USB_HOST=n allows CORE to hit retention again. Kevin Hi kevin It woks. only the log was wrong. I was using no_console_suspend in boot args. i removed it. now I can see the core retention hits with USB host in Beagle XM. below is the log: You are not reading what I write. To repeat: your patch fixes the oops during boot, and the suspend hang and now I see CORE hit retention in *suspend*. thanks ! However, CORE does still not hit retention during *idle*. here is the problem. usb host retention in idle is not supported till now. in current code, usb host cuts clock only in driver suspend not in bus suspend ( auto suspend). usb host driver need to use the io daisy chain framework through io wakeup. I will post the patches once ehci remote wakeup features stabilized in omap3, omap4 and omap5 too. Then I suggest you revert the changes that introduced this PM support until it is fully working. The current form of the code prevents retention for the *whole* SoC during idle because it prevents CORE retention. The PM support for this driver was clearly not fully tested and should be reverted until it can be tested and fully validated. Please revert the PM changes for v3.5-rc. Kevin -- 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
Hi, On Fri, Jun 22, 2012 at 07:14:32AM -0700, Kevin Hilman wrote: Felipe Balbi ba...@ti.com writes: Hi, On Fri, Jun 22, 2012 at 01:00:39PM +0530, Munegowda, Keshava wrote: On Fri, Jun 22, 2012 at 12:32 AM, Kevin Hilman khil...@ti.com wrote: Munegowda, Keshava keshava_mgo...@ti.com writes: On Thu, Jun 21, 2012 at 7:12 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) is causing the usb hub and device detection fails in beagle XM causeing NFS not functional. This affects the core retention too. The same commit logic needs to be revisted adhering to hwmod and device tree framework. for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) reverted. This patch is validated on BeagleXM with NFS support over usb ethernet and USB mass storage and other device detection. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com [...] hi kevin here is pm count log on beagle XM with the above patch: What are you meaning to show by this log? This dump shows that neither PER or CORE are hitting retention in idle. Which sounds to me like you have not enabled UART runtime suspend: echo 3000 /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.3/power/autosuspend_delay_ms My test with your patch shows that it fixes the oops during boot, and doesn't hang during suspend, but that USB host is still preventing CORE retention during idle (after UART runtime suspend is enabled.) This happens on 3530/Overo, 3630/Beagle-xM and 3730/Overo Setting CONFIG_MFD_OMAP_USB_HOST=n allows CORE to hit retention again. Kevin Hi kevin It woks. only the log was wrong. I was using no_console_suspend in boot args. i removed it. now I can see the core retention hits with USB host in Beagle XM. below is the log: the fact is that we can't really survive without that workaround. Kevin, I don't know what workaround you're talking about.Are you talking about the revert proposed in $SUBJECT patch? I don't have a problem with that revert. The problem I have is that it does not fix the problem I initially reported: USB host prevents CORE retention in *idle*. Keshava is reverting a fix for a HW errata. I can't accept it as it will cause regressions. Granted, regression by regression, there's no change, but I simply can't knowingly cause a regression to the driver just to have PM working. We need a real fix for this issue. -- balbi signature.asc Description: Digital signature
[PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue
This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled
Fix OMAP EHCI suspend/resume failure (i693) is causing
the usb hub and device detection fails in beagle XM
causeing NFS not functional. This affects the core retention too.
The same commit logic needs to be revisted adhering to hwmod and
device tree framework.
for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac
titled Fix OMAP EHCI suspend/resume failure (i693) reverted.
This patch is validated on BeagleXM with NFS support over
usb ethernet and USB mass storage and other device detection.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
drivers/usb/host/ehci-omap.c | 164 +-
1 file changed, 1 insertion(+), 163 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 17cfb8a..272e661 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -56,15 +56,6 @@
#defineEHCI_INSNREG05_ULPI_EXTREGADD_SHIFT 8
#defineEHCI_INSNREG05_ULPI_WRDATA_SHIFT0
-/* Errata i693 */
-static struct clk *utmi_p1_fck;
-static struct clk *utmi_p2_fck;
-static struct clk *xclk60mhsp1_ck;
-static struct clk *xclk60mhsp2_ck;
-static struct clk *usbhost_p1_fck;
-static struct clk *usbhost_p2_fck;
-static struct clk *init_60m_fclk;
-
/*-*/
static const struct hc_driver ehci_omap_hc_driver;
@@ -80,40 +71,6 @@ static inline u32 ehci_read(void __iomem *base, u32 reg)
return __raw_readl(base + reg);
}
-/* Erratum i693 workaround sequence */
-static void omap_ehci_erratum_i693(struct ehci_hcd *ehci)
-{
- int ret = 0;
-
- /* Switch to the internal 60 MHz clock */
- ret = clk_set_parent(utmi_p1_fck, init_60m_fclk);
- if (ret != 0)
- ehci_err(ehci, init_60m_fclk set parent
- failed error:%d\n, ret);
-
- ret = clk_set_parent(utmi_p2_fck, init_60m_fclk);
- if (ret != 0)
- ehci_err(ehci, init_60m_fclk set parent
- failed error:%d\n, ret);
-
- clk_enable(usbhost_p1_fck);
- clk_enable(usbhost_p2_fck);
-
- /* Wait 1ms and switch back to the external clock */
- mdelay(1);
- ret = clk_set_parent(utmi_p1_fck, xclk60mhsp1_ck);
- if (ret != 0)
- ehci_err(ehci, xclk60mhsp1_ck set parent
- failed error:%d\n, ret);
-
- ret = clk_set_parent(utmi_p2_fck, xclk60mhsp2_ck);
- if (ret != 0)
- ehci_err(ehci, xclk60mhsp2_ck set parent
- failed error:%d\n, ret);
-
- clk_disable(usbhost_p1_fck);
- clk_disable(usbhost_p2_fck);
-}
static void omap_ehci_soft_phy_reset(struct platform_device *pdev, u8 port)
{
@@ -145,50 +102,6 @@ static void omap_ehci_soft_phy_reset(struct
platform_device *pdev, u8 port)
}
}
-static int omap_ehci_hub_control(
- struct usb_hcd *hcd,
- u16 typeReq,
- u16 wValue,
- u16 wIndex,
- char*buf,
- u16 wLength
-)
-{
- struct ehci_hcd *ehci = hcd_to_ehci(hcd);
- u32 __iomem *status_reg = ehci-regs-port_status[
- (wIndex 0xff) - 1];
- u32 temp;
- unsigned long flags;
- int retval = 0;
-
- spin_lock_irqsave(ehci-lock, flags);
-
- if (typeReq == SetPortFeature wValue == USB_PORT_FEAT_SUSPEND) {
- temp = ehci_readl(ehci, status_reg);
- if ((temp PORT_PE) == 0 || (temp PORT_RESET) != 0) {
- retval = -EPIPE;
- goto done;
- }
-
- temp = ~PORT_WKCONN_E;
- temp |= PORT_WKDISC_E | PORT_WKOC_E;
- ehci_writel(ehci, temp | PORT_SUSPEND, status_reg);
-
- omap_ehci_erratum_i693(ehci);
-
- set_bit((wIndex 0xff) - 1, ehci-suspended_ports);
- goto done;
- }
-
- spin_unlock_irqrestore(ehci-lock, flags);
-
- /* Handle the hub control events here */
- return ehci_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
-done:
- spin_unlock_irqrestore(ehci-lock, flags);
- return retval;
-}
-
static void disable_put_regulator(
struct ehci_hcd_omap_platform_data *pdata)
{
@@ -353,76 +266,9 @@ static int ehci_hcd_omap_probe(struct platform_device
*pdev)
/* root ports should always stay powered */
ehci_port_power(omap_ehci, 1);
- /* get clocks */
- utmi_p1_fck = clk_get(dev, utmi_p1_gfclk);
- if (IS_ERR(utmi_p1_fck)) {
- ret = PTR_ERR(utmi_p1_fck);
- dev_err(dev, utmi_p1_gfclk failed error:%d\n, ret);
- goto err_add_hcd;
- }
-
- xclk60mhsp1_ck = clk_get(dev,
Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue
On Thu, Jun 21, 2012 at 7:12 PM, Keshava Munegowda
keshava_mgo...@ti.com wrote:
This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled
Fix OMAP EHCI suspend/resume failure (i693) is causing
the usb hub and device detection fails in beagle XM
causeing NFS not functional. This affects the core retention too.
The same commit logic needs to be revisted adhering to hwmod and
device tree framework.
for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac
titled Fix OMAP EHCI suspend/resume failure (i693) reverted.
This patch is validated on BeagleXM with NFS support over
usb ethernet and USB mass storage and other device detection.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
drivers/usb/host/ehci-omap.c | 164
+-
1 file changed, 1 insertion(+), 163 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 17cfb8a..272e661 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -56,15 +56,6 @@
#define EHCI_INSNREG05_ULPI_EXTREGADD_SHIFT 8
#define EHCI_INSNREG05_ULPI_WRDATA_SHIFT 0
-/* Errata i693 */
-static struct clk *utmi_p1_fck;
-static struct clk *utmi_p2_fck;
-static struct clk *xclk60mhsp1_ck;
-static struct clk *xclk60mhsp2_ck;
-static struct clk *usbhost_p1_fck;
-static struct clk *usbhost_p2_fck;
-static struct clk *init_60m_fclk;
-
/*-*/
static const struct hc_driver ehci_omap_hc_driver;
@@ -80,40 +71,6 @@ static inline u32 ehci_read(void __iomem *base, u32 reg)
return __raw_readl(base + reg);
}
-/* Erratum i693 workaround sequence */
-static void omap_ehci_erratum_i693(struct ehci_hcd *ehci)
-{
- int ret = 0;
-
- /* Switch to the internal 60 MHz clock */
- ret = clk_set_parent(utmi_p1_fck, init_60m_fclk);
- if (ret != 0)
- ehci_err(ehci, init_60m_fclk set parent
- failed error:%d\n, ret);
-
- ret = clk_set_parent(utmi_p2_fck, init_60m_fclk);
- if (ret != 0)
- ehci_err(ehci, init_60m_fclk set parent
- failed error:%d\n, ret);
-
- clk_enable(usbhost_p1_fck);
- clk_enable(usbhost_p2_fck);
-
- /* Wait 1ms and switch back to the external clock */
- mdelay(1);
- ret = clk_set_parent(utmi_p1_fck, xclk60mhsp1_ck);
- if (ret != 0)
- ehci_err(ehci, xclk60mhsp1_ck set parent
- failed error:%d\n, ret);
-
- ret = clk_set_parent(utmi_p2_fck, xclk60mhsp2_ck);
- if (ret != 0)
- ehci_err(ehci, xclk60mhsp2_ck set parent
- failed error:%d\n, ret);
-
- clk_disable(usbhost_p1_fck);
- clk_disable(usbhost_p2_fck);
-}
static void omap_ehci_soft_phy_reset(struct platform_device *pdev, u8 port)
{
@@ -145,50 +102,6 @@ static void omap_ehci_soft_phy_reset(struct
platform_device *pdev, u8 port)
}
}
-static int omap_ehci_hub_control(
- struct usb_hcd *hcd,
- u16 typeReq,
- u16 wValue,
- u16 wIndex,
- char *buf,
- u16 wLength
-)
-{
- struct ehci_hcd *ehci = hcd_to_ehci(hcd);
- u32 __iomem *status_reg = ehci-regs-port_status[
- (wIndex 0xff) - 1];
- u32 temp;
- unsigned long flags;
- int retval = 0;
-
- spin_lock_irqsave(ehci-lock, flags);
-
- if (typeReq == SetPortFeature wValue == USB_PORT_FEAT_SUSPEND) {
- temp = ehci_readl(ehci, status_reg);
- if ((temp PORT_PE) == 0 || (temp PORT_RESET) != 0) {
- retval = -EPIPE;
- goto done;
- }
-
- temp = ~PORT_WKCONN_E;
- temp |= PORT_WKDISC_E | PORT_WKOC_E;
- ehci_writel(ehci, temp | PORT_SUSPEND, status_reg);
-
- omap_ehci_erratum_i693(ehci);
-
- set_bit((wIndex 0xff) - 1, ehci-suspended_ports);
- goto done;
- }
-
- spin_unlock_irqrestore(ehci-lock, flags);
-
- /* Handle the hub control events here */
- return ehci_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
-done:
- spin_unlock_irqrestore(ehci-lock, flags);
- return retval;
-}
-
static void disable_put_regulator(
struct ehci_hcd_omap_platform_data *pdata)
{
@@ -353,76 +266,9 @@ static int ehci_hcd_omap_probe(struct platform_device
*pdev)
/* root ports should always stay powered */
ehci_port_power(omap_ehci, 1);
- /* get clocks */
- utmi_p1_fck = clk_get(dev, utmi_p1_gfclk);
- if (IS_ERR(utmi_p1_fck)) {
-
Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue
Munegowda, Keshava keshava_mgo...@ti.com writes: On Thu, Jun 21, 2012 at 7:12 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) is causing the usb hub and device detection fails in beagle XM causeing NFS not functional. This affects the core retention too. The same commit logic needs to be revisted adhering to hwmod and device tree framework. for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) reverted. This patch is validated on BeagleXM with NFS support over usb ethernet and USB mass storage and other device detection. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com [...] hi kevin here is pm count log on beagle XM with the above patch: What are you meaning to show by this log? This dump shows that neither PER or CORE are hitting retention in idle. Which sounds to me like you have not enabled UART runtime suspend: echo 3000 /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.3/power/autosuspend_delay_ms My test with your patch shows that it fixes the oops during boot, and doesn't hang during suspend, but that USB host is still preventing CORE retention during idle (after UART runtime suspend is enabled.) This happens on 3530/Overo, 3630/Beagle-xM and 3730/Overo Setting CONFIG_MFD_OMAP_USB_HOST=n allows CORE to hit retention again. Kevin cat ./debug/pm_debug/count usbhost_pwrdm (ON),OFF:0,RET:3,INA:0,ON:4,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 per_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 dss_pwrdm (ON),OFF:0,RET:1254,INA:0,ON:1255,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 neon_pwrdm (ON),OFF:0,RET:1254,INA:0,ON:1255,RET-LOGIC-OFF:0 mpu_pwrdm (ON),OFF:0,RET:1254,INA:0,ON:1255,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 iva2_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0 usbhost_clkdm-usbhost_pwrdm (3) sgx_clkdm-sgx_pwrdm (0) per_clkdm-per_pwrdm (19) cam_clkdm-cam_pwrdm (0) dss_clkdm-dss_pwrdm (1) core_l4_clkdm-core_pwrdm (25) core_l3_clkdm-core_pwrdm (4) d2d_clkdm-core_pwrdm (0) iva2_clkdm-iva2_pwrdm (0) neon_clkdm-neon_pwrdm (0) mpu_clkdm-mpu_pwrdm (0) prm_clkdm-wkup_pwrdm (0) cm_clkdm-core_pwrdm (0) regards keshava -- 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
