Am 10.06.2015 um 14:23 schrieb Andrzej Hajda:
On 06/10/2015 12:19 PM, Tomeu Vizoso wrote:
On 10 June 2015 at 09:30, Linus Walleij linus.walleij@linaro.org wrote:
On Tue, Jun 2, 2015 at 12:14 PM, Tomeu Vizoso tomeu.vizoso@collabora.com wrote:
On 2 June 2015 at 10:48, Linus Walleij linus.walleij@linaro.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.
Hmm, if I understand correctly what you say, this is exactly what this particular series does:
regulator_get -> of_platform_device_ensure -> probe() on the platform device that encloses the requested device node (i2c host) -> i2c slave gets probed and the regulator registered -> regulator_get returns the requested resource
The downside of this solution is that it will not work without device tree or even without device dependencies not explicitly specified in device tree.
Solution for what? The goal isn't to search another fancy registration/initialization algorithm.
So I wonder which problem that would solve at all. It doesn't give you some deterministic initialization order nor does it (re)solve dependencies (besides directly from one driver to another, but that isn't enough), nor does it solve the problem of identifying drivers (the other end of such an instrumented on-demand-initialization-call). So all it would be is some fancy on-demand initialization without having solved any problem.
Sorry if that sounds hard. Maybe I miss something. But I don't see any currently existing problem the above described solution would solve, besides beeing something different (which shouldn't be the goal).
Alexander Holler