Suspend/Resume oversight wrt GSM handling
Andy Green
andy at openmoko.com
Thu May 15 17:02:40 CEST 2008
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Somebody in the thread at some point said:
| Andy Green wrote:
| ...
|> By all means send out a patch on the list and it will be read by at
|> least one pair of interested eyes.
|
| Let me just toss this part of the set of patches out. It's not the
| final one; there's some additional logic required to integrate in the
| modem-control stuff for Qtopia, assuming I correctly understood how that
| software expects things to work.
| @@ -214,6 +277,12 @@ static int gta01_gsm_resume(struct platf
| if (machine_is_neo1973_gta02())
| s3c2410_gpio_setpin(GTA02_GPIO_nDL_GSM,
| gta01_gsm.gpio_ndl_gsm);
|
| + /* 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");
| +
| return 0;
Ah I see... not the first problem caused by resume ordering misery...
maybe better than msleep for >= the requested time, the work function
can loop sleeping and snooping on a register state that is definitively
changed when the serial driver is up? If not then fine I guess... I
also guess other folks that have an interest in the serial subsystem can
have other opinions...
- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEUEARECAAYFAkgsUJAACgkQOjLpvpq7dMrJ4ACY0A0/4Rma+TeRyU3kk+uZw6NA
ygCeITPJk1vUs3dIBJ/ECFBUOPcYzv0=
=DNhZ
-----END PGP SIGNATURE-----
More information about the openmoko-kernel
mailing list