Re: [PATCHv3 01/19] [HACK] of: dev_node has struct device pointer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 10/25/2013 07:20 AM, Will Deacon wrote:
> On Fri, Oct 25, 2013 at 09:22:02AM +0100, Hiroshi Doyu wrote:
>> Thierry Reding <thierry.reding@xxxxxxxxx> wrote @ Fri, 25 Oct 2013 09:56:55 +0200:
>>
>>> I suspect that there will be enough differences between the various
>>> IOMMU implementations that we won't be able to have a unified binding
>>> (especially for how to associate devices with a particular virtual
>>> address space), but perhaps that could be solved with something like an
>>> .of_xlate() that IOMMU drivers implement, much like we've done with most
>>> other subsystems too.
>>>
>>> The binding for Tegra's IOMMU currently only uses the HW IDs (or a mask)
>>> to put a device into a given address space, but I think that could be
>>> easily extended to something like:
>>>
>>> 	memory-clients = <&iommu MASK>;
>>>
>>> Or similar. If other information is required, we could encode that into
>>> a multi-cell specifier. Perhaps we could even leave away the phandle
>>> since typically there will only be a single IOMMU in the system?
>>>
>>> Does that sound reasonable? Hiroshi is much more familiar with IOMMUs,
>>> so I'd like to get his opinion on the above as well.
>>
>> I think that the above may be possible, but I'd like to listen from
>> other IOMMU SOC maintainers.
>>
>> A brief explanation for "memory-clients":
>>
>> In tegra, every H/W has its own memory-client ID, and it can be
>> associated to any address spaces. The above "memory-cilents" is used
>> to indicate which ID a device has in DT. If the other SOC IOMMUs need
>> this kind of "memory-clients", this would be standarized. Any comment?
>>
>> At least arm-smmu seems to have the following. multiple IOMMUs can be
>> handled with this.
>>
>>
>> - smmu-parent   : When multiple SMMUs are chained together, this
>>                   property can be used to provide a phandle to the
>>                   parent SMMU (that is the next SMMU on the path going
>>                   from the mmu-masters towards memory) node for this
>>                   SMMU.
> 
> This property is for the case when IOMMUs are connected in series, which is
> fairly horrendous. However, it is extremely common to have multiple IOMMU
> instances within an Soc (Exynos SoCs have one IOMMU per device iirc), so
> that certainly needs to be handled.

That property sounds a bit scary; is the value a single parent IOMMU?
What if an IOMMU splits its requests between two different parent IOMMUs
based on some property of the request. I hope smmu-parent isn't going to
get us into another interrupts -vs- interrupts-extended situation.

(/me checks the documentation of that property)

I suppose smmu-parent is documented in a device-specific binding rather
than as a generic property, although there's no vendor-prefix on the
property name:-(, so we havne't cornered ourselves too much here; any
IOMMU device which actually has multiple parents can always define its
own custom property to represent that.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux