Re: [PATCH 2/6] iommu/tegra: smmu: Pass swgroup info from DT
From: Stephen Warren <hidden>
Date: 2013-01-16 21:07:53
Also in:
linux-iommu
On 01/15/2013 01:17 AM, Hiroshi Doyu wrote:
Pass available H/W client component(software client group) info from DT in bitmap. This info is specific to a certain generation of Tegra SoC. With this, Tegra SMMU driver could be identical among Tegra generations. This also removes the old way of passing this bit from each device pdata, which could configure(enable/disable) each device IOMMU'able, but it belongs to a kind of "policy", which can be done by kernel/system later. Now DT passes just pure H/W info.
quoted hunk
diff --git a/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt b/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt index 89fb543..de449d0 100644 --- a/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt +++ b/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt@@ -8,6 +8,46 @@ Required properties: - nvidia,#asids : # of ASIDs - dma-window : IOVA start address and length. - nvidia,ahb : phandle to the ahb bus connected to SMMU. +- nvidia,swgroups: Available H/W client component(software client + group) in bitmap in SoC. Those IDs are calculated as below: + + <ID> = (<OFFSET> - MC_SMMU_AFI_ASID_0) / 4;
OK, so I understand the addition to the DT defines which clients exist, and hence which ASID-selection registers exist. This addition makes sense to me.
quoted hunk
diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
quoted hunk
/* * Per client for address space@@ -263,7 +192,6 @@ struct smmu_client { struct device *dev; struct list_head list; struct smmu_as *as; - u32 swgrp; };
What I don't quite understand is that change, but perhaps that's because I'm not sure what that field meant before, and/or where the client<->ASID mapping comes from. Before this patch, did each client use that removed "u32 swgrp" to tell the SMMU driver which ASID-selection register was used to configure it, and then the SMMU took the union of all clients to know which ASID-selection registers existed? If so, then perhaps this change makes more sense than I thought... But, how does the SMMU driver know which of the bits in the new nvidia,swgroups property is related to each struct smmu_client? Or, did the removed "u32 swgrp" indicate which of the SMMU's ASIDs should be assigned to the client? I guess what I'm missing is: How does the SMMU know which ASID to assign to each client, either before or after this change? Or, does the driver just assign every client to ASID 0 right now, and there's no provision for separate ASIDs?