Re: Help wanted with USB and OMAP3 off_mode

2013-01-17 Thread NeilBrown
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, 17 Jan 2013 11:22:55 +1100 NeilBrown ne...@suse.de wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On Wed, 16 Jan 2013 13:11:26 +0200 Igor Grinberg grinb...@compulab.co.il
 wrote:
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
  
  On 01/16/13 12:19, NeilBrown wrote:
   On Wed, 16 Jan 2013 11:28:02 +0200 Igor Grinberg grinb...@compulab.co.il
   wrote:
   
   -BEGIN PGP SIGNED MESSAGE-
   Hash: SHA1
   
   On 01/16/13 09:26, NeilBrown wrote:
   On Wed, 09 Jan 2013 14:54:00 +0200 Igor Grinberg 
   grinb...@compulab.co.il
   wrote:
  
   On 01/09/13 14:08, Michael Trimarchi wrote:
   Hi Neil
  
   I forget to answer to your questions
  
   On 01/09/2013 12:34 PM, NeilBrown wrote:
   On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi
   mich...@amarulasolutions.com wrote:
  
   Hi Neil
  
   On 01/09/2013 11:19 AM, NeilBrown wrote:
   On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg 
   grinb...@compulab.co.il
   wrote:
  
   -BEGIN PGP SIGNED MESSAGE-
   Hash: SHA1
  
   Hi Neil,
  
   On 01/09/13 00:29, NeilBrown wrote:
  
   Hi,
I'm trying to get off_mode working reliably on my gta04 mobile 
   phone.
  
   My current stumbling block is USB.  The Option GSM module is 
   attached via
   USB (there is a separate transceiver chip attached to port 1 
   which is placed
   in OMAP_EHCI_PORT_MODE_PHY).
  
   Which PHY is this (vendor/model)?
  
   Hi Igor,
 it is the SMSC USB3322
  
   http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf
  
  
   BTW I subsequently discovered that keeping USBHOST out off 
   off_mode only
   sometimes avoid the problem, not always.  So there are probably 
   multiple
   issues :-(
  
   We have the same PHY and it has some issues with the OMAP USB code.
   First issue we experience is that if we reset the PHY more then once
   w/o power cycling it, the PHY dies until next power cycle.
   So, we stop providing the reset GPIO to the usb code and do the reset
   in the board code.
  
   I've tried various change w.r.t the resetting and  I cannot fault it.
   Resetting or not resetting neither causes a problem while the USB is
   otherwise working, not fixed the USB while  it is otherwise failing.
   So I don't think this is my problem - thanks.
  
  
  
   Are you sure that you don't have glitch on power, reset pin during 
   suspend?
  
  
   No, I don't really have the equipment to measure such things.
   But is it likely?  Would enabling off_mode make it more likely?
  
   I don't know the reason of the off_mode problem :(
  
   We have the equipment to check this and no - this is not the case.
  
  
   Can you suggest some way I could test the hypothesis?
  
   I had the same problem on a rugged mobile phone, so it is just 
   experience
   Check the modem power and reset gpio too, but if you don't need to 
   unblock it
   with the pin after resume we know that modem is not the problem
  
   I don't think modem is the problem...
   We have plain USB connector ports that are dead after the resume from 
   off-mode.
  
   The good news are that we have the off-mode working on v3.6.1,
   including the USB, but we had to do some horrible ugly hacking for 
   this.
  
  
   I assume this  means some patches on top of 3.6.1 ??
   Care to share your code?  Even horribly ugly hacks can be educational.
   
   We are not ready to share these patches (this will happen eventually
   after some work is finished), but I can explain what they do...
   
   We split the ehci_run function to separate the debugfs and sysfs stuff 
   from
   other initializations, so we can run the new version without the debugfs 
   and
   sysfs stuff multiple times.
   
   Then we implement the suspend/resume ehci callbacks:
   on suspend, assert phy reset,
   on resume, deassert phy reset, write EHCI_INSNREG04_DISABLE_UNSUSPEND to
   EHCI_INSNREG04, and call the new ehci_run() function.
   
   That does the job for USB host to resume from off mode.
   
   Interesting thanks.  That makes a certain amount of sense.
   
   However I tried compiling ehci-hcd as a module and  unload/reloading it 
   which
   should have a similar net effect to what you did, but it didn't make any
   difference - device disappears on resume.
  
  Yes it does for cm-t3730, in fact, that is what we have started from...
  
   
   I also tried restoring the correct value to EHCI_INSNREG04 and
   EHCI_INSNREG05_ULPI which are the only registers written by 
   ehci-omap.c, and that didn't help either.
   
   The only thing I've found that works is keeping 'core' out of off-mode.
  
  Ah, one more thing, we ensure that phy is completely powered off through
  the TPS power scripts, otherwise, it does not work...
  
 
 Ahhh  that does make a difference.
 
 I turned off the 5V5 rail which powered the phy (and a few other things) and
 now the usb-attached modem appears after resume.  Very interesting.
 
 I hadn't been doing this as 

Re: Help wanted with USB and OMAP3 off_mode

2013-01-17 Thread NeilBrown
On Wed, 16 Jan 2013 12:57:08 +0200 Roger Quadros rog...@ti.com wrote:

 On 01/16/2013 12:27 PM, NeilBrown wrote:
  On Wed, 16 Jan 2013 12:00:48 +0200 Roger Quadros rog...@ti.com wrote:
  
  On 01/09/2013 12:29 AM, NeilBrown wrote:
 
  Hi,
   I'm trying to get off_mode working reliably on my gta04 mobile phone.
 
  My current stumbling block is USB.  The Option GSM module is attached 
  via
  USB (there is a separate transceiver chip attached to port 1 which is 
  placed
  in OMAP_EHCI_PORT_MODE_PHY).
 
  After a suspend/resume cycle with off_mode enabled the GSM module 
  disappears.
  i.e. 'lsusb' doesn't see it any more and the various ttyHSxx devices don't
  exist.
  Without off mode, the modem always appears after resume.
 
  I discovered that the registers set by:
 
 drivers/mfd/omap-usb-host.c
 
  are not maintained across as suspend/resume so I added the following patch
  (which I can make a formal submission of if it looks right to others), but
  that didn't help (or didn't help enough).
 
  If I
 
echo 1  /sys/kernel/debug/pm_debug/usbhost_pwrdm/suspend
 
  thus keeping just the USBHOST power domain out of off_mode, the GSM module
  doesn't disappear.  So it seems that some context in the usbhost domain is
  not being save and restored.
 
  This is as far as I can get.  Can someone suggest where I should look to 
  find
  out what is not being saved/restored properly, and how to go about saving 
  and
  restoring?
 
  You need to ensure that USBHOST/TLL context is saved as per the Save and
  Restore sequence see section USBHOST/USBTLL Save-and-Restore
  Management in the OMAP Technical Reference Manual.
 
  The basic idea there is that software does the context saving into SAR
  RAM before entering OFF mode and hardware automatically restores the
  context after coming out of OFF mode.
  
  Is it?  The way I read the doco, the hardware both saves to SAR RAM, and
  restores from  SAR RAM.
Section 22.2.4.1.6  Save and Restore
  of my copy of the TRM says:
  
  The save-and-restore (SAR) mechanism can extract the hardware context of 
  the high-speed USB host
  controller (after all USB activity has been suspended) before switching 
  off (=save), save it to an external
  always-on memory, and reinject it later after the module has been switched 
  on again and reset (=restore)
  seamlessly for the USB. Part of that context is composed of the register 
  fields described in the current
  chapter. The rest of the context is composed of the buried flip-flops 
  and memories (not accessible by
  software) like finite state-machine (FSM) states, buffer contents, and 
  miscellaneous random logic bits.
  
  which strongly suggests that it is all handled by hardware.  Of course there
  are other registers that aren't covered  by the SAR - we need to identify
  those and make sure they are saved and restored.  I've found a few registers
  that aren't being restored, but restoring them hasn't made a visible
  difference yet.
 
 Yes, you are right. I mixed it up with OMAP4 behaviour, sorry.
 But still, software needs to ensure that the USBHOST and CORE power
 domain's SAVEANDRESTORE bit are set to ensure that SAR works.
 
 see section 3.5.4.6 USBHOST/USBTLL Save-and-Restore Management
 
 This seems to be done by the powerdomain code based on the
 PWRDM_HAS_HDWR_SAR flag. However, this flag is disabled for USBHOST
 powerdomain with the following comment.
 
  Both USBHOST and USBTLL support a save-and-restore mechanism. When the 
  device enters into off
  mode (that is, all power domains, except the WKUP power domain, are off), 
  the user may want to save
  the USBHOST context and restore it when exiting off mode. The 
  save-and-restore mechanism for the HS
  USB Host is enabled by setting the PRCM.PM_PWSTCTRL_USBHOST[4] 
  SAVEANDRESTORE bit; for
  the USBTLL, it is configured by the PRCM.PM_PWSTCTRL_CORE[4] SAVEANDRESTORE 
  bit. The save
  mechanism is initiated as the power domain transitions from active to off 
  state (or to OSWR state for the
  USBTLL), whereas the restore mechanism is initiated as the power domain 
  transitions from off to active
  power state.
 
 Can you try with the flag enabled?

If I keep CORE and  USBHOST out of off-mode (by writing to the relevant
'suspend' files in /sys/kernel/debug/pm-debug) then it all works.

If I set this flag, then I can allow USBHOST to enter off-mode as long as I
keep CORE in retention or better.

If I let CORE and USBHOST go to off-mode and don't have the flag set, then I
can resume from suspend, but the usb modem has disappeared.

