Hi Bjørn, 2016-11-16 9:50 GMT+01:00 Daniele Palmas <dnlplm@xxxxxxxxx>: > Hi Bjørn, > > 2016-11-15 19:56 GMT+01:00 Bjørn Mork <bjorn@xxxxxxx>: >> Daniele Palmas <dnlplm@xxxxxxxxx> writes: >> >>> The problem is in cdc_ncm, function cdc_ncm_bind_common, line >>> >>> usleep_range(10000, 20000); >>> >>> It seems that LE922 needs an higher timeout; changing the line to >>> >>> usleep_range(70000, 80000); >>> >>> makes the modem to work fine. >> >> Extremely interesting! As you probably noticed, that delay was recently >> added as a workaround for the same problem on Sierra Wireless EM7455 >> modems. I believe these are based on the Qualcomm MDM9230. Which >> chipset is the LE922 based on? Is it also one of the newer Qualcom >> chips? > > Yes, it is based on one of latest QC chipsets. > >> >> >>> I will submit a patch for this. >> >> Thanks. It would also be great if you could trigger some investigation >> into the actual firmware issue. It looks like the firmware returns >> control to the driver before it's actually ready at this point of >> initialisation. >> > > Yeah, for sure I will ask for some investigation also on the firmware > side, even though I don't have many expectations for this. > > It seems that, if the modem is attached to the host and then turned > on, the previous delay is not enough. And then there seems also to be > constraints on the application side (e.g. ModemManager). > > Currently I'm not going to submit a patch until things are more clear. it turned out that resetting the interface in cdc_ncm_init after getting the NTB parameters removes the need for the sleep, making the modem to work fine. I wonder if this is an acceptable solution and can be applied also for MC7455. Regards, Daniele > > Thanks for your help, > Daniele > >> >> >> >> Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
