On Wed, Aug 27, 2014 at 05:37:58PM +0100, Stephen Warren wrote: > On 08/27/2014 10:30 AM, Alexander Holler wrote: > > Am 27.08.2014 18:22, schrieb Stephen Warren: > >> On 08/27/2014 08:44 AM, Catalin Marinas wrote: > > > >>> It's not just optimisation but an important feature for new arm64 SoCs. > >>> Given some Tegra discussions recently, in many cases the machine_desc > >>> use on arm is primarily to initialise devices in the right order. If we > >>> can solve this in a more deterministic way (other than deferred > >>> probing), we avoid the need for a dedicated SoC platform driver (or > >>> machine_desc) or workarounds like different initcall levels and explicit > >>> DT parsing. > >> > >> A lot of the ordering is SW driver dependencies. I'm not sure how much > >> of that can accurately be claimed as HW dependencies. As such, I'm not > >> sure that putting dependencies into DT would be a good idea; it doesn't > >> feel like HW data, and might well change if we restructure SW. It'd need > >> some detailed research though. > > > > Almost every phandle is a dependency, so the DT is already full with them. > > That's true, but not entirely relevant. > > phandles in DT should only be present where there's an obvious HW > dependency. It's obvious that, for example, there's a real HW dependency > between an IRQ controller and a device that has an IRQ signal fed into > the IRQ controller. It makes perfect sense to represent that as a > phandle (+args). Other examples are power controllers or some MFD device (as we have on vexpress). For these we normally have phandles. > However, most of the ordering imposed by the Tegra machine descriptor > callbacks is nothing to do with this. It's more that the SW driver for > component X needs some low level data (e.g. SKU/fuse information) before > it can run. However, there's no real HW dependency between the HW > component X and the fuse module. As such, it doesn't make sense to > represent such a dependency in DT, using a phandle or by any other means. But isn't fuse some piece of hardware? We don't have a model for it, so I guess you just present it as a library that accesses the hardware. Anyway, in such case something like Pawel's SoC driver proposal would work. Now if anything inside the SoC bus (I have to re-read, I don't fully remember the details) is probed after the SoC driver, you could even initialise your SoC at device_initcall() level. > Irrespective though, a new kernel needs to work against an old DT, I fully agree. But we shouldn't really extend the "old DT" statement to a new ARMv8 SoC ;). -- Catalin -- 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