If I let CORE and USBHOST go to off-mode and DO have the flag set, then I
cannot even resume from suspend sometimes.

I hate those sometimess!

If I remove the battery (with no other power source present) and re-insert
it, and let the phone boot up to  stable state and then enter suspend, I
cannot resume from suspend.  (I tried setting no_console_suspend to see if
anything was happening - but that keeps 

Re: Help wanted with USB and OMAP3 off_mode

2013-01-17 Thread Roger Quadros
On 01/17/2013 01:01 PM, NeilBrown wrote:
 On Wed, 16 Jan 2013 12:57:08 +0200 Roger Quadros rog...@ti.com wrote:
 
 On 01/16/2013 12:27 PM, NeilBrown wrote:
 On Wed, 16 Jan 2013 12:00:48 +0200 Roger Quadros rog...@ti.com wrote:

 On 01/09/2013 12:29 AM, NeilBrown wrote:

 Hi,
  I'm trying to get off_mode working reliably on my gta04 mobile phone.

 My current stumbling block is USB.  The Option GSM module is attached 
 via
 USB (there is a separate transceiver chip attached to port 1 which is 
 placed
 in OMAP_EHCI_PORT_MODE_PHY).

 After a suspend/resume cycle with off_mode enabled the GSM module 
 disappears.
 i.e. 'lsusb' doesn't see it any more and the various ttyHSxx devices don't
 exist.
 Without off mode, the modem always appears after resume.

 I discovered that the registers set by:

drivers/mfd/omap-usb-host.c

 are not maintained across as suspend/resume so I added the following patch
 (which I can make a formal submission of if it looks right to others), but
 that didn't help (or didn't help enough).

 If I

   echo 1  /sys/kernel/debug/pm_debug/usbhost_pwrdm/suspend

 thus keeping just the USBHOST power domain out of off_mode, the GSM module
 doesn't disappear.  So it seems that some context in the usbhost domain is
 not being save and restored.

 This is as far as I can get.  Can someone suggest where I should look to 
 find
 out what is not being saved/restored properly, and how to go about saving 
 and
 restoring?

 You need to ensure that USBHOST/TLL context is saved as per the Save and
 Restore sequence see section USBHOST/USBTLL Save-and-Restore
 Management in the OMAP Technical Reference Manual.

 The basic idea there is that software does the context saving into SAR
 RAM before entering OFF mode and hardware automatically restores the
 context after coming out of OFF mode.

 Is it?  The way I read the doco, the hardware both saves to SAR RAM, and
 restores from  SAR RAM.
   Section 22.2.4.1.6  Save and Restore
 of my copy of the TRM says:

 The save-and-restore (SAR) mechanism can extract the hardware context of 
 the high-speed USB host
 controller (after all USB activity has been suspended) before switching 
 off (=save), save it to an external
 always-on memory, and reinject it later after the module has been switched 
 on again and reset (=restore)
 seamlessly for the USB. Part of that context is composed of the register 
 fields described in the current
 chapter. The rest of the context is composed of the buried flip-flops 
 and memories (not accessible by
 software) like finite state-machine (FSM) states, buffer contents, and 
 miscellaneous random logic bits.

 which strongly suggests that it is all handled by hardware.  Of course there
 are other registers that aren't covered  by the SAR - we need to identify
 those and make sure they are saved and restored.  I've found a few registers
 that aren't being restored, but restoring them hasn't made a visible
 difference yet.

 Yes, you are right. I mixed it up with OMAP4 behaviour, sorry.
 But still, software needs to ensure that the USBHOST and CORE power
 domain's SAVEANDRESTORE bit are set to ensure that SAR works.

 see section 3.5.4.6 USBHOST/USBTLL Save-and-Restore Management

 This seems to be done by the powerdomain code based on the
 PWRDM_HAS_HDWR_SAR flag. However, this flag is disabled for USBHOST
 powerdomain with the following comment.

 Both USBHOST and USBTLL support a save-and-restore mechanism. When the 
 device enters into off
 mode (that is, all power domains, except the WKUP power domain, are off), 
 the user may want to save
 the USBHOST context and restore it when exiting off mode. The 
 save-and-restore mechanism for the HS
 USB Host is enabled by setting the PRCM.PM_PWSTCTRL_USBHOST[4] 
 SAVEANDRESTORE bit; for
 the USBTLL, it is configured by the PRCM.PM_PWSTCTRL_CORE[4] SAVEANDRESTORE 
 bit. The save
 mechanism is initiated as the power domain transitions from active to off 
 state (or to OSWR state for the
 USBTLL), whereas the restore mechanism is initiated as the power domain 
 transitions from off to active
 power state.

 Can you try with the flag enabled?
 
 If I keep CORE and  USBHOST out of off-mode (by writing to the relevant
 'suspend' files in /sys/kernel/debug/pm-debug) then it all works.
 
 If I set this flag, then I can allow USBHOST to enter off-mode as long as I
 keep CORE in retention or better.
 
 If I let CORE and USBHOST go to off-mode and don't have the flag set, then I
 can resume from suspend, but the usb modem has disappeared.
 
 If I let CORE and USBHOST go to off-mode and DO have the flag set, then I
 cannot even resume from suspend sometimes.
 

It looks like the problem creeps in when the OMAP device hits OFF. i.e.
CORE is allowed to go OFF.

 I hate those sometimess!
 
 If I remove the battery (with no other power source present) and re-insert
 it, and let the phone boot up to  stable state and then enter suspend, I
 cannot resume from suspend.  (I tried setting 

Re: Help wanted with USB and OMAP3 off_mode

2013-01-17 Thread NeilBrown
On Thu, 17 Jan 2013 13:29:07 +0200 Roger Quadros rog...@ti.com wrote:

 On 01/17/2013 01:01 PM, NeilBrown wrote:
  On Wed, 16 Jan 2013 12:57:08 +0200 Roger Quadros rog...@ti.com wrote:
  
  On 01/16/2013 12:27 PM, NeilBrown wrote:
  On Wed, 16 Jan 2013 12:00:48 +0200 Roger Quadros rog...@ti.com wrote:
 
  On 01/09/2013 12:29 AM, NeilBrown wrote:
 
  Hi,
   I'm trying to get off_mode working reliably on my gta04 mobile phone.
 
  My current stumbling block is USB.  The Option GSM module is attached 
  via
  USB (there is a separate transceiver chip attached to port 1 which is 
  placed
  in OMAP_EHCI_PORT_MODE_PHY).
 
  After a suspend/resume cycle with off_mode enabled the GSM module 
  disappears.
  i.e. 'lsusb' doesn't see it any more and the various ttyHSxx devices 
  don't
  exist.
  Without off mode, the modem always appears after resume.
 
  I discovered that the registers set by:
 
 drivers/mfd/omap-usb-host.c
 
  are not maintained across as suspend/resume so I added the following 
  patch
  (which I can make a formal submission of if it looks right to others), 
  but
  that didn't help (or didn't help enough).
 
  If I
 
echo 1  /sys/kernel/debug/pm_debug/usbhost_pwrdm/suspend
 
  thus keeping just the USBHOST power domain out of off_mode, the GSM 
  module
  doesn't disappear.  So it seems that some context in the usbhost domain 
  is
  not being save and restored.
 
  This is as far as I can get.  Can someone suggest where I should look 
  to find
  out what is not being saved/restored properly, and how to go about 
  saving and
  restoring?
 
  You need to ensure that USBHOST/TLL context is saved as per the Save and
  Restore sequence see section USBHOST/USBTLL Save-and-Restore
  Management in the OMAP Technical Reference Manual.
 
  The basic idea there is that software does the context saving into SAR
  RAM before entering OFF mode and hardware automatically restores the
  context after coming out of OFF mode.
 
  Is it?  The way I read the doco, the hardware both saves to SAR RAM, and
  restores from  SAR RAM.
Section 22.2.4.1.6  Save and Restore
  of my copy of the TRM says:
 
  The save-and-restore (SAR) mechanism can extract the hardware context of 
  the high-speed USB host
  controller (after all USB activity has been suspended) before switching 
  off (=save), save it to an external
  always-on memory, and reinject it later after the module has been 
  switched on again and reset (=restore)
  seamlessly for the USB. Part of that context is composed of the register 
  fields described in the current
  chapter. The rest of the context is composed of the buried flip-flops 
  and memories (not accessible by
  software) like finite state-machine (FSM) states, buffer contents, and 
  miscellaneous random logic bits.
 
  which strongly suggests that it is all handled by hardware.  Of course 
  there
  are other registers that aren't covered  by the SAR - we need to identify
  those and make sure they are saved and restored.  I've found a few 
  registers
  that aren't being restored, but restoring them hasn't made a visible
  difference yet.
 
  Yes, you are right. I mixed it up with OMAP4 behaviour, sorry.
  But still, software needs to ensure that the USBHOST and CORE power
  domain's SAVEANDRESTORE bit are set to ensure that SAR works.
 
  see section 3.5.4.6 USBHOST/USBTLL Save-and-Restore Management
 
  This seems to be done by the powerdomain code based on the
  PWRDM_HAS_HDWR_SAR flag. However, this flag is disabled for USBHOST
  powerdomain with the following comment.
 
  Both USBHOST and USBTLL support a save-and-restore mechanism. When the 
  device enters into off
  mode (that is, all power domains, except the WKUP power domain, are off), 
  the user may want to save
  the USBHOST context and restore it when exiting off mode. The 
  save-and-restore mechanism for the HS
  USB Host is enabled by setting the PRCM.PM_PWSTCTRL_USBHOST[4] 
  SAVEANDRESTORE bit; for
  the USBTLL, it is configured by the PRCM.PM_PWSTCTRL_CORE[4] 
  SAVEANDRESTORE bit. The save
  mechanism is initiated as the power domain transitions from active to off 
  state (or to OSWR state for the
  USBTLL), whereas the restore mechanism is initiated as the power domain 
  transitions from off to active
  power state.
 
  Can you try with the flag enabled?
  
  If I keep CORE and  USBHOST out of off-mode (by writing to the relevant
  'suspend' files in /sys/kernel/debug/pm-debug) then it all works.
  
  If I set this flag, then I can allow USBHOST to enter off-mode as long as I
  keep CORE in retention or better.
  
  If I let CORE and USBHOST go to off-mode and don't have the flag set, then I
  can resume from suspend, but the usb modem has disappeared.
  
  If I let CORE and USBHOST go to off-mode and DO have the flag set, then I
  cannot even resume from suspend sometimes.
  
 
 It looks like the problem creeps in when the OMAP device hits OFF. i.e.
 CORE is allowed to go OFF.
 
  I hate those 

