Re: [PATCH] documentation: iommu: add description of ARM System MMU binding

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

 



On Tue, Apr 23, 2013 at 11:54:53PM +0100, Olav Haugan wrote:
> Hi Will,

Hello again,

> On 4/18/2013 12:01 PM, Will Deacon wrote:
> > No. The device-tree describes the *hardware*, as per usual. The StreamIDs
> > are fixed properties of the SoC and we can't change them from Linux, so we
> > describe all of the StreamIDs upstream of each SMMU so that we can program
> > the thing. There's no way to generic way to discover them.
> 
> I meant that you are putting phandles to bus masters in the device tree
> that use/need the SMMU for VA2PA translation. Doesn't this put a
> dependency on the bus master devices? How will this work? Lets say that
> we have a device during bootup that needs to use the SMMU (such as a
> display processor [DP]). Don't you have cyclic dependency? The SMMU
> device needs the DP device (phandle) but the DP device needs the SMMU to
> initialize its device driver?

That's a problem you have with the driver model anyway. The SMMU must be
registered on the same bus as the device before it can be used and the
devices must be added to that bus before they can be attached to a domain.

Getting phandles has no dependencies on anything -- the only dependency is
that the device is added to the bus on which the SMMU sits, just like every
other IOMMU driver.

> > Why would a page table shared between devices require multiple context
> > banks? Multiple SMRs and S2CRs, sure, but they would ultimately point at the
> > same context bank (and hence same address space).
> 
> What if you want to have 2 different VMID's being generated? Also, what
> about TLB management? If I have two context banks I can invalidate only
> entries associated with 1 of the context banks (if VMID differ for the
> two context banks).

Huh? We allocate one VMID per domain. If you want more VMIDs, use more
domains. TLB invalidation is per-domain, so there's no issue there.

> > If a master needs to be in two address spaces at once, then it will need to
> > attach it's StreamIDs to different domains. You can't place a single
> > StreamID in two address spaces (this is an architectural constraint).
> 
> Yes, you would have a separate domain. I am just wondering how I would
> model this in DT using the bindings that you are proposing? How does it
> work? The bindings specify bus masters to StreamIDs. So if I call attach
> with the master device you will allocate a context bank and program the
> StreamIDs as specified in the DT. So now if I want to have another
> context bank associated with the same master device what do I do? I call
> into attach with a new domain but with the same master device but the
> master device is already attached to a context/domain.

Why would you want to place a StreamID into two domains? That doesn't make
any sense and isn't even supported by the architecture (things like
conflicting SMR entries may not even be reported).

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux