Hi!

> > > > > > Outgoing is easy. Incoming may be more tricky.
> > > > > >
> > > > > > We should really switch the code not to use AT code at all.
> > > > >
> > > > > Based on my experiments we cannot re-route the notifications
> > > > > away from the /dev/motmdm* devices to the qmimodem. So it seems
> > > > > at least incoming voice and sms need to be handled via /dev/motmdm*.
> > > > > Probably also USSD.
> > > >
> > > > That was not what I meant.
> > > >
> > > > We are currently using /dev/motmdm <-> ofono/gatchat "AT parsing" <-> ofono/drivers/motorolamodem .
> > > >
> > > > But the motmdm does not really talk AT commands, they just happen to
> > > > have "AT" in them. gatchat really does more harm than good. We should
> > > > avoid using it.
> > >
> > > Ah OK yes I agree the modem is not AT compatible.
> >
> > It is not... and gatchat is unsuitable for this modem. But we are
> > using it :-(, and it causes subtle/nasty problems.
>
> Well if you can figure out a clean way to do raw packet reads and
> writes in ofono without gatchat that would be great!

There should be way to directly access files, and do so cleanly. We'll
just lose all the gatchat functionality... But I'm starting to think
that's the best way to go.

> And then when it works, we can also easily just switch to using raw
> /dev/gsmmux* interfaces instead of /dev/motmdm* (with same numbering)
> and just leave out the whole kernel chardev thingy use for ofono.

Hmm, I like motmdm* interface. I'd suggest we keep it.

> Based on comments from Johan, we want to keep the /dev/gsmmux* support
> as is for serdev users too. Presumably most serdev-ngsm users would
> not need any custom handling, and only we are really stuck with the
> custom packet IDs AFAIK.

? I'm not sure I understand this or its implications.

> If we still want to keep the kernel chardev support, that's still
> doable to bring up /dev/motmdm* chardevs like now instead of
> /dev/gsmmux* like we have now. But I'm guessing we don't even need it
> if we get ofono working with raw packet reads and writes and stop
> pretending to be using AT commands :)
>
> Once we have raw packet read and write working, flipping to use the
> raw /dev/gsmmux* should be trivial. At that point we just need to add
> each packet ID to the beginning of each write as "U1234AT+CFUN?\r".
> And then use it or ignore it in the results like we already do for the
> kernel serdev gnss and audio drivers. I guess that only needs to be
> done in the motorolamodem specific raw read and write functions.
>
> For sending continuation messages, they start with just "U" with no
> packet ID. And for the packet ID, we can just use something similar
> to what kernel is using with jiffies % 10000.

But yes, this should be doable, too.

> > > > Unfortunately USB networking still disconnects rather often; lets say
> > > > 5 times an hour. Still usable, but a bit annoying.
> > >
> > > Hmm maybe you have a broken micro-USB connector?
> >
> > I don't think it is mechanical. It sounds more like some kind of power
> > problems really. Do you have rock solid connection with recent
> > kernels?
>
> Hmm OK. I'm typing this from a lapdock so at least the USB host mode
> is behaving. Sounds like I need to test the USB peripheral support
> again.

Hmm, working USB host would also do the trick for me. I do have USB
ethernet...

> Care to check if your USB disconnects are related to the green battery
> charge led turning on or off when the battery is full?

I don't think so. It was more like "USB is more likely to disconnect
when doing power-hungry stuff on D4". I'll keep my eye on it...

Best regards,
                                    Pavel

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html