Re: Report from 2013 ARM kernel summit

[Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On 11/19/2013 11:35 AM, Will Deacon wrote:
> On Tue, Nov 19, 2013 at 09:40:54AM +0000, Hiroshi Doyu wrote:
>> Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote @ Fri, 15 Nov 2013 08:06:27 +0100:
>>> On Mon, 11 Nov 2013 10:47:23 +0100, Hiroshi Doyu <hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>>>> 1, When a device is populated, it checks if that device is IOMMU'able
>>>>    or not. This is identified by "#stream-id-cells" in DT. If
>>>>    a device is normal(non IOMMU), a device is populated. If a device
>>>>    is IOMMU'able, it continues to be checked.
> 
> [...]
> 
>>>> I'm not so sure if this dependecy on "#stream-id-cells" is acceptable
>>>> or not, but I haven't any better idea right now.
>>>
>>> It seems a little fragile to me too. I'd rather the IOMMU requirement be
>>> described more explicitly.

I don't see how this can work. Typically you find a property and then
read the relevant #*-cells to determine the size. Having multiple cell
properties is asking for errors.

>>
>> I think that Will Deacon can do better than I.
> 
> I already commented briefly here:
> 
>   http://www.spinics.net/lists/devicetree/msg11513.html
> 
> basically deferring to DT people :)
> 
> Anyway, I'm happy to tighten up the IOMMU requirement description but
> *not* at the expense of breaking what we currently have for the ARM SMMU,
> which is being used by Calxeda.
> 
> Adding Andreas and Rob for input on potential binding additions to the SMMU.

The above proposal would be an incompatible change. However, I think we
could still deal with a change in this binding at this stage.

One way approach to handle this without changing the binding would be to
scan the DT for all iommu's up front and create a list of all nodes and
their iommu parent. The fact that the hierarchy is described in a way
that doesn't fit Linux well is really a Linux implementation detail.

If changing the binding, a simple approach would be to allow
'smmu-parent' to be a bus and/or device property and not just for
chained iommu's. This could be a global or bus property that is
inherited. Like interrupt-parent, you would have to deal with the parent
being itself. Also, perhaps iommu-parent would be a better name. In any
case, I'd like to see this all be a generic iommu binding.

Rob