On 07/04/16(Thu) 18:31, Patrick Wildt wrote: > On Thu, Apr 07, 2016 at 06:00:25PM +0200, Mark Kettenis wrote: > > [...] > > I have no objections to rename fdt.c fdt_subr.c. However, I do object > > against having an "fdt" bus, at least for socppc. The fdt code should > > I don't propose an fdt bus for socppc. > > > just be the enumeration mechanism for "mainbus". And I think armv7 > > should be the same. > > That sounds more like implementing the fdtbus functionality, but just > call it mainbus. > > The current situation is that we have a mainbus0 on arm that attaches > anything that wants to be attached. It's not really the mainbus you > expect it to be. What is does is attach cpu0 at mainbus0 and depending > on the SoC an obio0 at mainbus0, pxaip0 at mainbus0, or imx0 at > mainbus0, exynos0 at mainbus0 and so on. These are the actual busses > that create their own bus space and bus dma tag and pass it to the > controller driver instance. mainbus0 does (not yet) do anything in that > regard. This also means all drivers are ... imxuart0 at imx0, not at > mainbus0. > > Looks like: > > mainbus0 at root > cpu0 at mainbus0 > cortex0 at mainbus0 > ampintc0 at mainbus0 > imx0 at mainbus0 > imxuart0 at imx0 > imxiic0 at imx0 > ehci0 at imx0 > > Goal was: > > mainbus0 at root > cpu0 at mainbus0
So you don't have a CPU node in your FDT? > ampintc0 at fdt0 > imxuart0 at fdt0 Does that mean that all (most of?) the nodes in your FDT are children of the root node? > So the idea was to replace imx0, exynos0, vexpress0, etc. on ARMv7 with > an fdt0 that does all that what e. g. imx0 used to do, just with FDT > only. You don't have a "kind-of-bus" node? I'm thinking of the nodes attached to the socppc obio(4) driver. > Attaching controllers from FDT is not just going through the tree and > attaching all nodes that are there. You have to take care of interrupt- > controller hierarchy and clocks. Those need to be attached first. This > adds a bit of complexity and should probably not be duplicated for a new > arch (arm64 for instance). Which is why we thought it would be nice to > have that in sys/dev/ofw/. Makes sense. Note that earlier macppc, those using dev/macintr.c had a similar problem: the interrupt controller was late in the tree. > I could though completely replace mainbus.c with the fdtbus, call it > mainbus, implement it for armv7 only, and fall back to the old version > for the legacy platforms armish, zaurus and non-fdt armv7. Is that the > way to go? How consistent are the FDTs? Do you generate them? Do you have to work around broken trees? Because if every SoC comes with its own set of problem I'm not sure that having a single "bus" driver will help you.
