On Thu, 17 Jan 2013 13:29:07 +0200 Roger Quadros <rogerq@xxxxxx> wrote: > On 01/17/2013 01:01 PM, NeilBrown wrote: > > On Wed, 16 Jan 2013 12:57:08 +0200 Roger Quadros <rogerq@xxxxxx> wrote: > > > >> On 01/16/2013 12:27 PM, NeilBrown wrote: > >>> On Wed, 16 Jan 2013 12:00:48 +0200 Roger Quadros <rogerq@xxxxxx> 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 "sometimes"s! > > > > 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 CORE awake). > > > > If I do the same but before it suspends I: > > > > echo 1 > /sys/kernel/debug/pm_debug/core_pwrdm/suspend > > > > then let is suspend and resume, the resume works. Then I: > > > > echo 0 > /sys/kernel/debug/pm_debug/core_pwrdm/suspend > > > > to allow full sleep mode and now suspend, and again resume works. > > And it continues to work. > > And the USB modem remains visible - it doesn't disconnect at all. > > > > So does repeated suspend/resume work after this? Or is it only the first > suspend/resume. suspend/resume continues to work until a power-down. Even after a soft reboot (which goes back to ILO and u-boot, but doesn't remove power), suspend/resume continue to work. It is only after a power-off that I need one suspend cycle with CORE in retention before things work. > > > So.... something very odd is happening somewhere. > > Maybe the USBHOST powerdomain isn't really going to off-mode again after the > > first time like the comment in powerdomains3xxx_data.c says: > > > > /* > > * REVISIT: Enabling usb host save and restore mechanism seems to > > * leave the usb host domain permanently in ACTIVE mode after > > * changing the usb host power domain state from OFF to active once. > > * Disabling for now. > > */ > > > > However the /sys/kernel/debug/pm_debug/count file shows the "OFF" count for > > usbhost_pwrdm increments on each suspend, and that seems to be based on info > > read out of the the OMAP3 itself.... > > > > All very odd. > > I need to give this a try. I can try it out on OMAP3 beagle board. > > What OMAP3 are you on, and which kernel are you using for your tests? I believe it is a DM3730 # cat /proc/cpuinfo Processor : ARMv7 Processor rev 2 (v7l) BogoMIPS : 311.92 Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x3 CPU part : 0xc08 CPU revision : 2 Hardware : GTA04 Revision : 0020 Serial : 0000000000000000 Kernel is the 'mainline' branch of git://neil.brown.name/gta04 (commit 388c9f46f9d566bd7f7dd6acb45c113c59c11417) This is 3.7 plus a bunch of fixes and additions to make it all mostly work on this board (Panel driver, audio glue, sdio wifi fixes, sensor drivers, bug fixes, etc etc etc). Thanks, NeilBrown
Attachment:
signature.asc
Description: PGP signature