Re: Help wanted with USB and OMAP3 off_mode

2013-01-16 Thread Igor Grinberg
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/16/13 09:26, NeilBrown wrote:
 On Wed, 09 Jan 2013 14:54:00 +0200 Igor Grinberg grinb...@compulab.co.il
 wrote:
 
 On 01/09/13 14:08, Michael Trimarchi wrote:
 Hi Neil

 I forget to answer to your questions

 On 01/09/2013 12:34 PM, NeilBrown wrote:
 On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi
 mich...@amarulasolutions.com wrote:

 Hi Neil

 On 01/09/2013 11:19 AM, NeilBrown wrote:
 On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg 
 grinb...@compulab.co.il
 wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi Neil,

 On 01/09/13 00:29, NeilBrown wrote:

 Hi,
  I'm trying to get off_mode working reliably on my gta04 mobile phone.

 My current stumbling block is USB.  The Option GSM module is 
 attached via
 USB (there is a separate transceiver chip attached to port 1 which is 
 placed
 in OMAP_EHCI_PORT_MODE_PHY).

 Which PHY is this (vendor/model)?

 Hi Igor,
   it is the SMSC USB3322

 http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf


 BTW I subsequently discovered that keeping USBHOST out off off_mode only
 sometimes avoid the problem, not always.  So there are probably multiple
 issues :-(

 We have the same PHY and it has some issues with the OMAP USB code.
 First issue we experience is that if we reset the PHY more then once
 w/o power cycling it, the PHY dies until next power cycle.
 So, we stop providing the reset GPIO to the usb code and do the reset
 in the board code.
 
 I've tried various change w.r.t the resetting and  I cannot fault it.
 Resetting or not resetting neither causes a problem while the USB is
 otherwise working, not fixed the USB while  it is otherwise failing.
 So I don't think this is my problem - thanks.
 


 Are you sure that you don't have glitch on power, reset pin during 
 suspend?


 No, I don't really have the equipment to measure such things.
 But is it likely?  Would enabling off_mode make it more likely?

 I don't know the reason of the off_mode problem :(

 We have the equipment to check this and no - this is not the case.


 Can you suggest some way I could test the hypothesis?

 I had the same problem on a rugged mobile phone, so it is just experience
 Check the modem power and reset gpio too, but if you don't need to unblock 
 it
 with the pin after resume we know that modem is not the problem

 I don't think modem is the problem...
 We have plain USB connector ports that are dead after the resume from 
 off-mode.

 The good news are that we have the off-mode working on v3.6.1,
 including the USB, but we had to do some horrible ugly hacking for this.

 
 I assume this  means some patches on top of 3.6.1 ??
 Care to share your code?  Even horribly ugly hacks can be educational.

We are not ready to share these patches (this will happen eventually
after some work is finished), but I can explain what they do...

We split the ehci_run function to separate the debugfs and sysfs stuff from
other initializations, so we can run the new version without the debugfs and
sysfs stuff multiple times.

Then we implement the suspend/resume ehci callbacks:
on suspend, assert phy reset,
on resume, deassert phy reset, write EHCI_INSNREG04_DISABLE_UNSUSPEND to
EHCI_INSNREG04, and call the new ehci_run() function.

That does the job for USB host to resume from off mode.

- -- 
Regards,
Igor.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQ9nKiAAoJEBDE8YO64Efa7U4QAKFXRyyNR5Q7jjwVG6UwITWq
6kJyNXJKQTqn6GLEV7xJmT4SZAtxq+dRDl/XE9dcXFK3RTebttXxyVz1X0vXZQud
h6QLenH8jHczNubfn6CTLI38PKprl1F2zpZtjKpHfNmD5cLWzJ1EIoTH19ENsJ4v
zV3KI3RgiFuq02vxOULtp9gP/x0WZSHwBEGm/ToqqsEaX7wAJc2BDFOSS8NpSGbb
VLPFA1doMrFOYkL+oMS2IVudM0wEYCBGhGxMi/Y++RY1omlonhEGCoVxaxzGoHrk
H/ZpxFheIGBKwo+VX1eSgW9oQZyzbPZttyEWXXNCRh/6oejXCBSS3zkKrWrctmVD
ONu1gzoaC9p/c1n2GDioIfxC41dPKdjCETMbTi9rR5shc12ZmwtrgUOU80mpzWj3
6fY+TRW4x8qYbsFL89T6TWGpDz7JrBdtdJiBD/TPtJW05ikn9DTL5/GNVjeeoRk0
5DJ06pHh+rQFKThEvoDdLAH3PZdtDVSdXnAg+gF4D7/BMZ14TLHmW2l471I95S2I
eKxZxIwFa2IscTbGKhTlrdPF4UShEvLuFgO6NCb1ea1FT7m3ih8rwA5ObI4676DG
Y5kokqi9dpzMB/6T/SDk/gySTg9WUDXFlhS6x/b89f1xC71GzGTJkkqqH4u6KfX8
GcqI3wEFlqpG4FM39XAw
=nynZ
-END PGP SIGNATURE-
--
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: Help wanted with USB and OMAP3 off_mode

2013-01-16 Thread Roger Quadros
On 01/09/2013 12:29 AM, NeilBrown wrote:
 
 Hi,
  I'm trying to get off_mode working reliably on my gta04 mobile phone.
 
 My current stumbling block is USB.  The Option GSM module is attached via
 USB (there is a separate transceiver chip attached to port 1 which is placed
 in OMAP_EHCI_PORT_MODE_PHY).
 
 After a suspend/resume cycle with off_mode enabled the GSM module disappears.
 i.e. 'lsusb' doesn't see it any more and the various ttyHSxx devices don't
 exist.
 Without off mode, the modem always appears after resume.
 
 I discovered that the registers set by:
 
drivers/mfd/omap-usb-host.c
 
 are not maintained across as suspend/resume so I added the following patch
 (which I can make a formal submission of if it looks right to others), but
 that didn't help (or didn't help enough).
 
 If I
 
   echo 1  /sys/kernel/debug/pm_debug/usbhost_pwrdm/suspend
 
 thus keeping just the USBHOST power domain out of off_mode, the GSM module
 doesn't disappear.  So it seems that some context in the usbhost domain is
 not being save and restored.
 
 This is as far as I can get.  Can someone suggest where I should look to find
 out what is not being saved/restored properly, and how to go about saving and
 restoring?

You need to ensure that USBHOST/TLL context is saved as per the Save and
Restore sequence see section USBHOST/USBTLL Save-and-Restore
Management in the OMAP Technical Reference Manual.

The basic idea there is that software does the context saving into SAR
RAM before entering OFF mode and hardware automatically restores the
context after coming out of OFF mode.

But that alone is not enough for USB host to work. We need to make sure
we have covered all the erratas. There are a number of them which are
not covered yet in mainline.

USB remote wakeup is another challenge with OMAP USB host (while in OFF
mode). The usual workaround here is to use a GPIO as a wakeup line from
the modem.

regards,
-roger

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


Re: Help wanted with USB and OMAP3 off_mode

2013-01-16 Thread NeilBrown
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 16 Jan 2013 11:28:02 +0200 Igor Grinberg grinb...@compulab.co.il
wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 01/16/13 09:26, NeilBrown wrote:
  On Wed, 09 Jan 2013 14:54:00 +0200 Igor Grinberg grinb...@compulab.co.il
  wrote:
  
  On 01/09/13 14:08, Michael Trimarchi wrote:
  Hi Neil
 
  I forget to answer to your questions
 
  On 01/09/2013 12:34 PM, NeilBrown wrote:
  On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi
  mich...@amarulasolutions.com wrote:
 
  Hi Neil
 
  On 01/09/2013 11:19 AM, NeilBrown wrote:
  On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg 
  grinb...@compulab.co.il
  wrote:
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  Hi Neil,
 
  On 01/09/13 00:29, NeilBrown wrote:
 
  Hi,
   I'm trying to get off_mode working reliably on my gta04 mobile 
  phone.
 
  My current stumbling block is USB.  The Option GSM module is 
  attached via
  USB (there is a separate transceiver chip attached to port 1 which 
  is placed
  in OMAP_EHCI_PORT_MODE_PHY).
 
  Which PHY is this (vendor/model)?
 
  Hi Igor,
