andy git 06/15 suspend/resume observations

[Mike (mwester)]

Andy Green wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Somebody in the thread at some point said:
> | Somebody in the thread at some point said:
> | | Andy,
> | |
> | | I've now confirmed it is from GSM wakeup. If I do not initialize the
> GSM
> | | then the phone never locks up.
> |
> | EXCELLENT, thanks a lot.
> |
> | Mike can this plug into the serial resume problems?

I haven't taken a thorough look at the GTA02; with the console safely
out of the way on port 2 on this device there should be absolutely no
reason for any suspend/resume ordering issue to cause lockup/hang problems.

> |
> | How can one provoke GSM wakes then?  Although I am in runlevel 3 I do
> | actually have a SIM card in and am running gsmd -- last night before I
> | went to bed though I put it in suspend, and it woke 100% perfect
> | thismorning after 7 - 8 hours suspended.  But it didn't wake before that
> | from GSM.... you really have to ring the phone?

Depends on your rootfs; the other emails on this thread outline the
common things.  One can enable the "nspy" feature to find out.  Echo "1"
 to the nspy_enable sysfs file to turn it on.  Then when the phone
wakes, repeatedly "cat" the nspy_buffer sysfs file to dump out the event
buffer.  You'll see the suspend/resume events from the point of view of
the serial and neo1973_pm_gsm drivers, and you'll see the data stream
from the UART identifying the reason for the wakeup.

There is one other possibility -- when the GSM first powers up, it
always issues a GSM wakeup interrupt, although it has no data to send.
Is there a possibility that the GSM is being unpowered and powering back up?

> 
> Hm what's going on here... in the resume:
> 
>     /* We must defer the auto flowcontrol because we resume before
>      * the serial driver */
>     if (!schedule_work(&gsmwork))
>         dev_err(&pdev->dev,
>             "Unable to schedule GSM wakeup work\n");
> 
> but in the work function there
> 
> static void gsm_resume_work(struct work_struct *w)
> {
>     printk(KERN_INFO "%s: waiting...\n", __FUNCTION__);
>     nspy_add(NSPY_TYPE_RESUME, 'W', jiffies);
>     if (gsm_autounlock_delay)                    <=== zero on GTA02
>         msleep(gsm_autounlock_delay);        <=== no delay

User-space on the GTA02 is expected to explicitly manage the
flow-control by means of the sysfs flag (preferred), or by means of
changing the modem control lines on the serial port (deprecated, IMO),
or as a last resort (and highly discouraged) to set the auto-unlock
delay to some non-zero value.

The GTA01 had different defaults because I thought (at the time) that by
using the auto-unlock technique and the horrible hack in the serial
driver, we could avoid the overrun problem.  It turns out that just
defers it, so there's no longer any point to having GTA01 handled any
differently than GTA02.

Which (as I mentioned in an earlier email) leaves us with three means to
handle flowcontrol of the GSM, which is two too many.  This particular
bit of code will be removed, along with the code in the serial driver
that does this function from the modem-control code.

>     if (gsm_auto_flowcontrolled) {
>         nspy_add(NSPY_TYPE_SPECIAL, '+', jiffies);
>         if (machine_is_neo1973_gta01())
>             s3c24xx_fake_rx_interrupt(10000);
>         s3c2410_gpio_cfgpin(S3C2410_GPH1, S3C2410_GPH1_nRTS0);
>         gsm_auto_flowcontrolled = 0;
>     }
>     nspy_add(NSPY_TYPE_RESUME, 'Z', jiffies);
>     printk(KERN_INFO "%s: done.\n", __FUNCTION__);
> }
> 
> There's no schedule_delayed_work, no msleep, this could execute right
> away, and yet it says in the comment we need to wait for serial driver
> !?!?

We need to wait for the serial driver in order to avoid data loss -- not
because of any hangs or lockups that I've ever observed.  The issue is
that depending on whether the low-level debug for suspend/resume is
enabled in the defconfig, the UART registers may be restored on wake, or
they may be reset to the default boot-time settings and then reset to
the settings specified in the termio structures.  Because of the shared
console on the GTA01, that device actually sets the port to function as
a console, then immediately sets it to the desired settings -- it is
this "diddling about" with the UART status that requires that we keep
the GSM from sending anything until after things have stabilized.

>  I check the resume ordering
> 
> [ 7187.755000] neo1973-pm-gsm neo1973-pm-gsm.0: resuming
> 
> [ 7187.755000] gsm_resume_work: waiting...
> 
> [ 7187.755000] gsm_resume_work: done.
> 
> ...
> [ 7187.755000] s3c2440-uart s3c2440-uart.0: resuming
> 
> [ 7187.755000] s3c24xx_serial_set_mctrl: GSM mctrl=0x00000000
> 
> [ 7187.755000] s3c24xx_serial_set_mctrl: GSM mctrl=0x00000006
> 
> [ 7187.755000] s3c2440-uart s3c2440-uart.1: resuming
> 
> [ 7187.755000] s3c2440-uart s3c2440-uart.2: resuming
> 
> Hum what happens when that completes and the uarts aren't up?

> - -Andy
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkhZQjEACgkQOjLpvpq7dMrP4wCffPwrQrZ8lALBP02Wnj/QTnbO
> P74An3brJPpA2Y5t10ERTbsDQt3vphrQ
> =w3HI
> -----END PGP SIGNATURE-----
> 

Mike (mwester)