Re: Quectel EC21 with internal GSM MUX

Hi Christian,

> 
> We are operating this modem with a single physical serial connection between CPU and modem. Starting in AT mode and switching over to GSM 07.10 MUX-ing. If I'm getting this correctly, there are three GSM MUX channels opened: control, aux, and PPP data.

Gotcha.  You're using naming conventions of pre-multiplexed devices (e.g. 
multiple USB interfaces, 1 AT port per USB interface) and this is confusing me.

> 
> What do you mean with premultiplexed ports? The one serial port we are using starts in plain AT communication mode after powering up the device and is then put into GSM 07.10 multiplexing mode.
> 

Yeah forget I mentioned this :)

> 
>> You can invoke g_at_chat_send however you like, even one after the other in the same function.  The underlying implementation still uses a command queue, so commands will be sent only when the modem channel is idle, or after receiving a final response from the modem (ERROR, OK, etc)
> 
> Thank you for clarifying this. Last weeks debugging brought me to the point where I found the command list in g_at_chat and I got up to the point where additional instrumentation below have_line gives me the following:
> 
>      Sep 26 09:43:25 target ofonod[2502]: chat_wakeup_writer
>      Sep 26 09:43:25 target ofonod[2502]: Aux: > ATE0; &C0; +CMEE=1\r
>      Sep 26 09:43:25 target ofonod[2502]: Aux: < \r\nOK\r\n
>      Sep 26 09:43:25 target ofonod[2502]: have_line(0x5d6e78, "OK")
>      Sep 26 09:43:25 target ofonod[2502]: at_chat_handle_command_response(0x5d6e78, ..., "OK")
>      Sep 26 09:43:25 target ofonod[2502]: checking common terminators
>      Sep 26 09:43:25 target ofonod[2502]: at_chat_finish_command
>      Sep 26 09:43:25 target ofonod[2502]: command queue not empty
>      Sep 26 09:43:25 target ofonod[2502]: chat_wakeup_writer

Here's how GAtChat operates:
- When 1 or more commands are queued up via g_at_chat_send(), GAtChat checks if 
there's a command in progress.  If there is, it waits for the final response.
- If the modem is idle, it wakes up the writer.  This sets up poll to notify the 
application using POLLOUT.
- When POLLOUT arrives, the command is sent to the kernel via write().
- When POLLIN arrives, the command response is processed
- If it is a final response, go back to step 1.

What seems to be happening is that POLLOUT is somehow broken on this particular 
device.  I imagine the kernel suffers from the same problem.

Regards,
-Denis