Re: [PATCHv3 10/19] iommu/tegra: smmu: Get "nvidia,swgroups" from DT

Stephen Warren [off-list ref] wrote @ Fri, 1 Nov 2013 17:54:37 +0100:

On 10/31/2013 02:17 AM, Hiroshi Doyu wrote:

quoted

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

...

quoted

Right.
"memory client ID" is used to find out MC_SMMU_<swgroup>_ASID_0
register. This register is used to associate <swgroup> to address
space(AS). <swgroup> == H/W. <swgroup> can be attached to any AS.

quoted

Is "swgroup" simply another name for "memory client ID"? If so, it'd
be good to use just one term consistently.

I used the name "memory client ID" because this ID can be used to find
out HOTRESET bit in MC_CLIENT_HOTRESET_*_0 registers in addition to
find the MC_SMMU_<swgroup>_ASID_0 offset. But maybe it's easy to use
the consistent name as "swgroup". If laster HOTRESET wants automatic
calculation they could borrow/redefine the same ID list, just
replacing the prefix. What do you think?

quoted

Assuming "swgroup" is "memory client ID",

Yes

I took a look at the TRM, and it does look like there's a distinction
between client IDs and swgroups. The basic idea is that each swgroup
encompasses n (n >= 1) memory client IDs. So, we do have to use both terms.

Well, I considred that memory-client's' ~= 'a' swgroup, and the term
"swgroup" isn't used in HOTREST, where actually each bit represents
a "swgroup".

However, the bits in the HOTRESET register appear mostly align with
swgroup IDs rather client IDs, so I think some of your explanation above
is innaccurate.

I do want to point out that the HOTRESET bits don't 100% match the
swgroup IDs though, so the driver needs to be careful, and perhaps
contain some kind of mapping table between the two numbering spaces. In
particular, on Tegra114, swgroups and ASID registers appear in order
PPCS, <gap>, SATA, whereas there's no gap between the HOTRESET bits for
PPCS and SATA, assuming the TRM is correct.

In our downstream, basically I provided to two conversion tables, one
for "MC_SMMU_<swgroup ID>_ASID_0" and the other for "HOTRESET"
bit. That table converts ID to them respectively. I think that this is
acceptable.