from:"Munegowda, Keshava"

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: config : disable the usb host configuration in omap2plus_defconfig

On Fri, Jul 6, 2012 at 5:19 PM, Keshava Munegowda keshava_mgo...@ti.com wrote:
 The usb host is disabled in the omap2 build; This is because
 usb host is causing the retention to break in cpu idle.

 Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
 ---
  arch/arm/configs/omap2plus_defconfig |   11 ---
  1 file changed, 11 deletions(-)

 diff --git a/arch/arm/configs/omap2plus_defconfig 
 b/arch/arm/configs/omap2plus_defconfig
 index 9854ff4..7b32da6 100644
 --- a/arch/arm/configs/omap2plus_defconfig
 +++ b/arch/arm/configs/omap2plus_defconfig
 @@ -170,17 +170,6 @@ CONFIG_SND_USB_AUDIO=m
  CONFIG_SND_SOC=m
  CONFIG_SND_OMAP_SOC=m
  CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m
 -CONFIG_USB=y
 -CONFIG_USB_DEBUG=y
 -CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
 -CONFIG_USB_DEVICEFS=y
 -CONFIG_USB_SUSPEND=y
 -CONFIG_USB_MON=y
 -CONFIG_USB_EHCI_HCD=y
 -CONFIG_USB_WDM=y
 -CONFIG_USB_STORAGE=y
 -CONFIG_USB_LIBUSUAL=y
 -CONFIG_USB_TEST=y
  CONFIG_USB_GADGET=y
  CONFIG_USB_GADGET_DEBUG=y
  CONFIG_USB_GADGET_DEBUG_FILES=y
 --
 1.7.9.5


Sameo
please merge this patch ; this makes the core retention to work in
omap2plus_defconfig

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: config : disable the usb host configuration in omap2plus_defconfig

On Fri, Jul 6, 2012 at 5:29 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
 On Fri, Jul 6, 2012 at 5:25 PM, Munegowda, Keshava
 keshava_mgo...@ti.com wrote:
 On Fri, Jul 6, 2012 at 5:19 PM, Keshava Munegowda keshava_mgo...@ti.com 
 wrote:
 The usb host is disabled in the omap2 build; This is because
 usb host is causing the retention to break in cpu idle.

 Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
 ---
  arch/arm/configs/omap2plus_defconfig |   11 ---
  1 file changed, 11 deletions(-)

 diff --git a/arch/arm/configs/omap2plus_defconfig 
 b/arch/arm/configs/omap2plus_defconfig
 index 9854ff4..7b32da6 100644
 --- a/arch/arm/configs/omap2plus_defconfig
 +++ b/arch/arm/configs/omap2plus_defconfig
 @@ -170,17 +170,6 @@ CONFIG_SND_USB_AUDIO=m
  CONFIG_SND_SOC=m
  CONFIG_SND_OMAP_SOC=m
  CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m
 -CONFIG_USB=y
 -CONFIG_USB_DEBUG=y
 -CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
 -CONFIG_USB_DEVICEFS=y
 -CONFIG_USB_SUSPEND=y
 -CONFIG_USB_MON=y
 -CONFIG_USB_EHCI_HCD=y
 -CONFIG_USB_WDM=y
 -CONFIG_USB_STORAGE=y
 -CONFIG_USB_LIBUSUAL=y
 -CONFIG_USB_TEST=y
  CONFIG_USB_GADGET=y
  CONFIG_USB_GADGET_DEBUG=y
  CONFIG_USB_GADGET_DEBUG_FILES=y
 --
 1.7.9.5


 Sameo
 please merge this patch ; this makes the core retention to work in
 omap2plus_defconfig

 If at all this patch has to be merged, it should be via Tony's tree,
 otherwise you
 might have merge conflicts.

 Regards
 Santosh

Thanks Santosh
   looping Tony

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: config : disable the usb host configuration in omap2plus_defconfig

On Fri, Jul 6, 2012 at 5:37 PM, Tony Lindgren t...@atomide.com wrote:
 * Munegowda, Keshava keshava_mgo...@ti.com [120706 05:06]:
 On Fri, Jul 6, 2012 at 5:29 PM, Shilimkar, Santosh
 santosh.shilim...@ti.com wrote:
  On Fri, Jul 6, 2012 at 5:25 PM, Munegowda, Keshava
  keshava_mgo...@ti.com wrote:
  On Fri, Jul 6, 2012 at 5:19 PM, Keshava Munegowda keshava_mgo...@ti.com 
  wrote:
  The usb host is disabled in the omap2 build; This is because
  usb host is causing the retention to break in cpu idle.
 ...
  Sameo
  please merge this patch ; this makes the core retention to work in
  omap2plus_defconfig
 
  If at all this patch has to be merged, it should be via Tony's tree,
  otherwise you
  might have merge conflicts.

 I think it's best to fix things properly, even if it means that it will
 take longer and go into next kernel version.

 Tony

Hi tony

This requires ehci remote wakeup feature to be implemented, which
will take at least to 3 months to
get reviewed in opensource.
hence for now  kevin is also agreed to disable it by default;


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: config : disable the usb host configuration in omap2plus_defconfig

On Fri, Jul 6, 2012 at 6:09 PM, Tony Lindgren t...@atomide.com wrote:
 * Munegowda, Keshava keshava_mgo...@ti.com [120706 05:30]:
 On Fri, Jul 6, 2012 at 5:37 PM, Tony Lindgren t...@atomide.com wrote:
 
  I think it's best to fix things properly, even if it means that it will
  take longer and go into next kernel version.

 This requires ehci remote wakeup feature to be implemented, which
 will take at least to 3 months to
 get reviewed in opensource.
 hence for now  kevin is also agreed to disable it by default;

 Why does echi need a remote wakeup feature? If you're talking about
 echi wake-up events, I don't see how that would affect core retention.

Hi Tony
 the cpu should hit the retention in idle; in this case,  up on
usb bus suspend ( no device connected) , if I cut the clock, then later
device detection happen through I/O wakeup, so implementing the
ehci remote wakeup using I/O chain handler ensure the retention in idle too.
now, with the existing ehci driver in mainline, whether device connected or not
the clocks are not cut and prevents the retention in idle.
so, I need to implement the ehci clock gating mechanism through I/O interrupts
in bus spend /resume . This activity will take some time.

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 V3 5/5] ARM: OMAP: change the USB TLL clocks device name

2012-07-04 Thread Munegowda, Keshava

On Wed, Jul 4, 2012 at 1:00 PM, Paul Walmsley p...@pwsan.com wrote:
 On Mon, 2 Jul 2012, Keshava Munegowda wrote:

 The platform device name for the functional, interface and
 channel clocks of the TLL module is changed from usbhs device
 to usb tll platform device name.

 Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
 Reviewed-by: Partha Basak part...@india.ti.com

 The basic idea of this patch looks reasonable, but you should make sure
 that this series doesn't result in a broken TLL at any point during the
 series.  Otherwise 'git bisect' operations will break.

 To do this, you'll presumably need to add the new clkdev aliases much
 earlier in the series, and remove the old ones at the end of the
 series.

Thanks Paul
  I will change this.
please let me if you have other comments on this series.

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

2012-07-03 Thread Munegowda, Keshava

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

2012-07-03 Thread Munegowda, Keshava

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

2012-07-03 Thread Munegowda, Keshava

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 0/5 V2 RESEND] ARM: OMAP: TLL driver implementation for USB host driver

On Mon, Jul 2, 2012 at 8:01 PM, Samuel Ortiz sa...@linux.intel.com wrote:
 Hi Keshava,

 On Tue, Jun 26, 2012 at 04:56:02PM +0530, Keshava Munegowda wrote:
 The TLL configuration is removed from the UHH driver and implemented as
 a seperate platform driver. Now, the UHH driver configures the TLL
 through API's exported by the TLL platform driver. The TLL is an
 has independent hardware mod structure for in OMAP3 and later chips,
 hence an dedicated platform driver is created.
 I'm sort of ok with that split although the new driver is definitely not an
 MFD one, but I guess there's no better place for it.
 Now, a few comments before applying it:

 - I'd appreciate to get ACKs from e.g. Tony for the OMAP parts.
 - Patch #3 doesn't apply on top of my for-next branch. Would you mind rebasing
   it properly ?
 - Fix the coypright years to 2012.

 Cheers,
 Samuel.


Hi samuel
just now I have posted v3 of this series.

This series is on top of

Rus dill patch : http://permalink.gmane.org/gmane.linux.usb.general/65988
and my patch : ttp://permalink.gmane.org/gmane.linux.usb.general/66239

you need these patches before applying this series.

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 v3] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset fix issues.

On Fri, Jun 29, 2012 at 9:03 PM, Alan Stern st...@rowland.harvard.edu wrote:
 On Wed, 27 Jun 2012, Russ Dill wrote:

 From: Russ Dill russ.d...@gmail.com

 'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' (1fcb57d0) fixes
 an issue where the ULPI PHYs were not held in reset while initializing
 the EHCI controller. However, it also changes behavior in
 omap-usb-host.c omap_usbhs_init by releasing reset while the
 configuration in that function was done.

 This change caused a regression on BB-xM where USB would not function
 if 'usb start' had been run from u-boot before booting. A change was
 made to release reset a little bit earlier which fixed the issue on
 BB-xM and did not cause any regressions on 3430 sdp, the board for
 which the fix was originally made.

 This new fix, 'USB: EHCI: OMAP: Finish ehci omap phy reset cycle
 before adding hcd.', (3aa2ae74) caused a regression on OMAP5.

 The original fix to hold the EHCI controller in reset during
 initialization was correct, however it appears that changing
 omap_usbhs_init to not hold the PHYs in reset during it's
 configuration was incorrect. This patch first reverts both fixes, and
 then changes ehci_hcd_omap_probe in ehci-omap.c to hold the PHYs in
 reset as the original patch had done. It also is sure to incorporate
 the _cansleep change that has been made in the meantime.

 Tested on Beagleboard xM.

 Looking at the result of this patch, there seem to be a few mistakes
 remaining in the probe routine.

 If the regulator_get() call fails, the failure is logged but ignored.
 Is that really the right thing to do?

 The pm_runtime_get_sync() call occurs before the probe is finished.
 This means that ehci-hcd's resume routine will try to power-up the
 device before its data structures have been initialized.  That can't be
 right.

 The get clocks section occurs after the call to usb_add_hcd().  This
 means the controller will start running before the clock references are
 acquired -- so the clocks might still be turned off.  That can't be
 right either.

 If the clk_get(dev, utmi_p1_gfclk) call fails, the error path never
 calls usb_remove_hcd().

 The err_add_hcd pathway never calls usb_put_hcd().

 I'm going to resubmit my most recent patch based the current
 ehci-omap.c, but you or someone else will still have to fix these
 problems.

 Alan Stern


Hi Rus Dill,
once Alan post his changes on ehci-omap.c, please re-base this
patch on top of it.
so that, I will rebase UHH-TLL split series on top your patch.

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 v3] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset fix issues.

On Mon, Jul 2, 2012 at 4:52 PM, Samuel Ortiz sa...@linux.intel.com wrote:
 Hi Russ,

 On Thu, Jun 14, 2012 at 09:24:21AM -0700, Russ Dill wrote:
 From: Russ Dill russ.d...@gmail.com

 'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' (1fcb57d0) fixes
 an issue where the ULPI PHYs were not held in reset while initializing
 the EHCI controller. However, it also changes behavior in
 omap-usb-host.c omap_usbhs_init by releasing reset while the
 configuration in that function was done.

 This change caused a regression on BB-xM where USB would not function
 if 'usb start' had been run from u-boot before booting. A change was
 made to release reset a little bit earlier which fixed the issue on
 BB-xM and did not cause any regressions on 3430 sdp, the board for
 which the fix was originally made.

 This new fix, 'USB: EHCI: OMAP: Finish ehci omap phy reset cycle
 before adding hcd.', (3aa2ae74) caused a regression on OMAP5.

 The original fix to hold the EHCI controller in reset during
 initialization was correct, however it appears that changing
 omap_usbhs_init to not hold the PHYs in reset during it's
 configuration was incorrect. This patch first reverts both fixes, and
 then changes ehci_hcd_omap_probe in ehci-omap.c to hold the PHYs in
 reset as the original patch had done. It also is sure to incorporate
 the _cansleep change that has been made in the meantime.

 I've tested this on Beagleboard xM, I'd really like to get an ack from
 the 3430 sdp and OMAP5 guys before getting this merged.

 v3 - Brown paper bag its too early in the morning actually run
  git commit amend fix
 v2 - Put cansleep gpiolib call outside of spinlock

 Signed-off-by: Russ Dill russ.d...@gmail.com
 ---
  drivers/mfd/omap-usb-host.c  |   48 
 +-
  drivers/usb/host/ehci-omap.c |   18 +++-
  2 files changed, 55 insertions(+), 11 deletions(-)
 I applied this one to my for-linus branch, it will be part of my next 3.5 pull
 request to Linus.

 Cheers,
 Samuel.


Hi Samuel
   please drop this patch for now , since Alan stern has mentioned
improvements for this patch and we
need to wait for Alan's new patch on ehci-omap.c and then Rus dill
patch and my usbhs tll
patch series need to be rebased.


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 v3] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset fix issues.

On Mon, Jul 2, 2012 at 7:35 PM, Alan Stern st...@rowland.harvard.edu wrote:
 On Mon, 2 Jul 2012, Munegowda, Keshava wrote:

 Hi Samuel
please drop this patch for now , since Alan stern has mentioned
 improvements for this patch and we
 need to wait for Alan's new patch on ehci-omap.c and then Rus dill
 patch and my usbhs tll
 patch series need to be rebased.

 No, that's okay.  I rebased my patch on top of Russ's; see

 http://marc.info/?l=linux-usbm=134098478928668w=2

 so Russ's patch should be kept.  My patch needed other changes also, so
 this wasn't a big deal.

 The extra problems I mentioned in an earlier email will still need to
 be fixed after both Russ's patch and my own are merged.

 Alan Stern

Thanks Alan,
Ok, then I will rebase my TLL driver patch series on top
of this patch.

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 V3 0/5] ARM: OMAP: TLL driver implementation for USB host driver

On Mon, Jul 2, 2012 at 8:31 PM, Keshava Munegowda keshava_mgo...@ti.com wrote:
 The TLL configuration is removed from the UHH driver and implemented as
 a seperate platform driver. Now, the UHH driver configures the TLL
 through API's exported by the TLL platform driver. The TLL is an
 has independent hardware mod structure for in OMAP3 and later chips,
 hence an dedicated platform driver is created.

 Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com

 In v3:
   - rebased on top V3 of Russ dill's patch
'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue'
fixes an issue where the ULPI PHYs were not held in reset
while initializing the EHCI controller
 http://permalink.gmane.org/gmane.linux.usb.general/65988

   - rebased on top of patch
 OMAP: USB : Fix the EHCI enumeration and core retention issue
  http://permalink.gmane.org/gmane.linux.usb.general/66239

 In V2:
 - covered review comments from linux omap and usb community
 - rebased on top Russ dill's patch
'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue'
fixes an issue where the ULPI PHYs were not held in reset
while initializing the EHCI controller


 Keshava Munegowda (5):
   ARM: OMAP: USB: HOST TLL platform driver
   ARM: OMAP: USB: Build the USB HOST TLL omap device
   ARM: OMAP: USB: Remove TLL specific code
   ARM: OMAP: USB: Invoke the TLL driver from USB HS core driver
   ARM: OMAP: change the USB TLL clocks device name

  arch/arm/mach-omap2/clock3xxx_data.c  |8 +-
  arch/arm/mach-omap2/clock44xx_data.c  |4 +-
  arch/arm/mach-omap2/usb-host.c|   31 ++-
  arch/arm/plat-omap/include/plat/usb.h |7 +
  drivers/mfd/Kconfig   |2 +-
  drivers/mfd/Makefile  |2 +-
  drivers/mfd/omap-usb-host.c   |  238 ++---
  drivers/mfd/omap-usb-tll.c|  471 
 +
  8 files changed, 523 insertions(+), 240 deletions(-)
  create mode 100644 drivers/mfd/omap-usb-tll.c

 --
 1.7.9.5

Hi Paul and Tony
  since Felipe Balbi is on vacation , Can I get your ack by please?
This is good candidate to v3.5 kernel.

paul,
   Just to remind you that, in last ELC Europe , we discussed about the
design of split of UHH and TLL drivers. This series does the same.

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] ARM: OMAP: EHCI: Fix the hub disconnect after resume

2012-06-28 Thread Munegowda, Keshava

On Wed, Jun 27, 2012 at 7:54 PM, Alan Stern st...@rowland.harvard.edu wrote:
 On Wed, 27 Jun 2012, Keshava Munegowda wrote:

 Its observed that in Beagle XM , during suspend/resume the OMAP
 EHCI controller losing the register contents. this is causing the
 hub disconnect after the resume, this is causing failure of
 device detection after the resume.
 to avoid the hub disconnect , The ehci config flag register is
 configured again , reset the phy and issue the port powers during
 resume.

 The idea is good, but the implementation is wrong.

 +static int omap_ehci_bus_resume(struct usb_hcd *hcd)
 +{
 +
 +     struct device                           *dev = hcd-self.controller;
 +     struct ehci_hcd_omap_platform_data      *pdata = dev-platform_data;
 +     struct resource                         *regs = hcd-regs;
 +
 +     /* In case , ports are not powered and config flag not set */
 +     if (~(ehci_read(regs, EHCI_CONFIGFLAG)  0x01)) {
 +             ehci_write(regs, EHCI_CONFIGFLAG, 0x1);
 +
 +             /*
 +              * An undocumented feature in the OMAP3 EHCI controller,
 +              * causes suspended ports to be taken out of suspend when
 +              * the USBCMD.Run/Stop bit is cleared (for example when
 +              * we do ehci_bus_suspend).
 +              * This breaks suspend-resume if the root-hub is allowed
 +              * to suspend. Writing 1 to this undocumented register bit
 +              * disables this feature and restores normal behavior.
 +              */
 +             ehci_write(regs, EHCI_INSNREG04,
 +                        EHCI_INSNREG04_DISABLE_UNSUSPEND);
 +
 +             /* Soft reset the PHY using PHY reset command over ULPI */
 +             if (pdata-port_mode[0] == OMAP_EHCI_PORT_MODE_PHY)
 +                     omap_ehci_soft_phy_reset(dev, 0);
 +             if (pdata-port_mode[1] == OMAP_EHCI_PORT_MODE_PHY)
 +                     omap_ehci_soft_phy_reset(dev, 1);
 +
 +             /* root ports should always stay powered */
 +             ehci_port_power(hcd_to_ehci(hcd), 1);
 +     }

 This needs to be done in the resume routine, not the bus_resume
 routine.  Since ehci-omap doesn't have any suspend or resume routines,
 it's not surprising that the controller doesn't work correctly after
 the system is resumed.

 In a couple of days I will submit a patch that will make it a lot
 easier to add suspend and resume routines for EHCI platform drivers.
 Maybe you'd prefer to wait until then to fix this issue.

 Alan Stern

Thanks Alan
Ok, I will wait for 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 04/11] mfd: omap-usb: add clk_prepare and clk_unprepare

