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. 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
Attachment:
signature.asc
Description: PGP signature
