Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933572AbbFJKUX (ORCPT ); Wed, 10 Jun 2015 06:20:23 -0400 Received: from mail-wi0-f181.google.com ([209.85.212.181]:34684 "EHLO mail-wi0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752109AbbFJKUN (ORCPT ); Wed, 10 Jun 2015 06:20:13 -0400 MIME-Version: 1.0 In-Reply-To: References: <1432565608-26036-1-git-send-email-tomeu.vizoso@collabora.com> From: Tomeu Vizoso Date: Wed, 10 Jun 2015 12:19:49 +0200 X-Google-Sender-Auth: kY9RsUBcO6dxUo7xNVFj8NF9flc Message-ID: Subject: Re: [PATCH 00/21] On-demand device registration To: Linus Walleij Cc: Mark Rutland , "devicetree@vger.kernel.org" , "linux-fbdev@vger.kernel.org" , linux-samsung-soc , dmaengine@vger.kernel.org, "linux-gpio@vger.kernel.org" , "linux-pm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-pwm@vger.kernel.org" , linux-clk@vger.kernel.org, "linux-tegra@vger.kernel.org" , Rob Herring , "open list:DRM PANEL DRIVERS" , Grant Likely , Alexander Holler , Dan Williams , Dmitry Torokhov , "linux-usb@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-i2c@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3613 Lines: 83 On 10 June 2015 at 09:30, Linus Walleij wrote: > On Tue, Jun 2, 2015 at 12:14 PM, Tomeu Vizoso > wrote: >> On 2 June 2015 at 10:48, Linus Walleij 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 I'm currently looking at is that an explicit dependency graph would be useful to have for other purposes. For example to print a neat warning when a dependency cannot be fulfilled. Or to refuse to unbind a device which other devices depend on, or to automatically unbind the devices that depend on it, or to print a warning if a device is hotplugged off and other devices depend on it. > 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. Yeah, if you can give it a second look and say if it matches what you wrote above, it would be very much appreciated. > Deepest respect for your efforts! Thanks! Tomeu > Yours, > Linus Walleij > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/