[FSO] add QCT msm7* modem support

Lukas Gorris lukas.gorris at googlemail.com
Sun Nov 23 21:08:34 CET 2008


Hi,

On Sun, Nov 23, 2008 at 6:42 PM, Michael 'Mickey' Lauer
<mickey at openmoko.org> wrote:
> Hi,
>
>> > 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?

> Example:
> If you have one channel where you always retrieve unsolicited responses, you
> can
> 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
> server.

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
calypso.

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?
Calypso?

Could you comment on the AT debug logs I sent?

Kind regards,

Lukas



More information about the devel mailing list