On 10/31/2013 01:16 PM, Stephen Warren wrote:

On 10/31/2013 11:40 AM, Mark Rutland wrote:

quoted

On Thu, Oct 31, 2013 at 08:18:08AM +0000, Hiroshi Doyu wrote:

quoted

Stephen Warren [off-list ref] wrote @ Wed, 30 Oct 2013 23:44:04 +0100:

quoted

quoted

+	host1x {
+		compatible = "nvidia,tegra30-host1x", "simple-bus";
+		nvidia,memory-clients = <&smmu TEGRA_SWGROUP_HC>;
+		....
+		gr3d {
+			compatible = "nvidia,tegra30-gr3d";
+			nvidia,memory-clients = <&smmu TEGRA_SWGROUP_NV
+						       TEGRA_SWGROUP_NV2>;

Why one cell for the host1x property, and two cells for the gr3d
property; shouldn't they be the same length?

That can vary. Even a single device node in DT can belong to multiple
software groups.

Same with ARM SMMU.

quoted

quoted

quoted

diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c

quoted

+static u64 smmu_of_get_memory_client(struct device *dev)

quoted

+	np = of_parse_phandle(dev->of_node, propname, 0);
+	if (np != smmu_handle->dev->of_node)
+		return ~0;
+
+	prop = of_get_property(dev->of_node, propname, &bytes);
+	if (!prop || !bytes)
+		return ~0;

of_parse_phandle_with_fixed_args() might be a good fit here, or perhaps
require a property #smmu-cells in the SMMU node, thus allowing the
non-fixed-length of_parse_phandle_with_args() to be used here.

I once considered of_parse_phandle_with_args() but I couldn't use that
since "#smmu-cells" needed to be fixed in smmu node, not in client
node. In this case, the number of argument(number of swgroup IDs)
varies per client device.

For the ARM SMMU binding, each device has a #stream-id-cells property
describing how many IDs it has, and then the SMMU node has a phandle+args
linkage to each of the devices attached to it, describing their stream IDs.
While this does have some limitations (a device can't be plugged into multiple
SMMUs with a different number of IDs), it seems generally sane.

Hmm. That's interesting. I see that the ARM SMMU has a list of the
clients it affects, whereas this Tegra series puts information into each
client device about the SMMU(s) that affect it. Is it better to flip the
Tegra binding around to match the style of the ARM SMMU?

One question here: How do you ensure that the SMMU driver probe()s
before probe() runs for devices affected by the SMMU?

With the DT binding in this series, there's a property in each client
node that describes the SMMU that affects the device. That can feed into
deferred probe very nicely.

However, if all the information is in the SMMU node, how can a client
find that, and hence defer its probe?

Perhaps the ARM SMMU assumes that it sits at the root of a bus, and
hence must be probe()d before any of its child devices can be probe()d?
I'm not sure that there's any general guarantee that a device's control
bus is the same bus it issues bus-master transactions too though, so I'm
not sure that's a general solution.