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


Attachment: signature.asc
Description: PGP signature

Reply via email to