Sierra Wireless AirPrime EM919x PCIe support

IoT Modules
22

Not a stupid question at all, no.

Today I’ve tested with the same changes in my host PC, i.e. with:

 static const struct pci_device_id mhi_pci_id_table[] = {
+       /* EM919x (sdx55), listed before the generic 0x0306 */
+       { PCI_DEVICE_SUB(PCI_VENDOR_ID_QCOM, 0x0306, 0x18d7, 0x0200),
+               .driver_data = (kernel_ulong_t) &mhi_sierra_em919x_info },
        { PCI_DEVICE(PCI_VENDOR_ID_QCOM, 0x0306),
                .driver_data = (kernel_ulong_t) &mhi_qcom_sdx55_info },

And that worked in my PC as expected

[  805.929339] mhi-pci-generic 0000:17:00.0: MHI PCI device found: sierra-em919x
[  805.929352] mhi-pci-generic 0000:17:00.0: BAR 0: assigned [mem 0xb5e01000-0xb5e01fff 64bit]

When I yesterday tried the same changes in the embedded system I’m working on, they didn’t seem to work as expected. But now I don’t know if it’s a faulty build I may have tested or a mess I did in my changes, or a real issue somewhere. I’ll need to confirm once I test again on the device.

1 Like
23

@dl5162 tested again in the RPI4 and in this case, the PCI_DEVICE_SUB() entry listed before the more generic one isn’t picked first for some reason, not sure why.

24

That’s odd. But I won’t claim I understand any of this driver stuff :slight_smile:

Maybe sprinkle a few debug printk’s all over pci-driver.c to see what happens? Doesn’t look like there is any debugging there you can just enable on the fly, unfortunately.

Not directly related… Just curious. How do you connect the modem to an RPi4? Did you desolder the xhci controller and replace it with a PCIe connection to an m.2 slot?

EDIT: Ah, right - I see you are referring to a CM4 earlier. Do you have a nice pointer to a carrier board suitable for the EM919x for that one?

25

My main issue right now is the instability during boot; once that is solved I’ll try to see why the entry is not being picked up :slight_smile: But there is definitely something wrong somewhere, and for now I’m just hacking the table by making the generic entry use a different product id :sweat_smile:

I was given this setup for testing; it’s a custom board with a CM4. Not sure it can be acquired anywhere :confused:

26

On a related note, Techship has just released several new M.2 to mPCIe adapters that allow playing easily (jumpers) with the PCIE_DIS pin:

MP301-S - USB2, PCIe
MP201-S - USB2, USB3

These adapters connect either the USB3 or PCI lines, and they’re generic enough to be able to be used with any kind of 5G module, not only the EM919x ones. They seem quite promising for us tinkerers :slight_smile:

27

Thanks for this one. :slight_smile:

Otherwise, I asked Sierra if

is it possible to use several MHI event rings for the control, the data and the diag?

I got an answer:

It is possible to use several event , yes it is like they notice and it could not be changed, as it depends on the Qualcomm implementation, which is fixed.

28

SDX55 or SDX65 support the inband wake method by default, then if it is the case on EM919x, sideband_wake should be set to false.
But the EM919x also provides a gpio pin (PCIE_PEWAKE_N) that can be used by the module to wake the host when the PCIe link is in a power saving state. So, I asked for confirmation, I’m waiting for an answer.

29

Oh, that is totally unrelated I think. That other pin should be like the ring indicator line basically if I’m not mistaken.

30

It was not completely clear to me, thanks. Then sideband_wake should be set to false.