MHI on 5G modems

Sat Aug 13 09:06:18 UTC 2022

Hi Koen, Daniele,

On Fri, 12 Aug 2022 at 16:16, Daniele Palmas <dnlplm at gmail.com> wrote:
>
> Hi Koen,
>
> Il giorno ven 12 ago 2022 alle ore 15:26 Koen Vandeputte
> <koen.vandeputte at citymesh.com> ha scritto:
> >
> >
> > On 12.08.22 10:55, Daniele Palmas wrote:
> > > Hi Koen,
> > >
> > > Il giorno gio 11 ago 2022 alle ore 15:24 Koen Vandeputte
> > > <koen.vandeputte at citymesh.com> ha scritto:
> > >> Hi All,
> > >>
> > >> I'm currently working on adding MHI support within OpenWRT. (kernel 5.15.59)
> > >>
> > >> I have a few modems laying around here:
> > >>
> > >> - Sierra Wireless EM9191
> > >> - Telit FN980
> > >> - Fibocom FM150-AE
> > >>
> > >> On all 3 of them, MHI seems to enumerate correctly:
> > >>
> > >> [    8.258921] mhi-pci-generic 0000:01:00.0: BAR 0: assigned [mem
> > >> 0x01100000-0x01100fff 64bit]
> > >> [    8.267488] mhi-pci-generic 0000:01:00.0: enabling device (0140 -> 0142)
> > >> [    8.276817] mhi mhi0: Requested to power ON
> > >> [    8.288905] mhi mhi0: Power on setup success
> > >> [    8.341370] mhi mhi0: Wait for device to enter SBL or Mission mode
> > >>
> > >> Exposed devices:
> > >>
> > >> /dev/wwan0mbim0
> > >> /dev/wwan0qcdm0
> > >> /dev/wwan0qmi0
> > >>
> > >> And a network device:
> > >>
> > >> mhi_hwip0
> > >>
> > >>
> > >> Following kernel SYMS are enabled:
> > >>
> > >> CONFIG_MHI_BUS=m
> > >> CONFIG_MHI_BUS_DEBUG=y
> > >> CONFIG_MHI_BUS_PCI_GENERIC=m
> > >> CONFIG_MHI_NET=m
> > >> CONFIG_MHI_WWAN_CTRL=m
> > >> CONFIG_MHI_WWAN_MBIM=m
> > >> CONFIG_WWAN=m
> > >>
> > >>
> > >> Now the problem is, when sending QMI traffic towards wwan0qmi0, I never
> > >> get a reply back on any of them.
> > >> When using cdc-wdm  or when wwan0qmi0 is exposed over usb, it works,
> > >> but as soon as wwan0qmi0 is exposed over pcie, it fails.
> > >>
> > >> Does anyone have any clue what is missing here?
> > >>
> > > I suggest you enable dynamic debugging on mhi and wwan to get more
> > > information about what's going on.
> > >
> > > My experience is that some hosts have issues with runtime power
> > > management (e.g. the modem is not able to exit M3) and the symptoms
> > > seem to be the same as the ones you describe.
> > >
> > > Regards,
> > > Daniele
> >
> > Hi Daniele,
> >
> > Thanks for the reply.
> > Well .. this is interesting.  Looks like my EM919x is always detected as
> > a generic "qcom sdx55"
> >
> > All looks well-defined within mhi/pci-generic.c and lspci -v reports the
> > proper ID's:
> >
> >
> > static const struct pci_device_id mhi_pci_id_table[] = {
> >          /* EM919x (sdx55), use the same vid:pid as qcom-sdx55m */
> >          { PCI_DEVICE_SUB(PCI_VENDOR_ID_QCOM, 0x0306, 0x18d7, 0x0200),
> >                  .driver_data = (kernel_ulong_t) &mhi_sierra_em919x_info },
> >          /* Telit FN980 hardware revision v1 */
> >          { PCI_DEVICE_SUB(PCI_VENDOR_ID_QCOM, 0x0306, 0x1C5D, 0x2000),
> >                  .driver_data = (kernel_ulong_t)
> > &mhi_telit_fn980_hw_v1_info },
> >          { PCI_DEVICE(PCI_VENDOR_ID_QCOM, 0x0306),
> >                  .driver_data = (kernel_ulong_t) &mhi_qcom_sdx55_info },
> >          { PCI_DEVICE(PCI_VENDOR_ID_QCOM, 0x0304),
> >                  .driver_data = (kernel_ulong_t) &mhi_qcom_sdx24_info },
> >
> >
> > 01:00.0 Unassigned class [ff00]: Qualcomm Device 0306
> >      Subsystem: Device 18d7:0200
> >
> >
> > hmz ..
> >
>
> Yeah, that's odd.
>
> >
> >
> > Here are the logs:
> >
> >
> > [   10.506776] mhi-pci-generic 0000:01:00.0: MHI PCI device found:
> > qcom-sdx55m
> > [   10.513847] mhi-pci-generic 0000:01:00.0: BAR 0: assigned [mem
> > 0x01100000-0x01100fff 64bit]
> > [   10.522357] mhi-pci-generic 0000:01:00.0: enabling device (0140 -> 0142)
> > [   10.532198] mhi mhi0: Requested to power ON
> > [   10.536490] mhi mhi0: Attempting power on with EE: PASS THROUGH,
> > state: RESET
> > [   10.547145] mhi mhi0: Power on setup success
> > [   10.547293] mhi mhi0: Handling state transition: PBL
> > [   10.556541] mhi mhi0: Device in READY State
> > [   10.560738] mhi mhi0: Initializing MHI registers
> > [   10.565457] mhi mhi0: Wait for device to enter SBL or Mission mode
> > [   10.633687] mhi mhi0: local ee: MISSION MODE state: READY device ee:
> > MISSION MODE state: READY
> > [   10.657015] mhi mhi0: State change event to state: M0
> > [   10.662281] mhi mhi0: Received EE event: MISSION MODE
> > [   10.667577] mhi mhi0: Handling state transition: MISSION MODE
> > [   10.673524] mhi mhi0: Processing Mission Mode transition
> > [   10.684850] mhi_net mhi0_IP_HW0: 100: Updating channel state to: START
> > [   10.707859] mhi_net mhi0_IP_HW0: 100: Channel state change to START
> > successful
> > [   10.715374] mhi_net mhi0_IP_HW0: 101: Updating channel state to: START
> > [   10.737501] mhi_net mhi0_IP_HW0: 101: Channel state change to START
> > successful
> >
> > // start talking QMI to wwan0qmi0
> >
> > [  131.173212] mhi_wwan_ctrl mhi0_QMI: 14: Updating channel state to: START
> > [  131.187781] mhi_wwan_ctrl mhi0_QMI: 14: Channel state change to START
> > successful
> > [  131.195303] mhi_wwan_ctrl mhi0_QMI: 15: Updating channel state to: START
> > [  131.207145] mhi_wwan_ctrl mhi0_QMI: 15: Channel state change to START
> > successful

The below line is suspicious, it looks like MHI channels are closed
just after being started (successfully), could it be that user side
program closes the file descriptor? what program/daemon are you
running to talk over the QMI character device? The device should stay
open as long as your 'session' is running.

I would suggest to CC mhi at lists.linux.dev .

> > [  131.966531] mhi_wwan_ctrl mhi0_QMI: 15: Updating channel state to: RESET
> > [  131.980574] mhi_wwan_ctrl mhi0_QMI: 15: Channel state change to RESET
> > successful
> > [  131.988018] mhi mhi0: Marking all events for chan: 15 as stale
> > [  131.993887] mhi mhi0: Finished marking events as stale events
> > [  131.999704] mhi_wwan_ctrl mhi0_QMI: mhi_dl_xfer_cb: status: -107

[...]