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: 515795 Return-Path: X-Original-To: incoming-imx@patchwork.ozlabs.org Delivered-To: patchwork-incoming-imx@bilbo.ozlabs.org Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 271451402B0 for ; Wed, 9 Sep 2015 19:44:11 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b=q0tWHAVZ; dkim-atps=neutral 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-Spam-Report: SpamAssassin version 3.4.0 on bombadil.infradead.org summary: Content analysis details: (-2.3 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [2607:f8b0:4003:c01:0:0:0:233 listed in] [list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (tomeu.vizoso[at]gmail.com) 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list 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+incoming-imx=patchwork.ozlabs.org@lists.infradead.org List-Id: linux-imx-kernel.lists.patchwork.ozlabs.org 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); }