Hi Sergey,

On Tue, Jul 20, 2021 at 12:10:42PM +0300, Sergey Ryazanov wrote:

On Mon, Jul 19, 2021 at 6:01 PM Stephan Gerhold [off-list ref] wrote:

quoted

The BAM Data Multiplexer provides access to the network data channels of
modems integrated into many older Qualcomm SoCs, e.g. Qualcomm MSM8916 or
MSM8974. It is built using a simple protocol layer on top of a DMA engine
(Qualcomm BAM) and bidirectional interrupts to coordinate power control.

The modem announces a fixed set of channels by sending an OPEN command.
The driver exports each channel as separate network interface so that
a connection can be established via QMI from userspace. The network
interface can work either in Ethernet or Raw-IP mode (configurable via
QMI). However, Ethernet mode seems to be broken with most firmwares
(network packets are actually received as Raw-IP), therefore the driver
only supports Raw-IP mode.

The driver uses runtime PM to coordinate power control with the modem.
TX/RX buffers are put in a kind of "ring queue" and submitted via
the bam_dma driver of the DMAEngine subsystem.

The basic architecture looks roughly like this:

                   +------------+                +-------+
         [IPv4/6]  |  BAM-DMUX  |                |       |
         [Data...] |            |                |       |
        ---------->|rmnet0      | [DMUX chan: x] |       |
         [IPv4/6]  | (chan: 0)  | [IPv4/6]       |       |
         [Data...] |            | [Data...]      |       |
        ---------->|rmnet1      |--------------->| Modem |
                   | (chan: 1)  |      BAM       |       |
         [IPv4/6]  | ...        |  (DMA Engine)  |       |
         [Data...] |            |                |       |
        ---------->|rmnet7      |                |       |
                   | (chan: 7)  |                |       |
                   +------------+                +-------+

However, on newer SoCs/firmware versions Qualcomm began gradually moving
to QMAP (rmnet driver) as backend-independent protocol for multiplexing
and data aggegration. Some firmware versions allow using QMAP on top of
BAM-DMUX (effectively resulting in a second multiplexing layer plus data
aggregation). The architecture with QMAP would look roughly like this:

           +-------------+           +------------+                  +-------+
 [IPv4/6]  |    RMNET    |           |  BAM-DMUX  |                  |       |
 [Data...] |             |           |            | [DMUX chan: 0]   |       |
---------->|rmnet_data1  |     ----->|rmnet0      | [QMAP mux-id: x] |       |
           | (mux-id: 1) |     |     | (chan: 0)  | [IPv4/6]         |       |
           |             |     |     |            | [Data...]        |       |
 [IPv4/6]  | ...         |------     |            |----------------->| Modem |
 [Data...] |             |           |            |       BAM        |       |
---------->|rmnet_data42 | [QMAP: x] |[rmnet1]    |   (DMA Engine)   |       |
           | (mux-id: 42)| [IPv4/6]  |... unused! |                  |       |
           |             | [Data...] |[rmnet7]    |                  |       |
           |             |           |            |                  |       |
           +-------------+           +------------+                  +-------+

In this case, rmnet1-7 would remain unused. The firmware used on the most
recent SoCs with BAM-DMUX even seems to announce only a single BAM-DMUX
channel (rmnet0), which makes QMAP the only option for multiplexing there.

So far the driver is mainly tested on various smartphones/tablets based on
Qualcomm MSM8916/MSM8974 without QMAP. It looks like QMAP depends on a MTU
negotiation feature in BAM-DMUX which is not yet supported by the driver.

Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
---
Note that this is my first network driver, so I apologize in advance
if I made some obvious mistakes. :)

I'm not sure how to integrate the driver with the WWAN subsystem yet.
At the moment the driver creates network interfaces for all channels
announced by the modem, it does not make use of the WWAN link management
yet. Unfortunately, this is a bit complicated:

Both QMAP and the built-in multiplexing layer might be needed at some point.
There are firmware versions that do not support QMAP and the other way around
(the built-in multiplexing was disabled on very recent firmware versions).
Only userspace can check if QMAP is supported in the firmware (via QMI).

I am not very familiar with the Qualcomm protocols and am just curious
whether BAM-DMUX has any control (management) channels or only IPv4/v6
data channels?

The WWAN subsystem began as a framework for exporting management
interfaces (MBIM, AT, etc.) to user space. And then the network
interfaces (data channels) management interface was added to
facilitate management of devices with multiple data channels. That is
why I am curious about the BAM-DMUX device management interface or in
other words, how a user space application could control the modem
work?

Sorry for the confusion! It's briefly mentioned in the Kconfig option
but I should have made this more clear in the commit message. It was so
long already that I wasn't sure where to put it. :)

BAM-DMUX does not have any control channels. Instead I use it together
with the rpmsg_wwan_ctrl driver [1] that I already submitted for 5.14.
The control/data channels are pretty much separate in this setup and
don't have much to do with each other.

I also had a short overview of some of the many different modem
protocols Qualcomm has come up with in a related RFC for that driver,
see [2] if you are curious.

I hope that clarifies some things, please let me know if I should
explain something better! :)

Thanks!
Stephan

[1]: https://lore.kernel.org/netdev/20210618173611.134685-3-stephan@gerhold.net/ (local)
[2]: https://lore.kernel.org/netdev/YLfL9Q+4860uqS8f@gerhold.net/ (local)