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 "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.... 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.
Thanks,
NeilBrown
signature.asc
Description: PGP signature
