On 2/21/22 18:58, Robin Murphy wrote:
On 2022-02-21 15:28, Mikko Perttunen wrote:
On 2/21/22 17:23, Robin Murphy wrote:
On 2022-02-18 11:39, Mikko Perttunen via iommu wrote:
Add schema information for the memory-contexts property used to
specify context stream IDs. This uses the standard iommu-map property
inside a child node.
Couldn't you simply make "iommu-map" an allowed property on the
host1x node itself? From a DT perspective I'm not sure the
intermediate node really fits meaningfully, and I can't see that it
serves much purpose in practice either, other than perhaps defeating
fw_devlink.
Robin.
The stream IDs described here are not used by the host1x device
itself, so I don't think I can. Host1x's memory transactions still go
through the stream ID specified in its 'iommus' property, these stream
IDs are used by engines (typically in addition to the stream ID
specified in their own nodes).
Host1x 'iommus' -- Channel commands
Engine 'iommus' -- Engine firmware (and data if context isolation is
not enabled)
memory-contexts 'iommu-map' -- Data used by engines.
Right, that still appears to match my understanding, that as far as
software sees, the host1x is effectively acting as a bridge to the
engines in itself. Even if it's not physically routing traffic in and/or
out, the host1x device is the place where the context IDs *logically*
exist, and thus owns the mapping between context IDs and the StreamIDs
emitted by any engine working in a given context.
Consider a PCIe root complex with integrated endpoints - chances are the
RCiEPs have their own physical interfaces to issue DMA directly into the
SoC interconnect, but that doesn't change how we describe the PCI
Requester ID to StreamID mapping at the root complex, since the RC still
logically owns the RID space. You can think of a RID as being "consumed"
at the RC by indexing into config space to ultimately gain control of
the corresponding endpoint, just like context IDs are "consumed" at the
host1x by generating commands to ultimately cause some engine to
operate in the correct address space.
You don't have to pretend the host1x uses a context for its own
command-fetching (or whatever) traffic either - it's always been
intended that the "iommus" and "iommu-map" properties should happily be
able to coexist on the same node, since they serve distinctly different
purposes. If it doesn't work in practice then we've got a bug to fix
somewhere.
Interesting, I had assumed that they were exclusive but indeed comparing
with PCIe this makes sense. I'll look into it.
If the context-switching mechanism was some distinct self-contained
thing bolted on beside the other host1x functionality then describing it
as a separate level of DT hierarchy might be more justifiable, but
that's not the impression I'm getting from skimming the rest of the
series. Just reading of the names of things in patch #6, my intuitive
reaction is that clearly each host1x owns 9 StreamIDs, one for general
stuff and 8 for contexts. Adding the knowledge that technically the
context StreamIDs end up delegated to other host1x-controlled engines
still doesn't shift the paradigm. I don't believe we need a level of DT
structure purely to help document what the iommu-map means for host1x -
the binding can do that just fine.
Theoretically there can be any number of these stream IDs, but indeed,
there is quite specific HW support for this in Host1x.
Thanks for your help once again!
Mikko
Thanks,
Robin.
(Perhaps I should add this information to various places in more
abundance and clarity.)
Mikko
Signed-off-by: Mikko Perttunen <mperttunen@xxxxxxxxxx>
---
v3:
* New patch
---
.../bindings/display/tegra/nvidia,tegra20-host1x.yaml | 10
++++++++++
1 file changed, 10 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
index 4fd513efb0f7..3ac0fde54a16 100644
---
a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
+++
b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
@@ -144,6 +144,16 @@ allOf:
reset-names:
maxItems: 1
+ memory-contexts:
+ type: object
+ properties:
+ iommu-map:
+ description: Specification of stream IDs available
for memory context device
+ use. Should be a mapping of IDs 0..n to IOMMU
entries corresponding to
+ usable stream IDs.
+ required:
+ - iommu-map
+
required:
- reg-names
