[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-iommu
Subject:    [v2 1/1] iommu/tegra: smmu: Support variable MMIO ranges/blocks
From:       swarren () wwwdotorg ! org (Stephen Warren)
Date:       2013-01-29 17:57:25
Message-ID: 51080D85.4050201 () wwwdotorg ! org
[Download RAW message or body]

On 01/29/2013 10:40 AM, Hiroshi Doyu wrote:
> Stephen Warren <swarren at wwwdotorg.org> wrote @ Tue, 29 Jan 2013 18:03:51 +0100:
> 
>>> +	/* Same as "mc" 1st regiter block start address */
>>> +	smmu->regbase = (void __iomem *)((u32)smmu->regs[0] & ~PAGE_MASK);
>>
>> I'm not sure if it's relevant how these register ranges are related to
>> the MC registers, given this is the SMMU driver?
> 
> All SMMU register offsets are against MC[0]'s start address and SMMU
> register blocks are interleaved as below. The 1st SMMU register block
> SMMU[0]'s offset is always 0x10.
> 
> Address Register block
> -----------------------
> 000-010	MC[0]
> 010-03c	SMMU[0]
> 03c-1f0	MC[1]
> 1f0-200	SMMU[1]
> 200-228	MC[2]
> 228-284	SMMU[2]
> 284-...	MC[3]

I know that's true, but it's still not really relevant to the SMMU
driver. What is relevant is that the SMMU has a bunch of chunks of
address space containing SMMU registers, and there are gaps, and all the
register offsets in the SMMU driver are relative to the page-aligned
base of the first chunk. The fact the gaps contain MC registers is what
isn't relevant.

> If the above assumption is not acceptable, alternatively we need to
> access MC's node to get the 1st MC register block start address, for
> example, via embedded in MC's phandle in smmu entry.

Like I said, the code is fine so I'm not really objecting to it.

[prev in list] [next in list] [prev in thread] [next in thread]