2012-06-25 Thread Munegowda, Keshava

On Sat, Jun 23, 2012 at 12:34 AM, Paul Walmsley p...@pwsan.com wrote:
 On Fri, 22 Jun 2012, Rajendra Nayak wrote:

 In preparation of OMAP moving to Common Clk Framework (CCF) add clk_prepare()
 and clk_unprepare() for the various usb host clocks.

 Signed-off-by: Rajendra Nayak rna...@ti.com
 Cc: Samuel Ortiz sa...@linux.intel.com

 Looks like this one will be at least partially obsoleted by this series:


Thanks paul
Hi Rajendra
 please re-base this patch to below series:

 ARM: OMAP: TLL driver implementation for USB host driver
 http://marc.info/?l=linux-omapm=134019432606399w=2

 and the runtime PM conversion in that series needs to be done anyway.


 - Paul
--
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

2012-06-22 Thread Munegowda, Keshava

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

2012-06-22 Thread Munegowda, Keshava

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

2012-06-22 Thread Munegowda, Keshava

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: MFD USB host: prevents CORE retention in idle

2012-06-21 Thread Munegowda, Keshava

On Wed, Jun 20, 2012 at 7:53 PM, Kevin Hilman khil...@ti.com wrote:
 Munegowda, Keshava keshava_mgo...@ti.com writes:

 On Wed, Jun 20, 2012 at 11:53 AM, Munegowda, Keshava
 keshava_mgo...@ti.com wrote:
 On Tue, Jun 19, 2012 at 11:32 PM, Kevin Hilman khil...@ti.com wrote:
 Munegowda, Keshava keshava_mgo...@ti.com writes:

 On Fri, Jun 15, 2012 at 7:17 PM, Jean Pihet jean.pi...@newoldbits.com 
 wrote:
 Hi Keshava,

 On Fri, Jun 15, 2012 at 2:04 PM, Munegowda, Keshava
 keshava_mgo...@ti.com wrote:
 On Tue, Jun 12, 2012 at 6:28 PM, Munegowda, Keshava
 keshava_mgo...@ti.com wrote:
 hi kevin
     now I am using initramfs with kernel linux3.5.rc1,
 but the retention is not working in 3430 sdp.  I am seeing the 
 following
 error followed by a crash


 echo mem  /sys/power/state
 [   35.609252] PM: Syncing filesystems ... done.
 [   35.614654] PM: Preparing system for mem sleep
 [   35.658630] Freezing user space processes ... (elapsed 0.01 seconds)
 done.
 [   35.689727] Freezing remaining freezable tasks ... (elapsed 0.02 
 seconds)
 done.
 [   35.697692] PM: Entering mem sleep
 [   35.722442] usb usb1: usb auto-resume
 [   35.726409] ehci-omap ehci-omap.0: resume root hub
 [   35.775451] hub 1-0:1.0: hub_resume
 [   35.779846] hub 1-0:1.0: hub_suspend
 [   35.784240] usb usb1: bus suspend, wakeup 0
 [   35.788665] ehci-omap ehci-omap.0: suspend root hub
 [   35.805786] PM: suspend of devices complete after 99.304 msecs
 [   35.816497] PM: late suspend of devices complete after 4.364 msecs
 [   35.831573] PM: noirq suspend of devices complete after 8.331 msecs
 [   35.838500] Disabling non-boot CPUs ...
 [   36.312164] Powerdomain (core_pwrdm) didn't enter target state 1
 [   36.318481] Could not enter target state in pm_suspend
 [   36.324859] Unable to handle kernel NULL pointer dereference at 
 virtual
 address 0018
 [   36.333557] pgd = c628
 [   36.336639] [0018] *pgd=85c8f831, *pte=, *ppte=
 [   36.343414] Internal error: Oops: 17 [#1] SMP ARM
 [   36.348388] Modules linked in:
 [   36.351623] CPU: 0    Tainted: G    W (3.5.0-rc1 #1)
 [   36.357574] PC is at _od_resume_noirq+0x14/0x58
 [   36.362365] LR is at dpm_run_callback+0x2c/0x74

 You need the fix from
 https://gitorious.org/linux-omap-dss2/linux/commit/9e0ca55fa5d9ff012964a7c7cef8af1b814b2fdb

 Hope this helps!

 Regards,
 Jean

 thanks Jean
     I used this patch; this solved the crash issue, but suspend/resume
 is still failing.

 Failing in what way?  Did you debug any further?

 It may be failing because of problems with the USB host driver, which is
 what I'm needing you to debug.

 The suspend/resume was failing even without USB in the mainline kernel 
 image.


 I'm convinced now that these USB host PM changes were not very well
 tested at all as they seem to be causing a variety of different problems
 on my boards: faults during boot, preventing CORE idle retention,
 hanging suspend/resume.

 Anyways...

 To get current l-o master to succesfully suspend/resume, you need 3 things:

 1) the DSS fixes that Jean mentioned above (these are merged in
   v3.5-rc3, but not yet into l-o master)
 2) disable USB host: set CONFIG_MFD_OMAP_USB_HOST=n
 3) for for 32k timer which is also preventing CORE retention
   http://marc.info/?l=linux-omapm=13453229888w=2

 With that setup on top of current l-o master, suspend/resume is working
 for me on several OMAP3/4 platforms.

 Kevin


 I tired the linux2.3.5.rc2 + DSS fixes + sync 32k timer fix without USB
 on beagle XM.

 I suggested using l-o master as a baseline, not -rc2.

 I just pushed a branch with this baseline so we are sure to be testing
 the same baseline.  Please use the 'tmp/test/usb-host' branch from my
 tree[1] as the starting point.

 Build using omap2plus_defconfig, boot, then suspend/resume and send the output
 of 'cat /debug/pm_debug/count'

 This baseline is working fine for me on 3430/n900, 3530/Overo and
 3630/Beagle-xM.

 Kevin

 [1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git


I did the clone of this , But I am not seeing the branch 'tmp/test/usb-host'
I am seeing only the branch /wip/arm-nohz-cpusets other than master.
I didn't any usb-host branch here too:
http://git.kernel.org/?p=linux/kernel/git/khilman/linux.git;a=summary

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

2012-06-21 Thread Munegowda, Keshava

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: MFD USB host: prevents CORE retention in idle

2012-06-20 Thread Munegowda, Keshava

On Tue, Jun 19, 2012 at 11:32 PM, Kevin Hilman khil...@ti.com wrote:
 Munegowda, Keshava keshava_mgo...@ti.com writes:

 On Fri, Jun 15, 2012 at 7:17 PM, Jean Pihet jean.pi...@newoldbits.com 
 wrote:
 Hi Keshava,

 On Fri, Jun 15, 2012 at 2:04 PM, Munegowda, Keshava
 keshava_mgo...@ti.com wrote:
 On Tue, Jun 12, 2012 at 6:28 PM, Munegowda, Keshava
 keshava_mgo...@ti.com wrote:
 hi kevin
     now I am using initramfs with kernel linux3.5.rc1,
 but the retention is not working in 3430 sdp.  I am seeing the following
 error followed by a crash


 echo mem  /sys/power/state
 [   35.609252] PM: Syncing filesystems ... done.
 [   35.614654] PM: Preparing system for mem sleep
 [   35.658630] Freezing user space processes ... (elapsed 0.01 seconds)
 done.
 [   35.689727] Freezing remaining freezable tasks ... (elapsed 0.02 
 seconds)
 done.
 [   35.697692] PM: Entering mem sleep
 [   35.722442] usb usb1: usb auto-resume
 [   35.726409] ehci-omap ehci-omap.0: resume root hub
 [   35.775451] hub 1-0:1.0: hub_resume
 [   35.779846] hub 1-0:1.0: hub_suspend
 [   35.784240] usb usb1: bus suspend, wakeup 0
 [   35.788665] ehci-omap ehci-omap.0: suspend root hub
 [   35.805786] PM: suspend of devices complete after 99.304 msecs
 [   35.816497] PM: late suspend of devices complete after 4.364 msecs
 [   35.831573] PM: noirq suspend of devices complete after 8.331 msecs
 [   35.838500] Disabling non-boot CPUs ...
 [   36.312164] Powerdomain (core_pwrdm) didn't enter target state 1
 [   36.318481] Could not enter target state in pm_suspend
 [   36.324859] Unable to handle kernel NULL pointer dereference at virtual
 address 0018
 [   36.333557] pgd = c628
 [   36.336639] [0018] *pgd=85c8f831, *pte=, *ppte=
 [   36.343414] Internal error: Oops: 17 [#1] SMP ARM
 [   36.348388] Modules linked in:
 [   36.351623] CPU: 0    Tainted: G    W (3.5.0-rc1 #1)
 [   36.357574] PC is at _od_resume_noirq+0x14/0x58
 [   36.362365] LR is at dpm_run_callback+0x2c/0x74

 You need the fix from
 https://gitorious.org/linux-omap-dss2/linux/commit/9e0ca55fa5d9ff012964a7c7cef8af1b814b2fdb

 Hope this helps!

 Regards,
 Jean

 thanks Jean
     I used this patch; this solved the crash issue, but suspend/resume
 is still failing.

 Failing in what way?  Did you debug any further?

 It may be failing because of problems with the USB host driver, which is
 what I'm needing you to debug.

The suspend/resume was failing even without USB in the mainline kernel image.


 I'm convinced now that these USB host PM changes were not very well
 tested at all as they seem to be causing a variety of different problems
 on my boards: faults during boot, preventing CORE idle retention,
 hanging suspend/resume.

 Anyways...

 To get current l-o master to succesfully suspend/resume, you need 3 things:

 1) the DSS fixes that Jean mentioned above (these are merged in
   v3.5-rc3, but not yet into l-o master)
 2) disable USB host: set CONFIG_MFD_OMAP_USB_HOST=n
 3) for for 32k timer which is also preventing CORE retention
   http://marc.info/?l=linux-omapm=13453229888w=2

 With that setup on top of current l-o master, suspend/resume is working
 for me on several OMAP3/4 platforms.

 Kevin

Ok, I will test this.

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: MFD USB host: prevents CORE retention in idle

2012-06-20 Thread Munegowda, Keshava

On Wed, Jun 20, 2012 at 11:53 AM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
 On Tue, Jun 19, 2012 at 11:32 PM, Kevin Hilman khil...@ti.com wrote:
 Munegowda, Keshava keshava_mgo...@ti.com writes:

 On Fri, Jun 15, 2012 at 7:17 PM, Jean Pihet jean.pi...@newoldbits.com 
 wrote:
 Hi Keshava,

 On Fri, Jun 15, 2012 at 2:04 PM, Munegowda, Keshava
 keshava_mgo...@ti.com wrote:
 On Tue, Jun 12, 2012 at 6:28 PM, Munegowda, Keshava
 keshava_mgo...@ti.com wrote:
 hi kevin
     now I am using initramfs with kernel linux3.5.rc1,
 but the retention is not working in 3430 sdp.  I am seeing the following
 error followed by a crash


 echo mem  /sys/power/state
 [   35.609252] PM: Syncing filesystems ... done.
 [   35.614654] PM: Preparing system for mem sleep
 [   35.658630] Freezing user space processes ... (elapsed 0.01 seconds)
 done.
 [   35.689727] Freezing remaining freezable tasks ... (elapsed 0.02 
 seconds)
 done.
 [   35.697692] PM: Entering mem sleep
 [   35.722442] usb usb1: usb auto-resume
 [   35.726409] ehci-omap ehci-omap.0: resume root hub
 [   35.775451] hub 1-0:1.0: hub_resume
 [   35.779846] hub 1-0:1.0: hub_suspend
 [   35.784240] usb usb1: bus suspend, wakeup 0
 [   35.788665] ehci-omap ehci-omap.0: suspend root hub
 [   35.805786] PM: suspend of devices complete after 99.304 msecs
 [   35.816497] PM: late suspend of devices complete after 4.364 msecs
 [   35.831573] PM: noirq suspend of devices complete after 8.331 msecs
 [   35.838500] Disabling non-boot CPUs ...
 [   36.312164] Powerdomain (core_pwrdm) didn't enter target state 1
 [   36.318481] Could not enter target state in pm_suspend
 [   36.324859] Unable to handle kernel NULL pointer dereference at 
 virtual
 address 0018
 [   36.333557] pgd = c628
 [   36.336639] [0018] *pgd=85c8f831, *pte=, *ppte=
 [   36.343414] Internal error: Oops: 17 [#1] SMP ARM
 [   36.348388] Modules linked in:
 [   36.351623] CPU: 0    Tainted: G    W (3.5.0-rc1 #1)
 [   36.357574] PC is at _od_resume_noirq+0x14/0x58
 [   36.362365] LR is at dpm_run_callback+0x2c/0x74

 You need the fix from
 https://gitorious.org/linux-omap-dss2/linux/commit/9e0ca55fa5d9ff012964a7c7cef8af1b814b2fdb

 Hope this helps!

 Regards,
 Jean

 thanks Jean
     I used this patch; this solved the crash issue, but suspend/resume
 is still failing.

 Failing in what way?  Did you debug any further?

 It may be failing because of problems with the USB host driver, which is
 what I'm needing you to debug.

 The suspend/resume was failing even without USB in the mainline kernel image.


 I'm convinced now that these USB host PM changes were not very well
 tested at all as they seem to be causing a variety of different problems
 on my boards: faults during boot, preventing CORE idle retention,
 hanging suspend/resume.

 Anyways...

 To get current l-o master to succesfully suspend/resume, you need 3 things:

 1) the DSS fixes that Jean mentioned above (these are merged in
   v3.5-rc3, but not yet into l-o master)
 2) disable USB host: set CONFIG_MFD_OMAP_USB_HOST=n
 3) for for 32k timer which is also preventing CORE retention
   http://marc.info/?l=linux-omapm=13453229888w=2

 With that setup on top of current l-o master, suspend/resume is working
 for me on several OMAP3/4 platforms.

 Kevin


I tired the linux2.3.5.rc2 + DSS fixes + sync 32k timer fix without USB
on beagle XM. but I can see that core retention in suspend/resume is
not working .
Apply , DSS fixes patch has resolved the the crash in suspend/resume,
but retention
is not entering.

 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: MFD USB host: prevents CORE retention in idle

2012-06-18 Thread Munegowda, Keshava

