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: 7145541 Return-Path: X-Original-To: patchwork-linux-pm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id A7D0E9F32B for ; Wed, 9 Sep 2015 09:41:05 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 89D2420637 for ; Wed, 9 Sep 2015 09:41:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EE92D205E5 for ; Wed, 9 Sep 2015 09:41:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754806AbbIIJkp (ORCPT ); Wed, 9 Sep 2015 05:40:45 -0400 Received: from mail-ob0-f171.google.com ([209.85.214.171]:33676 "EHLO mail-ob0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752460AbbIIJki convert rfc822-to-8bit (ORCPT ); Wed, 9 Sep 2015 05:40:38 -0400 Received: by obbbh8 with SMTP id bh8so3289317obb.0; 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 Cc: "linux-kernel@vger.kernel.org" , Stephen Warren , Javier Martinez Canillas , Mark Brown , Thierry Reding , "Rafael J. Wysocki" , "linux-arm-kernel@lists.infradead.org" , Dmitry Torokhov , "devicetree@vger.kernel.org" , Linus Walleij , "linux-acpi@vger.kernel.org" , Arnd Bergmann , "linux-fbdev@vger.kernel.org" , Linux USB List , Felipe Balbi , Linux PWM List , =?UTF-8?Q?Terje_Bergstr=C3=B6m?= , Greg Kroah-Hartman , Jingoo Han , David Airlie , Michael Turquette , linux-clk@vger.kernel.org, dmaengine@vger.kernel.org, Jean-Christophe Plagniol-Villard , Tomi Valkeinen , Grant Likely , Sebastian Reichel , Frank Rowand , Alexandre Courbot , "linux-pm@vger.kernel.org" , Stephen Boyd , Wolfram Sang , Russell King , "linux-gpio@vger.kernel.org" , Vinod Koul , Liam Girdwood , dri-devel , Lee Jones , "linux-tegra@vger.kernel.org" , Dan Williams , Dmitry Eremin-Solenikov , David Woodhouse , Kishon Vijay Abraham I , "linux-i2c@vger.kernel.org" Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID,T_RP_MATCHES_RCVD,UNPARSEABLE_RELAY autolearn=unavailable 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/ --- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html 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); }