Hi Greg, On Wed, Nov 27, 2013 at 11:06:50PM +0000, Greg KH wrote: > On Wed, Nov 27, 2013 at 05:28:06PM +0000, Dave Martin wrote: > > >From will.deacon@xxxxxxx Wed Nov 20 12:06:22 2013 > > A number of discussion points remain to be resolved: > > > > - Use of the ranges property and describing slave vs master bus > > address ranges. In the latter case, we actually want to describe our > > address space with respect to the bus on which the bus masters, > > rather than the parent. This could potentially be achieved by adding > > properties such as dma-parent and dma-ranges (already used by PPC?) > > > > - Describing masters that master through multiple different buses > > > > - How on Earth this fits in with the Linux device model (it doesn't) > > How does this _not_ fit into the Linux device model? What am I missing > here that precludes the use of the "driver/device/bus" model we have > today? The main problem is that we have devices which slave on one bus and master on another. That then complicates probing, power-management, IOMMU configuration, address mapping (e.g. I walk the slave buses to figure out where the slave registers live, but then I need a way to work out where exactly I master on a different bus) and dynamic coherency, amongst other things. If we try to use the current infrastructure then we end up with one bus per device, which usually ends up being a fake bus representing both the slave and master buses (which is how the platform bus gets abused) and then device drivers having their own idea of the system topology where it's required. This is fairly horrible and doesn't work for anything other than the trivial case, where one or both of the buses are `dumb' and don't require any work from Linux. > > .../devicetree/bindings/arm/coherent-bus.txt | 110 +++++++++++++++++++++ > > Why "arm"? > > What makes it ARM specific? This is just an RFC, so I'd be happy to put the binding somewhere more broad. I'm not sure how much of an issue this is outside of the SoC space, though. 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
