Re: Voice support methods in contemporary modems
On Fri, 2016-03-11 at 19:17 +0100, Marcin Szewczyk wrote: > Hi, > > sorry for writing on a devel group but I really did not find any > better > place to ask. I am working on a phone-like device that could make a > voice call and sometimes send some data over the internet. I am > confused, probably because most of documentation on voice modems is > from > another century. > > At first I thought that modems can use the serial interface to send > audio data the same way they do with internet data (TCP/IP). Was it > ever > true? Internet remembers things like FCLASS=8, AT+VTX, AT+VRX and > switching between modes with pause, +++, pause. > > I thought that maybe mPCIe modem could do things like that using > ttyUSB. > > Then I found a thread on the Tizen bugtracker and some documentation > on > Sierra and Telit modems. They seem to have an I2S interface on > reserved > mPCIe pins. Is it correct to assume that there is no other way but > to > have a motherboard with I2S hardware support or an external ADC/DAC? > There are a couple different classes of devices here. First you have typical dongles and mPCI/mPCIE/M.2 cards that use USB. Not all of these devices support voice calls though. But the ones that do typically expose a normal serial port (eg, ttyUSB3 or whatever) that speaks PCM audio. Like, literally when you're in a voice call you can write 16-bit 8khz PCM-coded audio data to ttyUSB3 and read the same format data from it. The interface becomes active when the modem dials a voicecall with ATD or some other command. One example is the Huawei K3520 USB dongle; many other Huawei dongles have voice support too. But the modems usually found in embedded devices or phones have much different audio call routing, often because they don't use the main CPU for audio processing due to power/battery concerns. In these cases the modem itself handles the audio and is directly connected to the DAC/ADC. The CPU is not involved in audio processing or routing at all. This allows the CPU to go to sleep while the phone is held up to your ear and doing nothing. This is unfortunately highly platform specific. > Can > a regular Atom motherboard do things like that? Is there a de-facto > standard on using some specific pins for I2S on mPCIe and some > motherboards support that by forwarding sound to their Intel HDA for > example? There is no standard that I know of for mPCIe voice routing, but at least some Telit and other devices dedicate 4 pins to I2S-based "Digital Voice Interface" stuff. Given that you need specifically wired mPCIE slots for connecting SIM cards I don't think you'll find too many that wire up I2S. > Then I have also read about QMI and MBIM protocols. Some of articles > mention voice in that context. Are there any devices supporting audio > transfer using just software without any soldering of I2S pins? The QMI and MBIM commands are only used to set up the voice calls, but don't have any relationship to audio routing. That would be modem dependent. Some have specific pins/lines for the audio, others direct it over USB, etc. > Are there any modems that emulate an ALSA sound card? Not that I know of. > What are the options with voice support as far as contemporary > (mainly > mPCIe) modems are concerned? I know that is a lot of questions but > maybe > there is a good read you could provide me with? It does look like some mPCI devices do support I2S on the same pins, but I have no idea if any of this is standard. http://www.telit.com/index.php?eID=tx_nawsecuredl&u=0&g=0&t=1457821946&; hash=9f7b2671f9068c04d6ca770e04187bedbdf4e7b5&file=downloadZone/1VV0301 006_xE910_Mini_PCIe_Adapter_HW_USER_GUIDE_r10.pdf http://www.eltech.spb.ru/files/item/MC8704.pdf In any case, ModemManager would only control the voicecall start, stop, and perhaps configure the modem with vendor-specific commands to enable DVI over the I2S pins, but the actual audio handling would have to be done through hardware and other mechanisms. Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Voice support methods in contemporary modems
Hi, sorry for writing on a devel group but I really did not find any better place to ask. I am working on a phone-like device that could make a voice call and sometimes send some data over the internet. I am confused, probably because most of documentation on voice modems is from another century. At first I thought that modems can use the serial interface to send audio data the same way they do with internet data (TCP/IP). Was it ever true? Internet remembers things like FCLASS=8, AT+VTX, AT+VRX and switching between modes with pause, +++, pause. I thought that maybe mPCIe modem could do things like that using ttyUSB. Then I found a thread on the Tizen bugtracker and some documentation on Sierra and Telit modems. They seem to have an I2S interface on reserved mPCIe pins. Is it correct to assume that there is no other way but to have a motherboard with I2S hardware support or an external ADC/DAC? Can a regular Atom motherboard do things like that? Is there a de-facto standard on using some specific pins for I2S on mPCIe and some motherboards support that by forwarding sound to their Intel HDA for example? Then I have also read about QMI and MBIM protocols. Some of articles mention voice in that context. Are there any devices supporting audio transfer using just software without any soldering of I2S pins? Are there any modems that emulate an ALSA sound card? What are the options with voice support as far as contemporary (mainly mPCIe) modems are concerned? I know that is a lot of questions but maybe there is a good read you could provide me with? Regards, -- Marcin Szewczyk http://wodny.org ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Update SIM related data according to an event
Hi all, I'm trying to update some modem data according to an unsolicited event. Telit modems have an unsolicited indication #QSS (Query SIM Status) which is emitted when the SIM status changes (e.g. SIM removed/inserted). My intention is to register an handler to this notification and somehow trigger an update of the SIM related data when a #QSS event occurs, the problem is how to update those data? I tried a bit with some "update" functions like `mm_iface_modem_update_lock_info`, but since the SIM is not there anymore those command fail and the data (e.g. sim locked status, unlocked retries, etc.) do not change. Moreover, I tried with a modified version of modem_load_unlock_retries that unset the value of the retries (mm_unlock_retries_unset), but that doesn't seem to change the cached values (mmcli -m 0 still reports the old valued of unlock retries). I think I am missing somenthing and/or that I need a more systematic approach, like repeating the steps done when a modem is first initialized. Is this possible? Best regards, Carlo ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [PATCH 2/2] port-probe: simplify task completion
On Thu, Mar 10, 2016 at 9:10 AM, Aleksander Morgado
wrote:
> We no longer need to complete in idle, because the limitation imposed by the
> serial port methods no longer exists.
> ---
This has been merged to git master now.
> src/mm-port-probe.c | 230
> ++--
> 1 file changed, 81 insertions(+), 149 deletions(-)
>
> diff --git a/src/mm-port-probe.c b/src/mm-port-probe.c
> index e260f34..c09b8a1 100644
> --- a/src/mm-port-probe.c
> +++ b/src/mm-port-probe.c
> @@ -323,9 +323,6 @@ typedef struct {
> /* MBIM probing specific context */
> MMPortMbim *mbim_port;
> #endif
> -
> -/* Error reporting during idle completion */
> -GError *possible_error;
> } PortProbeRunContext;
>
> static gboolean serial_probe_at (MMPortProbe *self);
> @@ -333,11 +330,8 @@ static gboolean serial_probe_qcdm (MMPortProbe
> *self);
> static void serial_probe_schedule (MMPortProbe *self);
>
> static void
> -port_probe_run_context_cleanup (PortProbeRunContext *ctx)
> +port_probe_run_context_free (PortProbeRunContext *ctx)
> {
> -/* We cleanup signal connections here, to be executed before a task is
> - * completed (and when it's freed) */
> -
> if (ctx->cancellable && ctx->at_probing_cancellable_linked) {
> g_cancellable_disconnect (ctx->cancellable,
> ctx->at_probing_cancellable_linked);
> ctx->at_probing_cancellable_linked = 0;
> @@ -352,13 +346,6 @@ port_probe_run_context_cleanup (PortProbeRunContext *ctx)
> g_signal_handler_disconnect (ctx->serial, ctx->buffer_full_id);
> ctx->buffer_full_id = 0;
> }
> -}
> -
> -static void
> -port_probe_run_context_free (PortProbeRunContext *ctx)
> -{
> -/* Cleanup signals */
> -port_probe_run_context_cleanup (ctx);
>
> if (ctx->serial) {
> if (mm_port_serial_is_open (ctx->serial))
> @@ -387,85 +374,9 @@ port_probe_run_context_free (PortProbeRunContext *ctx)
> if (ctx->cancellable)
> g_object_unref (ctx->cancellable);
>
> -/* We may have an error here if the task was completed
> - * with error and was cancelled at the same time */
> -if (ctx->possible_error)
> -g_error_free (ctx->possible_error);
> -
> g_slice_free (PortProbeRunContext, ctx);
> }
>
> -static gboolean
> -task_return_in_idle_cb (GTask *task)
> -{
> -PortProbeRunContext *ctx;
> -
> -ctx = g_task_get_task_data (task);
> -
> -if (g_task_return_error_if_cancelled (task))
> -goto out;
> -
> -if (ctx->possible_error) {
> -g_task_return_error (task, ctx->possible_error);
> -ctx->possible_error = NULL;
> -goto out;
> -}
> -
> -g_task_return_boolean (task, TRUE);
> -
> -out:
> -g_object_unref (task);
> -return G_SOURCE_REMOVE;
> -}
> -
> -static void
> -task_return_in_idle (MMPortProbe *self,
> - GError *error)
> -{
> -PortProbeRunContext *ctx;
> -GTask *task;
> -
> -/* Steal task from private info */
> -g_assert (self->priv->task);
> -task = self->priv->task;
> -self->priv->task = NULL;
> -
> -/* Early cleanup of signals */
> -ctx = g_task_get_task_data (task);
> -port_probe_run_context_cleanup (ctx);
> -
> -/* We will propatate an error if we have one */
> -ctx->possible_error = error;
> -
> -/* Schedule idle to complete.
> - *
> - * NOTE!!!
> - *
> - * Completing not-on-idle is very problematic due to how we process
> - * responses in the serial port: the response returned by the finish()
> - * call is constant, so that completion is always not-on-idle. And if we
> - * mix both tasks completed not-on-idle, we may end up reaching a point
> - * where the serial port is being closed while the serial port response
> - * is still being processed.
> - *
> - * By always completing this task on-idle, we make sure that the serial
> - * port gets closed always once the response processor has been finished.
> - */
> -g_idle_add ((GSourceFunc) task_return_in_idle_cb, task);
> -}
> -
> -static gboolean
> -task_return_error_in_idle_if_cancelled (MMPortProbe *self)
> -{
> -if (!g_cancellable_is_cancelled (g_task_get_cancellable
> (self->priv->task)))
> -return FALSE;
> -
> -/* We complete without error because the error is set afterwards by
> - * the GTask in g_task_return_error_if_cancelled() */
> -task_return_in_idle (self, NULL);
> -return TRUE;
> -}
> -
> /***/
> /* QMI & MBIM */
>
> @@ -616,8 +527,10 @@ wdm_probe (MMPortProbe *self)
> ctx->source_id = 0;
>
> /* If already cancelled, do nothing else */
> -if (task_return_error_in_idle_if_cancelled (self))
> +if (g_task_return_error_if_cancelled (self->priv->task)) {
> +g_clear_object (&self->priv->task);
> return G_SOURCE_REMOVE;
> +}
>
> /* QMI pro
Re: [PATCH 1/2] port-serial: allow completions not in idle
On Thu, Mar 10, 2016 at 9:10 AM, Aleksander Morgado
wrote:
> Port serial command completions may be performed in several different places:
> * When a cached response is set during command sending.
> * When errors happen during command sending.
> * When we process a response (i.e. common_input_available())
> * When we process a timeout (i.e. port_serial_timed_out())
> * When cancelled (i.e. port_serial_response_wait_cancelled())
>
> We're currently safe with the previous logic only because the users of the
> serial port explicitly complete operations in idle, which means that whenever
> we're processing in a internal callback (e.g. during response or timeout
> processing) the serial port object is valid for as long as the callback runs.
>
> But, if we ever end up using the serial port with a not-in-idle completion,
> it may happen that if the command is completed within a internal signal
> callback
> the serial port object may get fully closed and unref-ed before exiting the
> callback.
>
> We could force a valid port reference to exist as long as the internal signal
> is scheduled, but then we may lose the ability to automatically close the port
> during a full unref(), as the internal signals are set as long as the port is
> open.
>
> So, to cope with this possibility of not-in-idle completion, we instead force
> references to be valid whenever we see that a command completion may happen,
> which is basically whenever port_serial_got_response() is called; but we only
> do that if we're going to use the port object after that, otherwise, we ignore
> the problem.
>
> In addition to the problems with the references, we also update the
> common_input_available() method so that the source isn't kept if the last
> response buffer processing ended up closing the port.
> ---
This has been merged to git master now.
> src/mm-port-serial.c | 137
> ---
> 1 file changed, 87 insertions(+), 50 deletions(-)
>
> diff --git a/src/mm-port-serial.c b/src/mm-port-serial.c
> index fc5d59e..684b0ac 100644
> --- a/src/mm-port-serial.c
> +++ b/src/mm-port-serial.c
> @@ -698,8 +698,6 @@ port_serial_got_response (MMPortSerial *self,
>GByteArray *parsed_response,
>const GError *error)
> {
> -CommandContext *ctx;
> -
> /* Either one or the other, not both */
> g_assert ((parsed_response && !error) || (!parsed_response && error));
>
> @@ -717,26 +715,36 @@ port_serial_got_response (MMPortSerial *self,
>
> g_clear_object (&self->priv->cancellable);
>
> -ctx = (CommandContext *) g_queue_pop_head (self->priv->queue);
> -if (ctx) {
> -/* Complete the command context with the appropriate result */
> -if (error)
> -g_simple_async_result_set_from_error (ctx->result, error);
> -else {
> -if (ctx->allow_cached)
> -port_serial_set_cached_reply (self, ctx->command,
> parsed_response);
> -g_simple_async_result_set_op_res_gpointer (ctx->result,
> - g_byte_array_ref
> (parsed_response),
> - (GDestroyNotify)
> g_byte_array_unref);
> +/* The completion of the command context may end up fully disposing the
> + * serial port object. In order to cope with that, we make sure we have
> + * our own reference to the object while the completion and follow up
> + * setup runs. */
> +g_object_ref (self);
> +{
> +CommandContext *ctx;
> +
> +ctx = (CommandContext *) g_queue_pop_head (self->priv->queue);
> +if (ctx) {
> +/* Complete the command context with the appropriate result */
> +if (error)
> +g_simple_async_result_set_from_error (ctx->result, error);
> +else {
> +if (ctx->allow_cached)
> +port_serial_set_cached_reply (self, ctx->command,
> parsed_response);
> +g_simple_async_result_set_op_res_gpointer (ctx->result,
> + g_byte_array_ref
> (parsed_response),
> + (GDestroyNotify)
> g_byte_array_unref);
> +}
> +
> +/* Don't complete in idle. We need the caller remove the
> response range which
> + * was processed, and that must be done before processing any
> new queued command */
> +command_context_complete_and_free (ctx, FALSE);
> }
>
> -/* Don't complete in idle. We need the caller remove the response
> range which
> - * was processed, and that must be done before processing any new
> queued command */
> -command_context_complete_and_free (ctx, FALSE);
> +if (!g_queue_is_empty (self->priv->queue))
> +port_serial_schedule_queue_process (self, 0);
> }
>
Re: Huawei me906s-158
Andreas Fett writes: > On 11/03/16 12:16, Bjørn Mork wrote: >> I went back to your lsusb output to see if I could see anything strange >> wrt the LPM settings, but the whole dump was strange.. Did you use a >> very old lsusb version? The device says >> >> bcdUSB 2.10 >> >> so it must have a BOS descriptor. And AFAICS, BOS descriptor dump for >> USB 2.1 was added in usbutils v006. The MBIM functional descriptors >> weren't decoded either, but that wasn't added before v007. > Sorry about that, but yes the lsusb version is ancient. I attached a new > log using v007 (can't use v008 because of libudev). > >> Do you see any *lpm* attributes in the USB device power sysfs group? >> What's the output of >> >> grep . /sys/bus/usb/devices/1-3/power/* > /sys/bus/usb/devices/1-3/power/active_duration:189447 > /sys/bus/usb/devices/1-3/power/async:enabled > /sys/bus/usb/devices/1-3/power/autosuspend:2 > /sys/bus/usb/devices/1-3/power/autosuspend_delay_ms:2000 > /sys/bus/usb/devices/1-3/power/connected_duration:189447 > /sys/bus/usb/devices/1-3/power/control:on > /sys/bus/usb/devices/1-3/power/level:on > /sys/bus/usb/devices/1-3/power/persist:1 > /sys/bus/usb/devices/1-3/power/runtime_active_kids:0 > /sys/bus/usb/devices/1-3/power/runtime_active_time:189130 > /sys/bus/usb/devices/1-3/power/runtime_enabled:forbidden > /sys/bus/usb/devices/1-3/power/runtime_status:active > /sys/bus/usb/devices/1-3/power/runtime_suspended_time:0 > /sys/bus/usb/devices/1-3/power/runtime_usage:1 > /sys/bus/usb/devices/1-3/power/usb2_hardware_lpm:disabled > /sys/bus/usb/devices/1-3/power/usb2_lpm_besl:4 > /sys/bus/usb/devices/1-3/power/usb2_lpm_l1_timeout:512 > /sys/bus/usb/devices/1-3/power/wakeup:disabled So this is with both autosuspend and usb2_hardware_lpm disabled. Is that the setting that works? How about enabling just one of them? Hoping you can find some pattern for the work/non-work case. Don't know what elso to do right now. > Bus 001 Device 002: ID 12d1:15c1 Huawei Technologies Co., Ltd. > Device Descriptor: > bLength18 > bDescriptorType 1 > bcdUSB 2.10 .. > Binary Object Store Descriptor: > bLength 5 > bDescriptorType15 > wTotalLength 22 > bNumDeviceCaps 2 > USB 2.0 Extension Device Capability: > bLength 7 > bDescriptorType16 > bDevCapabilityType 2 > bmAttributes 0x0002 > Link Power Management (LPM) Supported > SuperSpeed USB Device Capability: > bLength10 > bDescriptorType16 > bDevCapabilityType 3 > bmAttributes 0x00 > wSpeedsSupported 0x000f > Device can operate at Low Speed (1Mbps) > Device can operate at Full Speed (12Mbps) > Device can operate at High Speed (480Mbps) > Device can operate at SuperSpeed (5Gbps) > bFunctionalitySupport 1 > Lowest fully-functional device speed is Full Speed (12Mbps) > bU1DevExitLat 1 micro seconds > bU2DevExitLat 500 micro seconds > Device Status: 0x0001 > Self Powered Thanks. Looks good to me, but I don't understand much of this. Like: The device support SS and is internally connected to an xhci controller via an m.2 slot, but still runs in HS mode? Didn't they connect the SS lanes or what? I am way over my head here... I think I'll go prepare the "NDP to end" quirk for cdc_mbim. That I know how to do. Bjørn ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Huawei me906s-158
Hi Bjørn, On 11/03/16 12:16, Bjørn Mork wrote: > I went back to your lsusb output to see if I could see anything strange > wrt the LPM settings, but the whole dump was strange.. Did you use a > very old lsusb version? The device says > > bcdUSB 2.10 > > so it must have a BOS descriptor. And AFAICS, BOS descriptor dump for > USB 2.1 was added in usbutils v006. The MBIM functional descriptors > weren't decoded either, but that wasn't added before v007. Sorry about that, but yes the lsusb version is ancient. I attached a new log using v007 (can't use v008 because of libudev). > Do you see any *lpm* attributes in the USB device power sysfs group? > What's the output of > > grep . /sys/bus/usb/devices/1-3/power/* /sys/bus/usb/devices/1-3/power/active_duration:189447 /sys/bus/usb/devices/1-3/power/async:enabled /sys/bus/usb/devices/1-3/power/autosuspend:2 /sys/bus/usb/devices/1-3/power/autosuspend_delay_ms:2000 /sys/bus/usb/devices/1-3/power/connected_duration:189447 /sys/bus/usb/devices/1-3/power/control:on /sys/bus/usb/devices/1-3/power/level:on /sys/bus/usb/devices/1-3/power/persist:1 /sys/bus/usb/devices/1-3/power/runtime_active_kids:0 /sys/bus/usb/devices/1-3/power/runtime_active_time:189130 /sys/bus/usb/devices/1-3/power/runtime_enabled:forbidden /sys/bus/usb/devices/1-3/power/runtime_status:active /sys/bus/usb/devices/1-3/power/runtime_suspended_time:0 /sys/bus/usb/devices/1-3/power/runtime_usage:1 /sys/bus/usb/devices/1-3/power/usb2_hardware_lpm:disabled /sys/bus/usb/devices/1-3/power/usb2_lpm_besl:4 /sys/bus/usb/devices/1-3/power/usb2_lpm_l1_timeout:512 /sys/bus/usb/devices/1-3/power/wakeup:disabled To me it appears that the time at which the cdc_mbim module is loaded makes a difference. I think that loading it *later* lead to success more often. But I haven't tested this in a way that would proof anything. Andreas Bus 001 Device 002: ID 12d1:15c1 Huawei Technologies Co., Ltd. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 255 bMaxPacketSize064 idVendor 0x12d1 Huawei Technologies Co., Ltd. idProduct 0x15c1 bcdDevice1.02 iManufacturer 1 Huawei Technologies Co., Ltd. iProduct2 HUAWEI Mobile iSerial 3 0123456789ABCDEF bNumConfigurations 3 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 301 bNumInterfaces 6 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower2mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 6 bInterfaceProtocol 16 iInterface 7 Huawei Mobile Connect - Modem ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 04 24 02 02 ** UNRECOGNIZED: 05 24 01 00 00 ** UNRECOGNIZED: 05 24 06 00 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x000a 1x 10 bytes bInterval 9 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 6 bInterfaceProtocol 19 iInterface 8 Huawei Mobile Connect - Application ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 04 24 02 02 ** UNRECOGNIZED: 05 24 01 00 01 ** UNRECOGNIZED: 05 24 06 00 00 Endpoint Descriptor: bL
Re: Huawei me906s-158
Andreas Fett writes: > On 10/03/16 18:39, Bjørn Mork wrote: >> Andreas Fett writes: >>> I still have to load the mbim_module manually and sometimes I'm able to >>> "talk" to it. I have no clue which factors lead to success or failure here. >> >> Huh? Why do you need to load cdc_mbim manually? Doesn't it autoload >> when the modem is switched to the MBIM configuration? Or is the probe >> failing at this time? > The autoload works just fine. It's just that the xhci module is loaded > in the initramfs where the cdc_mbim module is not available and I > disabled the "udevadm trigger" later on to prevent interference of other > modules. > >> Well, a couple of more things to try out if you are able to connect >> again: >> >> 1) move the NDP >> >> With a v4.5 kernel you will have a "ndp_to_end" sysfs attribute. Try >> toggling it on and see if that makes any difference: >> >> echo Y >/sys/class/net/wwan0/cdc_ncm/ndp_to_end >> >> You can do this after connecting if you want to. The driver will enable >> it immediately for the rest of the session. > I had one boot now where the modem responded and this actually made it > fully functional, that is I could get a ping across it after connecting > and assigning the ip address. Great! Thanks for verifying that. We'll add a quirk for it then, so this setting becomes the default. I guess it's time to reconsider applying that quirk to all Huawei modems. >> 2) DHCP >> >> You should also try using a DHCP client instead of manual IP >> configuration. Some firmwares can be a bit difficult about this, >> although I don't think we have seen that with MBIM yet. Mostly worth >> trying because it is easy to test. Not really believing it will work :) > When the modem responds I can do dhcp on it. I then get the same > address information ModemManager reports. I'm not sure if this is > required though. > > To sum up, when the modem comes to a state where it will respond > to mbimcli --query-device-caps it seems to be operational (after setting > the cdc_ncm sysctl). If I can't talk to it using mbimcli it's just > totally silent and it seems to me that only a cold reset (as opposed to > a reboot) will get it out of that state. > > However up to now its only about one in ten boots (using the same image) > where this works. So this appears as if the modem firmware has suspended its USB connection. I have a feeling there is some USB low power mode or suspend feature I am missing here. I don't really have any experience with xhci or USB3, and there are a few new power knobs there. This should of course just work and not really depend on specific USB devices or device drivers, but who knows? Not me at least. I don't think it's something we can fix in the cdc_mbim driver in any case. You said earlier that it made a difference when you disabled or enabled autosuspend? The modem needed autosuspend to work? That's strange. I went back to your lsusb output to see if I could see anything strange wrt the LPM settings, but the whole dump was strange.. Did you use a very old lsusb version? The device says bcdUSB 2.10 so it must have a BOS descriptor. And AFAICS, BOS descriptor dump for USB 2.1 was added in usbutils v006. The MBIM functional descriptors weren't decoded either, but that wasn't added before v007. If the device really doesn't have a BOS descriptor then I guess all the fancy-schmancy USB3 LPM stuff is disabled anyway. But it would be good to know. Do you see any *lpm* attributes in the USB device power sysfs group? What's the output of grep . /sys/bus/usb/devices/1-3/power/* Is there any noticable differences between the working and non-working states? Bjørn ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Huawei me906s-158
Hi Bjørn, On 10/03/16 18:39, Bjørn Mork wrote: > Andreas Fett writes: >> I still have to load the mbim_module manually and sometimes I'm able to >> "talk" to it. I have no clue which factors lead to success or failure here. > > Huh? Why do you need to load cdc_mbim manually? Doesn't it autoload > when the modem is switched to the MBIM configuration? Or is the probe > failing at this time? The autoload works just fine. It's just that the xhci module is loaded in the initramfs where the cdc_mbim module is not available and I disabled the "udevadm trigger" later on to prevent interference of other modules. > Well, a couple of more things to try out if you are able to connect > again: > > 1) move the NDP > > With a v4.5 kernel you will have a "ndp_to_end" sysfs attribute. Try > toggling it on and see if that makes any difference: > > echo Y >/sys/class/net/wwan0/cdc_ncm/ndp_to_end > > You can do this after connecting if you want to. The driver will enable > it immediately for the rest of the session. I had one boot now where the modem responded and this actually made it fully functional, that is I could get a ping across it after connecting and assigning the ip address. > 2) DHCP > > You should also try using a DHCP client instead of manual IP > configuration. Some firmwares can be a bit difficult about this, > although I don't think we have seen that with MBIM yet. Mostly worth > trying because it is easy to test. Not really believing it will work :) When the modem responds I can do dhcp on it. I then get the same address information ModemManager reports. I'm not sure if this is required though. To sum up, when the modem comes to a state where it will respond to mbimcli --query-device-caps it seems to be operational (after setting the cdc_ncm sysctl). If I can't talk to it using mbimcli it's just totally silent and it seems to me that only a cold reset (as opposed to a reboot) will get it out of that state. However up to now its only about one in ten boots (using the same image) where this works. Andreas signature.asc Description: OpenPGP digital signature ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
