Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2939661imm; Fri, 10 Aug 2018 00:37:00 -0700 (PDT) X-Google-Smtp-Source: AA+uWPwnkiAfiIf4dZ1kpB3sKkcR6YIWwdp9r6n+Zeu1LfDIrSAeVS7XjDKQ0BeGyIlN4Ut25YA3 X-Received: by 2002:a63:a5c:: with SMTP id z28-v6mr5224325pgk.209.1533886620473; Fri, 10 Aug 2018 00:37:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533886620; cv=none; d=google.com; s=arc-20160816; b=q7htJr0bArvXdPi6ionDKQsDbhUljLOq1wDJx9SNwv6UMYb6QidNRQbqvJvNPWbQZr BJQfN38WDWzU/hhuxLfv7yUJsT1fLeOXOrnuBLmFfLh1g0+zihjq1uFU2SZz2l23CrQF whV1xRoGMM6ad12lv0MVTNq/eSEfw0Ek1blt5kJphwoOt7dLhvtvRsWGP3DKEIQGAb7p OGTncQFP5fZe6zXY8DKlwx0k9AD3EAyLyZgorNly2Dr6VGoj6mnw7xPjLQegUpXVYdj1 cxcqmo3kuYyl/Q3+AmwrTrYS4hjlU2fW/IFmlfK9y+lbrGlhKV75uFBICsdemyvy7Na/ N90g== 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=qAMtMcsUKqXSoOsXMnGeuxzuMfy0Ae7MzvZeOUW/ZNU=; b=pZs6U2q+EnlDN8gjFdM5Rt86koeLBxyhqZBDlrVQYuIref+8kfLl7ww3uY5dhBbf6w hOyeHLjdYh7r0AW/E0HGf7eQr8jztKWG5jYEK85gf4A90AjKUdP9lyg4QAADhOdgokqv hbCc0g91eEykn4RGowDD+PbPyBP9V51flKmMHWnPzBiib4eSkPkNh5qWe8P6Sj+YDLyU v2+oTZ1dl7cIjyolRCZx1d8Ci26Qo+2NARbbI0PTeeAz7PDrG7MSpB+akX2qNkDyWdII YjQJNKPY5cLRwvWdMgFq5kanfrxIqquzUSdMyTQDtT1WTvwSa1urM/wH/+UfEWFqmSMV 3Gyw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=eaXptnOn; 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 a20-v6si7571917pls.237.2018.08.10.00.36.45; Fri, 10 Aug 2018 00:37:00 -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=eaXptnOn; 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 S1727519AbeHJJjF (ORCPT + 99 others); Fri, 10 Aug 2018 05:39:05 -0400 Received: from mail-oi0-f68.google.com ([209.85.218.68]:33219 "EHLO mail-oi0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725832AbeHJJjF (ORCPT ); Fri, 10 Aug 2018 05:39:05 -0400 Received: by mail-oi0-f68.google.com with SMTP id 8-v6so14271988oip.0 for ; Fri, 10 Aug 2018 00:10:32 -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=qAMtMcsUKqXSoOsXMnGeuxzuMfy0Ae7MzvZeOUW/ZNU=; b=eaXptnOnW+xdRIL2Rj6a4S6RjrjByFOvGIM+Z7pCukvTZhaMQuj7YcRAyqe7Ghx8G9 4zs37sRPGhZbp/GznPKw7K7I8sJh9iEhqfAGlfAfpiWLjOwZg8RU5b6F3hVgby/WHi0/ VAJZVTrUnm7OXPQrkXyHwYTWAJTtmRxUL93h9YEW3NJeuurx+2NGnViwLUkRbAcGKeEe mOHiZtnqyzwGrUQ1yyOQLb5oRzAucTkMUFpBMoFc5bAQwFfvafFtWzUTj950bWaiRBe+ beOIAHrAs7DRSnC9l2qKG/ybfUWO31Qungm0KWXUket0pT3GCh3a7COSjChfaqO02YIC 864Q== 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=qAMtMcsUKqXSoOsXMnGeuxzuMfy0Ae7MzvZeOUW/ZNU=; b=T1DIVLuNd5vy0ioguZWg03MpvWv27fkfEVsUk0f9Lfdn2JXXnAwaa562OdTJNnzrxS 74eLUCFm4OgPOW9AVoNxD/2A5nhczHFC9jE1U9OT3X0iSOwWldAEorqoOPdbtOba7P5G fq/oFIUvRbItnGzaAsHN43/QCWoeFQLmjkJ8CkD9SKdkwJ5+OomuFe3hhO0BFswyOtD6 0kgoyoIljLpDMR9RIE6kB/lSTyTdlgILDPLX+Z/AjGJJDqQDOzjruIyWNbeOnfe8rEFN /qZ9vn5kwMz4IQabOLRvkVWQ5n+lT22UCWxUksorYxAIOQP9sOj6NWXKpREP766eM2bs m9+A== X-Gm-Message-State: AOUpUlGdF24wTyESBC7ghItfxSwTyBZq4xVYS0TJGQIi1v7vRBlWgaW7 d3aViB60ELsS7xJ+Osi7eTHfYVR3RonzDW23/Fo= X-Received: by 2002:aca:ccc4:: with SMTP id c187-v6mr5188738oig.282.1533885031456; Fri, 10 Aug 2018 00:10:31 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:63d2:0:0:0:0:0 with HTTP; Fri, 10 Aug 2018 00:10:30 -0700 (PDT) In-Reply-To: <2aecb7753a305aac081c9c9b981cedc1@codeaurora.org> References: <1532035440-7860-1-git-send-email-rishabhb@codeaurora.org> <68b90830d5024ce75a20b017aaf21c05@codeaurora.org> <2aecb7753a305aac081c9c9b981cedc1@codeaurora.org> From: "Rafael J. Wysocki" Date: Fri, 10 Aug 2018 09:10:30 +0200 X-Google-Sender-Auth: 7IIauD4cOCmDbLMTXF3uCffGLWA Message-ID: Subject: Re: [PATCH] dd: Invoke one probe retry cycle after every initcall level To: Rishabh Bhatnagar Cc: "Rafael J. Wysocki" , Sodagudi Prasad , Greg Kroah-Hartman , tsoni@codeaurora.org, Vikram Mulukutla , Linux Kernel Mailing List , ckadabi@codeaurora.org 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 Fri, Aug 10, 2018 at 12:30 AM, wrote: > On 2018-08-06 01:53, Rafael J. Wysocki wrote: >> >> On Fri, Aug 3, 2018 at 12:20 AM, Sodagudi Prasad >> wrote: >>>> >>>> From: RAFAEL J. WYSOCKI >>>> Date: Wed, Aug 1, 2018 at 2:21 PM >>>> 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 >>>> >>>> >>>> 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_? >>> >>> >>> 1) re-probe probing devices in the active list on every level help >>> to >>> avoid circular dependency pending list. >>> 2) There are so many devices which gets deferred in earlier init >>> call >>> levels, so we wanted to reprobe them at every successive init call level. >> >> >> Do you have specific examples of devices for which that helps? >> >>>> >>>>> This change helps in overall android bootup as well. >>>> >>>> >>>> >>>> How exactly? >>> >>> >>> We have seen less no of re-probes at late_init and most of the driver's >>> dependency met earlier than late_init call level. It helped display and >>> couple of other drivers by executing the re probe work at every init >>> level. >> >> >> So I can believe that walking the deferred list on device_initcall and >> maybe on device_initcall_sync may help, but I'm not quite convinced >> that it matters for the earlier initcall levels. > > > Many of our drivers are dependent on the regulator and bus driver. > Both the regulator and bus driver are probed in the subsys_initcall level. > Now the probe of bus driver requires regulator to be working. If the probe > of > bus driver happens before regulator, then bus driver's probe will be > deferred and all other device's probes which depend on bus driver will also > be deferred. > The impact of this problem is reduced if we have this patch. Fair enough, but this information should be there in the changelog of your patch. And why do you do that for arch_initcall_sync()?