andy git 06/15 suspend/resume observations

[Sean McNeil]

Mike (mwester) wrote:
>  Andy Green wrote:
> 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.
>

This is a gross hack. The whole point of device drivers having 
suspend/resume callbacks is to put them in a proper state so that they 
are there when you come back up. I, for one, do not want to use sysfs 
flags at all. I already set the hardware flow control on opening the 
device. Are you saying that the user-space must now monitor that is has 
been resumed and then write to some sysfs file? I repeat: Gross Hack.

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

OK, then it should be stabilized in the resume process.

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

>  Mike (mwester)