[PATCH 2/3] iommu/arm-smmu: Add initial driver support for ARM SMMUv3 devices

[leizhen]

On 2015/5/27 0:12, Will Deacon wrote:
> On Mon, May 25, 2015 at 03:07:17AM +0100, leizhen wrote:
>> On 2015/5/21 19:25, Will Deacon wrote:
>>> On Wed, May 13, 2015 at 09:33:19AM +0100, leizhen wrote:
>>>> If SMMU_IDR1.SIDSIZE = 32 really exist(or too big), we need dynamic choose
>>>> Lv2 table size(4K,16K,64K).  Because Lv1 table maybe too big, and can not
>>>> be allocated by current API, a dts configuration should be added, like
>>>> lv1-table-base = <0x0 0x0>, and we use ioremap_cache get VA(maybe ioremap,
>>>> for non-coherent SMMU).
>>>>
>>>> Oh, I can do it after your patches upstreamed, because this problem maybe
>>>> only I met.
>>>
>>> I'll have a think about this and see what I can come up with for version
>>> 2 of the patch. I'd like to avoid adding additional properties to the DT
>>> until they're actually needed, though.
>>
>> OK. Will you support non-pci devices in patch version 2?
> 
> I don't (yet) plan to support non-PCI devices, for two reasons:
> 
>   (1) The support should be based on top of Laurent's RFC series here:
> 
>   http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/343686.html
> 
>       which needs some review etc.
> 
>   (2) My simulator only has PCI endpoints
> 
> Of course, if you have something that you can test with, then I'm more
> than happy to review patches adding this support providing that they're
> based on the series above.

OK. I'm so glad to do it.

> 
> On the table front, my current v2 patch uses 16k level-2 tables allocated
> lazily (so each one has 256 entries and covers a single PCI bus). I've
> also capped the SIDSIZE to 21 for the moment, which means we get a 64k
> table there.
> 
> Sound reasonable for the time being?

OK. My SIDSIZE is 25, I will also do this.

> 
> Will
> 
> .
>