On Fri, Jun 15, 2012 at 7:17 PM, Jean Pihet jean.pi...@newoldbits.com wrote:
 Hi Keshava,

 On Fri, Jun 15, 2012 at 2:04 PM, Munegowda, Keshava
 keshava_mgo...@ti.com wrote:
 On Tue, Jun 12, 2012 at 6:28 PM, Munegowda, Keshava
 keshava_mgo...@ti.com wrote:
 hi kevin
     now I am using initramfs with kernel linux3.5.rc1,
 but the retention is not working in 3430 sdp.  I am seeing the following
 error followed by a crash


 echo mem  /sys/power/state
 [   35.609252] PM: Syncing filesystems ... done.
 [   35.614654] PM: Preparing system for mem sleep
 [   35.658630] Freezing user space processes ... (elapsed 0.01 seconds)
 done.
 [   35.689727] Freezing remaining freezable tasks ... (elapsed 0.02 seconds)
 done.
 [   35.697692] PM: Entering mem sleep
 [   35.722442] usb usb1: usb auto-resume
 [   35.726409] ehci-omap ehci-omap.0: resume root hub
 [   35.775451] hub 1-0:1.0: hub_resume
 [   35.779846] hub 1-0:1.0: hub_suspend
 [   35.784240] usb usb1: bus suspend, wakeup 0
 [   35.788665] ehci-omap ehci-omap.0: suspend root hub
 [   35.805786] PM: suspend of devices complete after 99.304 msecs
 [   35.816497] PM: late suspend of devices complete after 4.364 msecs
 [   35.831573] PM: noirq suspend of devices complete after 8.331 msecs
 [   35.838500] Disabling non-boot CPUs ...
 [   36.312164] Powerdomain (core_pwrdm) didn't enter target state 1
 [   36.318481] Could not enter target state in pm_suspend
 [   36.324859] Unable to handle kernel NULL pointer dereference at virtual
 address 0018
 [   36.333557] pgd = c628
 [   36.336639] [0018] *pgd=85c8f831, *pte=, *ppte=
 [   36.343414] Internal error: Oops: 17 [#1] SMP ARM
 [   36.348388] Modules linked in:
 [   36.351623] CPU: 0    Tainted: G    W (3.5.0-rc1 #1)
 [   36.357574] PC is at _od_resume_noirq+0x14/0x58
 [   36.362365] LR is at dpm_run_callback+0x2c/0x74

 You need the fix from
 https://gitorious.org/linux-omap-dss2/linux/commit/9e0ca55fa5d9ff012964a7c7cef8af1b814b2fdb

 Hope this helps!

 Regards,
 Jean

thanks Jean
I used this patch; this solved the crash issue, but suspend/resume
is still failing.

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 v3] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset fix issues.

2012-06-18 Thread Munegowda, Keshava

On Fri, Jun 15, 2012 at 12:36 AM, Sarashetti, Mantesh mant...@ti.com wrote:
 'Acked-by: mant...@ti.com'
 'Tested-by: mant...@ti.com'

 Regards,
 Mantesh
 -Original Message-
 From: Russ Dill [mailto:russ.d...@gmail.com] On Behalf Of Dill, Russ
 Sent: Thursday, June 14, 2012 11:24 AM
 To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
 Cc: Balbi, Felipe; Munegowda, Keshava; Partha Basak; Igor Grinberg; Samuel 
 Ortiz; Sarashetti, Mantesh; Setty, Sapna; Russ Dill
 Subject: [PATCH v3] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset fix issues.

 From: Russ Dill russ.d...@gmail.com

 'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' (1fcb57d0) fixes
 an issue where the ULPI PHYs were not held in reset while initializing
 the EHCI controller. However, it also changes behavior in
 omap-usb-host.c omap_usbhs_init by releasing reset while the
 configuration in that function was done.

 This change caused a regression on BB-xM where USB would not function
 if 'usb start' had been run from u-boot before booting. A change was
 made to release reset a little bit earlier which fixed the issue on
 BB-xM and did not cause any regressions on 3430 sdp, the board for
 which the fix was originally made.

 This new fix, 'USB: EHCI: OMAP: Finish ehci omap phy reset cycle
 before adding hcd.', (3aa2ae74) caused a regression on OMAP5.

 The original fix to hold the EHCI controller in reset during
 initialization was correct, however it appears that changing
 omap_usbhs_init to not hold the PHYs in reset during it's
 configuration was incorrect. This patch first reverts both fixes, and
 then changes ehci_hcd_omap_probe in ehci-omap.c to hold the PHYs in
 reset as the original patch had done. It also is sure to incorporate
 the _cansleep change that has been made in the meantime.

 I've tested this on Beagleboard xM, I'd really like to get an ack from
 the 3430 sdp and OMAP5 guys before getting this merged.

 v3 - Brown paper bag its too early in the morning actually run
     git commit amend fix
 v2 - Put cansleep gpiolib call outside of spinlock

 Signed-off-by: Russ Dill russ.d...@gmail.com
 ---
  drivers/mfd/omap-usb-host.c  |   48 
 +-
  drivers/usb/host/ehci-omap.c |   18 +++-
  2 files changed, 55 insertions(+), 11 deletions(-)

 diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
 index 7e96bb2..41088ec 100644
 --- a/drivers/mfd/omap-usb-host.c
 +++ b/drivers/mfd/omap-usb-host.c
 @@ -25,6 +25,7 @@
  #include linux/clk.h
  #include linux/dma-mapping.h
  #include linux/spinlock.h
 +#include linux/gpio.h
  #include plat/cpu.h
  #include plat/usb.h
  #include linux/pm_runtime.h
 @@ -500,8 +501,21 @@ static void omap_usbhs_init(struct device *dev)
        dev_dbg(dev, starting TI HSUSB Controller\n);

        pm_runtime_get_sync(dev);
 -       spin_lock_irqsave(omap-lock, flags);

 +       if (pdata-ehci_data-phy_reset) {
 +               if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[0]))
 +                       gpio_request_one(pdata-ehci_data-reset_gpio_port[0],
 +                                        GPIOF_OUT_INIT_LOW, USB1 PHY 
 reset);
 +
 +               if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[1]))
 +                       gpio_request_one(pdata-ehci_data-reset_gpio_port[1],
 +                                        GPIOF_OUT_INIT_LOW, USB2 PHY 
 reset);
 +
 +               /* Hold the PHY in RESET for enough time till DIR is high */
 +               udelay(10);
 +       }
 +
 +       spin_lock_irqsave(omap-lock, flags);
        omap-usbhs_rev = usbhs_read(omap-uhh_base, OMAP_UHH_REVISION);
        dev_dbg(dev, OMAP UHH_REVISION 0x%x\n, omap-usbhs_rev);

 @@ -581,9 +595,39 @@ static void omap_usbhs_init(struct device *dev)
        }

        spin_unlock_irqrestore(omap-lock, flags);
 +
 +       if (pdata-ehci_data-phy_reset) {
 +               /* Hold the PHY in RESET for enough time till
 +                * PHY is settled and ready
 +                */
 +               udelay(10);
 +
 +               if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[0]))
 +                       gpio_set_value_cansleep
 +                               (pdata-ehci_data-reset_gpio_port[0], 1);
 +
 +               if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[1]))
 +                       gpio_set_value_cansleep
 +                               (pdata-ehci_data-reset_gpio_port[1], 1);
 +       }
 +
        pm_runtime_put_sync(dev);
  }

 +static void omap_usbhs_deinit(struct device *dev)
 +{
 +       struct usbhs_hcd_omap           *omap = dev_get_drvdata(dev);
 +       struct usbhs_omap_platform_data *pdata = omap-platdata;
 +
 +       if (pdata-ehci_data-phy_reset) {
 +               if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[0]))
 +                       gpio_free(pdata-ehci_data-reset_gpio_port[0]);
 +
 +               if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[1]))
 +                       gpio_free(pdata

Re: MFD USB host: prevents CORE retention in idle

2012-06-15 Thread Munegowda, Keshava

On Tue, Jun 12, 2012 at 6:28 PM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
 hi kevin
     now I am using initramfs with kernel linux3.5.rc1,
 but the retention is not working in 3430 sdp.  I am seeing the following
 error followed by a crash


 echo mem  /sys/power/state
 [   35.609252] PM: Syncing filesystems ... done.
 [   35.614654] PM: Preparing system for mem sleep
 [   35.658630] Freezing user space processes ... (elapsed 0.01 seconds)
 done.
 [   35.689727] Freezing remaining freezable tasks ... (elapsed 0.02 seconds)
 done.
 [   35.697692] PM: Entering mem sleep
 [   35.722442] usb usb1: usb auto-resume
 [   35.726409] ehci-omap ehci-omap.0: resume root hub
 [   35.775451] hub 1-0:1.0: hub_resume
 [   35.779846] hub 1-0:1.0: hub_suspend
 [   35.784240] usb usb1: bus suspend, wakeup 0
 [   35.788665] ehci-omap ehci-omap.0: suspend root hub
 [   35.805786] PM: suspend of devices complete after 99.304 msecs
 [   35.816497] PM: late suspend of devices complete after 4.364 msecs
 [   35.831573] PM: noirq suspend of devices complete after 8.331 msecs
 [   35.838500] Disabling non-boot CPUs ...
 [   36.312164] Powerdomain (core_pwrdm) didn't enter target state 1
 [   36.318481] Could not enter target state in pm_suspend
 [   36.324859] Unable to handle kernel NULL pointer dereference at virtual
 address 0018
 [   36.333557] pgd = c628
 [   36.336639] [0018] *pgd=85c8f831, *pte=, *ppte=
 [   36.343414] Internal error: Oops: 17 [#1] SMP ARM
 [   36.348388] Modules linked in:
 [   36.351623] CPU: 0    Tainted: G    W (3.5.0-rc1 #1)
 [   36.357574] PC is at _od_resume_noirq+0x14/0x58
 [   36.362365] LR is at dpm_run_callback+0x2c/0x74
 [   36.367126] pc : [c003c150]    lr : [c02d75e4]    psr: a013
 [   36.367126] sp : c5ebfe80  ip : c0a72fc0  fp : 0006
 [   36.379150] r10: c78af4b8  r9 : c0a3607c  r8 : c003c13c
 [   36.384643] r7 :   r6 :   r5 : c78af408  r4 : c78af408
 [   36.391479] r3 :   r2 :   r1 : c78af408  r0 : c78af400
 [   36.398315] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment
 user
 [   36.405792] Control: 10c5387d  Table: 86280019  DAC: 0015
 [   36.411834] Process sh (pid: 1254, stack limit = 0xc5ebe2f8)
 [   36.417785] Stack: (0xc5ebfe80 to 0xc5ec)
 [   36.422363] fe80: c78af408 c02d75e4 c0a36020 c0a36040  
 c78af408 c0f9e4a8
 [   36.430938] fea0: 0010 c0a36014 c0a36074 c02d8178 58566b0d 0008
 58566b0d 0008
 [   36.439514] fec0: c0a1df38 0010  0003 c0a4d11c 
  c09da45c
 [   36.448089] fee0: 000ed008 c02d8a14 c0a62c28 c0080360 0003 c05b9ce8
  0004
 [   36.456665] ff00:  c04c9704 c78012c0 c00806a4 c5c8e000 0003
 c05b9ce8 c007f8a8
 [   36.465240] ff20: c5c8d4c0 c5c8d4d8 c5ebff80 c7863e00 c02674a8 c02674c0
 0004 c016d7fc
 [   36.473815] ff40: c5d94a80 0004 b6ff6000 c5ebff80  
  c010c244
 [   36.482421] ff60: c0014400 c5c92280 c5d94a80 b6ff6000 0004 0004
  c010c398
 [   36.490997] ff80:   b6f235e8  0004 b6ff6000
 b6f235e8 c00144a8
 [   36.499572] ffa0: c5ebe000 c00142e0 0004 b6ff6000 0001 b6ff6000
 0004 
 [   36.508148] ffc0: 0004 b6ff6000 b6f235e8 0004 0004 0964
 000a 000ed008
 [   36.516723] ffe0: b6ff6000 bee815d0 b6e61c70 b6eb1abc 6010 0001
  
 [   36.525360] [c003c150] (_od_resume_noirq+0x14/0x58) from [c02d75e4]
 (dpm_run_callback+0x2c/0x74)
 [   36.534973] [c02d75e4] (dpm_run_callback+0x2c/0x74) from [c02d8178]
 (dpm_resume_noirq+0xdc/0x2f4)
 [   36.544677] [c02d8178] (dpm_resume_noirq+0xdc/0x2f4) from [c02d8a14]
 (dpm_resume_start+0xc/0x18)
 [   36.554290] [c02d8a14] (dpm_resume_start+0xc/0x18) from [c0080360]
 (suspend_devices_and_enter+0x114/0x2d8)
 [   36.564819] [c0080360] (suspend_devices_and_enter+0x114/0x2d8) from
 [c00806a4] (pm_suspend+0x180/0x1fc)
 [   36.575042] [c00806a4] (pm_suspend+0x180/0x1fc) from [c007f8a8]
 (state_store+0x90/0x124)
 [   36.583953] [c007f8a8] (state_store+0x90/0x124) from [c02674c0]
 (kobj_attr_store+0x18/0x1c)
 [   36.593109] [c02674c0] (kobj_attr_store+0x18/0x1c) from [c016d7fc]
 (sysfs_write_file+0xfc/0x180)
 [   36.602722] [c016d7fc] (sysfs_write_file+0xfc/0x180) from [c010c244]
 (vfs_write+0xb0/0x134)
 [   36.611877] [c010c244] (vfs_write+0xb0/0x134) from [c010c398]
 (sys_write+0x40/0x70)
 [   36.620300] [c010c398] (sys_write+0x40/0x70) from [c00142e0]
 (ret_fast_syscall+0x0/0x3c)
 [   36.629180] Code: e1a04000 e258 01a02000 15902248 (e5d23018)
 [   36.635833] ---[ end trace b3b167c1e86e5512 ]---


 which kernel version are you using? do you have any good commit on which
 retention works because of usb host?


 regards
 keshava



 On Fri, Jun 8, 2012 at 7:55 PM, Munegowda, Keshava keshava_mgo...@ti.com
 wrote:

 yes! I am using the ramfs.

 regards
 keshava



 On Fri, Jun 8, 2012 at 7:31 PM, Kevin Hilman khil

Re: MFD USB host: prevents CORE retention in idle

2012-05-24 Thread Munegowda, Keshava

On Thu, May 24, 2012 at 5:55 AM, Kevin Hilman khil...@ti.com wrote:
 On 05/23/2012 05:01 PM, Kevin Hilman wrote:

 Hi Keshava,

 Using current l-o master, I noticed that CORE was not hitting retention
 in idle on my 3530/Overo.  CORE hits retention on suspend just fine.

 Debugging this, I found that usbtll_fck was still enabled during idle,
 thus preventing CORE from hitting retention.

 To test, I disabled USB host (CONFIG_MFD_OMAP_USB_HOST=n in .config) and
 was then started seeing CORE hit retention in idle again.

 I have nothing plugged into the USB host port on this board, so I
 would've expected that runtime PM would've kicked in and shutdown this
 clock.

 Any ideas what's going on here?  Is this expected behavior?


 If it helps, attached is a bootlog after enabling debug for
 mfd/omap-usb-host.c as well.  Notice there's a couple of clock-related
 warnings from this driver as well.  Not sure if they're relevant:

 usbhs_omap: alias fck already exists
 usbhs_omap usbhs_omap: xclk60mhsp2_ck set parentfailed error:-22

these clocks were specific to omap4 and it should not cause any
problem to omap3 boards.

I will try to reproduce this on 3430 sdp to explore further.



 With debug enabled, I see the runtime resume during init followed by the
 runtime suspend.

 [    0.936248] usbhs_omap usbhs_omap: xclk60mhsp2_ck set parentfailed
 error:-22
 [    0.944152] usbhs_omap usbhs_omap: starting TI HSUSB Controller
 [    0.944335] usbhs_omap usbhs_omap: usbhs_runtime_resume
 [    0.944641] usbhs_omap usbhs_omap: OMAP UHH_REVISION 0x10
 [    0.944641] usbhs_omap usbhs_omap: OMAP3 ES version  ES2.1
 [    0.944671] usbhs_omap usbhs_omap: UHH setup done,ry
 uhh_hostconfig=8000121d
 [    0.947082] usbhs_omap usbhs_omap: usbhs_runtime_suspend

 However, later in the boot I see a runtime_resume and never see another
 suspend.  That seems to be the root cause of CORE not hitting retention.

 From the boot log:

 [    2.018707] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
 [    2.025787] ehci_hcd: block sizes: qh 64 qtd 96 itd 160 sitd 96
 [    2.026306] ehci-omap ehci-omap.0: failed to get ehci port1 regulator
 [    2.026519] usbhs_omap usbhs_omap: usbhs_runtime_resume
 [    3.030639] ehci-omap ehci-omap.0: phy reset operation timed out
 [    3.030700] ehci-omap ehci-omap.0: reset hcs_params 0x1313 dbg=0 cc=1
 pcc=3 ordered ports=3
 [    3.030731] ehci-omap ehci-omap.0: reset hcc_params 0016 thresh 1 uframes
 256/512/1024 park
 [    3.030761] ehci-omap ehci-omap.0: reset command 0080b02  park=3
 ithresh=8 period=1024 Reset HALT
 [    3.030792] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller

 Since the only get/puts I see are in omap_usbhs_init(), I'm not sure how
 this driver is being runtime resumed.  Presumably it's due to how the rest
 of the USB stack works, which I'm not at all familiar with.

 Hopefully, the above is enough to debug the problem,

 Thanks,

 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] Fix build breakage in omap-usb-host.c

2012-04-23 Thread Munegowda, Keshava

On Sun, Apr 22, 2012 at 2:20 PM, Russ Dill russ.d...@ti.com wrote:
 On Sun, Apr 22, 2012 at 1:48 AM, Russ Dill russ.d...@ti.com wrote:
 'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' removes the include for
 linux/gpio.h from omap-usb-host.c. This include indirectly includes 
 plat/cpu.h
 which is required by omap-usb-host.c. Fix the build breakage by including
 it directly.

 (Sorry, I should add some detail, this is a build breakage in linux-next)

Russ Dill and Anatolij Gustschin

Both patches fixes the same issue; But here , I am seeing Russ Dill
has sent earlier (in my mailbox it shows 21 hours ago)
Here my ack by:

Acked-by:  Keshava Munegowda keshava_mgo...@ti.com

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 RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue

2012-04-17 Thread Munegowda, Keshava

On Mon, Apr 16, 2012 at 10:16 PM, Samuel Ortiz sa...@linux.intel.com wrote:
 Hi Keshava,

 On Wed, Apr 11, 2012 at 05:15:03PM +0530, Munegowda, Keshava wrote:
 On Tue, Mar 27, 2012 at 8:40 PM, Igor Grinberg grinb...@compulab.co.il 
 wrote:
  On 03/19/12 08:42, Keshava Munegowda wrote:
  From: Keshava Munegowda keshava_mgo...@ti.com
 
  It is observed that the echi ports of 3430 sdp board
  are not working due to the random timing of programming
  the associated GPIOs of the ULPI PHYs of the EHCI for reset.
  If the PHYs are reset at during usbhs core driver, host ports will
  not work because EHCI driver is loaded after the resetting PHYs.
  The PHYs should be in reset state while initializing the EHCI
  controller.
  The code which does the GPIO pins associated with the PHYs
  are programmed to reset is moved from the USB host core driver
  to EHCI driver.
 
  Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
  Reviewed-by: Partha Basak part...@india.ti.com
 
  Both EHCI ports worked on cm-t3730 previously and
  no regression is seen with this patch.
 
  Tested-by: Igor Grinberg grinb...@compulab.co.il
 
  --
  Regards,
  Igor.

 Hi sameo
          Since I am not seeing this patch in linux-next labled 3.4.rc2
 on 10th april 2012;
  please let me know your plan to queue this patch for the main line.
 I applied this one to my for-linus branch, thanks.

 Cheers,
 Samuel.

 --
 Intel Open Source Technology Centre
 http://oss.intel.com/

Thank a lot Samuel

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 RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue

2012-04-11 Thread Munegowda, Keshava

On Tue, Mar 27, 2012 at 8:40 PM, Igor Grinberg grinb...@compulab.co.il wrote:
 On 03/19/12 08:42, Keshava Munegowda wrote:
 From: Keshava Munegowda keshava_mgo...@ti.com

 It is observed that the echi ports of 3430 sdp board
 are not working due to the random timing of programming
 the associated GPIOs of the ULPI PHYs of the EHCI for reset.
 If the PHYs are reset at during usbhs core driver, host ports will
 not work because EHCI driver is loaded after the resetting PHYs.
 The PHYs should be in reset state while initializing the EHCI
 controller.
 The code which does the GPIO pins associated with the PHYs
 are programmed to reset is moved from the USB host core driver
 to EHCI driver.

 Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
 Reviewed-by: Partha Basak part...@india.ti.com

 Both EHCI ports worked on cm-t3730 previously and
 no regression is seen with this patch.

 Tested-by: Igor Grinberg grinb...@compulab.co.il

 --
 Regards,
 Igor.

Hi sameo
 Since I am not seeing this patch in linux-next labled 3.4.rc2
on 10th april 2012;
 please let me know your plan to queue this patch for the main line.

Thanks and 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] ARM: OMAP: USB: fix warning on EHCI PHY reset path

2012-03-28 Thread Munegowda, Keshava

On Wed, Mar 28, 2012 at 4:23 PM, Raja, Govindraj govindraj.r...@ti.com wrote:
 On Wed, Mar 28, 2012 at 2:22 PM, Felipe Balbi ba...@ti.com wrote:
 On Tue, Mar 27, 2012 at 04:08:55PM +0200, Igor Grinberg wrote:
 When PHY reset pin is connected to a GPIO on external GPIO chip
 (e.g. I2C), we should not call the gpio_set_value() function, but
 gpio_set_value_cansleep().

 Signed-off-by: Igor Grinberg grinb...@compulab.co.il

 Acked-by: Felipe Balbi ba...@ti.com

 Keshava, please give us your tested-by. Patch looks fine to me.

 Tried on beagle-xm where the smsc hub + smsc95xx ethernet controller
 relies gpio nreset sequence for initialization.

 Both hub + Ethernet controller get enumerated even after this patch.

 Tested-by: Govindraj.R govindraj.r...@ti.com



Thanks govind.



 ---
 This patch depends on the patch from Keshava [1]:
 ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue

 [1] http://www.spinics.net/lists/linux-omap/msg66774.html

  drivers/usb/host/ehci-omap.c |    4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
 index 5c78f9e..26e9241 100644
 --- a/drivers/usb/host/ehci-omap.c
 +++ b/drivers/usb/host/ehci-omap.c
 @@ -258,10 +258,10 @@ static int ehci_hcd_omap_probe(struct platform_device 
 *pdev)
               udelay(10);

               if (gpio_is_valid(pdata-reset_gpio_port[0]))
 -                     gpio_set_value(pdata-reset_gpio_port[0], 1);
 +                     gpio_set_value_cansleep(pdata-reset_gpio_port[0], 1);

               if (gpio_is_valid(pdata-reset_gpio_port[1]))
 -                     gpio_set_value(pdata-reset_gpio_port[1], 1);
 +                     gpio_set_value_cansleep(pdata-reset_gpio_port[1], 1);
       }

       return 0;
 --
 1.7.3.4


 --
 balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue

