1. 10 3月, 2020 33 次提交
  2. 09 3月, 2020 7 次提交
    • D
      Merge branch 'net-introduce-Qualcomm-IPA-driver' · fbd43602
      David S. Miller 提交于
      Alex Elder says:
      
      ====================
      net: introduce Qualcomm IPA driver (UPDATED)
      
      This series presents the driver for the Qualcomm IP Accelerator (IPA).
      
      This is version 2 of this updated series.  It includes the following
      small changes since the previous version:
        - Now based on net-next instead of v5.6-rc
        - Config option now named CONFIG_QCOM_IPA
        - Some minor cleanup in the GSI code
        - Small change to replenish logic
        - No longer depends on remoteproc bug fixes
      What follows is the basically same explanation as was posted previously.
      
      					-Alex
      
      I have posted earlier versions of this code previously, but it has
      undergone quite a bit of development since the last time, so rather
      than calling it "version 3" I'm just treating it as a new series
      (indicating it's been updated in this message).  The fast/data path
      is the same as before.  But the driver now (nearly) supports a
      second platform, its transaction handling has been generalized
      and improved, and modem activities are now handled in a more
      unified way.
      
      This series is available (based on net-next in branch "ipa_updated-v2"
      in this git repository:
        https://git.linaro.org/people/alex.elder/linux.git
      
      The branch depends on other one other small patch that I sent out
      for review earlier.
        https://lore.kernel.org/lkml/20200306042302.17602-1-elder@linaro.org/
      
      I want to address some of the discussion that arose last time.
      
      First, there was the WWAN discussion.  Here's the history:
        - This was last posted nine months ago.
        - Reviewers at that time favored developing a new WWAN subsystem that
          would be used for managing devices like this.  And the suggestion
          was to not accept this driver until that could be developed.
        - Along the way, Apple acquired much of Intel's modem business.
          And as a result, the generic framework became less pressing.
        - I did participate in the WWAN subsystem design however, and
          although it went dormant for a while it's been resurrected:
            https://lore.kernel.org/netdev/20200225100053.16385-1-johannes@sipsolutions.net/
        - Unfortunately the proposed WWAN design was not an easy fit
          with Qualcomm's integrated modem interfaces.  Given that
          rmnet is a supported link type for in the upstream "iproute2"
          package (more on this below), I have opted not to integrate
          with any WWAN subsystem.
      
      So in summary, this driver does not integrate with a generic WWAN
      framework.  And I'd like it to be accepted upstream despite that.
      
      Next, Arnd Bergmann had some concerns about flow control.  (Note:
      some of my discussions with Arnd about this were offline.) The
      overall architecture here also involves the "rmnet" driver:
        drivers/net/ethernet/qualcomm/rmnet
      
      The rmnet driver presents a network device for use.  It connects
      with another network device presented, by the IPA driver.  The
      rmnet driver wraps (and unwraps) packets transferred to (and from)
      the IPA driver with QMAP headers.
      
         ---------------
         | rmnet_data0 |    <-- "real" netdev
         ---------------
                ||       }- QMAP spoken here
         --------------
         | rmnet_ipa0 |     <-- also netdev, transporting QMAP packets
         --------------
                ||
         --------------
        ( IPA hardware )
         --------------
      
      Arnd's concern was that the rmnet_data0 network device does not
      have the benefit of information about the state of the underlying
      IPA hardware in order to be effective in controlling TX flow.
      The feared result is over-buffering of TX packets (bufferbloat).
      I began working on some simple experiments to see whether (or how
      much) his concern was warranted.  But it turned out that completing
      these experiments was much more work than had been hoped.
      
      The rmnet driver is present in the upstream kernel.  There is also
      support for the rmnet link type in the upstream "ip" user space
      command in the "iproute2" package.  Changing the layering of rmnet
      over IPA likely involves deprecating the rmnet driver and its
      support in "iproute2".  I would really rather not go down that
      path.
      
      There is precedent for this sort of layering of network devices
      (L2TP, VLAN).  And any architecture like this would suffer the
      issues Arnd mentioned; the problem is not limited to rmnet and IPA.
      I do think this is a problem worth solving, but the prudent thing
      to do might be to try to solve it more generally.
      
      So to summarize on this issue, this driver does not attempt to
      change the way the rmnet and IPA drivers work together.  And even
      though I think Arnd's concerns warrant more investigation, I'd like
      this driver to to be accepted upstream without any change to this
      architecture.
      
      Finally, a more technical description for the series, and some
      acknowledgements to some people who contributed to it.
      
      The IPA is a component present in some Qualcomm SoCs that allows
      network functions such as aggregation, filtering, routing, and NAT
      to be performed without active involvement of the main application
      processor (AP).
      
      In this initial patch series these advanced features are not
      implemented.  The IPA driver simply provides a network interface
      that makes the modem's LTE network available in Linux.  This initial
      series supports only the Qualcomm SDM845 SoC.  The Qualcomm SC7180
      SoC is partially supported, and support for other platforms will
      follow.
      
      This code is derived from a driver developed by Qualcomm.  A version
      of the original source can be seen here:
        https://source.codeaurora.org/quic/la/kernel/msm-4.9/tree
      in the "drivers/platform/msm/ipa" directory.  Many were involved in
      developing this, but the following individuals deserve explicit
      acknowledgement for their substantial contributions:
      
          Abhishek Choubey
          Ady Abraham
          Chaitanya Pratapa
          David Arinzon
          Ghanim Fodi
          Gidon Studinski
          Ravi Gummadidala
          Shihuan Liu
          Skylar Chang
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fbd43602
    • A
      arm64: dts: sdm845: add IPA information · 9cc5ae12
      Alex Elder 提交于
      Add IPA-related nodes and definitions to "sdm845.dtsi".
      Signed-off-by: NAlex Elder <elder@linaro.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9cc5ae12
    • A
      MAINTAINERS: add entry for the Qualcomm IPA driver · aa302745
      Alex Elder 提交于
      Add an entry in the MAINTAINERS file for the Qualcomm IPA driver
      Signed-off-by: NAlex Elder <elder@linaro.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aa302745
    • A
      soc: qcom: ipa: support build of IPA code · 08120d23
      Alex Elder 提交于
      Add build and Kconfig support for the Qualcomm IPA driver.
      Signed-off-by: NAlex Elder <elder@linaro.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      08120d23
    • A
      soc: qcom: ipa: AP/modem communications · 530f9216
      Alex Elder 提交于
      This patch implements two forms of out-of-band communication between
      the AP and modem.
      
        - QMI is a mechanism that allows clients running on the AP
          interact with services running on the modem (and vice-versa).
          The AP IPA driver uses QMI to communicate with the corresponding
          IPA driver resident on the modem, to agree on parameters used
          with the IPA hardware and to ensure both sides are ready before
          entering operational mode.
      
        - SMP2P is a more primitive mechanism available for the modem and
          AP to communicate with each other.  It provides a means for either
          the AP or modem to interrupt the other, and furthermore, to provide
          32 bits worth of information.  The IPA driver uses SMP2P to tell
          the modem what the state of the IPA clock was in the event of a
          crash.  This allows the modem to safely access the IPA hardware
          (or avoid doing so) when a crash occurs, for example, to access
          information within the IPA hardware.
      Signed-off-by: NAlex Elder <elder@linaro.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      530f9216
    • A
      soc: qcom: ipa: modem and microcontroller · a646d6ec
      Alex Elder 提交于
      This patch includes code implementing the modem functionality.
      There are several communication paths between the AP and modem,
      separate from the main data path provided by IPA.  SMP2P provides
      primitive messaging and interrupt capability, and QMI allows more
      complex out-of-band messaging to occur between entities on the AP
      and modem.  (SMP2P and QMI support are added by the next patch.)
      Management of these (plus the network device implementing the data
      path) is done by code within "ipa_modem.c".
      
      Sort of unrelated, this patch also includes the code supporting the
      microcontroller CPU present on the IPA.  The microcontroller can be
      used to implement special handling of packets, but at this time we
      don't support that.  Still, it is a component that needs to be
      initialized, and in the event of a crash we need to do some
      synchronization between the AP and the microcontroller.
      Signed-off-by: NAlex Elder <elder@linaro.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a646d6ec
    • A
      soc: qcom: ipa: immediate commands · 731c46ed
      Alex Elder 提交于
      One TX endpoint (per EE) is used for issuing immediate commands to
      the IPA.  These commands request activites beyond simple data
      transfers to be done by the IPA hardware.  For example, the IPA is
      able to manage routing packets among endpoints, and immediate commands
      are used to configure tables used for that routing.
      
      Immediate commands are built on top of GSI transactions.  They are
      different from normal transfers (in that they use a special endpoint,
      and their "payload" is interpreted differently), so separate functions
      are used to issue immediate command transactions.
      Signed-off-by: NAlex Elder <elder@linaro.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      731c46ed