Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1344860imm; Wed, 1 Aug 2018 14:22:25 -0700 (PDT) X-Google-Smtp-Source: AAOMgpeKZ9Hf3QU9oonirCOXOGx1DB5OHBJ41gMhK9D+Ofgpz5/qhtP1SENcvhO+0fR6ZPducOwK X-Received: by 2002:a63:f309:: with SMTP id l9-v6mr9342pgh.369.1533158545164; Wed, 01 Aug 2018 14:22:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533158545; cv=none; d=google.com; s=arc-20160816; b=UaJgEkf4siEnXRipq4C1x3GEdCwAnf3b/cvVHFhVcd401fAoCV7FHUAVRNjDYdNmBg ZenJhqdiscFcUllDt1qnvezJXlinvjqJEmJnBmIZHQGghyu93HNJ+Onz88/SVhEL9gmx ssEvyZ1GSFsKbcsdfokdMPPUnNNgwafToFCfGuAS98+R77ST2G3WhgoyYHlemU14QOw/ x1pbxVyuVHRFSR9jEjdNfVBU8R2UL4iOJaPxcDjvzZQKU+bf8lafsB9XlUBE7xhgYElH PfTuchLh/8d8o9HgFtrX+WUjtwg4Fa9kU0F00qhWss2/d//LdkYqZTIsvv1qmOqIm4Et sExg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=ucwNnjxHiiHHwhrYQyRF97UJ0t2Xnv51N7lgffCez0U=; b=yEFX5FBsQS3h5VKbWpObM6XF7JnfjVL7fap+pzEsyd2sdgtWsjR2iq+bxNfc79K7yF mRUL8GCi5cMq6rhN5JuDfsd9oJPRQbygT1tq2CSFqTv5xW9OgLj15mYh69V4fNq3TO06 2za1V9K6rxHyP8zbCCpDjMCP+tYY619ohwy585xC0lWjyX7fJ66HhHQg8kpnvJDcv1zh Z6Pk5kyXGqQq0FjnkAJnt/yd0yhRRDW6AIR7uQkX63veKnxLvTTXPfLUc7LHkqgiTmF1 loJKXxB12fmJdvvTamD+Si8SmjHeHAicHnJJyFfd6UavVeNQeQuZ2vGFvmMDXOIzegGS 9j+A== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=YDHBMKx8; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j85-v6si19413pfa.232.2018.08.01.14.22.09; Wed, 01 Aug 2018 14:22:25 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=YDHBMKx8; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731990AbeHAXJA (ORCPT + 99 others); Wed, 1 Aug 2018 19:09:00 -0400 Received: from mail-oi0-f66.google.com ([209.85.218.66]:39620 "EHLO mail-oi0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729736AbeHAXJA (ORCPT ); Wed, 1 Aug 2018 19:09:00 -0400 Received: by mail-oi0-f66.google.com with SMTP id d189-v6so84144oib.6 for ; Wed, 01 Aug 2018 14:21:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ucwNnjxHiiHHwhrYQyRF97UJ0t2Xnv51N7lgffCez0U=; b=YDHBMKx8U38+8VAmSA1otru15KoVR/xWTp9rYZCf/Q1gFlyBE4K5j0vWeQzWOHN578 Y3n+3dOFomUbIpMZizETkOWmaJFSxVsGj7TClKcG5fAWoCP9thqVCfpBI3CZKWMSgj9U qtwBWRJNZv+Vkd2ckYbnpsMvbgeauv3T8YG1ZVaWT3YICl6guisnpxfyGqnKNFp6jBk3 iKW/FzPs2an9RByYLYosm9vIvrp4S4oB4xgIKsEuV3USmUuwbN8MqQTDFYs6ZBR+U1oG 5GXE4RIbszIxQNn2UcNyoj9YYvXBvBEHpLfsNG7lFlS0XfS23yvS9B1zu6jw8gJEpZRM oY9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ucwNnjxHiiHHwhrYQyRF97UJ0t2Xnv51N7lgffCez0U=; b=ji8cmuUvVVS3sflTmAdDO89qPqs2eDeQOmMWrSpTcwkJ/QYxgxor9UP7rmrW2RbxyI /uwT5M61hK0boKOOhI0kJU8rxXcAmUU9zWGA6XtC1zqMcYNIQ75PDr5aydRiU7QwBcOS yCDqIhNXA+0e4ySyhGJsa80Hu83jGvKpZAYAnLXyxEipzu9iOuNQJuxajx9+CfOlaCSK Weu205xrZDjy3Mx1Nn80RS+u/Ntmj0qSxjtuHbgav16mJJMhhDlfGTCr5ynd+Q4WboVa VFrLycr/Pbu9R06+dg3+VOZX1b2XhZrHl0lAXFXxIpsjXhp5dlPNJqSI9f+kZzs025wR zozA== X-Gm-Message-State: AOUpUlF0tZV3Vs+9Y78+dc29PhN173Z80PpTJU3CQpMs+Bl9/4/ahnL4 pJ3T70fOk8okkScOSSjfusHEA9R91Wk0ctDflRg= X-Received: by 2002:aca:ccc4:: with SMTP id c187-v6mr40045oig.282.1533158476809; Wed, 01 Aug 2018 14:21:16 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:63d2:0:0:0:0:0 with HTTP; Wed, 1 Aug 2018 14:21:16 -0700 (PDT) In-Reply-To: <68b90830d5024ce75a20b017aaf21c05@codeaurora.org> References: <1532035440-7860-1-git-send-email-rishabhb@codeaurora.org> <68b90830d5024ce75a20b017aaf21c05@codeaurora.org> From: "Rafael J. Wysocki" Date: Wed, 1 Aug 2018 23:21:16 +0200 X-Google-Sender-Auth: 5FyVw2g84TQtsNFI2Jyxd2zZFag Message-ID: Subject: Re: [PATCH] dd: Invoke one probe retry cycle after every initcall level To: Rishabh Bhatnagar Cc: "Rafael J. Wysocki" , Greg Kroah-Hartman , Linux Kernel Mailing List , ckadabi@codeaurora.org, tsoni@codeaurora.org, Vikram Mulukutla Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 1, 2018 at 11:18 PM, wrote: > On 2018-07-24 01:24, Rafael J. Wysocki wrote: >> >> On Mon, Jul 23, 2018 at 10:22 PM, wrote: >>> >>> On 2018-07-23 04:17, Rafael J. Wysocki wrote: >>>> >>>> >>>> On Thu, Jul 19, 2018 at 11:24 PM, Rishabh Bhatnagar >>>> wrote: >>>>> >>>>> >>>>> Drivers that are registered at an initcall level may have to >>>>> wait until late_init before the probe deferral mechanism can >>>>> retry their probe functions. It is possible that their >>>>> dependencies were resolved much earlier, in some cases even >>>>> before the next initcall level. Invoke one probe retry cycle >>>>> at every _sync initcall level, allowing these drivers to be >>>>> probed earlier. >>>> >>>> >>>> >>>> Can you please say something about the actual use case this is >>>> expected to address? >>> >>> >>> We have a display driver that depends 3 other devices to be >>> probed so that it can bring-up the display. Because of dependencies >>> not being met the deferral mechanism defers the probes for a later time, >>> even though the dependencies might be met earlier. With this change >>> display can be brought up much earlier. >> >> >> OK >> >> What runlevel brings up the display after the change? >> >> Thanks, >> Rafael > > After the change the display can come up after device_initcall level > itself. > The above mentioned 3 devices are probed at 0.503253, 0.505210 and 0.523264 > secs. > Only the first device is probed successfully. With the current > deferral mechanism the devices get probed again after late_initcall > at 9.19 and 9.35 secs. So display can only come up after 9.35 secs. > With this change the devices are re-probed successfully at 0.60 and > 0.613 secs. Therefore display can come just after 0.613 secs. OK, so why do you touch the initcall levels earlier than device_? > This change helps in overall android bootup as well. How exactly?