2012-03-21 Thread Munegowda, Keshava

On Tue, Mar 20, 2012 at 9:25 PM, Felipe Balbi ba...@ti.com wrote:
 On Tue, Mar 20, 2012 at 04:53:53PM +0100, Samuel Ortiz wrote:
 Hi Keshava,

 On Mon, Mar 19, 2012 at 12:12:47PM +0530, Keshava Munegowda wrote:
  From: Keshava Munegowda keshava_mgo...@ti.com
 
  It is observed that the echi ports of 3430 sdp board
  are not working due to the random timing of programming
  the associated GPIOs of the ULPI PHYs of the EHCI for reset.
  If the PHYs are reset at during usbhs core driver, host ports will
  not work because EHCI driver is loaded after the resetting PHYs.
  The PHYs should be in reset state while initializing the EHCI
  controller.
  The code which does the GPIO pins associated with the PHYs
  are programmed to reset is moved from the USB host core driver
  to EHCI driver.
 
  Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
  Reviewed-by: Partha Basak part...@india.ti.com
 Felipe, are you ok with that patch ?
 I'll most likely queue it after this merge window is closed though.

 my bad, here's my Ack:

 Acked-by: Felipe Balbi ba...@ti.com

 --
 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 1/5 RESEND] ARM: OMAP: USB: HOST TLL platform driver

On Mon, Mar 19, 2012 at 4:39 PM, Sergei Shtylyov sshtyl...@mvista.com wrote:
 Hello.


 On 19-03-2012 14:06, Felipe Balbi wrote:

 +       ver =  usbtll_read(base, OMAP_USBTLL_REVISION);
 +       if (ver == OMAP_USBTLL_REV1)
 +               count = OMAP_TLL_CHANNEL_COUNT;
 +       else if (ver == OMAP_USBTLL_REV2)
 +               count = OMAP_REV2_TLL_CHANNEL_COUNT;
 +       else {
 +               dev_err(dev, TLL version failed\n);
 +               ret = -ENODEV;
 +               goto err_ioremap;
 +       }


 wrong coding style.


   And *switch* seems more fitting here.

 WBR, Sergei

Thanks , I will do this,
--
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 1/5 RESEND] ARM: OMAP: USB: HOST TLL platform driver

On Mon, Mar 19, 2012 at 3:11 PM, Shubhrajyoti shubhrajy...@ti.com wrote:
 Hi Keshava,
 Some doubts / comments .
 On Monday 19 March 2012 12:18 PM, Keshava Munegowda wrote:
 From: Keshava Munegowda keshava_mgo...@ti.com

 The platform driver for the TLL component of the OMAP USB host controller
 is implemented. Depending on the TLL hardware revision , the TLL channels
 are configured. The USB HS core driver uses this driver through exported
 APIs from the TLL platform driver.
 usb_tll_enable and usb_tll_disble are the exported APIs of the USB TLL
 platform driver.

 Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
 Reviewed-by: Partha Basak part...@india.ti.com
 ---
  arch/arm/plat-omap/include/plat/usb.h |    8 +
  drivers/mfd/Kconfig                   |    2 +-
  drivers/mfd/Makefile                  |    2 +-
  drivers/mfd/omap-usb-tll.c            |  463 
 +
  4 files changed, 473 insertions(+), 2 deletions(-)
  create mode 100644 drivers/mfd/omap-usb-tll.c

 diff --git a/arch/arm/plat-omap/include/plat/usb.h 
 b/arch/arm/plat-omap/include/plat/usb.h
 index dc864b5..eb1e47d 100644
 --- a/arch/arm/plat-omap/include/plat/usb.h
 +++ b/arch/arm/plat-omap/include/plat/usb.h
 @@ -61,6 +61,10 @@ struct usbhs_omap_platform_data {
       struct ehci_hcd_omap_platform_data      *ehci_data;
       struct ohci_hcd_omap_platform_data      *ohci_data;
  };
 +
 +struct usbtll_omap_platform_data {
 +     enum usbhs_omap_port_mode               port_mode[OMAP3_HS_USB_PORTS];
 +};
  /*-*/

  #define OMAP1_OTG_BASE                       0xfffb0400
 @@ -105,6 +109,10 @@ extern int omap4430_phy_set_clk(struct device *dev, int 
 on);
  extern int omap4430_phy_init(struct device *dev);
  extern int omap4430_phy_exit(struct device *dev);
  extern int omap4430_phy_suspend(struct device *dev, int suspend);
 +
 +extern int omap_tll_enable(void);
 +extern int omap_tll_disable(void);
 +
  #endif

  extern void am35x_musb_reset(void);
 diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
 index f147395..5f75ad4 100644
 --- a/drivers/mfd/Kconfig
 +++ b/drivers/mfd/Kconfig
 @@ -772,7 +772,7 @@ config MFD_WL1273_CORE
         audio codec.

  config MFD_OMAP_USB_HOST
 -     bool Support OMAP USBHS core driver
 +     bool Support OMAP USBHS core and TLL driver
       depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3
       default y
       help
 diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
 index b953bab..4b3a8e0 100644
 --- a/drivers/mfd/Makefile
 +++ b/drivers/mfd/Makefile
 @@ -105,7 +105,7 @@ obj-$(CONFIG_MFD_TPS6586X)        += tps6586x.o
  obj-$(CONFIG_MFD_VX855)              += vx855.o
  obj-$(CONFIG_MFD_WL1273_CORE)        += wl1273-core.o
  obj-$(CONFIG_MFD_CS5535)     += cs5535-mfd.o
 -obj-$(CONFIG_MFD_OMAP_USB_HOST)      += omap-usb-host.o
 +obj-$(CONFIG_MFD_OMAP_USB_HOST)      += omap-usb-host.o omap-usb-tll.o
  obj-$(CONFIG_MFD_PM8921_CORE)        += pm8921-core.o
  obj-$(CONFIG_MFD_PM8XXX_IRQ)         += pm8xxx-irq.o
  obj-$(CONFIG_TPS65911_COMPARATOR)    += tps65911-comparator.o
 diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
 new file mode 100644
 index 000..3da468a
 --- /dev/null
 +++ b/drivers/mfd/omap-usb-tll.c
 @@ -0,0 +1,463 @@
 +/**
 + * omap-usb-tll.c - The USB TLL driver for OMAP EHCI  OHCI
 + *
 + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com
 Nitpick : 2012
 + * Author: Keshava Munegowda keshava_mgo...@ti.com
 + *
 + * This program is free software: you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2  of
 + * the License as published by the Free Software Foundation.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + *
 + * You should have received a copy of the GNU General Public License
 + * along with this program.  If not, see http://www.gnu.org/licenses/.
 + */
 +#include linux/kernel.h
 +#include linux/module.h
 +#include linux/types.h
 +#include linux/slab.h
 +#include linux/spinlock.h
 +#include linux/platform_device.h
 +#include linux/clk.h
 +#include linux/io.h
 +#include linux/err.h
 +#include plat/usb.h
 +#include linux/pm_runtime.h
 +
 +#define USBTLL_DRIVER_NAME   usbhs_tll
 +
 +/* TLL Register Set */
 +#define      OMAP_USBTLL_REVISION                            (0x00)
 +#define      OMAP_USBTLL_SYSCONFIG                           (0x10)
 +#define      OMAP_USBTLL_SYSCONFIG_CACTIVITY                 (1  8)
 +#define      OMAP_USBTLL_SYSCONFIG_SIDLEMODE                 (1  3)
 +#define      OMAP_USBTLL_SYSCONFIG_ENAWAKEUP                 (1  2)
 +#define      OMAP_USBTLL_SYSCONFIG_SOFTRESET                 (1  1)
 +#define      OMAP_USBTLL_SYSCONFIG_AUTOIDLE

Re: [PATCH 1/5 RESEND] ARM: OMAP: USB: HOST TLL platform driver

On Mon, Mar 19, 2012 at 12:18 PM, Keshava Munegowda
keshava_mgo...@ti.com wrote:
 From: Keshava Munegowda keshava_mgo...@ti.com

 The platform driver for the TLL component of the OMAP USB host controller
 is implemented. Depending on the TLL hardware revision , the TLL channels
 are configured. The USB HS core driver uses this driver through exported
 APIs from the TLL platform driver.
 usb_tll_enable and usb_tll_disble are the exported APIs of the USB TLL
 platform driver.

 Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
 Reviewed-by: Partha Basak part...@india.ti.com
 ---
  arch/arm/plat-omap/include/plat/usb.h |    8 +
  drivers/mfd/Kconfig                   |    2 +-
  drivers/mfd/Makefile                  |    2 +-
  drivers/mfd/omap-usb-tll.c            |  463 
 +
  4 files changed, 473 insertions(+), 2 deletions(-)
  create mode 100644 drivers/mfd/omap-usb-tll.c

 diff --git a/arch/arm/plat-omap/include/plat/usb.h 
 b/arch/arm/plat-omap/include/plat/usb.h
 index dc864b5..eb1e47d 100644
 --- a/arch/arm/plat-omap/include/plat/usb.h
 +++ b/arch/arm/plat-omap/include/plat/usb.h
 @@ -61,6 +61,10 @@ struct usbhs_omap_platform_data {
        struct ehci_hcd_omap_platform_data      *ehci_data;
        struct ohci_hcd_omap_platform_data      *ohci_data;
  };
 +
 +struct usbtll_omap_platform_data {
 +       enum usbhs_omap_port_mode               port_mode[OMAP3_HS_USB_PORTS];
 +};
  /*-*/

  #define OMAP1_OTG_BASE                 0xfffb0400
 @@ -105,6 +109,10 @@ extern int omap4430_phy_set_clk(struct device *dev, int 
 on);
  extern int omap4430_phy_init(struct device *dev);
  extern int omap4430_phy_exit(struct device *dev);
  extern int omap4430_phy_suspend(struct device *dev, int suspend);
 +
 +extern int omap_tll_enable(void);
 +extern int omap_tll_disable(void);
 +
  #endif

  extern void am35x_musb_reset(void);
 diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
 index f147395..5f75ad4 100644
 --- a/drivers/mfd/Kconfig
 +++ b/drivers/mfd/Kconfig
 @@ -772,7 +772,7 @@ config MFD_WL1273_CORE
          audio codec.

  config MFD_OMAP_USB_HOST
 -       bool Support OMAP USBHS core driver
 +       bool Support OMAP USBHS core and TLL driver
        depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3
        default y
        help
 diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
 index b953bab..4b3a8e0 100644
 --- a/drivers/mfd/Makefile
 +++ b/drivers/mfd/Makefile
 @@ -105,7 +105,7 @@ obj-$(CONFIG_MFD_TPS6586X)  += tps6586x.o
  obj-$(CONFIG_MFD_VX855)                += vx855.o
  obj-$(CONFIG_MFD_WL1273_CORE)  += wl1273-core.o
  obj-$(CONFIG_MFD_CS5535)       += cs5535-mfd.o
 -obj-$(CONFIG_MFD_OMAP_USB_HOST)        += omap-usb-host.o
 +obj-$(CONFIG_MFD_OMAP_USB_HOST)        += omap-usb-host.o omap-usb-tll.o
  obj-$(CONFIG_MFD_PM8921_CORE)  += pm8921-core.o
  obj-$(CONFIG_MFD_PM8XXX_IRQ)   += pm8xxx-irq.o
  obj-$(CONFIG_TPS65911_COMPARATOR)      += tps65911-comparator.o
 diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
 new file mode 100644
 index 000..3da468a
 --- /dev/null
 +++ b/drivers/mfd/omap-usb-tll.c
 @@ -0,0 +1,463 @@
 +/**
 + * omap-usb-tll.c - The USB TLL driver for OMAP EHCI  OHCI
 + *
 + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com
 + * Author: Keshava Munegowda keshava_mgo...@ti.com
 + *
 + * This program is free software: you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2  of
 + * the License as published by the Free Software Foundation.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + *
 + * You should have received a copy of the GNU General Public License
 + * along with this program.  If not, see http://www.gnu.org/licenses/.
 + */
 +#include linux/kernel.h
 +#include linux/module.h
 +#include linux/types.h
 +#include linux/slab.h
 +#include linux/spinlock.h
 +#include linux/platform_device.h
 +#include linux/clk.h
 +#include linux/io.h
 +#include linux/err.h
 +#include plat/usb.h
 +#include linux/pm_runtime.h
 +
 +#define USBTLL_DRIVER_NAME     usbhs_tll
 +
 +/* TLL Register Set */
 +#define        OMAP_USBTLL_REVISION                            (0x00)
 +#define        OMAP_USBTLL_SYSCONFIG                           (0x10)
 +#define        OMAP_USBTLL_SYSCONFIG_CACTIVITY                 (1  8)
 +#define        OMAP_USBTLL_SYSCONFIG_SIDLEMODE                 (1  3)
 +#define        OMAP_USBTLL_SYSCONFIG_ENAWAKEUP                 (1  2)
 +#define        OMAP_USBTLL_SYSCONFIG_SOFTRESET                 (1  1)
 +#define        OMAP_USBTLL_SYSCONFIG_AUTOIDLE                  (1  0)
 +
 +#define        OMAP_USBTLL_SYSSTATUS                           (0x14)

Re: [PATCH 1/5 RESEND] ARM: OMAP: USB: HOST TLL platform driver

On Tue, Mar 20, 2012 at 2:22 PM, Shubhrajyoti shubhrajy...@ti.com wrote:
 Hi Keshava,

 On Tuesday 20 March 2012 12:58 PM, Munegowda, Keshava wrote:Snip
 +}
 +
 +static const struct dev_pm_ops usbtllomap_dev_pm_ops = {
 +     .runtime_suspend        = usbtll_runtime_suspend,
 +     .runtime_resume         = usbtll_runtime_resume,
 +};
 +
 Also how about using runtime_pm_ops ?
 Sorry I din't get this? what exact alternative are you suggesting here?

 SET_RUNTIME_PM_OPS(usbtll_runtime_suspend,
                                usbtll_runtime_resume, NULL)

 I should have been clearer.

Thanks, I will do this , I think Felipe has already pointed out this.

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 1/5 RESEND] ARM: OMAP: USB: HOST TLL platform driver

On Mon, Mar 19, 2012 at 3:36 PM, Felipe Balbi ba...@ti.com wrote:
 Hi,

 On Mon, Mar 19, 2012 at 12:18:31PM +0530, Keshava Munegowda wrote:
 +     ver =  usbtll_read(base, OMAP_USBTLL_REVISION);
 +     if (ver == OMAP_USBTLL_REV1)
 +             count = OMAP_TLL_CHANNEL_COUNT;
 +     else if (ver == OMAP_USBTLL_REV2)
 +             count = OMAP_REV2_TLL_CHANNEL_COUNT;
 +     else {
 +             dev_err(dev, TLL version failed\n);
 +             ret = -ENODEV;
 +             goto err_ioremap;
 +     }

 wrong coding style.

 +static const struct dev_pm_ops usbtllomap_dev_pm_ops = {
 +     .runtime_suspend        = usbtll_runtime_suspend,
 +     .runtime_resume         = usbtll_runtime_resume,

 use SET_RUNTIME_PM_OPS()

 +static struct platform_driver usbtll_omap_driver = {
 +     .driver = {
 +             .name           = (char *)usbtll_driver_name,
 +             .owner          = THIS_MODULE,
 +             .pm             = usbtllomap_dev_pm_ops,
 +     },
 +     .remove         = __exit_p(usbtll_omap_remove),

 __devexit_p()

 +};
 +
 +int omap_tll_enable(void)
 +{
 +     if (!tll_pdev) {
 +             dev_dbg(tll_pdev-dev, missing platform_data\n);
 +             return  -ENODEV;
 +     }
 +     return pm_runtime_get_sync(tll_pdev-dev);
 +}
 +EXPORT_SYMBOL_GPL(omap_tll_enable);

 why ?

the usb hs core driver uses omap_tll_enable and omap_tll_disable
apis based on the port selection in ./drivers/mfd/omap-usb-host.c file.


 +
 +int omap_tll_disable(void)
 +{
 +     if (!tll_pdev) {
 +             dev_dbg(tll_pdev-dev, missing platform_data\n);
 +             return  -ENODEV;
 +     }
 +     return pm_runtime_put_sync(tll_pdev-dev);
 +}
 +EXPORT_SYMBOL_GPL(omap_tll_disable);

 why ?

 +MODULE_AUTHOR(Keshava Munegowda keshava_mgo...@ti.com);
 +MODULE_ALIAS(platform: USBHS_DRIVER_NAME);
 +MODULE_LICENSE(GPL v2);
 +MODULE_DESCRIPTION(usb tll driver for TI OMAP EHCI and OHCI controllers);
 +
 +static int __init omap_usbtll_drvinit(void)
 +{
 +     return platform_driver_probe(usbtll_omap_driver, usbtll_omap_probe);

 please don't. Make sure you use platform_driver_register, instead.


Here , omap_usbtll_drvinit is registered through fs_initcall call;
this is required because, the TLL driver is required to initialized
before the UHH ( usb host core) driver.

regards
keshava




 --
 balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5 RESEND] ARM: OMAP: USB: HOST TLL platform driver

On Tue, Mar 20, 2012 at 3:29 PM, Felipe Balbi ba...@ti.com wrote:
 Hi,

 On Tue, Mar 20, 2012 at 03:00:50PM +0530, Munegowda, Keshava wrote:
  +MODULE_AUTHOR(Keshava Munegowda keshava_mgo...@ti.com);
  +MODULE_ALIAS(platform: USBHS_DRIVER_NAME);
  +MODULE_LICENSE(GPL v2);
  +MODULE_DESCRIPTION(usb tll driver for TI OMAP EHCI and OHCI 
  controllers);
  +
  +static int __init omap_usbtll_drvinit(void)
  +{
  +     return platform_driver_probe(usbtll_omap_driver, 
  usbtll_omap_probe);
 
  please don't. Make sure you use platform_driver_register, instead.


 Here , omap_usbtll_drvinit is registered through fs_initcall call;
 this is required because, the TLL driver is required to initialized
 before the UHH ( usb host core) driver.

 no issues with fs_initcall. The issue is with platform_driver_probe()
 only.

 --
 balbi

Thanks , I got it.
I will take the same comment make the same change in usbhs driver 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] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue

2012-03-19 Thread Munegowda, Keshava

On Fri, Mar 16, 2012 at 9:50 PM, Samuel Ortiz sa...@linux.intel.com wrote:
 Hi Keshava,

 On Thu, Mar 08, 2012 at 08:30:21PM +0530, Munegowda, Keshava wrote:
 On Fri, Mar 2, 2012 at 7:36 PM, Munegowda, Keshava
 keshava_mgo...@ti.com wrote:
  On Fri, Feb 24, 2012 at 5:14 PM, Munegowda, Keshava
  keshava_mgo...@ti.com wrote:
  On Fri, Feb 24, 2012 at 3:46 PM, Felipe Balbi ba...@ti.com wrote:
  Hi,
 
  On Fri, Feb 24, 2012 at 03:36:15PM +0530, Keshava Munegowda wrote:
  From: Keshava Munegowda keshava_mgo...@ti.com
 
  It is observed that the echi ports of 3430 sdp board
  are not working due to the random timing of programming
  the associated GPIOs of the ULPI PHYs of the EHCI for reset.
  If the PHYs are reset at during usbhs core driver, host ports will
  not work because EHCI driver is loaded after the resetting PHYs.
  The PHYs should be in reset state while initializing the EHCI
  controller.
  The code which does the GPIO pins associated with the PHYs
  are programmed to reset is moved from the USB host core driver
  to EHCI driver.
 
  Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
  Reviewed-by: Partha Basak part...@india.ti.com
 
  won't this cause issues with EHCI/OHCI interactions ? I mean, what if
  you connect a FS/LS device and port is handed over to OHCI, does OHCI
  have any needs to reset the PHY or something similar ?
 
  No, it will not cause any issues with EHCI-OHCI issues.
  But its difficult to comment on this because we don't have port
  handoff supported
  in hardware.
 
  regards
  keshava
 
  Hi Samuel
         please let me know if you have any comments on this patch.
  This is required patch for omap3 ehci enumeration instabilities.
 
  Regards
  Keshava

 Hi Samuel
       do you have any comments on this patch?
 I actually never received the actual patch, I think.


 Felipe has reviewed this patch and he is agreed for this patch.
 there are no comments from your side, requesting to push this change
 to mainline.
 I looked at it on gmame, and it seems fine to me. If you want me to push this
 patch, then please (re-)send it to me, even privately.

 Cheers,
 Samuel.


Thanks Samuel
   yes, I will resend this 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 0/5] ARM: OMAP: TLL driver implementation for USB host driver

