On Tue, Jun 09, 2015 at 11:17:54AM +0100, Mark Rutland wrote: > On Fri, Jun 05, 2015 at 10:05:34AM +0100, Will Deacon wrote: > > On Thu, Jun 04, 2015 at 11:19:30PM +0100, Chalamarla, Tirumalesh wrote: > > > > On Jun 1, 2015, at 3:22 AM, Mark Rutland <mark.rutland@xxxxxxx> wrote: > > > > It's possible to specify that the paths exist. I expect that software > > > > would select which to use at runtime. > > > > > > > My worry is how to define any priorities/preferences between masters. > > > in general the proposal looks reasonable. > > > > I agree that the proposal looks reasonable (in terms of the ability to > > describe the sort of topologies that we will face) but I still don't > > understand what I need to do in e.g. my IOMMU driver to support this > > binding whilst continuing to support the existing iommus binding, which > > is relied upon to configure dma-mapping. > > > > Mark: how do you see this co-existing/merging with the current bindings? > > As I mentioned in my initial mail, it's not clear to me how this can be > reconciled with the current bindings. Everything I've been able to come > up with so far at best ends up describing the same thing repeatedly. > > I'll see what I can come up with. Any sugestions are welcome! Well, I'd start with the current iommu binding and see if you can figure out which properties need adding to it in order to describe the sort of topologies you can describe with your original proposal. > > I don't think it's practical to throw away what we have and move over to > > something totally different all in one go, but there clearly *is* benefit > > in your proposal over the existing scheme. > > I can see that's probably not practical. :( > > Do we know what we're going to do w.r.t. IORT? That's going to require > the kernel to be able to handle a similar description to this proposal. IORT is part of ACPI, so it doesn't care about the existing DT binding and doesn't need to co-exist at runtime. Will -- 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
