Re: [PATCH 00/21] On-demand device registration

From: Alexander Holler <holler@ahsoftware.de>
To: Linus Walleij <linus.walleij@linaro.org>,
	Tomeu Vizoso <tomeu.vizoso@collabora.com>,
	Grant Likely <grant.likely@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-pwm@vger.kernel.org" <linux-pwm@vger.kernel.org>,
	DRM PANEL DRIVERS <dri-devel@lists.freedesktop.org>,
	list@wandq.ahsoftware,
	"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
	linux-clk@vger.kernel.org,
	linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	open@wandq.ahsoftware,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
	Dan Williams <dan.j.williams@intel.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>
Subject: Re: [PATCH 00/21] On-demand device registration
Date: Wed, 03 Jun 2015 00:54:31 +0200	[thread overview]
Message-ID: <556E3427.6000704@ahsoftware.de> (raw)
In-Reply-To: <CACRpkdasLwMfEHGMRd1X3K_DU7NMPreE8TMwqqDTg8k9wj=wJQ@mail.gmail.com>

Am 02.06.2015 um 10:48 schrieb Linus Walleij:
> On Mon, May 25, 2015 at 4:53 PM, Tomeu Vizoso
> <tomeu.vizoso@collabora.com> wrote:
> 
>> have looked into ordered probing as a
>> better way of solving this than moving nodes around in the DT or playing with
>> initcall levels.
>>
>> While reading the thread [1] that Alexander Holler started with his series to
>> make probing order deterministic, it occurred to me that it should be possible
>> to achieve the same by registering devices as they are referenced by other
>> devices.
> 
> This is pretty cool, but a too local solution to a global problem.
> 
> Deferred probe and initcall reordering, silly as they may seem,
> does not require you to use device tree.
> 
> The real solution, which I think I pointed out already when we
> added deferred probe, is to put dependency graphs in the drivers
> and have the kernel device driver core percolate dependecies by
> walking the graph on probing driver, removing driver (usually the
> inverse use case), [runtime] suspend and [runtime] resumeing
> a driver. Possibly the dependencies will even be different
> depending on use case.
> 
> This is what systemd is doing in userspace for starting services:
> ask for your dependencies and wait for them if they are not
> there. So drivers ask for resources and wait for them. It also
> needs to be abstract, so for example we need to be able to
> hang on regulator_get() until the driver is up and providing that
> regulator, and as long as everything is in slowpath it should
> be OK. (And vice versa mutatis mutandis for clk, gpio, pin
> control, interrupts (!) and DMA channels for example.)
> 
> 
> So if this should be solved it should be solved in an abstract way
> in the device driver core available for all, then have calls calling
> out to DT, ACPI, possibly even PCI or USB (as these
> enumerate devices themselves) to obtain a certain
> dependency.

I suggest to start with making it possible to identify (at least most)
drivers. I've already posted a patch for that around a year ago and now
Tomeu did almost the same.

However one wants to make a deterministic order to load drivers, there
will be always the need to know which drivers one has to sort.

Regards,

Alexander Holler
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel