[FSO] add QCT msm7* modem support
lukas.gorris at googlemail.com
Sun Nov 23 21:08:34 CET 2008
On Sun, Nov 23, 2008 at 6:42 PM, Michael 'Mickey' Lauer
<mickey at openmoko.org> wrote:
>> > Let me add on that -- it is always desirable to have more than just one
>> > channel for usual AT commands, that way you can drastically simplify the
>> > gsm server logic. I would prefer three independent homogenous command
>> > channels, if we can have them, one for call control, one for unsolicited
>> > responses, and one for everything else.
>> Why does it simplify gsm server logic?
Is the gsm server logic fso here?
> If you have one channel where you always retrieve unsolicited responses, you
> a) disable unsolicited responses on the other channels and use them solely in
> request/response mode, and
> b) retrieve unsolicited responses while the other channels are busy (e.g.
> during dialing the ATD command hangs and blocks any other commands or
> unsolicited messages coming in)
My knowledge of the AT communications is poor, so I guess I can't
judge whether or not it will be worth creating all this extra
abstraction for the msm7*. Still I would like to understand it. What
is the benefit in the a) case? In the b) case, how would ATD hang? In
case it would, how would the unsolicited-only channel win over the
normal serial device method? If you mean by hanging, the modem chokes,
I don't see how some higher lever abstraction could save it...
>> What do you mean by independent and homogenous?
> Independent: They keep their own state, e.g. if you enable +CREG on channel A,
> it would not get sent on channel B.
> Homogenous: Channels are equal, e.g. you the same set of commands work equally
> on channel A and B.
>> If you want to change the way you access the modem in the msm7*, you
>> must modify the AMSS. It is the software which provides us with the
>> shared memory fifos where the serial nodes run on. The kernel driver
>> is only a thing that manages the data flow on them and provides the
>> devices. So that would be very hard. If I got this wrong and you want
>> to make userspace software that "sorts" different commands it's
>> something else. But I don't understand the reason. Does it work like
>> that on the mokos?
> On the TI Calypso, we have soft-multiplexing (done in userland) giving us 4
> independent, homogenous channels. This is a quite nice base for any gsm
If this will require any modification of the arm9 (modem) code like
modifying the AT communication behaviour, we can't do the multiplex
stuff. In msm7* we have nothing like ti tools luxury you have for the
Where can the sources to this soft-multiplexing mechanism used for the
calypso modem be found? Could you be more specific and name things so
in future I can have a look at the sources right away?
> On the Freescale Neptune, we have hard-multiplexing (done in hardware+kernel)
> giving us 8 channels, however they're not independent nor homogenous. Still
> they have something like a dedicated channel for several types of commands
> (i.e. unsolicited), so that's nice as well.
> Don't get me wrong, we can use a singleline modem fine as well, but you will
> have to live with certain limitations.
What are these limitations? You mean if we use the single present msm
AT channel (/dev/smd0) only, we can't recycle as much of the calypso
modem code in fso for use with msm7* as we could with the
soft-multiplexing? Or are these limitations on a higher level of
abstraction than fso?
Assuming I'm brave and I would want to run fso on my kaiser's
/dev/smd0, which (single line) modem type would I want to pick?
Could you comment on the AT debug logs I sent?
More information about the devel