Dieter, could you look into that? To whom it may concern: It also seems it turned out the kernel UART driver written by TI doesn't correctly handle STX/ETX resp. RTS/CTS handshake in a by-character granularity. A nice cause for buffer overruns, if that's a correct observation.
A third thing: in kernel we should mask/disable the calypso IRQ during calypso powerdown time, as it certainly isn't expected to see IRQs from a power-down modem, and state of this line during power-down isn't very well defined - might be floating. This could cause bogus resumes. /j Am Mo 9. Februar 2009 schrieb Paul Fertser: > Hi, > > Not exactly kernel issue, but since it is very low-level and affects > all distributions, i hope this ML is appropriate enough. > > Short summary: > > Calypso will not generate any interrupt until it sees CTS_MODEM fall > for the first time after powering on. That leads to inability to > trigger a first resume by calling or sending an SMS after turning on > GSM and suspending. > > Userspace workaround: > > After the Calypso is powered on, do "echo 1 > > /sys/bus/platform/devices/neo1973-pm-gsm.0/flowcontrolled; echo 0 > > /sys/bus/platform/devices/neo1973-pm-gsm.0/flowcontrolled" > > Long story: > > For quite some time i wondered why sometimes my FR doesn't resume on > incoming call while pressing power button works perfectly. > > Joerg was extremely helpful on IRC and spent considerable time > discussing all kinds of wild guesses, ways to reproduce, possible > races, irq handling techniques, testpoints access etc. Without his > help i'd given up long time ago. Werner, mwester, lindi and Kensan > also took part in discussions and gave plenty of good hints. > > Finally a reproducible testcase was constructed and with a help of > Werner's gpio tool it became obvious how the interrupt line works and > why it fails for the first time. > > Calypso is supposed to generate interrupt (via IO1 line, connected to > EINT1/GPF1 at SoC side) in every case when it has some data to send to > SoC but CTS_MODEM (NRTS0/GPH1) prohibits sending. It does that by > pulling the line up and pulls the line down after CTS_MODEM is > de-asserted (pulled down). The kernel is configured to react on edge > rise, so the interrupt is generated and if device is suspended, resume > is initiated. > > The problem can be seen right after powering on the modem because it > doesn't pull the IRQ line low on init and therefore it is unable to > generate rise. Joerg believes that it's a firmware bug and should be > fixed in the next version. If CTS_MODEM fall is somehow generated once > (with sysfs node or suspending and resuming by other means), calypso > finally pulls the line low and after that works as expected. > > Sounds easy, doesn't it? ;) > > -- > Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! > mailto:fercer...@gmail.com > > >
signature.asc
Description: This is a digitally signed message part.
