On Thu, Nov 28, 2013 at 11:13:31AM -0800, Greg KH wrote: > On Thu, Nov 28, 2013 at 05:33:39PM +0000, Dave Martin wrote: > > On Thu, Nov 28, 2013 at 10:28:45AM +0000, Will Deacon wrote: > > > 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 physical-sockets history of buses like PCI tends to force a simple > > tree-like topology as a natural consequence. You also end up with > > closely linked topologies for power, clocks, interrupts etc., because > > those all pass through the same sockets, so it's difficult to have a > > different structure. > > There's nothing in the driver core that enforces such a topology. Maybe not ... I have to wrap my head around that stuff a bit more. > > On SoC, those constraints have never existed and are not followed. A > > device's interface to the system is almost always split into multiple > > connections, not covered by a single design or standard. The problem > > now is that increasing complexity means that the sometimes bizarre > > topology features of SoCs are becoming less and less transparent for > > software. > > > > The device model currently seems to assume that certain things (power, > > DMA and MMIO accessibility) follow the tree (which may not work for many > > SoCs), and some other things (clocks, regulators, interrupts etc.) are > > not incorporated at all -- making them independent, but it may make some > > abstractions impossible today. > > > > How much this matters for actual systems is hard to foresee yet. Since > > not _all_ possible insanities find their way into silicon. The > > onus should certainly be on us (i.e., the ARM/SoC community) to > > demonstrate if the device model needs to change, and to find practical > > ways to change it that minimise the resulting churn. > > Yes it is, you all are the ones tasked with implementing the crazy crap > the hardware people have created, best of luck with that :) Agreed. The first assumption should be that we can fit in with the existing device model -- we should only reconsider if we find that to be impossible. > > > 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. > > > > If we can come up with some generic bus type that is just a container for > > a load of hooks that know how to deal with various aspects of each device's > > interface to the system, on a per-device basis, than may be a start. > > > > The platform bus kinda serves that role, but the trouble with that is that > > it doesn't encourage any abstraction at all. In the face of increasing > > complexity, abstraction is desperately needed. > > Then create a different abstraction, the normal solution to any problem > in programming :) That's certainly the first step. It might end up looking a lot like a kludge layer which duplicates core functionality -- if so, we should then consider whether there is a better way, but we shouldn't judge it prematurely. It would be great to get some comments [hint to everyone] on the proposed DT binding so that we can start to explore this properly. Cheers ---Dave -- 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
