Netdev Archive on lore.kernel.org help / color / mirror / Atom feed
From: Sergey Ryazanov <email@example.com> To: Stephan Gerhold <firstname.lastname@example.org> Cc: "David S. Miller" <email@example.com>, Jakub Kicinski <firstname.lastname@example.org>, Loic Poulain <email@example.com>, Johannes Berg <firstname.lastname@example.org>, Bjorn Andersson <email@example.com>, Andy Gross <firstname.lastname@example.org>, Vinod Koul <email@example.com>, Rob Herring <firstname.lastname@example.org>, Aleksander Morgado <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, open list <firstname.lastname@example.org>, email@example.com, ~firstname.lastname@example.org, Jeffrey Hugo <email@example.com> Subject: Re: [RFC PATCH net-next 4/4] net: wwan: Add Qualcomm BAM-DMUX WWAN network driver Date: Sat, 24 Jul 2021 13:22:21 +0300 [thread overview] Message-ID: <CAHNKnsQXb6H0Ee3sjbVi_UyED0UAXv7LK7mL1aKAG3SQtQ48ng@mail.gmail.com> (raw) In-Reply-To: <YPgQR/VbNVyxERnb@gerhold.net> Hello Stephan, On Wed, Jul 21, 2021 at 3:17 PM Stephan Gerhold <firstname.lastname@example.org> wrote: > On Tue, Jul 20, 2021 at 12:10:42PM +0300, Sergey Ryazanov wrote: >> On Mon, Jul 19, 2021 at 6:01 PM Stephan Gerhold <email@example.com> wrote: >>> 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 <firstname.lastname@example.org> >>> --- >>> 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  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  if you are curious. > > I hope that clarifies some things, please let me know if I should > explain something better! :) > > : https://email@example.com/ > : https://lore.kernel.org/netdev/YLfL9Q+4860uqS8f@gerhold.net/ Many thanks for such informative clarification, especially for pointing me to the rpmsg_wwan_ctrl driver. I saw it, but by a some reason I did not link it to BAM-DMUX. Reading these links in conjunction with your parallel talks make the situation much more clear. I could not say that "I know kung fu", but I can say that now I know how complex kung fu is. -- Sergey
next prev parent reply other threads:[~2021-07-24 10:22 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-19 14:53 [RFC PATCH net-next 0/4] net: wwan: Add Qualcomm BAM-DMUX WWAN network driver Stephan Gerhold 2021-07-19 14:53 ` [RFC PATCH net-next 1/4] dt-bindings: dmaengine: bam_dma: Add remote power collapse mode Stephan Gerhold 2021-07-29 19:36 ` Rob Herring 2021-07-29 19:50 ` Stephan Gerhold 2021-07-19 14:53 ` [RFC PATCH net-next 2/4] dmaengine: qcom: " Stephan Gerhold 2021-07-19 14:53 ` [RFC PATCH net-next 3/4] dt-bindings: net: Add schema for Qualcomm BAM-DMUX Stephan Gerhold 2021-07-19 14:53 ` [RFC PATCH net-next 4/4] net: wwan: Add Qualcomm BAM-DMUX WWAN network driver Stephan Gerhold 2021-07-19 16:01 ` Loic Poulain 2021-07-22 15:40 ` Stephan Gerhold 2021-07-24 11:25 ` Sergey Ryazanov 2021-07-26 8:10 ` Aleksander Morgado 2021-07-26 22:40 ` Sergey Ryazanov 2021-07-20 9:10 ` Sergey Ryazanov 2021-07-21 12:17 ` Stephan Gerhold 2021-07-24 10:22 ` Sergey Ryazanov [this message] 2021-07-19 15:43 ` [RFC PATCH net-next 0/4] " Jeffrey Hugo 2021-07-19 18:23 ` Stephan Gerhold 2021-07-19 23:13 ` Jeffrey Hugo 2021-07-22 14:51 ` Stephan Gerhold 2021-07-26 14:58 ` Jeffrey Hugo
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAHNKnsQXb6H0Ee3sjbVi_UyED0UAXv7LK7mL1aKAG3SQtQ48ng@mail.gmail.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).