2012-03-19 Thread Munegowda, Keshava

On Fri, Mar 16, 2012 at 10:13 PM, Samuel Ortiz sa...@linux.intel.com wrote:
 Hi Keshava,

 On Mon, Mar 05, 2012 at 08:13:45PM +0530, Munegowda, Keshava wrote:
 On Mon, Mar 5, 2012 at 8:01 PM, Keshava Munegowda keshava_mgo...@ti.com 
 wrote:
  From: Keshava Munegowda keshava_mgo...@ti.com
 
  The TLL configuration is removed from the UHH driver and implemented as
  a seperate platform driver. Now, the UHH driver configures the TLL
  through API's exported by the TLL platform driver. The TLL is an
  has independent hardware mod structure for in OMAP3 and later chips,
  hence an dedicated platform driver is created.
 
  Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
 
  Keshava Munegowda (5):
   ARM: OMAP: USB: HOST TLL platform driver
   ARM: OMAP: USB: Build the USB HOST TLL omap device
   ARM: OMAP: USB: Remove TLL specific code
   ARM: OMAP: USB: Invoke the TLL driver from USB HS core driver
   ARM: OMAP: change the USB TLL clocks device name
 
   arch/arm/mach-omap2/clock3xxx_data.c  |    8 +-
   arch/arm/mach-omap2/clock44xx_data.c  |    4 +-
   arch/arm/mach-omap2/usb-host.c        |   28 ++-
   arch/arm/plat-omap/include/plat/usb.h |    9 +
   drivers/mfd/Kconfig                   |    2 +-
   drivers/mfd/Makefile                  |    2 +-
   drivers/mfd/omap-usb-host.c           |  232 +
   drivers/mfd/omap-usb-tll.c            |  463 
  +
   8 files changed, 513 insertions(+), 235 deletions(-)
   create mode 100644 drivers/mfd/omap-usb-tll.c
 

 Hi Samuel
         just to get your attention; I have added your mail id in the
 to list.
 please let me know  your comments on this patch series;
 Here as well, I don't think I was cc'ed on the original submission. Without
 getting the actual patch, I'll have hard time reviewing it.

 Cheers,
 Samuel.

Sorry,  I resend the series CCing  you

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 RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue

2012-03-19 Thread Munegowda, Keshava

On Mon, Mar 19, 2012 at 7:04 PM, Raja, Govindraj govindraj.r...@ti.com wrote:
 On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda
 keshava_mgo...@ti.com wrote:
 From: Keshava Munegowda keshava_mgo...@ti.com

 It is observed that the echi ports of 3430 sdp board
 are not working due to the random timing of programming
 the associated GPIOs of the ULPI PHYs of the EHCI for reset.
 If the PHYs are reset at during usbhs core driver, host ports will
 not work because EHCI driver is loaded after the resetting PHYs.
 The PHYs should be in reset state while initializing the EHCI
 controller.
 The code which does the GPIO pins associated with the PHYs
 are programmed to reset is moved from the USB host core driver
 to EHCI driver.

 I tested on beagle xm where gpio nreset is requested from
 board file.
 (Basic enumertaion after gpio nreset seems to work fine,
 Hub and smsc lan chip get detected afetr boot up)


 Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
 Reviewed-by: Partha Basak part...@india.ti.com

 Tested-by: Govindraj.R govindraj.r...@ti.com

 ---
  drivers/mfd/omap-usb-host.c  |   44 
 --
  drivers/usb/host/ehci-omap.c |   39 +++-
  2 files changed, 37 insertions(+), 46 deletions(-)

 diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
 index 68ac2c5..9927129 100644
 --- a/drivers/mfd/omap-usb-host.c
 +++ b/drivers/mfd/omap-usb-host.c
 @@ -25,7 +25,6 @@
  #include linux/clk.h
  #include linux/dma-mapping.h
  #include linux/spinlock.h
 -#include linux/gpio.h
  #include plat/usb.h
  #include linux/pm_runtime.h

 @@ -502,19 +501,6 @@ static void omap_usbhs_init(struct device *dev)
        pm_runtime_get_sync(dev);
        spin_lock_irqsave(omap-lock, flags);

 -       if (pdata-ehci_data-phy_reset) {
 -               if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[0]))
 -                       
 gpio_request_one(pdata-ehci_data-reset_gpio_port[0],
 -                                        GPIOF_OUT_INIT_LOW, USB1 PHY 
 reset);
 -
 -               if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[1]))
 -                       
 gpio_request_one(pdata-ehci_data-reset_gpio_port[1],
 -                                        GPIOF_OUT_INIT_LOW, USB2 PHY 
 reset);
 -
 -               /* Hold the PHY in RESET for enough time till DIR is high */
 -               udelay(10);
 -       }
 -
        omap-usbhs_rev = usbhs_read(omap-uhh_base, OMAP_UHH_REVISION);
        dev_dbg(dev, OMAP UHH_REVISION 0x%x\n, omap-usbhs_rev);

 @@ -593,39 +579,10 @@ static void omap_usbhs_init(struct device *dev)
                        usbhs_omap_tll_init(dev, OMAP_TLL_CHANNEL_COUNT);
        }

 -       if (pdata-ehci_data-phy_reset) {
 -               /* Hold the PHY in RESET for enough time till
 -                * PHY is settled and ready
 -                */
 -               udelay(10);
 -
 -               if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[0]))
 -                       gpio_set_value
 -                               (pdata-ehci_data-reset_gpio_port[0], 1);
 -
 -               if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[1]))
 -                       gpio_set_value
 -                               (pdata-ehci_data-reset_gpio_port[1], 1);
 -       }
 -
        spin_unlock_irqrestore(omap-lock, flags);
        pm_runtime_put_sync(dev);
  }

 -static void omap_usbhs_deinit(struct device *dev)
 -{
 -       struct usbhs_hcd_omap           *omap = dev_get_drvdata(dev);
 -       struct usbhs_omap_platform_data *pdata = omap-platdata;
 -
 -       if (pdata-ehci_data-phy_reset) {
 -               if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[0]))
 -                       gpio_free(pdata-ehci_data-reset_gpio_port[0]);
 -
 -               if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[1]))
 -                       gpio_free(pdata-ehci_data-reset_gpio_port[1]);
 -       }
 -}
 -

  /**
  * usbhs_omap_probe - initialize TI-based HCDs
 @@ -861,7 +818,6 @@ static int __devexit usbhs_omap_remove(struct 
 platform_device *pdev)
  {
        struct usbhs_hcd_omap *omap = platform_get_drvdata(pdev);

 -       omap_usbhs_deinit(pdev-dev);
        iounmap(omap-tll_base);
        iounmap(omap-uhh_base);
        clk_put(omap-init_60m_fclk);
 diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
 index bba9850..5c78f9e 100644
 --- a/drivers/usb/host/ehci-omap.c
 +++ b/drivers/usb/host/ehci-omap.c
 @@ -42,6 +42,7 @@
  #include plat/usb.h
  #include linux/regulator/consumer.h
  #include linux/pm_runtime.h
 +#include linux/gpio.h

  /* EHCI Register Set */
  #define EHCI_INSNREG04                                 (0xA0)
 @@ -191,6 +192,19 @@ static int ehci_hcd_omap_probe(struct platform_device 
 *pdev)
                }
        }

 +       if (pdata-phy_reset) {
 +               if (gpio_is_valid(pdata-reset_gpio_port[0]))
 +                       gpio_request_one(pdata-reset_gpio_port[0],
 +

Re: [PATCH] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue

2012-03-08 Thread Munegowda, Keshava

On Fri, Mar 2, 2012 at 7:36 PM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
 On Fri, Feb 24, 2012 at 5:14 PM, Munegowda, Keshava
 keshava_mgo...@ti.com wrote:
 On Fri, Feb 24, 2012 at 3:46 PM, Felipe Balbi ba...@ti.com wrote:
 Hi,

 On Fri, Feb 24, 2012 at 03:36:15PM +0530, Keshava Munegowda wrote:
 From: Keshava Munegowda keshava_mgo...@ti.com

 It is observed that the echi ports of 3430 sdp board
 are not working due to the random timing of programming
 the associated GPIOs of the ULPI PHYs of the EHCI for reset.
 If the PHYs are reset at during usbhs core driver, host ports will
 not work because EHCI driver is loaded after the resetting PHYs.
 The PHYs should be in reset state while initializing the EHCI
 controller.
 The code which does the GPIO pins associated with the PHYs
 are programmed to reset is moved from the USB host core driver
 to EHCI driver.

 Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
 Reviewed-by: Partha Basak part...@india.ti.com

 won't this cause issues with EHCI/OHCI interactions ? I mean, what if
 you connect a FS/LS device and port is handed over to OHCI, does OHCI
 have any needs to reset the PHY or something similar ?

 No, it will not cause any issues with EHCI-OHCI issues.
 But its difficult to comment on this because we don't have port
 handoff supported
 in hardware.

 regards
 keshava

 Hi Samuel
        please let me know if you have any comments on this patch.
 This is required patch for omap3 ehci enumeration instabilities.

 Regards
 Keshava

Hi Samuel
  do you have any comments on this patch?
Felipe has reviewed this patch and he is agreed for this patch.
there are no comments from your side, requesting to push this change
to mainline.

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] ARM: OMAP: USB: fix the pointer type mismatch compilation warning

2012-03-05 Thread Munegowda, Keshava

On Mon, Mar 5, 2012 at 4:53 PM, Govindraj govindraj...@gmail.com wrote:
 On Mon, Mar 5, 2012 at 4:49 PM, Keshava Munegowda keshava_mgo...@ti.com 
 wrote:
 From: Keshava Munegowda keshava_mgo...@ti.com

 The compilation of usb-host.c file was resulting compilation warning
 due to pointer type mismatch in assignment of return pointer type
 of the function omap_device_build_ss to local pointer type.
 This warning is fixed.

 Its fixed already.

 https://lkml.org/lkml/2012/2/14/73

Thanks ;  it by Felipe :)

regards
keshava




 Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
 ---
  arch/arm/mach-omap2/usb-host.c |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
 index 771dc78..88d4a19 100644
 --- a/arch/arm/mach-omap2/usb-host.c
 +++ b/arch/arm/mach-omap2/usb-host.c
 @@ -486,7 +486,7 @@ static void setup_4430ohci_io_mux(const enum 
 usbhs_omap_port_mode *port_mode)
  void __init usbhs_init(const struct usbhs_omap_board_data *pdata)
  {
        struct omap_hwmod       *oh[2];
 -       struct omap_device      *od;
 +       struct platform_device  *od;
        int                     bus_id = -1;
        int                     i;

 --
 1.6.0.4

 --
 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] ARM: OMAP: USB: fix the pointer type mismatch compilation warning

2012-03-05 Thread Munegowda, Keshava

On Mon, Mar 5, 2012 at 5:13 PM, Sergei Shtylyov sshtyl...@mvista.com wrote:
 Hello.


 On 05-03-2012 15:19, Keshava Munegowda wrote:

 From: Keshava Munegowdakeshava_mgo...@ti.com


 The compilation of usb-host.c file was resulting compilation warning
 due to pointer type mismatch in assignment of return pointer type
 of the function omap_device_build_ss to local pointer type.
 This warning is fixed.


 Signed-off-by: Keshava Munegowdakeshava_mgo...@ti.com
 ---
  arch/arm/mach-omap2/usb-host.c |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)


 diff --git a/arch/arm/mach-omap2/usb-host.c
 b/arch/arm/mach-omap2/usb-host.c
 index 771dc78..88d4a19 100644
 --- a/arch/arm/mach-omap2/usb-host.c
 +++ b/arch/arm/mach-omap2/usb-host.c
 @@ -486,7 +486,7 @@ static void setup_4430ohci_io_mux(const enum
 usbhs_omap_port_mode *port_mode)
  void __init usbhs_init(const struct usbhs_omap_board_data *pdata)
  {
        struct omap_hwmod       *oh[2];
 -       struct omap_device      *od;
 +       struct platform_device  *od;


   Makes sense to rename variable to 'pd' then.

 WBR, Sergei

ya, and its already in mainline :)

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 0/5] ARM: OMAP: TLL driver implementation for USB host driver

2012-03-05 Thread Munegowda, Keshava

On Mon, Mar 5, 2012 at 8:01 PM, Keshava Munegowda keshava_mgo...@ti.com wrote:
 From: Keshava Munegowda keshava_mgo...@ti.com

 The TLL configuration is removed from the UHH driver and implemented as
 a seperate platform driver. Now, the UHH driver configures the TLL
 through API's exported by the TLL platform driver. The TLL is an
 has independent hardware mod structure for in OMAP3 and later chips,
 hence an dedicated platform driver is created.

 Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com

 Keshava Munegowda (5):
  ARM: OMAP: USB: HOST TLL platform driver
  ARM: OMAP: USB: Build the USB HOST TLL omap device
  ARM: OMAP: USB: Remove TLL specific code
  ARM: OMAP: USB: Invoke the TLL driver from USB HS core driver
  ARM: OMAP: change the USB TLL clocks device name

  arch/arm/mach-omap2/clock3xxx_data.c  |    8 +-
  arch/arm/mach-omap2/clock44xx_data.c  |    4 +-
  arch/arm/mach-omap2/usb-host.c        |   28 ++-
  arch/arm/plat-omap/include/plat/usb.h |    9 +
  drivers/mfd/Kconfig                   |    2 +-
  drivers/mfd/Makefile                  |    2 +-
  drivers/mfd/omap-usb-host.c           |  232 +
  drivers/mfd/omap-usb-tll.c            |  463 
 +
  8 files changed, 513 insertions(+), 235 deletions(-)
  create mode 100644 drivers/mfd/omap-usb-tll.c


Hi Samuel
just to get your attention; I have added your mail id in the
to list.
please let me know  your comments on this patch series;

This change was strongly suggested by Paul Walmsley during the
OMAP USB host runtime pm adaptations.

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] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue

2012-03-02 Thread Munegowda, Keshava

On Fri, Feb 24, 2012 at 5:14 PM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
 On Fri, Feb 24, 2012 at 3:46 PM, Felipe Balbi ba...@ti.com wrote:
 Hi,

 On Fri, Feb 24, 2012 at 03:36:15PM +0530, Keshava Munegowda wrote:
 From: Keshava Munegowda keshava_mgo...@ti.com

 It is observed that the echi ports of 3430 sdp board
 are not working due to the random timing of programming
 the associated GPIOs of the ULPI PHYs of the EHCI for reset.
 If the PHYs are reset at during usbhs core driver, host ports will
 not work because EHCI driver is loaded after the resetting PHYs.
 The PHYs should be in reset state while initializing the EHCI
 controller.
 The code which does the GPIO pins associated with the PHYs
 are programmed to reset is moved from the USB host core driver
 to EHCI driver.

 Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
 Reviewed-by: Partha Basak part...@india.ti.com

 won't this cause issues with EHCI/OHCI interactions ? I mean, what if
 you connect a FS/LS device and port is handed over to OHCI, does OHCI
 have any needs to reset the PHY or something similar ?

 No, it will not cause any issues with EHCI-OHCI issues.
 But its difficult to comment on this because we don't have port
 handoff supported
 in hardware.

 regards
 keshava

Hi Samuel
please let me know if you have any comments on this patch.
This is required patch for omap3 ehci enumeration instabilities.

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] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue

2012-02-24 Thread Munegowda, Keshava

On Fri, Feb 24, 2012 at 3:46 PM, Felipe Balbi ba...@ti.com wrote:
 Hi,

 On Fri, Feb 24, 2012 at 03:36:15PM +0530, Keshava Munegowda wrote:
 From: Keshava Munegowda keshava_mgo...@ti.com

 It is observed that the echi ports of 3430 sdp board
 are not working due to the random timing of programming
 the associated GPIOs of the ULPI PHYs of the EHCI for reset.
 If the PHYs are reset at during usbhs core driver, host ports will
 not work because EHCI driver is loaded after the resetting PHYs.
 The PHYs should be in reset state while initializing the EHCI
 controller.
 The code which does the GPIO pins associated with the PHYs
 are programmed to reset is moved from the USB host core driver
 to EHCI driver.

 Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
 Reviewed-by: Partha Basak part...@india.ti.com

 won't this cause issues with EHCI/OHCI interactions ? I mean, what if
 you connect a FS/LS device and port is handed over to OHCI, does OHCI
 have any needs to reset the PHY or something similar ?