it is the SMSC USB3322
 
  http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf
 
 
  BTW I subsequently discovered that keeping USBHOST out off off_mode 
  only
  sometimes avoid the problem, not always.  So there are probably 
  multiple
  issues :-(
 
  We have the same PHY and it has some issues with the OMAP USB code.
  First issue we experience is that if we reset the PHY more then once
  w/o power cycling it, the PHY dies until next power cycle.
  So, we stop providing the reset GPIO to the usb code and do the reset
  in the board code.
  
  I've tried various change w.r.t the resetting and  I cannot fault it.
  Resetting or not resetting neither causes a problem while the USB is
  otherwise working, not fixed the USB while  it is otherwise failing.
  So I don't think this is my problem - thanks.
  
 
 
  Are you sure that you don't have glitch on power, reset pin during 
  suspend?
 
 
  No, I don't really have the equipment to measure such things.
  But is it likely?  Would enabling off_mode make it more likely?
 
  I don't know the reason of the off_mode problem :(
 
  We have the equipment to check this and no - this is not the case.
 
 
  Can you suggest some way I could test the hypothesis?
 
  I had the same problem on a rugged mobile phone, so it is just experience
  Check the modem power and reset gpio too, but if you don't need to 
  unblock it
  with the pin after resume we know that modem is not the problem
 
  I don't think modem is the problem...
  We have plain USB connector ports that are dead after the resume from 
  off-mode.
 
  The good news are that we have the off-mode working on v3.6.1,
  including the USB, but we had to do some horrible ugly hacking for this.
 
  
  I assume this  means some patches on top of 3.6.1 ??
  Care to share your code?  Even horribly ugly hacks can be educational.
 
 We are not ready to share these patches (this will happen eventually
 after some work is finished), but I can explain what they do...
 
 We split the ehci_run function to separate the debugfs and sysfs stuff from
 other initializations, so we can run the new version without the debugfs and
 sysfs stuff multiple times.
 
 Then we implement the suspend/resume ehci callbacks:
 on suspend, assert phy reset,
 on resume, deassert phy reset, write EHCI_INSNREG04_DISABLE_UNSUSPEND to
 EHCI_INSNREG04, and call the new ehci_run() function.
 
 That does the job for USB host to resume from off mode.

Interesting thanks.  That makes a certain amount of sense.

However I tried compiling ehci-hcd as a module and  unload/reloading it which
should have a similar net effect to what you did, but it didn't make any
difference - device disappears on resume.

I also tried restoring the correct value to EHCI_INSNREG04 and
EHCI_INSNREG05_ULPI which are the only registers written by 
ehci-omap.c, and that didn't help either.

The only thing I've found that works is keeping 'core' out of off-mode.

BTW I discovered that arch/arm/mach-omap2/powerdomains3xxx_data.c
comments out the setting of 
  .flags= PWRDM_HAS_HDWR_SAR,
for the usbhost powerdomain - that is why I had to leave it in retention.
If I uncomment that setting, the it is safe for USBHOST to go to off-mode,
just not for CORE.

I'll keep exploring.

NeilBrown
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iQIVAwUBUPZ+rznsnt1WYoG5AQLYug//T+J3L11fwVq8JHfiPJVfbEfrAdx96+Id
OD+qpwWUarWfpxcgthuRmkrxxUSXxI8sBr0Y0wKWRw4biFxtzcY3qk5xnlUMCfFx
BuqrevVZ6bQZ3JDORv1OfeRwZXOheW0ocJ50s1aV8QTTZvrTKo0TNv7G2uLYIssK
vafA1WOTQPWAxMd7gx8qjpbT/HPi2kYaLlEJ1/kXYeylGboncUyus42j1q1qnGqy
xN6031rpwba4CXtXysx830/uPrnr3LPCh15HUUpxHsYB8rey+60F0ClbT72ZqajJ
w1Cy1GR+UDAM7DP3wt1z87H6/IHRXpJLVodUQ5LIZezbWYF1CbAcyJoSyrjZhefe
yQnGrFaxHS9oNwaZpDOccxGCPOt8uY5DBRMtEpQKt+3LR0lFJzeICMpfENyMg+3a
mU+fzVfGs0puyg/Imcds5yrpmjtGDzuF0yIZ2pIW8pcWjJwbYVzaw9TfzYSSALv1

Re: Help wanted with USB and OMAP3 off_mode

2013-01-16 Thread NeilBrown
On Wed, 16 Jan 2013 12:00:48 +0200 Roger Quadros rog...@ti.com wrote:

 On 01/09/2013 12:29 AM, NeilBrown wrote:
  
  Hi,
   I'm trying to get off_mode working reliably on my gta04 mobile phone.
  
  My current stumbling block is USB.  The Option GSM module is attached via
  USB (there is a separate transceiver chip attached to port 1 which is placed
  in OMAP_EHCI_PORT_MODE_PHY).
  
  After a suspend/resume cycle with off_mode enabled the GSM module 
  disappears.
  i.e. 'lsusb' doesn't see it any more and the various ttyHSxx devices don't
  exist.
  Without off mode, the modem always appears after resume.
  
  I discovered that the registers set by:
  
 drivers/mfd/omap-usb-host.c
  
  are not maintained across as suspend/resume so I added the following patch
  (which I can make a formal submission of if it looks right to others), but
  that didn't help (or didn't help enough).
  
  If I
  
echo 1  /sys/kernel/debug/pm_debug/usbhost_pwrdm/suspend
  
  thus keeping just the USBHOST power domain out of off_mode, the GSM module
  doesn't disappear.  So it seems that some context in the usbhost domain is
  not being save and restored.
  
  This is as far as I can get.  Can someone suggest where I should look to 
  find
  out what is not being saved/restored properly, and how to go about saving 
  and
  restoring?
 
 You need to ensure that USBHOST/TLL context is saved as per the Save and
 Restore sequence see section USBHOST/USBTLL Save-and-Restore
 Management in the OMAP Technical Reference Manual.
 
 The basic idea there is that software does the context saving into SAR
 RAM before entering OFF mode and hardware automatically restores the
 context after coming out of OFF mode.

Is it?  The way I read the doco, the hardware both saves to SAR RAM, and
restores from  SAR RAM.
  Section 22.2.4.1.6  Save and Restore
of my copy of the TRM says:

 The save-and-restore (SAR) mechanism can extract the hardware context of the 
 high-speed USB host
 controller (after all USB activity has been suspended) before switching off 
 (=save), save it to an external
 always-on memory, and reinject it later after the module has been switched on 
 again and reset (=restore)
 seamlessly for the USB. Part of that context is composed of the register 
 fields described in the current
 chapter. The rest of the context is composed of the buried flip-flops and 
 memories (not accessible by
 software) like finite state-machine (FSM) states, buffer contents, and 
 miscellaneous random logic bits.

which strongly suggests that it is all handled by hardware.  Of course there
are other registers that aren't covered  by the SAR - we need to identify
those and make sure they are saved and restored.  I've found a few registers
that aren't being restored, but restoring them hasn't made a visible
difference yet.

Am I missing something?

 
 But that alone is not enough for USB host to work. We need to make sure
 we have covered all the erratas. There are a number of them which are
 not covered yet in mainline.

Is there a list somewhere?

 
 USB remote wakeup is another challenge with OMAP USB host (while in OFF
 mode). The usual workaround here is to use a GPIO as a wakeup line from
 the modem.

Yes, this is not a problem for my device.  There is a GPIO line which signals
and incoming SMS or Call and it successfully wakes the device.

 
 regards,
 -roger

Thanks,
NeilBrown


signature.asc
Description: PGP signature


Re: Help wanted with USB and OMAP3 off_mode

