From patchwork Wed Sep 9 09:40:17 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Tomeu Vizoso X-Patchwork-Id: 7145561 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 1D656BEEC1 for ; Wed, 9 Sep 2015 09:43:50 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id D2A4E20939 for ; Wed, 9 Sep 2015 09:43:48 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A9CAE20865 for ; Wed, 9 Sep 2015 09:43:47 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1ZZbsF-0000dF-4s; Wed, 09 Sep 2015 09:41:03 +0000 Received: from mail-ob0-x233.google.com ([2607:f8b0:4003:c01::233]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1ZZbsB-0000RE-CM for linux-arm-kernel@lists.infradead.org; Wed, 09 Sep 2015 09:41:00 +0000 Received: by obqa2 with SMTP id a2so3223069obq.3 for ; Wed, 09 Sep 2015 02:40:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=zm9PSNugEnFdOZbiqJQz2/ZiYNbcQzYwbqF0BLEq80Y=; b=q0tWHAVZD2qIvnOs6DIx0Q2sDKiBQYMbUuJxJxj4J4e78+NyXCkhhkY+qzEWqRS26w lvwC1Zpw98a8kPuNHFbxzuNFta4PAcLpLUwyeCxeeajvdjON3eYK/uz4qrb0yCZKFAnC 7IB6TCHJ4EbUVcLf2ywPFzuYH7NfQa3qAypFSIfCtOuVkvxNbIhci5dQSMcDOTDmxC8c VSOKzcI5c0bazGGiSQDjfCWLZZdARLw0IljeCYOCvIiYqgKxwbqwMWA+gEvbLwR0jU1W Tyd8KL6rAc99N8iFGLNMrtlvmc/B30rp/vwAvsAImCvFsDhEyHmpoadMhVh3AKIroSfG bbDQ== X-Received: by 10.60.145.228 with SMTP id sx4mr24791257oeb.79.1441791637017; Wed, 09 Sep 2015 02:40:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.85.87 with HTTP; Wed, 9 Sep 2015 02:40:17 -0700 (PDT) In-Reply-To: <55EF8C65.4030706@kernel.org> References: <1441628627-5143-1-git-send-email-tomeu.vizoso@collabora.com> <55EF8C65.4030706@kernel.org> From: Tomeu Vizoso Date: Wed, 9 Sep 2015 11:40:17 +0200 X-Google-Sender-Auth: VixcNvVnxA3h_GTEKzLX4KXBw64 Message-ID: Subject: Re: [PATCH v4 0/22] On-demand device probing To: Rob Herring X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20150909_024059_637931_D3038D70 X-CRM114-Status: GOOD ( 33.78 ) X-Spam-Score: -2.3 (--) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "linux-fbdev@vger.kernel.org" , Dmitry Torokhov , Linux PWM List , David Airlie , Stephen Boyd , Linus Walleij , dri-devel , Sebastian Reichel , Thierry Reding , "linux-i2c@vger.kernel.org" , Frank Rowand , linux-clk@vger.kernel.org, Alexandre Courbot , =?UTF-8?Q?Terje_Bergstr=C3=B6m?= , Javier Martinez Canillas , Vinod Koul , Lee Jones , "linux-pm@vger.kernel.org" , Kishon Vijay Abraham I , "linux-acpi@vger.kernel.org" , Tomi Valkeinen , Wolfram Sang , Grant Likely , Jean-Christophe Plagniol-Villard , Michael Turquette , "devicetree@vger.kernel.org" , Arnd Bergmann , Stephen Warren , Liam Girdwood , "linux-gpio@vger.kernel.org" , Mark Brown , "linux-tegra@vger.kernel.org" , Russell King , Dan Williams , "linux-arm-kernel@lists.infradead.org" , Greg Kroah-Hartman , Linux USB List , "Rafael J. Wysocki" , "linux-kernel@vger.kernel.org" , Felipe Balbi , Dmitry Eremin-Solenikov , Jingoo Han , dmaengine@vger.kernel.org, David Woodhouse Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED, T_DKIM_INVALID, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 9 September 2015 at 03:33, Rob Herring wrote: > On 09/08/2015 02:30 AM, Tomeu Vizoso wrote: >> On 7 September 2015 at 22:50, Rob Herring wrote: >>> On Mon, Sep 7, 2015 at 7:23 AM, Tomeu Vizoso wrote: >>>> Hello, >>>> >>>> I have a problem with the panel on my Tegra Chromebook taking longer >>>> than expected to be ready during boot (Stéphane Marchesin reported what >>>> is basically the same issue in [0]), and have looked into ordered >>>> probing as a better way of solving this than moving nodes around in the >>>> DT or playing with initcall levels and linking order. >>>> >>>> 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 probing devices as they are >>>> referenced by other devices. >>>> >>>> This basically reuses the information that is already implicit in the >>>> probe() implementations, saving us from refactoring existing drivers or >>>> adding information to DTBs. >>>> >>>> During review of v1 of this series Linus Walleij suggested that it >>>> should be the device driver core to make sure that dependencies are >>>> ready before probing a device. I gave this idea a try [2] but Mark Brown >>>> pointed out to the logic duplication between the resource acquisition >>>> and dependency discovery code paths (though I think it's fairly minor). >>>> >>>> To address that code duplication I experimented with Arnd's devm_probe >>>> [3] concept of having drivers declare their dependencies instead of >>>> acquiring them during probe, and while it worked [4], I don't think we >>>> end up winning anything when compared to just probing devices on-demand >>>> from resource getters. >>>> >>>> One remaining objection is to the "sprinkling" of calls to >>>> of_device_probe() in the resource getters of each subsystem, but I think >>>> it's the right thing to do given that the storage of resources is >>>> currently subsystem-specific. >>>> >>>> We could avoid the above by moving resource storage into the core, but I >>>> don't think there's a compelling case for that. >>>> >>>> I have tested this on boards with Tegra, iMX.6, Exynos, Rockchip and >>>> OMAP SoCs, and these patches were enough to eliminate all the deferred >>>> probes (except one in PandaBoard because omap_dma_system doesn't have a >>>> firmware node as of yet). >>>> >>>> Have submitted a branch [5] with only these patches on top of thursday's >>>> linux-next to kernelci.org and I don't see any issues that could be >>>> caused by them. For some reason it currently has more passes than the >>>> version of -next it's based on! >>>> >>>> With this series I get the kernel to output to the panel in 0.5s, >>>> instead of 2.8s. >>>> >>>> Regards, >>>> >>>> Tomeu >>>> >>>> [0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html >>>> >>>> [1] https://lkml.org/lkml/2014/5/12/452 >>>> >>>> [2] https://lkml.org/lkml/2015/6/17/305 >>>> >>>> [3] http://article.gmane.org/gmane.linux.ports.arm.kernel/277689 >>>> >>>> [4] https://lkml.org/lkml/2015/7/21/441a >>>> >>>> [5] https://git.collabora.com/cgit/user/tomeu/linux.git/log/?h=on-demand-probes-v6 >>>> >>>> [6] http://kernelci.org/boot/all/job/collabora/kernel/v4.2-11902-g25d80c927f8b/ >>>> >>>> [7] http://kernelci.org/boot/all/job/next/kernel/next-20150903/ >>>> >>>> Changes in v4: >>>> - Added bus.pre_probe callback so the probes of Primecell devices can be >>>> deferred if their device IDs cannot be yet read because of the clock >>>> driver not having probed when they are registered. Maybe this goes >>>> overboard and the matching information should be in the DT if there is >>>> one. >>> >>> Seems overboard to me or at least a separate problem. >> >> It's a separate problem but this was preventing the series from >> working on a few boards. > > What is the failure? Not booting? Fixing not working would certainly not > be overboard. On the device I was testing on (qemu's vexpress-a15 machine) the machine booted and I was able to open a ssh session, but serial was broken among other AMBA devices: /memory-controller@2b0a0000 /memory-controller@7ffd0000 /dma@7ffb0000 /smb/motherboard/iofpga@3,00000000/sysctl@020000 /smb/motherboard/iofpga@3,00000000/aaci@040000 /smb/motherboard/iofpga@3,00000000/mmci@050000 /smb/motherboard/iofpga@3,00000000/kmi@060000 /smb/motherboard/iofpga@3,00000000/kmi@070000 /smb/motherboard/iofpga@3,00000000/uart@090000 /smb/motherboard/iofpga@3,00000000/uart@0a0000 /smb/motherboard/iofpga@3,00000000/uart@0b0000 /smb/motherboard/iofpga@3,00000000/uart@0c0000 /smb/motherboard/iofpga@3,00000000/wdt@0f0000 /smb/motherboard/iofpga@3,00000000/timer@110000 /smb/motherboard/iofpga@3,00000000/timer@120000 /smb/motherboard/iofpga@3,00000000/rtc@170000 /smb/motherboard/iofpga@3,00000000/clcd@1f0000 Another way of avoiding this particular problem would be not delaying the probe of devices in the configuration bus, by doing something like this: static int __init vexpress_config_init(void) But I think this would be papering over the underlying issue and it would be better to have proper explicit dependencies. Regards, Tomeu >>> Most clocks have >>> to be setup before the driver model simply because timers depend on >>> clocks usually. >> >> Yes, but in this case the apb clocks for the primecell devices are >> implemented in a normal platform driver (vexpress_osc_driver), instead >> of using CLK_OF_DECLARE. > > Okay. > > Rob > > -- > 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/ diff --git a/drivers/bus/vexpress-config.c b/drivers/bus/vexpress-config.c index 6575c0fe6a4e..eda293869cd3 100644 --- a/drivers/bus/vexpress-config.c +++ b/drivers/bus/vexpress-config.c @@ -181,7 +181,7 @@ static int vexpress_config_populate(struct device_node *node) if (WARN_ON(!parent)) return -ENODEV; - return of_platform_populate(node, NULL, NULL, parent); + return of_platform_populate_early(node, NULL, NULL, parent); }