No, it will not cause any issues with EHCI-OHCI issues.
But its difficult to comment on this because we don't have port
handoff supported
in hardware.

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 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3

2011-10-28 Thread Munegowda, Keshava

On Fri, Oct 28, 2011 at 5:33 PM, Tero Kristo t-kri...@ti.com wrote:
 Hi Again,

 I created a new version of the patch which should be better than this
 hack, I'll send it as an RFC to the l-o list in a bit.

cool ! our discussion helped me.
please send the patch..



 On Thu, 2011-10-13 at 13:49 +0200, Munegowda, Keshava wrote:
 On Thu, Oct 13, 2011 at 4:58 PM, Tero Kristo t-kri...@ti.com wrote:
  On Thu, 2011-10-13 at 09:12 +0200, Munegowda, Keshava wrote:
  On Tue, Sep 27, 2011 at 6:48 PM, Munegowda, Keshava
  keshava_mgo...@ti.com wrote:
   On Tue, Sep 27, 2011 at 6:12 PM, Tero Kristo t-kri...@ti.com wrote:
   On Tue, 2011-09-27 at 08:04 +0200, Basak, Partha wrote:
   
   Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 
   0115040-6. Kotipaikka: Helsinki
  
  
  Texas Instruments Oy, Porkkalankatu 22, 00180 Helsinki, Finland. Business 
  ID: 0115040-6. Domicile: Helsinki
 
 
 Texas Instruments Oy, Porkkalankatu 22, 00180 Helsinki, Finland. Business ID: 
 0115040-6. Domicile: Helsinki

 -Original Message-

 
  
   From: Munegowda, Keshava [mailto:keshava_mgo...@ti.com]
   Sent: Monday, September 26, 2011 7:49 PM
   To: Paul Walmsley; Tero Kristo; b-cous...@ti.com; ba...@ti.com;
   part...@india.ti.com
   Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; linux-
   ker...@vger.kernel.org; gadi...@ti.com; sa...@linux.intel.com;
   t...@atomide.com; khil...@ti.com; johns...@us.ibm.com;
   vishwanath...@ti.com
   Subject: Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod
   structures for omap3
   
   On Sat, Sep 24, 2011 at 12:00 PM, Paul Walmsley p...@pwsan.com 
   wrote:
On Fri, 23 Sep 2011, Munegowda, Keshava wrote:
   
On Thu, Sep 22, 2011 at 11:31 PM, Paul Walmsley p...@pwsan.com
   wrote:
   
But the question arises here , why do we need these ehci and ohci 
as
   two
different hwmods containing only irq and base address? It is 
required
for future - to implement remote wakeup feature for ehci and ohci
   ports
depending on irq-chain handler patches by Tero. Separate hwmods 
for
   ehci
and ohci are needed to enable prcm chain-handler to uniquely 
identify
the wakeup source as ehci or ohci and call only the corresponding
interrupt handler. We will be using omap_hwmod_mux_init for ehci 
and
ohci hwmods to enable I/O wakeup capability for respective 
IO-pads.
Depending on the particular wakeup source(ehci/ohci), the
   corresponding
ehci or ohci irq handler will be called.
   
If ehci and ohci are combined with usbhs hwmod as a single hwmod ,
   then
