Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
From: Catalin Marinas
Date: Wed Aug 27 2014 - 13:53:23 EST
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 ;).
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/