Thread (37 messages) 37 messages, 5 authors, 2018-11-15

[RFC PATCH 01/12] dt-bindings: soc: qcom: add IPA bindings

From: robh@kernel.org (Rob Herring)
Date: 2018-11-11 01:40:20
Also in: linux-arm-msm, linux-devicetree, lkml, netdev

On Fri, Nov 9, 2018 at 4:38 PM Alex Elder [off-list ref] wrote:
On 11/7/18 8:59 AM, Rob Herring wrote:
quoted
On Tue, Nov 6, 2018 at 6:33 PM Alex Elder [off-list ref] wrote:
quoted
Add the binding definitions for the "qcom,ipa" and "qcom,rmnet-ipa"
device tree nodes.

Signed-off-by: Alex Elder <redacted>
---
 .../devicetree/bindings/soc/qcom/qcom,ipa.txt | 136 ++++++++++++++++++
 .../bindings/soc/qcom/qcom,rmnet-ipa.txt      |  15 ++
 2 files changed, 151 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,ipa.txt
 create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,rmnet-ipa.txt
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,ipa.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,ipa.txt
new file mode 100644
index 000000000000..d4d3d37df029
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,ipa.txt
@@ -0,0 +1,136 @@
+Qualcomm IPA (IP Accelerator) Driver
Bindings are for h/w not drivers.
OK.  I'll drop " Driver".
quoted
quoted
+
+This binding describes the Qualcomm IPA.  The IPA is capable of offloading
+certain network processing tasks (e.g. filtering, routing, and NAT) from
+the main processor.  The IPA currently serves only as a network interface,
+providing access to an LTE network available via a modem.
+
+The IPA sits between multiple independent "execution environments,"
+including the AP subsystem (APSS) and the modem.  The IPA presents
+a Generic Software Interface (GSI) to each execution environment.
+The GSI is an integral part of the IPA, but it is logically isolated
+and has a distinct interrupt and a separately-defined address space.
+
+    ----------   -------------   ---------
+    |        |   |G|       |G|   |       |
+    |  APSS  |===|S|  IPA  |S|===| Modem |
+    |        |   |I|       |I|   |       |
+    ----------   -------------   ---------
+
+See also:
+  bindings/interrupt-controller/interrupts.txt
+  bindings/interconnect/interconnect.txt
+  bindings/soc/qcom/qcom,smp2p.txt
+  bindings/reserved-memory/reserved-memory.txt
+  bindings/clock/clock-bindings.txt
+
+All properties defined below are required.
+
+- compatible:
+       Must be one of the following compatible strings:
+               "qcom,ipa-sdm845-modem_init"
+               "qcom,ipa-sdm845-tz_init"
Normal order is <vendor>,<soc>-<ipblock>."
I'll use "qcom,sdm845-ipa-modem-init" and "qcom,sdm845-ipa-tz-init".
(Or just "qcom,sdm845-ipa", depending on the outcome of the discussion
below.)
quoted
Don't use '_'.
OK.
quoted
What's the difference between these 2? It can't be detected somehow?
There is some early initialization, including loading some firmware,
that must be done by trusted code.  That can be done by either Trust
Zone or the modem.  If it's done by the modem, there is an additional
step required during initialization so the modem can tell the AP
that it has done its part, and the AP can finish IPA initialization.

There  is no way of detecting (e.g. by probing hardware) which is
in effect so we use DT.  I discussed this with Bjorn, who said that
this was a situation seen elsewhere and that using compatible strings
was the way he suggested to address it.
Okay. However, if this is common for QCom blocks maybe we should
reconsider. I think compatible makes sense if the programming model
changes.
quoted
This might be better expressed as a property. Then if Trustzone
initializes things, it can just add a property.
A Boolean property to distinguish them would be fine as well, but
I would like to address this "common" problem consistently.

Bjorn, would you please weigh in?
quoted
quoted
+
+-reg:
+       Resources specyfing the physical address spaces of the IPA and GSI.
typo
quoted
+
+-reg-names:
+       The names of the address space ranges defined by the "reg" property.
+       Must be "ipa" and "gsi".
+
+- interrupts-extended:
Use 'interrupts' here and describe what they are and the order. What
they are connected to (and the need for interrupts-extended) is
outside the scope of this binding.
I used interrupts-extended because there were two interrupt parents
(a "normal" interrupt controller and the interrupt controller implemented
for SMP2P input).  A paragraph here:
    bindings/interrupt-controller/interrupts.txt
recommends "interrupts-extended" in that case.

I have no objection to using just "interrupts" but can you tell me what
I misunderstood?  It seems like I need to do "interrupts-extended".
Yes, in the dts you should use interrupts-extended. However, for
documentation purposes that aspect is not important. So we just use
interrupts most everywhere.

Rob
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help