On Wed, Aug 27, 2014 at 05:37:58PM +0100, Stephen Warren wrote:

On 08/27/2014 10:30 AM, Alexander Holler wrote:

quoted

Am 27.08.2014 18:22, schrieb Stephen Warren:

quoted

On 08/27/2014 08:44 AM, Catalin Marinas wrote:

quoted

quoted

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