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)
