summaryrefslogtreecommitdiff
path: root/drivers/net/ipa
AgeCommit message (Collapse)Author
2020-03-21soc: qcom: ipa: kill IPA_RX_BUFFER_ORDERAlex Elder
Don't assume the receive buffer size is a power-of-2 number of pages. Instead, define the receive buffer size independently, and then compute the page order from that size when needed. This fixes a build problem that arises when the ARM64_PAGE_SHIFT config option is set to have a page size greater than 4KB. The problem was identified by Linux Kernel Functional Testing. The IPA code basically assumed the page size to be 4KB. A larger page size caused the receive buffer size to become correspondingly larger (32KB or 128KB for ARM64_16K_PAGES and ARM64_64K_PAGES, respectively). The receive buffer size is used to compute an "aggregation byte limit" value that gets programmed into the hardware, and the large page sizes caused that limit value to be too big to fit in a 5 bit field. This triggered a BUILD_BUG_ON() call in ipa_endpoint_validate_build(). This fix causes a lot of receive buffer memory to be wasted if system is configured for page size greater than 4KB. But such a misguided configuration will now build successfully. Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Alex Elder <elder@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-19net: ipa: Remove unused including <linux/version.h>YueHaibing
Remove including <linux/version.h> that don't need it. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Reviewed-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-19net: ipa: fix platform_no_drv_owner.cocci warningsYueHaibing
Remove .owner field if calls are used which set it automatically Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci Signed-off-by: YueHaibing <yuehaibing@huawei.com> Reviewed-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-16remoteproc: clean up notification configAlex Elder
Rearrange the config files for remoteproc and IPA to fix their interdependencies. First, have CONFIG_QCOM_Q6V5_MSS select QCOM_Q6V5_IPA_NOTIFY so the notification code is built regardless of whether IPA needs it. Next, represent QCOM_IPA as being dependent on QCOM_Q6V5_MSS rather than setting its value to match QCOM_Q6V5_COMMON (which is selected by QCOM_Q6V5_MSS). Drop all dependencies from QCOM_Q6V5_IPA_NOTIFY. The notification code will be built whenever QCOM_Q6V5_MSS is set, and it has no other dependencies. Signed-off-by: Alex Elder <elder@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-11soc: qcom: ipa: fix spelling mistake "cahces" -> "caches"Colin Ian King
There is a spelling mistake in a dev_err message. Fix it. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-08soc: qcom: ipa: support build of IPA codeAlex Elder
Add build and Kconfig support for the Qualcomm IPA driver. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-08soc: qcom: ipa: AP/modem communicationsAlex 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: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-08soc: qcom: ipa: modem and microcontrollerAlex 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: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-08soc: qcom: ipa: immediate commandsAlex 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: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-08soc: qcom: ipa: filter and routing tablesAlex Elder
This patch contains code implementing filter and routing tables for the IPA. A filter table allows rules to be used for filtering packets that depart the AP at an endpoint. A filter table entry contains the address of a set of rules to apply for each endpoint that supports filtering. A routing table allows packets to be routed to an endpoint based on packet metadata. It is also a table whose entries each contain the address of a set of routing rules to apply. Neither filtering nor routing is supported by the current driver. All table entries refer to rules that mean "no filtering" and "no routing." Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-08soc: qcom: ipa: IPA endpointsAlex Elder
This patch includes the code implementing an IPA endpoint. This is the primary abstraction implemented by the IPA. An endpoint is one end of a network connection between two entities physically connected to the IPA. Specifically, the AP and the modem implement endpoints, and an (AP endpoint, modem endpoint) pair implements the transfer of network data in one direction between the AP and modem. Endpoints are built on top of GSI channels, but IPA endpoints represent the higher-level functionality that the IPA provides. Data can be sent through a GSI channel, but it is the IPA endpoint that represents what is on the "other end" to receive that data. Other functionality, including aggregation, checksum offload and (at some future date) IP routing and filtering are all associated with the IPA endpoint. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-08soc: qcom: ipa: GSI transactionsAlex Elder
This patch implements GSI transactions. A GSI transaction is a structure that represents a single request (consisting of one or more TREs) sent to the GSI hardware. The last TRE in a transaction includes a flag requesting that the GSI interrupt the AP to notify that it has completed. TREs are executed and completed strictly in order. For this reason, the completion of a single TRE implies that all previous TREs (in particular all of those "earlier" in a transaction) have completed. Whenever there is a need to send a request (a set of TREs) to the IPA, a GSI transaction is allocated, specifying the number of TREs that will be required. Details of the request (e.g. transfer offsets and length) are represented by in a Linux scatterlist array that is incorporated in the transaction structure. Once all commands (TREs) are added to a transaction it is committed. When the hardware signals that the request has completed, a callback function allows for cleanup or followup activity to be performed before the transaction is freed. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-08soc: qcom: ipa: IPA interface to GSIAlex Elder
This patch provides interface functions supplied by the IPA layer that are called from the GSI layer. One function is called when a GSI transaction has completed. The others allow the GSI layer to inform the IPA layer when the hardware has been told it has new TREs to execute, and when the hardware has indicated transactions have completed. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-08soc: qcom: ipa: the generic software interfaceAlex Elder
This patch includes "gsi.c", which implements the generic software interface (GSI) for IPA. The generic software interface abstracts channels, which provide a means of transferring data either from the AP to the IPA, or from the IPA to the AP. A ring buffer of "transfer elements" (TREs) is used to describe data transfers to perform. The AP writes a doorbell register associated with a channel to let it know it has added new entries (for an AP->IPA channel) or has finished processing entries (for an IPA->AP channel). Each channel also has an event ring buffer, used by the IPA to communicate information about events related to a channel (for example, the completion of TREs). The IPA writes its own doorbell register, which triggers an interrupt on the AP, to signal that new event information has arrived. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-08soc: qcom: ipa: GSI headersAlex Elder
The Generic Software Interface is a layer of the IPA driver that abstracts the underlying hardware. The next patch includes the main code for GSI (including some additional documentation). This patch just includes three GSI header files. - "gsi.h" is the top-level GSI header file. This structure is is embedded within the IPA structure. The main abstraction implemented by the GSI code is the channel, and this header exposes several operations that can be performed on a GSI channel. - "gsi_private.h" exposes some definitions that are intended to be private, used only by the main GSI code and the GSI transaction code (defined in an upcoming patch). - Like "ipa_reg.h", "gsi_reg.h" defines the offsets of the 32-bit registers used by the GSI layer, along with masks that define the position and width of fields less than 32 bits located within these registers. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-08soc: qcom: ipa: clocking, interrupts, and memoryAlex Elder
This patch incorporates three source files (and their headers). They're grouped into one patch mainly for the purpose of making the number and size of patches in this series somewhat reasonable. - "ipa_clock.c" and "ipa_clock.h" implement clocking for the IPA device. The IPA has a single core clock managed by the common clock framework. In addition, the IPA has three buses whose bandwidth is managed by the Linux interconnect framework. At this time the core clock and all three buses are either on or off; we don't yet do any more fine-grained management than that. The core clock and interconnects are enabled and disabled as a unit, using a unified clock-like abstraction, ipa_clock_get()/ipa_clock_put(). - "ipa_interrupt.c" and "ipa_interrupt.h" implement IPA interrupts. There are two hardware IRQs used by the IPA driver (the other is the GSI interrupt, described in a separate patch). Several types of interrupt are handled by the IPA IRQ handler; these are not part of data/fast path. - The IPA has a region of local memory that is accessible by the AP (and modem). Within that region are areas with certain defined purposes. "ipa_mem.c" and "ipa_mem.h" define those regions, and implement their initialization. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-08soc: qcom: ipa: configuration dataAlex Elder
This patch defines configuration data that is used to specify some of the details of IPA hardware supported by the driver. It is built as Device Tree match data, discovered at boot time. The driver supports the Qualcomm SDM845 SoC. Data for the Qualcomm SC7180 is also defined here, but it is not yet completely supported. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-08soc: qcom: ipa: main codeAlex Elder
This patch includes three source files that represent some basic "main program" code for the IPA driver. They are: - "ipa.h" defines the top-level IPA structure which represents an IPA device throughout the code. - "ipa_main.c" contains the platform driver probe function, along with some general code used during initialization. - "ipa_reg.h" defines the offsets of the 32-bit registers used for the IPA device, along with masks that define the position and width of fields within these registers. - "version.h" defines some symbolic IPA version numbers. Each file includes some documentation that provides a little more overview of how the code is organized and used. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>