2013-01-16 Thread Igor Grinberg
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/16/13 12:19, NeilBrown wrote:
 On Wed, 16 Jan 2013 11:28:02 +0200 Igor Grinberg grinb...@compulab.co.il
 wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 01/16/13 09:26, NeilBrown wrote:
 On Wed, 09 Jan 2013 14:54:00 +0200 Igor Grinberg grinb...@compulab.co.il
 wrote:

 On 01/09/13 14:08, Michael Trimarchi wrote:
 Hi Neil

 I forget to answer to your questions

 On 01/09/2013 12:34 PM, NeilBrown wrote:
 On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi
 mich...@amarulasolutions.com wrote:

 Hi Neil

 On 01/09/2013 11:19 AM, NeilBrown wrote:
 On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg 
 grinb...@compulab.co.il
 wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi Neil,

 On 01/09/13 00:29, NeilBrown wrote:

 Hi,
  I'm trying to get off_mode working reliably on my gta04 mobile 
 phone.

 My current stumbling block is USB.  The Option GSM module is 
 attached via
 USB (there is a separate transceiver chip attached to port 1 which 
 is placed
 in OMAP_EHCI_PORT_MODE_PHY).

 Which PHY is this (vendor/model)?

 Hi Igor,
   it is the SMSC USB3322

 http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf


 BTW I subsequently discovered that keeping USBHOST out off off_mode 
 only
 sometimes avoid the problem, not always.  So there are probably 
 multiple
 issues :-(

 We have the same PHY and it has some issues with the OMAP USB code.
 First issue we experience is that if we reset the PHY more then once
 w/o power cycling it, the PHY dies until next power cycle.
 So, we stop providing the reset GPIO to the usb code and do the reset
 in the board code.

 I've tried various change w.r.t the resetting and  I cannot fault it.
 Resetting or not resetting neither causes a problem while the USB is
 otherwise working, not fixed the USB while  it is otherwise failing.
 So I don't think this is my problem - thanks.



 Are you sure that you don't have glitch on power, reset pin during 
 suspend?


 No, I don't really have the equipment to measure such things.
 But is it likely?  Would enabling off_mode make it more likely?

 I don't know the reason of the off_mode problem :(

 We have the equipment to check this and no - this is not the case.


 Can you suggest some way I could test the hypothesis?

 I had the same problem on a rugged mobile phone, so it is just experience
 Check the modem power and reset gpio too, but if you don't need to 
 unblock it
 with the pin after resume we know that modem is not the problem

 I don't think modem is the problem...
 We have plain USB connector ports that are dead after the resume from 
 off-mode.

 The good news are that we have the off-mode working on v3.6.1,
 including the USB, but we had to do some horrible ugly hacking for this.


 I assume this  means some patches on top of 3.6.1 ??
 Care to share your code?  Even horribly ugly hacks can be educational.
 
 We are not ready to share these patches (this will happen eventually
 after some work is finished), but I can explain what they do...
 
 We split the ehci_run function to separate the debugfs and sysfs stuff from
 other initializations, so we can run the new version without the debugfs and
 sysfs stuff multiple times.
 
 Then we implement the suspend/resume ehci callbacks:
 on suspend, assert phy reset,
 on resume, deassert phy reset, write EHCI_INSNREG04_DISABLE_UNSUSPEND to
 EHCI_INSNREG04, and call the new ehci_run() function.
 
 That does the job for USB host to resume from off mode.
 
 Interesting thanks.  That makes a certain amount of sense.
 
 However I tried compiling ehci-hcd as a module and  unload/reloading it which
 should have a similar net effect to what you did, but it didn't make any
 difference - device disappears on resume.

Yes it does for cm-t3730, in fact, that is what we have started from...

 
 I also tried restoring the correct value to EHCI_INSNREG04 and
 EHCI_INSNREG05_ULPI which are the only registers written by 
 ehci-omap.c, and that didn't help either.
 
 The only thing I've found that works is keeping 'core' out of off-mode.

Ah, one more thing, we ensure that phy is completely powered off through
the TPS power scripts, otherwise, it does not work...

 
 BTW I discovered that arch/arm/mach-omap2/powerdomains3xxx_data.c
 comments out the setting of 
   .flags= PWRDM_HAS_HDWR_SAR,
 for the usbhost powerdomain - that is why I had to leave it in retention.
 If I uncomment that setting, the it is safe for USBHOST to go to off-mode,
 just not for CORE.
 
 I'll keep exploring.
 
 NeilBrown
 N?§²æìr¸?yúè?Øb²X¬¶Ç§vØ^?)Þº{.nÇ+?·¥?{±¢f©?{ayºÊ?Ú?ë,j­¢f£¢·h??àz¹®w¥¢¸
 ¢·¦j:+v?¨?wèjØm¶?ÿ¾«?êçzZ+?ù???Ý¢j?ú!tml=

- -- 
Regards,
Igor.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQ9oreAAoJEBDE8YO64EfaRasP/iUDBXhmPQtVm7ESB1DPopMc
b5dUWY1mwQGfNhdcPqApyPk5MPzHTAFfNiLTxJURUqN562gMl1+SR4Mr9cOX6ju4

Re: Help wanted with USB and OMAP3 off_mode

2013-01-16 Thread NeilBrown
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 16 Jan 2013 13:11:26 +0200 Igor Grinberg grinb...@compulab.co.il
wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 01/16/13 12:19, NeilBrown wrote:
  On Wed, 16 Jan 2013 11:28:02 +0200 Igor Grinberg grinb...@compulab.co.il
  wrote:
  
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
  
  On 01/16/13 09:26, NeilBrown wrote:
  On Wed, 09 Jan 2013 14:54:00 +0200 Igor Grinberg grinb...@compulab.co.il
  wrote:
 
  On 01/09/13 14:08, Michael Trimarchi wrote:
  Hi Neil
 
  I forget to answer to your questions
 
  On 01/09/2013 12:34 PM, NeilBrown wrote:
  On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi
  mich...@amarulasolutions.com wrote:
 
  Hi Neil
 
  On 01/09/2013 11:19 AM, NeilBrown wrote:
  On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg 
  grinb...@compulab.co.il
  wrote:
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  Hi Neil,
 
  On 01/09/13 00:29, NeilBrown wrote:
 
  Hi,
   I'm trying to get off_mode working reliably on my gta04 mobile 
  phone.
 
  My current stumbling block is USB.  The Option GSM module is 
  attached via
  USB (there is a separate transceiver chip attached to port 1 which 
  is placed
  in OMAP_EHCI_PORT_MODE_PHY).
 
  Which PHY is this (vendor/model)?
 
  Hi Igor,
it is the SMSC USB3322
 
  http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf
 
 
  BTW I subsequently discovered that keeping USBHOST out off off_mode 
  only
  sometimes avoid the problem, not always.  So there are probably 
  multiple
  issues :-(
 
  We have the same PHY and it has some issues with the OMAP USB code.
  First issue we experience is that if we reset the PHY more then once
  w/o power cycling it, the PHY dies until next power cycle.
  So, we stop providing the reset GPIO to the usb code and do the reset
  in the board code.
 
  I've tried various change w.r.t the resetting and  I cannot fault it.
  Resetting or not resetting neither causes a problem while the USB is
  otherwise working, not fixed the USB while  it is otherwise failing.
  So I don't think this is my problem - thanks.
 
 
 
  Are you sure that you don't have glitch on power, reset pin during 
  suspend?
 
 
  No, I don't really have the equipment to measure such things.
  But is it likely?  Would enabling off_mode make it more likely?
 
  I don't know the reason of the off_mode problem :(
 
  We have the equipment to check this and no - this is not the case.
 
 
  Can you suggest some way I could test the hypothesis?
 
  I had the same problem on a rugged mobile phone, so it is just 
  experience
  Check the modem power and reset gpio too, but if you don't need to 
  unblock it
  with the pin after resume we know that modem is not the problem
 
  I don't think modem is the problem...
  We have plain USB connector ports that are dead after the resume from 
  off-mode.
 
  The good news are that we have the off-mode working on v3.6.1,
  including the USB, but we had to do some horrible ugly hacking for this.
 
 
  I assume this  means some patches on top of 3.6.1 ??
  Care to share your code?  Even horribly ugly hacks can be educational.
  
  We are not ready to share these patches (this will happen eventually
  after some work is finished), but I can explain what they do...
  
  We split the ehci_run function to separate the debugfs and sysfs stuff from
  other initializations, so we can run the new version without the debugfs 
  and
  sysfs stuff multiple times.
  
  Then we implement the suspend/resume ehci callbacks:
  on suspend, assert phy reset,
  on resume, deassert phy reset, write EHCI_INSNREG04_DISABLE_UNSUSPEND to
  EHCI_INSNREG04, and call the new ehci_run() function.
  
  That does the job for USB host to resume from off mode.
  
  Interesting thanks.  That makes a certain amount of sense.
  
  However I tried compiling ehci-hcd as a module and  unload/reloading it 
  which
  should have a similar net effect to what you did, but it didn't make any
  difference - device disappears on resume.
 
 Yes it does for cm-t3730, in fact, that is what we have started from...
 
  
  I also tried restoring the correct value to EHCI_INSNREG04 and
  EHCI_INSNREG05_ULPI which are the only registers written by 
  ehci-omap.c, and that didn't help either.
  
  The only thing I've found that works is keeping 'core' out of off-mode.
 
 Ah, one more thing, we ensure that phy is completely powered off through
 the TPS power scripts, otherwise, it does not work...
 

Ahhh  that does make a difference.

I turned off the 5V5 rail which powered the phy (and a few other things) and
now the usb-attached modem appears after resume.  Very interesting.

I hadn't been doing this as I had been advised that the hardware wouldn't
like it.  There are a few devices (including the  USB PHY) which are supplied
by both a 1V8 rail and the 5V5 rail.  Some of them are out-of-spec if the 1V8
is supplied, but the 5V5 isn't.
The 1V8 must remain on during suspend as it 

Re: Help wanted with USB and OMAP3 off_mode

2013-01-15 Thread NeilBrown
On Wed, 09 Jan 2013 14:54:00 +0200 Igor Grinberg grinb...@compulab.co.il
wrote:

 On 01/09/13 14:08, Michael Trimarchi wrote:
  Hi Neil
  
  I forget to answer to your questions
  
  On 01/09/2013 12:34 PM, NeilBrown wrote:
  On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi
  mich...@amarulasolutions.com wrote:
 
  Hi Neil
 
  On 01/09/2013 11:19 AM, NeilBrown wrote:
  On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg 
  grinb...@compulab.co.il
  wrote:
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  Hi Neil,
 
  On 01/09/13 00:29, NeilBrown wrote:
 
  Hi,
   I'm trying to get off_mode working reliably on my gta04 mobile phone.
 
  My current stumbling block is USB.  The Option GSM module is 
  attached via
  USB (there is a separate transceiver chip attached to port 1 which is 
  placed
  in OMAP_EHCI_PORT_MODE_PHY).
 
  Which PHY is this (vendor/model)?
 
  Hi Igor,
it is the SMSC USB3322
 
  http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf
 
 
  BTW I subsequently discovered that keeping USBHOST out off off_mode only
  sometimes avoid the problem, not always.  So there are probably multiple
  issues :-(
 
 We have the same PHY and it has some issues with the OMAP USB code.
 First issue we experience is that if we reset the PHY more then once
 w/o power cycling it, the PHY dies until next power cycle.
 So, we stop providing the reset GPIO to the usb code and do the reset
 in the board code.

I've tried various change w.r.t the resetting and  I cannot fault it.
Resetting or not resetting neither causes a problem while the USB is
otherwise working, not fixed the USB while  it is otherwise failing.
So I don't think this is my problem - thanks.

 
 
  Are you sure that you don't have glitch on power, reset pin during 
  suspend?
 
 
  No, I don't really have the equipment to measure such things.
  But is it likely?  Would enabling off_mode make it more likely?
  
  I don't know the reason of the off_mode problem :(
 
 We have the equipment to check this and no - this is not the case.
 
  
  Can you suggest some way I could test the hypothesis?
  
  I had the same problem on a rugged mobile phone, so it is just experience
  Check the modem power and reset gpio too, but if you don't need to unblock 
  it
  with the pin after resume we know that modem is not the problem
 
 I don't think modem is the problem...
 We have plain USB connector ports that are dead after the resume from 
 off-mode.
 
 The good news are that we have the off-mode working on v3.6.1,
 including the USB, but we had to do some horrible ugly hacking for this.
 

I assume this  means some patches on top of 3.6.1 ??
Care to share your code?  Even horribly ugly hacks can be educational.

Thanks,
NeilBrown


signature.asc
Description: PGP signature


Re: Help wanted with USB and OMAP3 off_mode

2013-01-15 Thread NeilBrown
On Wed, 09 Jan 2013 12:42:43 +0100 Michael Trimarchi
mich...@amarulasolutions.com wrote:

 On 01/09/2013 12:34 PM, NeilBrown wrote:
  On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi
  mich...@amarulasolutions.com wrote:
  
  Hi Neil
 
  On 01/09/2013 11:19 AM, NeilBrown wrote:
  On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg grinb...@compulab.co.il
  wrote:
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  Hi Neil,
 
  On 01/09/13 00:29, NeilBrown wrote:
 
  Hi,
   I'm trying to get off_mode working reliably on my gta04 mobile phone.
 
  My current stumbling block is USB.  The Option GSM module is attached 
  via
  USB (there is a separate transceiver chip attached to port 1 which is 
  placed
  in OMAP_EHCI_PORT_MODE_PHY).
 
  Which PHY is this (vendor/model)?
 
  Hi Igor,
it is the SMSC USB3322
 
  http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf
 
 
  BTW I subsequently discovered that keeping USBHOST out off off_mode only
  sometimes avoid the problem, not always.  So there are probably multiple
  issues :-(
 
  Are you sure that you don't have glitch on power, reset pin during suspend?
 
  
  No, I don't really have the equipment to measure such things.
  But is it likely?  Would enabling off_mode make it more likely?
  Can you suggest some way I could test the hypothesis?
  
  The power pin is connected to a 3v3 regulator which certainly should stay on
  the whole time and other things which depend on it keep working.
  
  The reset line is connected to GPIO174 which is configured:
  
  # cat /sys/kernel/debug/omap_mux/mcspi1_cs0
  name: mcspi1_cs0.gpio_174 (0x480021ce/0x19e = 0x011c), b ac2, t NA
  mode: OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE4
  signals: mcspi1_cs0 | sdmmc2_dat7 | NA | NA | gpio_174 | NA | NA | safe_mode
  
  The PIN_INPUT seems a bit odd, so I changed it to OMAP_PIN_OUTPUT but that
  didn't appear to make any difference.
  
 
 Can you try to add this OMAP_PIN_OFF_OUTPUT_HIGH or LOW? It's suppose to be 
 the off_mode status of the pin.
 Is it correct?
 

You only set OMAP_PIN_OFF_OUTPUT_HIGH etc if you want the status  in
offmode to be different to what is was before off mode.
In the normal case without any of these bits set, the current value is
latched when output in entered and it remains like that that until you
leave off_mode.

Thanks,
NeilBrown


signature.asc
Description: PGP signature


Re: Help wanted with USB and OMAP3 off_mode

2013-01-09 Thread Igor Grinberg
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Neil,

On 01/09/13 00:29, NeilBrown wrote:
 
 Hi,
  I'm trying to get off_mode working reliably on my gta04 mobile phone.
 
 My current stumbling block is USB.  The Option GSM module is attached via
 USB (there is a separate transceiver chip attached to port 1 which is placed
 in OMAP_EHCI_PORT_MODE_PHY).

Which PHY is this (vendor/model)?

 
 After a suspend/resume cycle with off_mode enabled the GSM module disappears.
 i.e. 'lsusb' doesn't see it any more and the various ttyHSxx devices don't
 exist.
 Without off mode, the modem always appears after resume.
 
 I discovered that the registers set by:
 
drivers/mfd/omap-usb-host.c
 
 are not maintained across as suspend/resume so I added the following patch
 (which I can make a formal submission of if it looks right to others), but
 that didn't help (or didn't help enough).
 
 If I
 
   echo 1  /sys/kernel/debug/pm_debug/usbhost_pwrdm/suspend
 
 thus keeping just the USBHOST power domain out of off_mode, the GSM module
 doesn't disappear.  So it seems that some context in the usbhost domain is
 not being save and restored.
 
 This is as far as I can get.  Can someone suggest where I should look to find
 out what is not being saved/restored properly, and how to go about saving and
 restoring?
 
 Thanks in advance,
 NeilBrown
 
 
 
 diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
 index 23cec57..522405e 100644
 --- a/drivers/mfd/omap-usb-host.c
 +++ b/drivers/mfd/omap-usb-host.c
 @@ -100,6 +100,10 @@ struct usbhs_hcd_omap {
  
   void __iomem*uhh_base;
  
 + struct {
 + unsignedhostconfig;
 + } context;
 +
   struct usbhs_omap_platform_data platdata;
  
   u32 usbhs_rev;
 @@ -300,6 +304,10 @@ static int usbhs_runtime_resume(struct device *dev)
   clk_enable(omap-utmi_p1_fck);
   clk_enable(omap-utmi_p2_fck);
  
 + usbhs_write(omap-uhh_base,
 + OMAP_UHH_HOSTCONFIG,
 + omap-context.hostconfig);
 +
   spin_unlock_irqrestore(omap-lock, flags);
  
   return 0;
 @@ -319,6 +327,8 @@ static int usbhs_runtime_suspend(struct device *dev)
   }
  
   spin_lock_irqsave(omap-lock, flags);
 + omap-context.hostconfig = usbhs_read(omap-uhh_base,
 +   OMAP_UHH_HOSTCONFIG);
  
   if (is_ehci_tll_mode(pdata-port_mode[0]))
   clk_disable(omap-usbhost_p1_fck);

- -- 
Regards,
Igor.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQ7T+kAAoJEBDE8YO64Efaj8YQAI5nOE9vvf8wxbu5IXTxaMxn
6B+g2m/zkMlyVNL5hTrwkPkP4CTBwvsGCZYkZT5JS3KM+R+TuyIX07+eM59Ie0Po
u1CCn2XKZY2CP53b3nAtgk9Phxwruf5fDjEu9QiQapdUpbiTWmIn8W3CVye241O2
wXBKAXszX1bD81NFNY+Jm5Us5uGHNTtNtqe78Rng7BTvmaaNgE61PurFclgn0xQb
IO5E7eyq7TG1u/IBhge2jlZGx2BbLcVsrQI3WyuE2L6F+MRgAKBDD7K8uHTfxPyM
eXAk/u5tbA21t1mTIXk19N4c0YVgeFW2kKQOPShKywy9J6k3tE5LE4yUjooo4ZeS
TlIf7HFcp15N3FfX90FOYsQOXILnoNL6a8SOK3gU+iVxZU/4VohKOXBlMjuZ7o10
5FnglPaHjsEaa1DgB/FcnYh3OO33mODJsckUhi5GiIlrbm70JspfWShZfln1k8FS
SwClmyb6FCiqBOcRJ2uS1KTwObzYV9WeuPGCTXC5d4UBB57eRcGcX/NvSftV57mX
jcSEle93kgZx1EiG53Vwd29oV9nU6SJECF7Q8CqulDEQVr76E7Xh8Z1CrsD+BhKe
XuFa3zdtMg1SZO/ctcTIPPpElCVPF1FChX2lY9fCIdK2luHNrOs4GyrozCGXQcXO
ZMFiiStsjr021CGqQUFw
=yIA2
-END PGP SIGNATURE-
--
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: Help wanted with USB and OMAP3 off_mode

2013-01-09 Thread NeilBrown
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg grinb...@compulab.co.il
wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Hi Neil,
 
 On 01/09/13 00:29, NeilBrown wrote:
  
  Hi,
   I'm trying to get off_mode working reliably on my gta04 mobile phone.
  
  My current stumbling block is USB.  The Option GSM module is attached via
  USB (there is a separate transceiver chip attached to port 1 which is placed
  in OMAP_EHCI_PORT_MODE_PHY).
 
 Which PHY is this (vendor/model)?

Hi Igor,
  it is the SMSC USB3322

http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf


BTW I subsequently discovered that keeping USBHOST out off off_mode only
sometimes avoid the problem, not always.  So there are probably multiple
issues :-(

NeilBrown



 
  
  After a suspend/resume cycle with off_mode enabled the GSM module 
  disappears.
  i.e. 'lsusb' doesn't see it any more and the various ttyHSxx devices don't
  exist.
  Without off mode, the modem always appears after resume.
  
  I discovered that the registers set by:
  
 drivers/mfd/omap-usb-host.c
  
  are not maintained across as suspend/resume so I added the following patch
  (which I can make a formal submission of if it looks right to others), but
  that didn't help (or didn't help enough).
  
  If I
  
echo 1  /sys/kernel/debug/pm_debug/usbhost_pwrdm/suspend
  
  thus keeping just the USBHOST power domain out of off_mode, the GSM module
  doesn't disappear.  So it seems that some context in the usbhost domain is
  not being save and restored.
  
  This is as far as I can get.  Can someone suggest where I should look to 
  find
  out what is not being saved/restored properly, and how to go about saving 
  and
  restoring?
  
  Thanks in advance,
  NeilBrown
  
  
  
  diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
  index 23cec57..522405e 100644
  --- a/drivers/mfd/omap-usb-host.c
  +++ b/drivers/mfd/omap-usb-host.c
  @@ -100,6 +100,10 @@ struct usbhs_hcd_omap {
   
  void __iomem*uhh_base;
   
  +   struct {
  +   unsignedhostconfig;
  +   } context;
  +
  struct usbhs_omap_platform_data platdata;
   
  u32 usbhs_rev;
  @@ -300,6 +304,10 @@ static int usbhs_runtime_resume(struct device *dev)
  clk_enable(omap-utmi_p1_fck);
  clk_enable(omap-utmi_p2_fck);
   
  +   usbhs_write(omap-uhh_base,
  +   OMAP_UHH_HOSTCONFIG,
  +   omap-context.hostconfig);
  +
  spin_unlock_irqrestore(omap-lock, flags);
   
  return 0;
  @@ -319,6 +327,8 @@ static int usbhs_runtime_suspend(struct device *dev)
  }
   
  spin_lock_irqsave(omap-lock, flags);
  +   omap-context.hostconfig = usbhs_read(omap-uhh_base,
  + OMAP_UHH_HOSTCONFIG);
   
  if (is_ehci_tll_mode(pdata-port_mode[0]))
  clk_disable(omap-usbhost_p1_fck);
 
 - -- 
 Regards,
 Igor.
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.17 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
 iQIcBAEBAgAGBQJQ7T+kAAoJEBDE8YO64Efaj8YQAI5nOE9vvf8wxbu5IXTxaMxn
 6B+g2m/zkMlyVNL5hTrwkPkP4CTBwvsGCZYkZT5JS3KM+R+TuyIX07+eM59Ie0Po
 u1CCn2XKZY2CP53b3nAtgk9Phxwruf5fDjEu9QiQapdUpbiTWmIn8W3CVye241O2
 wXBKAXszX1bD81NFNY+Jm5Us5uGHNTtNtqe78Rng7BTvmaaNgE61PurFclgn0xQb
 IO5E7eyq7TG1u/IBhge2jlZGx2BbLcVsrQI3WyuE2L6F+MRgAKBDD7K8uHTfxPyM
 eXAk/u5tbA21t1mTIXk19N4c0YVgeFW2kKQOPShKywy9J6k3tE5LE4yUjooo4ZeS
 TlIf7HFcp15N3FfX90FOYsQOXILnoNL6a8SOK3gU+iVxZU/4VohKOXBlMjuZ7o10
 5FnglPaHjsEaa1DgB/FcnYh3OO33mODJsckUhi5GiIlrbm70JspfWShZfln1k8FS
 SwClmyb6FCiqBOcRJ2uS1KTwObzYV9WeuPGCTXC5d4UBB57eRcGcX/NvSftV57mX
 jcSEle93kgZx1EiG53Vwd29oV9nU6SJECF7Q8CqulDEQVr76E7Xh8Z1CrsD+BhKe
 XuFa3zdtMg1SZO/ctcTIPPpElCVPF1FChX2lY9fCIdK2luHNrOs4GyrozCGXQcXO
 ZMFiiStsjr021CGqQUFw
 =yIA2
 -END PGP SIGNATURE-

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iQIVAwUBUO1EMznsnt1WYoG5AQJ9Gg//Qwx5P/VjOi+9TDXIGr10OqldLEQKG4zv
Dbwhw5l9DR85JIuF+m5xVXUe9IWJZ0UCasi61LtkRJVGW8U7Lv0O2mmXcYHoQ9zt
diph8SVM9ZTh4SAaz2iiHeJ1Sqz0WkiZ47Kv1C0Q/n9MyFqKKG7Nxg5UAyAj39x4
pa8vsBGcPmwn5U/dUPQBxs3QKdp9aI3i2I6Q6vObRLYLJSvxAeXkGYfrmMy/NoZz
RNhkLhVTajPCYTBcPw+zH06Pv8VF+i/UwFggnVl+uW+6LrIpKbaLa7CMntXmrSgz
fi7y1LLiQuE7qK26IizLu/XIapb0tPGy28AebYwSbjFTaqHPNmlLAzyfww3lBteI
PS76DulKiR4YX58v0KGKITcYLKK3mUliOETcWylot2eTyqbP9m0Y3nX57AEDi0+N
FBBuoG4EKUQaLf5CnjF6ViMttUfvcfwL+Vrn+4VaYndS9S9w5IXTii5b1OcuhJaZ
aGS+Tm/Mwa1uNQWBjujc/DdvwKZRrRilHTBH4w/rHRwxNTqKAxWmq72162efpxdR
JxkHrPTEZZZwLewPXmTbD1+h50284apAw+D2PERFiB+Fh4ZVzsLIcBcUIZ3OT4L1
AlrqYC0wAS2RgjhvmveR360i8DS1SXMMafonrLhrwRu7oe1uzltKmnNX21Sp76vB
gM5LIokwosA=
=8VnD
-END PGP SIGNATURE-


Re: Help wanted with USB and OMAP3 off_mode

2013-01-09 Thread Michael Trimarchi
Hi Neil

On 01/09/2013 11:19 AM, NeilBrown wrote:
 On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg grinb...@compulab.co.il
 wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Hi Neil,
 
 On 01/09/13 00:29, NeilBrown wrote:

 Hi,
  I'm trying to get off_mode working reliably on my gta04 mobile phone.

 My current stumbling block is USB.  The Option GSM module is attached via
 USB (there is a separate transceiver chip attached to port 1 which is placed
 in OMAP_EHCI_PORT_MODE_PHY).
 
 Which PHY is this (vendor/model)?
 
 Hi Igor,
   it is the SMSC USB3322
 
 http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf
 
 
 BTW I subsequently discovered that keeping USBHOST out off off_mode only
 sometimes avoid the problem, not always.  So there are probably multiple
 issues :-(

Are you sure that you don't have glitch on power, reset pin during suspend?

Michael

 
 NeilBrown
 
 
 
 

 After a suspend/resume cycle with off_mode enabled the GSM module 
 disappears.
 i.e. 'lsusb' doesn't see it any more and the various ttyHSxx devices don't
 exist.
 Without off mode, the modem always appears after resume.

 I discovered that the registers set by:

drivers/mfd/omap-usb-host.c

 are not maintained across as suspend/resume so I added the following patch
 (which I can make a formal submission of if it looks right to others), but
 that didn't help (or didn't help enough).

 If I

   echo 1  /sys/kernel/debug/pm_debug/usbhost_pwrdm/suspend

 thus keeping just the USBHOST power domain out of off_mode, the GSM module
 doesn't disappear.  So it seems that some context in the usbhost domain is
 not being save and restored.

 This is as far as I can get.  Can someone suggest where I should look to 
 find
 out what is not being saved/restored properly, and how to go about saving 
 and
 restoring?

 Thanks in advance,
 NeilBrown



 diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
 index 23cec57..522405e 100644
 --- a/drivers/mfd/omap-usb-host.c
 +++ b/drivers/mfd/omap-usb-host.c
 @@ -100,6 +100,10 @@ struct usbhs_hcd_omap {
  
 void __iomem*uhh_base;
  
 +   struct {
 +   unsignedhostconfig;
 +   } context;
 +
 struct usbhs_omap_platform_data platdata;
  
 u32 usbhs_rev;
 @@ -300,6 +304,10 @@ static int usbhs_runtime_resume(struct device *dev)
 clk_enable(omap-utmi_p1_fck);
 clk_enable(omap-utmi_p2_fck);
  
 +   usbhs_write(omap-uhh_base,
 +   OMAP_UHH_HOSTCONFIG,
 +   omap-context.hostconfig);
 +
 spin_unlock_irqrestore(omap-lock, flags);
  
 return 0;
 @@ -319,6 +327,8 @@ static int usbhs_runtime_suspend(struct device *dev)
 }
  
 spin_lock_irqsave(omap-lock, flags);
 +   omap-context.hostconfig = usbhs_read(omap-uhh_base,
 + OMAP_UHH_HOSTCONFIG);
  
 if (is_ehci_tll_mode(pdata-port_mode[0]))
 clk_disable(omap-usbhost_p1_fck);
 
 - -- 
 Regards,
 Igor.
 

 N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±¢f©Š{ayºʇڙë,j­¢f£¢·hš‹àz¹®w¥¢¸
 ¢·¦j:+v‰¨ŠwèjØm¶Ÿÿ¾«‘êçzZ+ƒùšŽŠÝ¢j�ú!tml=
 
--
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: Help wanted with USB and OMAP3 off_mode

2013-01-09 Thread NeilBrown
On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi
mich...@amarulasolutions.com wrote:

 Hi Neil
 
 On 01/09/2013 11:19 AM, NeilBrown wrote:
  On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg grinb...@compulab.co.il
  wrote:
  
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
  
  Hi Neil,
  
  On 01/09/13 00:29, NeilBrown wrote:
 
  Hi,
   I'm trying to get off_mode working reliably on my gta04 mobile phone.
 
  My current stumbling block is USB.  The Option GSM module is attached 
  via
  USB (there is a separate transceiver chip attached to port 1 which is 
  placed
  in OMAP_EHCI_PORT_MODE_PHY).
  
  Which PHY is this (vendor/model)?
  
  Hi Igor,
it is the SMSC USB3322
  
  http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf
  
  
  BTW I subsequently discovered that keeping USBHOST out off off_mode only
  sometimes avoid the problem, not always.  So there are probably multiple
  issues :-(
 
 Are you sure that you don't have glitch on power, reset pin during suspend?
 

No, I don't really have the equipment to measure such things.
But is it likely?  Would enabling off_mode make it more likely?
Can you suggest some way I could test the hypothesis?

The power pin is connected to a 3v3 regulator which certainly should stay on
the whole time and other things which depend on it keep working.

The reset line is connected to GPIO174 which is configured:

# cat /sys/kernel/debug/omap_mux/mcspi1_cs0
name: mcspi1_cs0.gpio_174 (0x480021ce/0x19e = 0x011c), b ac2, t NA
mode: OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE4
signals: mcspi1_cs0 | sdmmc2_dat7 | NA | NA | gpio_174 | NA | NA | safe_mode

The PIN_INPUT seems a bit odd, so I changed it to OMAP_PIN_OUTPUT but that
didn't appear to make any difference.

Thanks,
NeilBrown


signature.asc
Description: PGP signature


Re: Help wanted with USB and OMAP3 off_mode

2013-01-09 Thread Michael Trimarchi
On 01/09/2013 12:34 PM, NeilBrown wrote:
 On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi
 mich...@amarulasolutions.com wrote:
 
 Hi Neil

 On 01/09/2013 11:19 AM, NeilBrown wrote:
 On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg grinb...@compulab.co.il
 wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi Neil,

 On 01/09/13 00:29, NeilBrown wrote:

 Hi,
  I'm trying to get off_mode working reliably on my gta04 mobile phone.

 My current stumbling block is USB.  The Option GSM module is attached 
 via
 USB (there is a separate transceiver chip attached to port 1 which is 
 placed
 in OMAP_EHCI_PORT_MODE_PHY).

 Which PHY is this (vendor/model)?

 Hi Igor,
   it is the SMSC USB3322

 http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf


 BTW I subsequently discovered that keeping USBHOST out off off_mode only
 sometimes avoid the problem, not always.  So there are probably multiple
 issues :-(

 Are you sure that you don't have glitch on power, reset pin during suspend?

 
 No, I don't really have the equipment to measure such things.
 But is it likely?  Would enabling off_mode make it more likely?
 Can you suggest some way I could test the hypothesis?
 
 The power pin is connected to a 3v3 regulator which certainly should stay on
 the whole time and other things which depend on it keep working.
 
 The reset line is connected to GPIO174 which is configured:
 
 # cat /sys/kernel/debug/omap_mux/mcspi1_cs0
 name: mcspi1_cs0.gpio_174 (0x480021ce/0x19e = 0x011c), b ac2, t NA
 mode: OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE4
 signals: mcspi1_cs0 | sdmmc2_dat7 | NA | NA | gpio_174 | NA | NA | safe_mode
 
 The PIN_INPUT seems a bit odd, so I changed it to OMAP_PIN_OUTPUT but that
 didn't appear to make any difference.
 

Can you try to add this OMAP_PIN_OFF_OUTPUT_HIGH or LOW? It's suppose to be the 
off_mode status of the pin.
Is it correct?


Michael




 Thanks,
 NeilBrown
 


-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |


--
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: Help wanted with USB and OMAP3 off_mode

2013-01-09 Thread Michael Trimarchi
Hi Neil

I forget to answer to your questions

On 01/09/2013 12:34 PM, NeilBrown wrote:
 On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi
 mich...@amarulasolutions.com wrote:
 
 Hi Neil

 On 01/09/2013 11:19 AM, NeilBrown wrote:
 On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg grinb...@compulab.co.il
 wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi Neil,

 On 01/09/13 00:29, NeilBrown wrote:

 Hi,
  I'm trying to get off_mode working reliably on my gta04 mobile phone.

 My current stumbling block is USB.  The Option GSM module is attached 
 via
 USB (there is a separate transceiver chip attached to port 1 which is 
 placed
 in OMAP_EHCI_PORT_MODE_PHY).

 Which PHY is this (vendor/model)?

 Hi Igor,
   it is the SMSC USB3322

 http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf


 BTW I subsequently discovered that keeping USBHOST out off off_mode only
 sometimes avoid the problem, not always.  So there are probably multiple
 issues :-(

 Are you sure that you don't have glitch on power, reset pin during suspend?

 
 No, I don't really have the equipment to measure such things.
 But is it likely?  Would enabling off_mode make it more likely?

I don't know the reason of the off_mode problem :(

 Can you suggest some way I could test the hypothesis?

I had the same problem on a rugged mobile phone, so it is just experience
Check the modem power and reset gpio too, but if you don't need to unblock it
with the pin after resume we know that modem is not the problem

Michael

 
 The power pin is connected to a 3v3 regulator which certainly should stay on
 the whole time and other things which depend on it keep working.
 
 The reset line is connected to GPIO174 which is configured:
 
 # cat /sys/kernel/debug/omap_mux/mcspi1_cs0
 name: mcspi1_cs0.gpio_174 (0x480021ce/0x19e = 0x011c), b ac2, t NA
 mode: OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE4
 signals: mcspi1_cs0 | sdmmc2_dat7 | NA | NA | gpio_174 | NA | NA | safe_mode
 
 The PIN_INPUT seems a bit odd, so I changed it to OMAP_PIN_OUTPUT but that
 didn't appear to make any difference.
 
 Thanks,
 NeilBrown
 

--
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: Help wanted with USB and OMAP3 off_mode

2013-01-09 Thread Igor Grinberg
On 01/09/13 14:08, Michael Trimarchi wrote:
 Hi Neil
 
 I forget to answer to your questions
 
 On 01/09/2013 12:34 PM, NeilBrown wrote:
 On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi
 mich...@amarulasolutions.com wrote:

 Hi Neil

 On 01/09/2013 11:19 AM, NeilBrown wrote:
 On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg grinb...@compulab.co.il
 wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi Neil,

 On 01/09/13 00:29, NeilBrown wrote:

 Hi,
  I'm trying to get off_mode working reliably on my gta04 mobile phone.

 My current stumbling block is USB.  The Option GSM module is attached 
 via
 USB (there is a separate transceiver chip attached to port 1 which is 
 placed
 in OMAP_EHCI_PORT_MODE_PHY).

 Which PHY is this (vendor/model)?

 Hi Igor,
   it is the SMSC USB3322

 http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf


 BTW I subsequently discovered that keeping USBHOST out off off_mode only
 sometimes avoid the problem, not always.  So there are probably multiple
 issues :-(

We have the same PHY and it has some issues with the OMAP USB code.
First issue we experience is that if we reset the PHY more then once
w/o power cycling it, the PHY dies until next power cycle.
So, we stop providing the reset GPIO to the usb code and do the reset
in the board code.


 Are you sure that you don't have glitch on power, reset pin during suspend?


 No, I don't really have the equipment to measure such things.
 But is it likely?  Would enabling off_mode make it more likely?
 
 I don't know the reason of the off_mode problem :(

We have the equipment to check this and no - this is not the case.

 
 Can you suggest some way I could test the hypothesis?
 
 I had the same problem on a rugged mobile phone, so it is just experience
 Check the modem power and reset gpio too, but if you don't need to unblock it
 with the pin after resume we know that modem is not the problem

I don't think modem is the problem...
We have plain USB connector ports that are dead after the resume from off-mode.

The good news are that we have the off-mode working on v3.6.1,
including the USB, but we had to do some horrible ugly hacking for this.

-- 
Regards,
Igor.
--
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


Help wanted with USB and OMAP3 off_mode

2013-01-08 Thread NeilBrown

Hi,
 I'm trying to get off_mode working reliably on my gta04 mobile phone.

My current stumbling block is USB.  The Option GSM module is attached via
USB (there is a separate transceiver chip attached to port 1 which is placed
in OMAP_EHCI_PORT_MODE_PHY).

After a suspend/resume cycle with off_mode enabled the GSM module disappears.
i.e. 'lsusb' doesn't see it any more and the various ttyHSxx devices don't
exist.
Without off mode, the modem always appears after resume.

I discovered that the registers set by:

   drivers/mfd/omap-usb-host.c

are not maintained across as suspend/resume so I added the following patch
(which I can make a formal submission of if it looks right to others), but
that didn't help (or didn't help enough).

If I

  echo 1  /sys/kernel/debug/pm_debug/usbhost_pwrdm/suspend

thus keeping just the USBHOST power domain out of off_mode, the GSM module
doesn't disappear.  So it seems that some context in the usbhost domain is
not being save and restored.

This is as far as I can get.  Can someone suggest where I should look to find
out what is not being saved/restored properly, and how to go about saving and
restoring?

Thanks in advance,
NeilBrown



diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 23cec57..522405e 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -100,6 +100,10 @@ struct usbhs_hcd_omap {
 
void __iomem*uhh_base;
 
+   struct {
+   unsignedhostconfig;
+   } context;
+
struct usbhs_omap_platform_data platdata;
 
u32 usbhs_rev;
@@ -300,6 +304,10 @@ static int usbhs_runtime_resume(struct device *dev)
clk_enable(omap-utmi_p1_fck);
clk_enable(omap-utmi_p2_fck);
 
+   usbhs_write(omap-uhh_base,
+   OMAP_UHH_HOSTCONFIG,
+   omap-context.hostconfig);
+
spin_unlock_irqrestore(omap-lock, flags);
 
return 0;
@@ -319,6 +327,8 @@ static int usbhs_runtime_suspend(struct device *dev)
}
 
spin_lock_irqsave(omap-lock, flags);
+   omap-context.hostconfig = usbhs_read(omap-uhh_base,
+ OMAP_UHH_HOSTCONFIG);
 
if (is_ehci_tll_mode(pdata-port_mode[0]))
clk_disable(omap-usbhost_p1_fck);


signature.asc
Description: PGP signature