Message-ID: <20140827175243.GJ13850@arm.com>
Date:	Wed, 27 Aug 2014 18:52:43 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Stephen Warren <swarren@...dotorg.org>
Cc:	Alexander Holler <holler@...oftware.de>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	Mark Rutland <Mark.Rutland@....com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Jon Loeliger <jdl@....com>,
	Russell King <linux@....linux.org.uk>,
	Arnd Bergmann <arnd@...db.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Rob Herring <robh+dt@...nel.org>,
	Thierry Reding <thierry.reding@...il.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver
 initialization order based on the DT)

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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists