Message-ID: <CACRpkdZuSj+S2x1yz6n5PgcRK=3ZCcq_To124b2Y+Oj54aydpg@mail.gmail.com>
Date:	Wed, 10 Jun 2015 09:30:32 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Tomeu Vizoso <tomeu.vizoso@...labora.com>
Cc:	Grant Likely <grant.likely@...aro.org>,
	Mark Rutland <mark.rutland@....com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-fbdev@...r.kernel.org" <linux-fbdev@...r.kernel.org>,
	linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Rob Herring <robh+dt@...nel.org>,
	"linux-pwm@...r.kernel.org" <linux-pwm@...r.kernel.org>,
	"open list:DRM PANEL DRIVERS" <dri-devel@...ts.freedesktop.org>,
	dmaengine@...r.kernel.org, Alexander Holler <holler@...oftware.de>,
	Dan Williams <dan.j.williams@...el.com>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	linux-clk@...r.kernel.org,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>
Subject: Re: [PATCH 00/21] On-demand device registration

On Tue, Jun 2, 2015 at 12:14 PM, Tomeu Vizoso
<tomeu.vizoso@...labora.com> wrote:
> On 2 June 2015 at 10:48, Linus Walleij <linus.walleij@...aro.org> wrote:

>> 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.)
>
> I understood above that you propose probing devices in order, but now
> you mention that resource getters would block until the dependency is
> fulfilled which confuses me because if we are probing in order then
> all dependencies would be fulfilled before the device in question gets
> probed.

Sorry, the problem space is a bit convoluted so the answers
get a bit convoluted. Maybe I'm thinking aloud and altering the course
of my thoughts as I type...

I guess there can be explicit dependencies for resources like this
patch does, but another way would be for all resource fetch functions
to be instrumented, so that you do not block until you try to take
a resource that is not yet there, e.g.:

regulator_get(...) -> not available, so:
- identify target regulator provider - this will need instrumentation
- probe it

It then turns out the regulator driver is on the i2c bus, so we
need to probe the i2c driver:
- identify target i2c host for the regulator driver - this will need
  instrumentation
- probe the i2c host driver

i2c host comes out, probes the regulator driver, regulator driver
probes and then the regulator_get() call returns.

This requires instrumentation on anything providing a resource
to another driver like those I mentioned and a lot of overhead
infrastructure, but I think it's the right approach. However I don't
know if I would ever be able to pull that off myself, I know talk
is cheap and I should show the code instead.

Deepest respect for your efforts!

Yours,
Linus Walleij
--
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