for every wakeup (either ehci or ohci port wakeup) only the first
interrupt handler will be called (please look at the function
omap_hwmod_mux_handle_irq of
   
/arch/arm/mach-omap2/mux.c file ; in tero's latest patch:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg53139.html)
, so in this
case, if ehci interrupt is the first interrupt , then even for 
ohci
   wakeup
, only ehci interrupt will get called; which will break the
   functionality.
   
Any reason why this couldn't be handled either by:
   
1. adding an IRQ number field to struct omap_hwmod_mux_info, and
   changing
_omap_hwmod_mux_handle_irq() to raise that IRQ number?
   
   
   yes, it is possible by changing the existing irq-chain handler by 
   tero
   Kristo
   
   I am looping tero too.
   
   So here are new requirements for the irq-chain handler
   
   1. The hwmod should have have option to have multiple mux structures
   
   This is something like:
   
   The existing mux structure definition in omap_hwmod [file:
   /arch/arm/plat-omap/include/plat/omap_hwmod.h ] structure
   
    struct omap_hwmod_mux_info      *mux;
   
   it should changed to
   
    struct omap_hwmod_mux_info      **pmux;
        U32                                            mux_cnt;
   
   
   pmux - pointers to mux ; array of mux structures.
   mux_cnt - number of mux per hwmod.
   
   
   2. The mux  omap_hwmod_mux_info  structure should have new member
   called irq, like as follows:
   
   struct omap_hwmod_mux_info {
    int                             nr_pads;
    ...
       
       u32                           irq;
   
   };
   
   Upon wakeup of the I/O pad of the mux , the irq-chain handler should
   invoke the irq handler of the irq numbered map_hwmod_mux_info.irq
   
   3.  There should be SOME WAY to supply the irqs  from hwmod
   structure (omap_hwmod) to mux structure (omap_hwmod_mux_info)
   
   
   if you , tero and other opensource people are aligned on the proposed
   changes on the irq-handler ;
   then it is possible to have two hwmods ( usbhs and tll) for usbhost
   driver.
   please let me know you comments on the above approach.
   
  
   Hello Tero,
  
   I would like to draw your attention to the following thread:
  
   We need to support the following:
   1. Ability to associate

Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3

2011-10-13 Thread Munegowda, Keshava

On Tue, Sep 27, 2011 at 6:48 PM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
On Tue, Sep 27, 2011 at 6:12 PM, Tero Kristo t-kri...@ti.com wrote:
On Tue, 2011-09-27 at 08:04 +0200, Basak, Partha wrote:

Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6.
Kotipaikka: Helsinki

-Original Message-

From: Munegowda, Keshava [mailto:keshava_mgo...@ti.com]
Sent: Monday, September 26, 2011 7:49 PM
To: Paul Walmsley; Tero Kristo; b-cous...@ti.com; ba...@ti.com;
part...@india.ti.com
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; linux-
ker...@vger.kernel.org; gadi...@ti.com; sa...@linux.intel.com;
t...@atomide.com; khil...@ti.com; johns...@us.ibm.com;
vishwanath...@ti.com
Subject: Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod
structures for omap3

On Sat, Sep 24, 2011 at 12:00 PM, Paul Walmsley p...@pwsan.com wrote:
On Fri, 23 Sep 2011, Munegowda, Keshava wrote:

On Thu, Sep 22, 2011 at 11:31 PM, Paul Walmsley p...@pwsan.com
wrote:

But the question arises here , why do we need these ehci and ohci as
two
different hwmods containing only irq and base address? It is required
for future - to implement remote wakeup feature for ehci and ohci
ports
depending on irq-chain handler patches by Tero. Separate hwmods for
ehci
and ohci are needed to enable prcm chain-handler to uniquely identify
the wakeup source as ehci or ohci and call only the corresponding
interrupt handler. We will be using omap_hwmod_mux_init for ehci and
ohci hwmods to enable I/O wakeup capability for respective IO-pads.
Depending on the particular wakeup source(ehci/ohci), the
corresponding
ehci or ohci irq handler will be called.

If ehci and ohci are combined with usbhs hwmod as a single hwmod ,
then
for every wakeup (either ehci or ohci port wakeup) only the first
interrupt handler will be called (please look at the function
omap_hwmod_mux_handle_irq of

/arch/arm/mach-omap2/mux.c file ; in tero's latest patch:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg53139.html)
, so in this
case, if ehci interrupt is the first interrupt , then even for ohci
wakeup
, only ehci interrupt will get called; which will break the
functionality.

Any reason why this couldn't be handled either by:

1. adding an IRQ number field to struct omap_hwmod_mux_info, and
changing
_omap_hwmod_mux_handle_irq() to raise that IRQ number?

yes, it is possible by changing the existing irq-chain handler by tero
Kristo

I am looping tero too.

So here are new requirements for the irq-chain handler

1. The hwmod should have have option to have multiple mux structures

This is something like:

The existing mux structure definition in omap_hwmod [file:
/arch/arm/plat-omap/include/plat/omap_hwmod.h ] structure

struct omap_hwmod_mux_info *mux;

it should changed to

struct omap_hwmod_mux_info **pmux;
U32 mux_cnt;

pmux - pointers to mux ; array of mux structures.
mux_cnt - number of mux per hwmod.

2. The mux omap_hwmod_mux_info structure should have new member
called irq, like as follows:

struct omap_hwmod_mux_info {
int nr_pads;
...
u32 irq;

};

Upon wakeup of the I/O pad of the mux , the irq-chain handler should
invoke the irq handler of the irq numbered map_hwmod_mux_info.irq

3. There should be SOME WAY to supply the irqs from hwmod
structure (omap_hwmod) to mux structure (omap_hwmod_mux_info)

if you , tero and other opensource people are aligned on the proposed
changes on the irq-handler ;
then it is possible to have two hwmods ( usbhs and tll) for usbhost
driver.
please let me know you comments on the above approach.

Hello Tero,

I would like to draw your attention to the following thread:

We need to support the following:
1. Ability to associate multiple mux info to a hwmod.
2. Able to associate a particular irq handler to a mux info.
3. PRCM Chain handler should loop through all mux-info arrays
for a particular hwmod to identify the possible wakeup source(s)
and call the appropriate irq handler for that mux-info.
(It is possible that both mux-info are woken up in which case both
handlers should be called).

To give you a little more perspective, EHCI OHCI are co-controllers
under UHH/TLL.
They do not get presented separately to the OCP bus, hence do not qualify
as separate hwmods
(Paul had objected to the design approach representing EHCI OHCI as
different hwmods).

However, we need a mechanism to efficiently identify/distinguish
remote-wakeup, connect/disconnect
On to an EHCI port vs an OHCI port call only the correct interrupt
handler(EHCI or OHCI).

To incorporate this, chain handler implementation would need some
enhancements.
We can look into the details in the next merge

Re: [PATCH 2/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap3

2011-10-12 Thread Munegowda, Keshava

On Tue, Oct 11, 2011 at 1:29 PM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
 On Tue, Oct 11, 2011 at 11:18 AM, Munegowda, Keshava
 keshava_mgo...@ti.com wrote:
 On Tue, Oct 11, 2011 at 6:08 AM, Paul Walmsley p...@pwsan.com wrote:
 Hi

 so I just noticed another problem with these hwmods:

 On Thu, 6 Oct 2011, Keshava Munegowda wrote:

 Following 2 hwmod structures are added
     1. usb_host_hs
          The hwmod of usbhs with uhh, ehci and ohci base addresses
          functional clock and ehci, ohci irqs

     2. usb_tll_hs
           hwmod of usbhs with the TLL base address and irq.

 Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
 Reviewed-by: Partha Basak part...@india.ti.com
 ---
  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |  227 
 
  1 files changed, 227 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
 b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
 index 59fdb9f..b8ca690 100644
 --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
 +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c

 ...

 +static struct omap_hwmod_ocp_if omap34xx_ick_cfg__usb_tll_hs = {

 This interface is missing a .master and .slave.  It must have both.  So,
 dropping this patch until it's fixed.

 Clearly we also need to modify the hwmod code needs to reject any
 instances where either .master or .slave is NULL.


 - Paul

 Hi Paul
           I will fix it today only and I will send the updated
 patches in couple of hours.
 please help me to make it in this merge window.



 Hi Paul
      I have posted v14 of the patches; please do review
 if it is OK, please merge to your branch for 3.2 version
 please let me know if you have any comments here.

  Thanks and Regards
  keshava


Hi Paul
requesting to please do review the patch set
if it is OK, please merge to your branch for 3.2 version
please let me know if you have any comments.

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 2/5 v14] arm: omap: usb: ehci and ohci hwmod structures for omap3

2011-10-11 Thread Munegowda, Keshava

On Tue, Oct 11, 2011 at 1:21 PM, Keshava Munegowda
keshava_mgo...@ti.com wrote:
 Following 2 hwmod structures are added
    1. usb_host_hs
         The hwmod of usbhs with uhh, ehci and ohci base addresses
         functional clock and ehci, ohci irqs

    2. usb_tll_hs
          hwmod of usbhs with the TLL base address and irq.

 Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
 Reviewed-by: Partha Basak part...@india.ti.com
 ---
  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |  230 
 
  1 files changed, 230 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
 b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
 index 59fdb9f..c06b4a4 100644
 --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
 +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
 @@ -84,6 +84,8 @@ static struct omap_hwmod omap3xxx_mcbsp4_hwmod;
  static struct omap_hwmod omap3xxx_mcbsp5_hwmod;
  static struct omap_hwmod omap3xxx_mcbsp2_sidetone_hwmod;
  static struct omap_hwmod omap3xxx_mcbsp3_sidetone_hwmod;
 +static struct omap_hwmod omap34xx_usb_host_hs_hwmod;
 +static struct omap_hwmod omap34xx_usb_tll_hs_hwmod;

  /* L3 - L4_CORE interface */
  static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
 @@ -3196,6 +3198,229 @@ static struct omap_hwmod omap3xxx_mmc3_hwmod = {
        .omap_chip      = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
  };

 +/*
 + * 'usb_host_hs' class
 + * high-speed multi-port usb host controller
 + */
 +static struct omap_hwmod_ocp_if omap34xx_usb_host_hs__l3_main_2 = {
 +       .master         = omap34xx_usb_host_hs_hwmod,
 +       .slave          = omap3xxx_l3_main_hwmod,
 +       .clk            = core_l3_ick,
 +       .user           = OCP_USER_MPU,
 +};
 +
 +static struct omap_hwmod_class_sysconfig omap34xx_usb_host_hs_sysc = {
 +       .rev_offs       = 0x,
 +       .sysc_offs      = 0x0010,
 +       .syss_offs      = 0x0014,
 +       .sysc_flags     = (SYSC_HAS_MIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
 +                          SYSC_HAS_SIDLEMODE | SYSC_HAS_ENAWAKEUP |
 +                          SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
 +       .idlemodes      = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
 +                          MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
 +       .sysc_fields    = omap_hwmod_sysc_type1,
 +};
 +
 +static struct omap_hwmod_class omap34xx_usb_host_hs_hwmod_class = {
 +       .name = usb_host_hs,
 +       .sysc = omap34xx_usb_host_hs_sysc,
 +};
 +
 +static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_masters[] = {
 +       omap34xx_usb_host_hs__l3_main_2,
 +};
 +
 +static struct omap_hwmod_addr_space omap34xx_usb_host_hs_addrs[] = {
 +       {
 +               .name           = uhh,
 +               .pa_start       = 0x48064000,
 +               .pa_end         = 0x480643ff,
 +               .flags          = ADDR_TYPE_RT
 +       },
 +       {
 +               .name           = ohci,
 +               .pa_start       = 0x48064400,
 +               .pa_end         = 0x480647ff,
 +       },
 +       {
 +               .name           = ehci,
 +               .pa_start       = 0x48064800,
 +               .pa_end         = 0x48064cff,
 +       },
 +       {}
 +};
 +
 +static struct omap_hwmod_ocp_if omap34xx_usb_host_hs__ick = {
 +       .master         = omap3xxx_l4_core_hwmod,
 +       .slave          = omap34xx_usb_host_hs_hwmod,
 +       .clk            = usbhost_ick,
 +       .addr           = omap34xx_usb_host_hs_addrs,
 +       .user           = OCP_USER_MPU | OCP_USER_SDMA,
 +};
 +
 +static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_slaves[] = {
 +       omap34xx_usb_host_hs__ick,
 +};
 +
 +static struct omap_hwmod_opt_clk omap34xx_usb_host_hs_opt_clks[] = {
 +         { .role = ehci_logic_fck, .clk = usbhost_120m_fck, },
 +};
 +
 +static struct omap_hwmod_irq_info omap34xx_usb_host_hs_irqs[] = {
 +       { .name = ohci-irq, .irq = 76 },
 +       { .name = ehci-irq, .irq = 77 },
 +       { .irq = -1 }
 +};
 +
 +static struct omap_hwmod omap34xx_usb_host_hs_hwmod = {
 +       .name           = usb_host_hs,
 +       .class          = omap34xx_usb_host_hs_hwmod_class,
 +       .clkdm_name     = l3_init_clkdm,
 +       .mpu_irqs       = omap34xx_usb_host_hs_irqs,
 +       .main_clk       = usbhost_48m_fck,
 +       .prcm = {
 +               .omap2 = {
 +                       .module_offs = OMAP3430ES2_USBHOST_MOD,
 +                       .prcm_reg_id = 1,
 +                       .module_bit = OMAP3430ES2_EN_USBHOST1_SHIFT,
 +                       .idlest_reg_id = 1,
 +                       .idlest_idle_bit = OMAP3430ES2_ST_USBHOST_IDLE_SHIFT,
 +                       .idlest_stdby_bit = 
 OMAP3430ES2_ST_USBHOST_STDBY_SHIFT,
 +               },
 +       },
 +       .opt_clks       = omap34xx_usb_host_hs_opt_clks,
 +       .opt_clks_cnt   = ARRAY_SIZE(omap34xx_usb_host_hs_opt_clks),
 +       .slaves         = omap34xx_usb_host_hs_slaves,
 +       .slaves_cnt     =

Re: [PATCH 2/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap3

2011-10-11 Thread Munegowda, Keshava

On Tue, Oct 11, 2011 at 11:18 AM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
 On Tue, Oct 11, 2011 at 6:08 AM, Paul Walmsley p...@pwsan.com wrote:
 Hi

 so I just noticed another problem with these hwmods:

 On Thu, 6 Oct 2011, Keshava Munegowda wrote:

 Following 2 hwmod structures are added
     1. usb_host_hs
          The hwmod of usbhs with uhh, ehci and ohci base addresses
          functional clock and ehci, ohci irqs

     2. usb_tll_hs
           hwmod of usbhs with the TLL base address and irq.

 Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
 Reviewed-by: Partha Basak part...@india.ti.com
 ---
  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |  227 
 
  1 files changed, 227 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
 b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
 index 59fdb9f..b8ca690 100644
 --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
 +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c

 ...

 +static struct omap_hwmod_ocp_if omap34xx_ick_cfg__usb_tll_hs = {

 This interface is missing a .master and .slave.  It must have both.  So,
 dropping this patch until it's fixed.

 Clearly we also need to modify the hwmod code needs to reject any
 instances where either .master or .slave is NULL.


 - Paul

 Hi Paul
           I will fix it today only and I will send the updated
 patches in couple of hours.
 please help me to make it in this merge window.



Hi Paul
  I have posted v14 of the patches; please do review
if it is OK, please merge to your branch for 3.2 version
please let me know if you have any comments here.

 Thanks and 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 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

On Fri, Oct 7, 2011 at 4:03 PM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
 On Fri, Oct 7, 2011 at 3:05 PM, Paul Walmsley p...@pwsan.com wrote:
 On Fri, 7 Oct 2011, Munegowda, Keshava wrote:

 Thanks Paul;
 yes, I can your changes in the patches.
 so, you don't need v14 from me right? please confirm.
 I am preparing/validating next version patches with  OCPIF_SWSUP_IDLE 
 removed.
 Thanks for guiding me and helping on the finalizing the hwmod 
 configurations.

 The first two patches of the series -- the OMAP3/4 hwmod data patches --
 have been queued for 3.2 in the 'hwmod_devel_3.2' branch of
 git://git.pwsan.com/linux-2.6

 So we don't need new versions of those two.

 But we need to figure out what to do about the remaining three
 patches.  I still think that the TLL and UHH hwmods should have
 separate drivers.  Looks like Felipe has a question pending about that
 but it's unlikely that I'll have time to dig into it for at least a
 few days.  So I'd encourage you to try splitting those UHH and TLL
 drivers in the meantime.

 some time last week; I had a discussion with Felipe and he is ok to
 have current design as it is
 for now; But, he wants to redesign this driver with UHH and TLL as two
 platform drivers.
 I will have discussion with Felipe and Partha to redesign it soon.


Hi paul and Felipe

Here is the highlights of the change in the design of  USB Host which
we can do after kernel 3.2 release;

1. separate the TLL changes  from UHH
2. The TLL is be a new platform driver in ./drivers/mfd
3. the TLL platform driver will export apis  for enable/disable clocks
and settings.
3. the UHH drivers uses these APIS of TLL based on the port
configurations from board files
 you don't need the TLL clocks to
be on while all the ports are in phy mode.

please let me know your thoughts about it.


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 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

On Mon, Oct 10, 2011 at 2:33 PM, Felipe Balbi ba...@ti.com wrote:
 Hi,

 On Mon, Oct 10, 2011 at 02:22:23PM +0530, Munegowda, Keshava wrote:
 Hi paul and Felipe

 Here is the highlights of the change in the design of  USB Host which
 we can do after kernel 3.2 release;

 1. separate the TLL changes  from UHH
 2. The TLL is be a new platform driver in ./drivers/mfd
 3. the TLL platform driver will export apis  for enable/disable clocks
 and settings.

 TLL should control its clocks through pm_runtime APIs like anything
 else. If you really must export APIs to be used by UHH, you need to have
 an API so that you can claim/release a TLL channel and get/put for
 increasing/decreasing PM counters.

 I still think though, you should try to avoid exporting OMAP-specific
 APIs all over the place. Ideally, we would be able to have some way of
 saying that UHH and TLL are closely related... something like having the
 ability to say e.g. two devices are sibblings of each other, so that we
 could ask for a sibbling to wakeup/sleep depending if we need it or not.

do we have sibling structures today? I dont think so.


 Dunno, maybe I'm drifting here, but I don't think exposing OMAP-specific
 APIs is wise.

so, it means , if we can have sibling structure, then we can
conditionally enable it right?
--
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 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

On Mon, Oct 10, 2011 at 3:35 PM, Felipe Balbi ba...@ti.com wrote:
 On Mon, Oct 10, 2011 at 12:26:15PM +0300, Felipe Balbi wrote:
 On Mon, Oct 10, 2011 at 02:47:42PM +0530, Munegowda, Keshava wrote:
  On Mon, Oct 10, 2011 at 2:33 PM, Felipe Balbi ba...@ti.com wrote:
   Hi,
  
   On Mon, Oct 10, 2011 at 02:22:23PM +0530, Munegowda, Keshava wrote:
   Hi paul and Felipe
  
   Here is the highlights of the change in the design of  USB Host which
   we can do after kernel 3.2 release;
  
   1. separate the TLL changes  from UHH
   2. The TLL is be a new platform driver in ./drivers/mfd
   3. the TLL platform driver will export apis  for enable/disable clocks
   and settings.
  
   TLL should control its clocks through pm_runtime APIs like anything
   else. If you really must export APIs to be used by UHH, you need to have
   an API so that you can claim/release a TLL channel and get/put for
   increasing/decreasing PM counters.
  
   I still think though, you should try to avoid exporting OMAP-specific
   APIs all over the place. Ideally, we would be able to have some way of
   saying that UHH and TLL are closely related... something like having the
   ability to say e.g. two devices are sibblings of each other, so that we
   could ask for a sibbling to wakeup/sleep depending if we need it or not.
 
  do we have sibling structures today? I dont think so.

 no we don't.

 Ok, here's a first shot at it:

 From 600ae62f4b4a832d90a83d43227deb6f84b9def1 Mon Sep 17 00:00:00 2001
 From: Felipe Balbi ba...@ti.com
 Date: Mon, 10 Oct 2011 12:56:34 +0300
 Subject: [RFC/NOT-FOR-MERGING/PATCH] base: add the idea of sibling devices
 Organization: Texas Instruments\n

 It's possible that some devices, which share a
 common parent, need to talk to each due to a
 very close relationship between them.

 Generally, one device will provide some sort of
 resources to the other (e.g. clocks) while still
 both sharing another common parent.

 In such cases, it seems necessary to define those
 two devices as siblings, rather than a virtual
 parent relationship, and have means for one device
 to ask the sibling device to e.g. turn on its clocks.

 Signed-off-by: Felipe Balbi ba...@ti.com
 ---
  drivers/base/core.c    |   41 +
  include/linux/device.h |    7 +++
  2 files changed, 48 insertions(+), 0 deletions(-)

 diff --git a/drivers/base/core.c b/drivers/base/core.c
 index bc8729d..3b7f2e5 100644
 --- a/drivers/base/core.c
 +++ b/drivers/base/core.c
 @@ -589,6 +589,7 @@ void device_initialize(struct device *dev)
        dev-kobj.kset = devices_kset;
        kobject_init(dev-kobj, device_ktype);
        INIT_LIST_HEAD(dev-dma_pools);
 +       INIT_LIST_HEAD(dev-siblings);
        mutex_init(dev-mutex);
        lockdep_set_novalidate_class(dev-mutex);
        spin_lock_init(dev-devres_lock);
 @@ -889,6 +890,7 @@ int device_private_init(struct device *dev)
  */
  int device_add(struct device *dev)
  {
 +       struct device *sibling, *n;
        struct device *parent = NULL;
        struct class_interface *class_intf;
        int error = -EINVAL;
 @@ -923,6 +925,10 @@ int device_add(struct device *dev)
        parent = get_device(dev-parent);
        setup_parent(dev, parent);

 +       /* setup siblings */
 +       list_for_each_entry_safe(sibling, n, dev-siblings, sibling_node)
 +               get_device(sibling);
 +
        /* use parent numa_node */
        if (parent)
                set_dev_node(dev, dev_to_node(parent));
 @@ -1071,6 +1077,31 @@ void put_device(struct device *dev)
  }

  /**
 + * get_sibling_device_byname - finds a sibling device by its name
 + * @dev: device.
 + * @name: name for the sibling to find.
 + *
 + * This is here to help drivers which need to ask their siblings
 + * for something in particular (like ask sibling to turn clocks on)
 + * achieve that by first finding the correct device pointer for
 + * that sibling.
 + */
 +struct device *get_sibling_device_byname(struct device *dev, const char 
 *name)
 +{
 +       struct device   *sibling, *n;
 +       struct device   *found = NULL;
 +
 +       list_for_each_entry_safe(sibling, n, dev-siblings, sibling_node) {
 +               if (!strcmp(dev_name(sibling), name))
 +                       found = sibling;
 +                       goto found;
 +       }
 +
 +found:
 +       return found;
 +}
 +
 +/**
  * device_del - delete device from system.
  * @dev: device.
  *
 @@ -1085,6 +1116,7 @@ void put_device(struct device *dev)
  */
  void device_del(struct device *dev)
  {
 +       struct device *sibling, *n;
        struct device *parent = dev-parent;
        struct class_interface *class_intf;

 @@ -1120,6 +1152,15 @@ void device_del(struct device *dev)
        device_remove_attrs(dev);
        bus_remove_device(dev);

 +       /* teardown siblings */
 +       list_for_each_entry_safe(sibling, n, dev-siblings, sibling_node) {
 +               /* siblings must have  the same parent */
 +               WARN(sibling

Re: [PATCH 2/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap3

On Tue, Oct 11, 2011 at 6:08 AM, Paul Walmsley p...@pwsan.com wrote:
 Hi

 so I just noticed another problem with these hwmods:

 On Thu, 6 Oct 2011, Keshava Munegowda wrote:

 Following 2 hwmod structures are added
     1. usb_host_hs
          The hwmod of usbhs with uhh, ehci and ohci base addresses
          functional clock and ehci, ohci irqs

     2. usb_tll_hs
           hwmod of usbhs with the TLL base address and irq.

 Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
 Reviewed-by: Partha Basak part...@india.ti.com
 ---
  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |  227 
 
  1 files changed, 227 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
 b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
 index 59fdb9f..b8ca690 100644
 --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
 +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c

 ...

 +static struct omap_hwmod_ocp_if omap34xx_ick_cfg__usb_tll_hs = {

 This interface is missing a .master and .slave.  It must have both.  So,
 dropping this patch until it's fixed.

 Clearly we also need to modify the hwmod code needs to reject any
 instances where either .master or .slave is NULL.


 - Paul

Hi Paul
   I will fix it today only and I will send the updated
patches in couple of hours.
please help me to make it in this merge window.

Thanks and 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 2/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap3

On Thu, Oct 6, 2011 at 10:05 PM, Paul Walmsley p...@pwsan.com wrote:
 Hi Keshava,

 On Thu, 6 Oct 2011, Keshava Munegowda wrote:

 Following 2 hwmod structures are added
     1. usb_host_hs
          The hwmod of usbhs with uhh, ehci and ohci base addresses
          functional clock and ehci, ohci irqs

     2. usb_tll_hs
           hwmod of usbhs with the TLL base address and irq.

 Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
 Reviewed-by: Partha Basak part...@india.ti.com
 ---
  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |  227 
 
  1 files changed, 227 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
 b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
 index 59fdb9f..b8ca690 100644
 --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
 +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
 @@ -84,6 +84,8 @@ static struct omap_hwmod omap3xxx_mcbsp4_hwmod;

 ...

 +static struct omap_hwmod_ocp_if omap34xx_usb_host_hs__ick = {
 +     .master         = omap3xxx_l4_core_hwmod,
 +     .slave          = omap34xx_usb_host_hs_hwmod,
 +     .clk            = usbhost_ick,
 +     .addr           = omap34xx_usb_host_hs_addrs,
 +     .user           = OCP_USER_MPU | OCP_USER_SDMA,
 +/*
 + * This clock should be on/off only with main clock; If auto idle is set,
 + * the usbhs controller prevents the omap to enter in to low power mode,
 + * hence don't use auto idle here.
 + */
 +     .flags          = OCPIF_SWSUP_IDLE,

 This is still unclear to me.  Doesn't this interface clock support
 interface clock auto-idle?  If so, then when the UHH's target port is
 forced idle and its initiator port is forced to standby, then shouldn't
 the PRCM automatically idle this interface clock?

Thanks paul;
Now I am seeing that  without  OCPIF_SWSUP_IDLE the system is going to
low power mode but after
adding HWMOD_INIT_NO_RESET flag ;  After adding this flag; I dint
check the system without this flag;
so, PRCM automatically idle this interface clock if UHH target port is
forced idle and force standby.
I can remove it now.  :-)

 Or is there some hardware problem where the PRCM won't auto-idle this
 clock when the UHH is in idle + standby?

 +};
 +

 ...

 +static struct omap_hwmod_ocp_if omap34xx_ick_cfg__usb_tll_hs = {
 +     .clk            = usbtll_ick,
 +     .addr           = omap34xx_usb_tll_hs_addrs,
 +     .user           = OCP_USER_MPU | OCP_USER_SDMA,
 +/*
 + * This clock should be on/off only with main clock; If auto idle is set,
 + * the usbhs controller prevents the omap to enter in to low power mode,
 + * hence don't use auto idle here.
 + */
 +     .flags          = OCPIF_SWSUP_IDLE,

 Same comment here, with the exception of the part about standby since the
 TLL doesn't have an initiator port.

I will remove this also;

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 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

On Fri, Oct 7, 2011 at 2:36 PM, Paul Walmsley p...@pwsan.com wrote:
 Hi

 On Thu, 6 Oct 2011, Keshava Munegowda wrote:

 From: Benoit Cousson b-cous...@ti.com

 Following 2 hwmod structures are added
 1. usb_host_hs
      The hwmod of usbhs with uhh, ehci and ohci base addresses
      functional clock and ehci, ohci irqs

 2. usb_tll_hs
       hwmod of usbhs with the TLL base address and irq.

 Signed-off-by: Benoit Cousson b-cous...@ti.com

 - rebased to kernel version 3.0
 - Workarounds for hardware issues

 Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
 Reviewed-by: Partha Basak part...@india.ti.com

 A few minor issues in this patch have been fixed.  Please be careful with
 whitespace and with multi-line comment style - see
 Documentation/CodingStyle for more information.

Thanks Paul;
yes, I can your changes in the patches.
so, you don't need v14 from me right? please confirm.
I am preparing/validating next version patches with  OCPIF_SWSUP_IDLE removed.
Thanks for guiding me and helping on the finalizing the hwmod configurations.


regards
keshava



 - Paul

 From fdf7c66244af5ca5ba4cdc820f7644efb9f6c1bf Mon Sep 17 00:00:00 2001
 From: Benoit Cousson b-cous...@ti.com
 Date: Fri, 7 Oct 2011 02:40:51 -0600
 Subject: [PATCH] arm: omap: usb: ehci and ohci hwmod structures for omap4

 Following 2 hwmod structures are added
 1. usb_host_hs
     The hwmod of usbhs with uhh, ehci and ohci base addresses
     functional clock and ehci, ohci irqs

 2. usb_tll_hs
      hwmod of usbhs with the TLL base address and irq.

 Signed-off-by: Benoit Cousson b-cous...@ti.com

 - rebased to kernel version 3.0
 - Workarounds for hardware issues

 Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
 Reviewed-by: Partha Basak part...@india.ti.com
 [p...@pwsan.com: fixed whitespace, fixed multi-line comment style]
 Signed-off-by: Paul Walmsley p...@pwsan.com
 ---
  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  206 
 +++-
  1 files changed, 205 insertions(+), 1 deletions(-)

 diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
 b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
 index caaf409..6149407 100644
 --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
 +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
 @@ -68,6 +68,8 @@ static struct omap_hwmod omap44xx_mmc2_hwmod;
  static struct omap_hwmod omap44xx_mpu_hwmod;
  static struct omap_hwmod omap44xx_mpu_private_hwmod;
  static struct omap_hwmod omap44xx_usb_otg_hs_hwmod;
 +static struct omap_hwmod omap44xx_usb_host_hs_hwmod;
 +static struct omap_hwmod omap44xx_usb_tll_hs_hwmod;

  /*
  * Interconnects omap_hwmod structures
 @@ -5254,6 +5256,205 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
        .slaves_cnt     = ARRAY_SIZE(omap44xx_wd_timer3_slaves),
  };

 +/*
 + * 'usb_host_hs' class
 + * high-speed multi-port usb host controller
 + */
 +static struct omap_hwmod_ocp_if omap44xx_usb_host_hs__l3_main_2 = {
 +       .master         = omap44xx_usb_host_hs_hwmod,
 +       .slave          = omap44xx_l3_main_2_hwmod,
 +       .clk            = l3_div_ck,
 +       .user           = OCP_USER_MPU | OCP_USER_SDMA,
 +};
 +
 +static struct omap_hwmod_class_sysconfig omap44xx_usb_host_hs_sysc = {
 +       .rev_offs       = 0x,
 +       .sysc_offs      = 0x0010,
 +       .syss_offs      = 0x0014,
 +       .sysc_flags     = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE |
 +                          SYSC_HAS_SOFTRESET),
 +       .idlemodes      = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
 +                          SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
 +                          MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
 +       .sysc_fields    = omap_hwmod_sysc_type2,
 +};
 +
 +static struct omap_hwmod_class omap44xx_usb_host_hs_hwmod_class = {
 +       .name = usb_host_hs,
 +       .sysc = omap44xx_usb_host_hs_sysc,
 +};
 +
 +static struct omap_hwmod_ocp_if *omap44xx_usb_host_hs_masters[] = {
 +       omap44xx_usb_host_hs__l3_main_2,
 +};
 +
 +static struct omap_hwmod_addr_space omap44xx_usb_host_hs_addrs[] = {
 +       {
 +               .name           = uhh,
 +               .pa_start       = 0x4a064000,
 +               .pa_end         = 0x4a0647ff,
 +               .flags          = ADDR_TYPE_RT
 +       },
 +       {
 +               .name           = ohci,
 +               .pa_start       = 0x4a064800,
 +               .pa_end         = 0x4a064bff,
 +       },
 +       {
 +               .name           = ehci,
 +               .pa_start       = 0x4a064c00,
 +               .pa_end         = 0x4a064fff,
 +       },
 +       {}
 +};
 +
 +static struct omap_hwmod_irq_info omap44xx_usb_host_hs_irqs[] = {
 +       { .name = ohci-irq, .irq = 76 + OMAP44XX_IRQ_GIC_START },
 +       { .name = ehci-irq, .irq = 77 + OMAP44XX_IRQ_GIC_START },
 +       { .irq = -1 }
 +};
 +
 +static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usb_host_hs = {
 +       .master         = omap44xx_l4_cfg_hwmod,
 +       .slave          =

Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

On Fri, Oct 7, 2011 at 3:05 PM, Paul Walmsley p...@pwsan.com wrote:
 On Fri, 7 Oct 2011, Munegowda, Keshava wrote:

 Thanks Paul;
 yes, I can your changes in the patches.
 so, you don't need v14 from me right? please confirm.
 I am preparing/validating next version patches with  OCPIF_SWSUP_IDLE 
 removed.
 Thanks for guiding me and helping on the finalizing the hwmod configurations.

 The first two patches of the series -- the OMAP3/4 hwmod data patches --
 have been queued for 3.2 in the 'hwmod_devel_3.2' branch of
 git://git.pwsan.com/linux-2.6

 So we don't need new versions of those two.

 But we need to figure out what to do about the remaining three
 patches.  I still think that the TLL and UHH hwmods should have
 separate drivers.  Looks like Felipe has a question pending about that
 but it's unlikely that I'll have time to dig into it for at least a
 few days.  So I'd encourage you to try splitting those UHH and TLL
 drivers in the meantime.

some time last week; I had a discussion with Felipe and he is ok to
have current design as it is
for now; But, he wants to redesign this driver with UHH and TLL as two
platform drivers.
I will have discussion with Felipe and Partha to redesign it soon.

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 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

On Fri, Oct 7, 2011 at 3:05 PM, Paul Walmsley p...@pwsan.com wrote:
 On Fri, 7 Oct 2011, Munegowda, Keshava wrote:

 Thanks Paul;
 yes, I can your changes in the patches.
 so, you don't need v14 from me right? please confirm.
 I am preparing/validating next version patches with  OCPIF_SWSUP_IDLE 
 removed.
 Thanks for guiding me and helping on the finalizing the hwmod configurations.

 The first two patches of the series -- the OMAP3/4 hwmod data patches --
 have been queued for 3.2 in the 'hwmod_devel_3.2' branch of
 git://git.pwsan.com/linux-2.6

Ok, then I will host a tree for remaining three patches and another
last patch for MFD tree.

regards
keshava



 So we don't need new versions of those two.

 But we need to figure out what to do about the remaining three
 patches.  I still think that the TLL and UHH hwmods should have
 separate drivers.  Looks like Felipe has a question pending about that
 but it's unlikely that I'll have time to dig into it for at least a
 few days.  So I'd encourage you to try splitting those UHH and TLL
 drivers in the meantime.


 - Paul

--
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 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

On Fri, Oct 7, 2011 at 4:13 PM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
 On Fri, Oct 7, 2011 at 3:05 PM, Paul Walmsley p...@pwsan.com wrote:
 On Fri, 7 Oct 2011, Munegowda, Keshava wrote:

 Thanks Paul;
 yes, I can your changes in the patches.
 so, you don't need v14 from me right? please confirm.
 I am preparing/validating next version patches with  OCPIF_SWSUP_IDLE 
 removed.
 Thanks for guiding me and helping on the finalizing the hwmod 
 configurations.

 The first two patches of the series -- the OMAP3/4 hwmod data patches --
 have been queued for 3.2 in the 'hwmod_devel_3.2' branch of
 git://git.pwsan.com/linux-2.6

 Ok, then I will host a tree for remaining three patches and another
 last patch for MFD tree.

Hi Felipe and Sameo

The patches are available in the branch kmg-usbhs-pm of
git repository: g...@gitorious.org:~kmg/mirrors/kmg-usbhs-pm.git

if you have review comment on v13 of these series; please let me know.
so I that I will make the changes in time.

 regards
 keshava



 So we don't need new versions of those two.

 But we need to figure out what to do about the remaining three
 patches.  I still think that the TLL and UHH hwmods should have
 separate drivers.  Looks like Felipe has a question pending about that
 but it's unlikely that I'll have time to dig into it for at least a
 few days.  So I'd encourage you to try splitting those UHH and TLL
 drivers in the meantime.


 - Paul


--
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 0/5 v12] mfd: omap: usb: Runtime PM support for EHCI and OHCI drivers

2011-10-04 Thread Munegowda, Keshava

On Sat, Oct 1, 2011 at 12:31 AM, Paul Walmsley p...@pwsan.com wrote:

 Hi Keshava,

 by the way, when you repost these, can you split this into two series --
 one for the arch/arm/*omap* changes, and the other for changes that should
 go in through the MFD tree?  Then just note in the second series that it
 has a dependency on the first.  That will make it easier to merge these
 patches, and should cut down on the number of cc's that are necessary for
 most of these patches.

so, only patch 5 will be out this existing series;
1-4 will be one series and only patch 5 will be sent as a separate patch.

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 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3

2011-10-04 Thread Munegowda, Keshava

On Fri, Sep 30, 2011 at 11:46 PM, Paul Walmsley p...@pwsan.com wrote:
 On Fri, 30 Sep 2011, Munegowda, Keshava wrote:

 On Fri, Sep 30, 2011 at 2:02 PM, Paul Walmsley p...@pwsan.com wrote:
  On Wed, 28 Sep 2011, Munegowda, Keshava wrote:
 
  Thanks paul,
 
  But In USB Host case, there is a challenge!
 
  I need both usbhost_48m_fck and usbhost_120m_fck to be turned on when
  I invoke pm_runtime_get_sync ; so there are couple of options to do this
 
  1. use clk_get with hard coded  usbhost_120m_fck name in  usbhs driver
         enable this clock after invoking pm_runtime_get_sync
 
  2. add an additional flag in hwmod ; so that pm_runtime_get_sync will 
  enable
             main clock as well as optional clocks
 
  please comment on these two approaches..
 
  Looks like you picked approach #1 which is fine with me.
 
  Here's what I don't understand about how this clock is used, though.
  According to the 34xx TRM vZR Section 24.2.3.1.2 High-Speed USB Host
  Subsystem Clocks, this is only used to clock EHCI controller internal
  logic.  So if EHCI is not being used, it would seem to me that this clock
  shouldn't be enabled?  But patch #5 seems to enable and disable it
  unconditionally.  Am I missing something here?

 OK. are you suggesting that this clock should be enabled/disabled; only
 if atleast one port is selected for ehci?

 Seems to make sense to me?  If the clock really isn't needed for OHCI,
 then it shouldn't be enabled when only OHCI is in use?

thanks. I will make this :-)

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 2/5 v12] arm: omap: usb: ehci and ohci hwmod structures for omap3

2011-10-04 Thread Munegowda, Keshava

On Fri, Sep 30, 2011 at 10:47 PM, Kevin Hilman khil...@ti.com wrote:
 Munegowda, Keshava keshava_mgo...@ti.com writes:

 [...]

 +
 +static struct omap_hwmod_ocp_if omap34xx_f_cfg__usb_tll_hs = {
 +     .clk            = usbtll_ick,
 +     .user           = OCP_USER_MPU,
 +     .flags          = OCPIF_SWSUP_IDLE,
 +};

 Does this really need OCPIF_SWSUP_IDLE?  If so, then there is a hardware
 bug, and some explanation is needed.


 it was not allowing enter usbhs pw domain to enter to low power idle mode; so
 I add a comment here.


 When you add this comment, please be sure it describes *why* the power
 domain was not hitting the target power state, and reference any
 relevant eerrata.

I will add the errata description and id

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 3/5 v12] arm: omap: usb: register hwmods of usbhs

On Fri, Sep 30, 2011 at 1:04 PM, Felipe Balbi ba...@ti.com wrote:
 Hi,

 On Fri, Sep 30, 2011 at 01:15:55AM -0600, Paul Walmsley wrote:
  The hwmod structure of usb_host_hs  and usb_tll are
  retrieved and registered with omap device
 
  Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
  Reviewed-by: Partha Basak part...@india.ti.com
  ---
   arch/arm/mach-omap2/usb-host.c |  100 
  ++--
   1 files changed, 34 insertions(+), 66 deletions(-)
 
  diff --git a/arch/arm/mach-omap2/usb-host.c 
  b/arch/arm/mach-omap2/usb-host.c
  index 89ae298..771dc78 100644
  --- a/arch/arm/mach-omap2/usb-host.c
  +++ b/arch/arm/mach-omap2/usb-host.c
  @@ -28,51 +28,28 @@

  +   oh[0] = omap_hwmod_lookup(USBHS_UHH_HWMODNAME);
  +   if (!oh[0]) {
  +           pr_err(Could not look up %s\n, USBHS_UHH_HWMODNAME);
  +           return;
      }
 
  -   if (platform_device_register(usbhs_device)  0)
  -           printk(KERN_ERR USBHS platform_device_register failed\n);
  +   oh[1] = omap_hwmod_lookup(USBHS_TLL_HWMODNAME);
  +   if (!oh[1]) {
  +           pr_err(Could not look up %s\n, USBHS_TLL_HWMODNAME);
  +           return;
  +   }
 
  -init_end:
  -   return;
  +   od = omap_device_build_ss(OMAP_USBHS_DEVICE, bus_id, oh, 2,
  +                           (void *)usbhs_data, sizeof(usbhs_data),
  +                           omap_uhhtll_latency,
  +                           ARRAY_SIZE(omap_uhhtll_latency), false);

 Usually there's something wrong with omap_devices that contain
 multiple hwmods.  Is there some reason why there isn't a separate driver
 for the TLL?  Judging by a brief look at drivers/mfd/omap_usb_host.c, the
 TLL handling looks logically distinct?

 Yes, I have the same feeling. To my understanding, USB Host Subsystem on
 OMAP is composed of the Transceiver-less link (TLL) and USB Host (UHH).
 Aparently, they could be handled by separate drivers.

 --
 balbi

yes, it can be as two separate drivers for uhh and tll;  But i don't
think driver can be used effectively.
Now ehci and ohci gets the clocks , config reg and port settings
through usb host which is sufficient.
If you make them as two different drivers; then ehci and ohci has to
interact with both the drivers separately.
which will be an unnecessary complications. I feel not divided this
driver into two

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 3/5 v12] arm: omap: usb: register hwmods of usbhs

On Fri, Sep 30, 2011 at 2:49 PM, Felipe Balbi ba...@ti.com wrote:
 Hi,

 On Fri, Sep 30, 2011 at 02:45:32PM +0530, Munegowda, Keshava wrote:
 On Fri, Sep 30, 2011 at 1:04 PM, Felipe Balbi ba...@ti.com wrote:
  Hi,
 
  On Fri, Sep 30, 2011 at 01:15:55AM -0600, Paul Walmsley wrote:
   The hwmod structure of usb_host_hs  and usb_tll are
   retrieved and registered with omap device
  
   Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
   Reviewed-by: Partha Basak part...@india.ti.com
   ---
    arch/arm/mach-omap2/usb-host.c |  100 
   ++--
    1 files changed, 34 insertions(+), 66 deletions(-)
  
   diff --git a/arch/arm/mach-omap2/usb-host.c 
   b/arch/arm/mach-omap2/usb-host.c
   index 89ae298..771dc78 100644
   --- a/arch/arm/mach-omap2/usb-host.c
   +++ b/arch/arm/mach-omap2/usb-host.c
   @@ -28,51 +28,28 @@
 
   +   oh[0] = omap_hwmod_lookup(USBHS_UHH_HWMODNAME);
   +   if (!oh[0]) {
   +           pr_err(Could not look up %s\n, USBHS_UHH_HWMODNAME);
   +           return;
       }
  
   -   if (platform_device_register(usbhs_device)  0)
   -           printk(KERN_ERR USBHS platform_device_register failed\n);
   +   oh[1] = omap_hwmod_lookup(USBHS_TLL_HWMODNAME);
   +   if (!oh[1]) {
   +           pr_err(Could not look up %s\n, USBHS_TLL_HWMODNAME);
   +           return;
   +   }
  
   -init_end:
   -   return;
   +   od = omap_device_build_ss(OMAP_USBHS_DEVICE, bus_id, oh, 2,
   +                           (void *)usbhs_data, sizeof(usbhs_data),
   +                           omap_uhhtll_latency,
   +                           ARRAY_SIZE(omap_uhhtll_latency), false);
 
  Usually there's something wrong with omap_devices that contain
  multiple hwmods.  Is there some reason why there isn't a separate driver
  for the TLL?  Judging by a brief look at drivers/mfd/omap_usb_host.c, the
  TLL handling looks logically distinct?
 
  Yes, I have the same feeling. To my understanding, USB Host Subsystem on
  OMAP is composed of the Transceiver-less link (TLL) and USB Host (UHH).
  Aparently, they could be handled by separate drivers.
 
  --
  balbi

 yes, it can be as two separate drivers for uhh and tll;  But i don't
 think driver can be used effectively.
 Now ehci and ohci gets the clocks , config reg and port settings
 through usb host which is sufficient.
 If you make them as two different drivers; then ehci and ohci has to
 interact with both the drivers separately.
 which will be an unnecessary complications. I feel not divided this
 driver into two

 Come again, EHCI/OHCI need clocks from UHH and TLL ?? If that's the
 case, then there's really no easy way to handle this as a device can
 have only one parent.

yes,  if you are using ehci phy mode ( port modes of UHH_HOSTCONFIG register)
then uhh functional ( omap3: interface clocks too) is sufficient;
if you are using ehci in tll mode , then you need tll functional clock 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 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3

On Fri, Sep 30, 2011 at 2:02 PM, Paul Walmsley p...@pwsan.com wrote:
 On Wed, 28 Sep 2011, Munegowda, Keshava wrote:

 Thanks paul,

 But In USB Host case, there is a challenge!

 I need both usbhost_48m_fck and usbhost_120m_fck to be turned on when
 I invoke pm_runtime_get_sync ; so there are couple of options to do this

 1. use clk_get with hard coded  usbhost_120m_fck name in  usbhs driver
        enable this clock after invoking pm_runtime_get_sync

 2. add an additional flag in hwmod ; so that pm_runtime_get_sync will enable
            main clock as well as optional clocks

 please comment on these two approaches..

 Looks like you picked approach #1 which is fine with me.

 Here's what I don't understand about how this clock is used, though.
 According to the 34xx TRM vZR Section 24.2.3.1.2 High-Speed USB Host
 Subsystem Clocks, this is only used to clock EHCI controller internal
 logic.  So if EHCI is not being used, it would seem to me that this clock
 shouldn't be enabled?  But patch #5 seems to enable and disable it
 unconditionally.  Am I missing something here?

OK. are you suggesting that this clock should be enabled/disabled; only
if atleast one port is selected for ehci?
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5 v12] arm: omap: usb: ehci and ohci hwmod structures for omap3

On Fri, Sep 30, 2011 at 12:42 PM, Paul Walmsley p...@pwsan.com wrote:
 Hi

 a few comments

 On Fri, 30 Sep 2011, Keshava Munegowda wrote:

 Following 2 hwmod structures are added
     1. usb_host_hs
          The hwmod of usbhs with uhh, ehci and ohci base addresses
          functional clock and ehci, ohci irqs

     2. usb_tll_hs
           hwmod of usbhs with the TLL base address and irq.

 Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
 Reviewed-by: Partha Basak part...@india.ti.com
 ---
  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |  195 
 
  1 files changed, 195 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
 b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
 index 59fdb9f..bc17493 100644
 --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
 +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
 @@ -84,6 +84,8 @@ static struct omap_hwmod omap3xxx_mcbsp4_hwmod;
  static struct omap_hwmod omap3xxx_mcbsp5_hwmod;
  static struct omap_hwmod omap3xxx_mcbsp2_sidetone_hwmod;
  static struct omap_hwmod omap3xxx_mcbsp3_sidetone_hwmod;
 +static struct omap_hwmod omap34xx_usb_host_hs_hwmod;
 +static struct omap_hwmod omap34xx_usb_tll_hs_hwmod;

  /* L3 - L4_CORE interface */
  static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
 @@ -3196,6 +3198,194 @@ static struct omap_hwmod omap3xxx_mmc3_hwmod = {
       .omap_chip      = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
  };

 +/*
 + * 'usb_host_hs' class
 + * high-speed multi-port usb host controller
 + */
 +static struct omap_hwmod_ocp_if omap34xx_usb_host_hs__l3_main_2 = {
 +     .master         = omap34xx_usb_host_hs_hwmod,
 +     .slave          = omap3xxx_l3_main_hwmod,
 +     .clk            = core_l3_ick,
 +     .user           = OCP_USER_MPU,
 +};
 +
 +static struct omap_hwmod_class_sysconfig omap34xx_usb_host_hs_sysc = {
 +     .rev_offs       = 0x,
 +     .sysc_offs      = 0x0010,
 +     .syss_offs      = 0x0014,
 +     .sysc_flags     = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),

 This register has other bitfields.  Please include them.

 +     .idlemodes      = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
 +                        MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
 +     .sysc_fields    = omap_hwmod_sysc_type1,
 +};
 +
 +static struct omap_hwmod_class omap34xx_usb_host_hs_hwmod_class = {
 +     .name = usb_host_hs,
 +     .sysc = omap34xx_usb_host_hs_sysc,
 +};
 +
 +static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_masters[] = {
 +     omap34xx_usb_host_hs__l3_main_2,
 +};
 +
 +static struct omap_hwmod_addr_space omap34xx_usb_host_hs_addrs[] = {
 +     {
 +             .name           = uhh,
 +             .pa_start       = 0x48064000,
 +             .pa_end         = 0x480643ff,
 +             .flags          = ADDR_TYPE_RT
 +     },
 +     {
 +             .name           = ohci,
 +             .pa_start       = 0x48064400,
 +             .pa_end         = 0x480647ff,
 +     },
 +     {
 +             .name           = ehci,
 +             .pa_start       = 0x48064800,
 +             .pa_end         = 0x48064cff,
 +     },
 +     {}
 +};
 +
 +static struct omap_hwmod_ocp_if omap34xx_l4_cfg__usb_host_hs = {
 +     .master         = omap3xxx_l4_core_hwmod,
 +     .slave          = omap34xx_usb_host_hs_hwmod,
 +     .clk            = l4_ick,
 +     .addr           = omap34xx_usb_host_hs_addrs,
 +     .user           = OCP_USER_MPU | OCP_USER_SDMA,
 +};
 +
 +static struct omap_hwmod_ocp_if omap34xx_usb_host_hs__ick = {
 +     .clk            = usbhost_ick,
 +     .user           = OCP_USER_MPU,
 +     .flags          = OCPIF_SWSUP_IDLE,

 Does this really need OCPIF_SWSUP_IDLE?  If so, then there is a hardware
 bug, and some explanation is needed.

 +};
 +
 +static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_slaves[] = {
 +     omap34xx_l4_cfg__usb_host_hs,
 +     omap34xx_usb_host_hs__ick,
 +};
 +
 +static struct omap_hwmod_opt_clk omap34xx_usb_host_hs_opt_clks[] = {
 +       { .role = usbhost_fck2, .clk = usbhost_120m_fck, },

 The role here doesn't need usbhost in its name -- ideally it would be
 something like 120m_fck or ehci_logic_fck.

yes, I will do this.


 +};
 +
 +static struct omap_hwmod_irq_info omap34xx_usb_host_hs_irqs[] = {
 +     { .name = ohci-irq, .irq = 76 },
 +     { .name = ehci-irq, .irq = 77 },
 +     { .irq = -1 }
 +};
 +
 +static struct omap_hwmod omap34xx_usb_host_hs_hwmod = {
 +     .name           = usb_host_hs,
 +     .class          = omap34xx_usb_host_hs_hwmod_class,
 +     .clkdm_name     = l3_init_clkdm,
 +     .mpu_irqs       = omap34xx_usb_host_hs_irqs,
 +     .main_clk       = usbhost_48m_fck,
 +     .prcm = {
 +             .omap2 = {
 +                     .module_offs = OMAP3430ES2_USBHOST_MOD,
 +                     .prcm_reg_id = 1,
 +                     .module_bit = OMAP3430ES2_EN_USBHOST1_SHIFT,
 +                     .idlest_reg_id = 1,
 +                     .idlest_idle_bit = OMAP3430ES2_ST_USBHOST_IDLE_SHIFT,
 +

Re: [PATCH 2/5 v12] arm: omap: usb: ehci and ohci hwmod structures for omap3