Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2562892imm; Thu, 9 Aug 2018 15:31:51 -0700 (PDT) X-Google-Smtp-Source: AA+uWPwe875dJcfNEcOi0U1OuQ1pP9WZfls1OXD/iXh3CzPlZIKogYYgEFUAkF0QJdeRhfZx3e6t X-Received: by 2002:a62:cc4d:: with SMTP id a74-v6mr4252502pfg.200.1533853911301; Thu, 09 Aug 2018 15:31:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533853911; cv=none; d=google.com; s=arc-20160816; b=jabI8Zu8ZTTqrfBxrpGm8eRDK3hrSQE+ZjnMbY7E6xgTvOAGOlcHir1FxQYlFRVsaV G0/o5i7nmRzHjEW4u9HL2b2CykS4swIVxSsMPvC3bKfLyCGIdv5E9yK8XCsX0wwPKKoL cnF8aikgv42y4VlfmU3m/+pdVSUSjdd0tf02jVPZ3xBNiF/M0jEpKYVDYVDE2erFvXrQ fbk3LeLaF+7gSgMUEnAJ7knpJC5VqF5r1ZgPDYu0ENwiHya7fg4QXU4jkvYri50eNi3E J1BS2F+tTYIs6kYf/iohnJVJZMD0mOM4PZGPqx6U2QpMt/yoLorhBVuLIHzEdtP4FEBE LGdA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:subject:cc:to:from:date:content-transfer-encoding :mime-version:dkim-signature:dkim-signature :arc-authentication-results; bh=pRkt1zBJUzlq6V3MMK1WSWojU7WzJ7CYeCO0Pzn7FZE=; b=z+eNmjKK/FAT/9mZBAQeah3Cked7lJy7NOkkwd9ds/m4xRu1oo/kUHS7QFd77YHniA JOtX5ga9I1idCx79egUwtCJbIC2yTRUqgCeAGiyBVbvLWcGkCCWeyRJWxJi1xFzeggZZ aYDW/4YRDW6vTitGqPfO9zp8yBDEQBLdhKLk/ngcbN16sucf0oQ17+QL4eun+0X0nDma FZpqYxQ2Hj6AFYPFEgJmgIhJI2lhes3Uk5izbcBP7NZ7zwyKALYO3H+YZ2jexOJT/hUC QesYKpmPz34Wh3VC03rXqq/aT6lR6ToDHocJMOSVTjF+ZE7Wy/sX4rLy9cYXyQ0NZKss KxnA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=OS7mooJP; dkim=pass header.i=@codeaurora.org header.s=default header.b=YHcDE1EA; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 188-v6si8654025pfg.154.2018.08.09.15.31.34; Thu, 09 Aug 2018 15:31:51 -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=pass header.i=@codeaurora.org header.s=default header.b=OS7mooJP; dkim=pass header.i=@codeaurora.org header.s=default header.b=YHcDE1EA; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727467AbeHJA5f (ORCPT + 99 others); Thu, 9 Aug 2018 20:57:35 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:41904 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727069AbeHJA5f (ORCPT ); Thu, 9 Aug 2018 20:57:35 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 00B8760B7F; Thu, 9 Aug 2018 22:30:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1533853839; bh=QE6RKQs2fS5EhRu3BgTzeBdXL0ME9mSqqSloh3lEAyE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=OS7mooJPzoRxUVaz8WY8656vhXPQgK4pQSOmTvT1/51tGB72sE4jQ4YPpE2DG4U/+ 1rvpi6v5OcAVlzL++c7I56/VHJeo9B+MMt1kW8SnkFJ8dxQRSYFq4esVqsXiyxcMfC yDPhYsYHWIuir4NYKqax2/cYZhfsCyhXCnptj2Nk= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id 7D8FD60B1A; Thu, 9 Aug 2018 22:30:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1533853838; bh=QE6RKQs2fS5EhRu3BgTzeBdXL0ME9mSqqSloh3lEAyE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=YHcDE1EAow8u0gXxT1slMVfYCKkvhENZ/5O8hTtaLQRaSJPAPZzGpPPXlxSeex6NK 5EYAwmF6G4FrWk6qP3ed3OJHxb8RcIH+xszuB+r+iAobkhxjGTtNK156qg888+DEmx AclEm0AXkj5yJ2GCdyVfuhzUoTOJg6W2TIdE/NuQ= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 09 Aug 2018 15:30:38 -0700 From: rishabhb@codeaurora.org To: "Rafael J. Wysocki" Cc: Sodagudi Prasad , Greg Kroah-Hartman , tsoni@codeaurora.org, Vikram Mulukutla , Linux Kernel Mailing List , ckadabi@codeaurora.org, rjwysocki@gmail.com Subject: Re: [PATCH] dd: Invoke one probe retry cycle after every initcall level In-Reply-To: References: <1532035440-7860-1-git-send-email-rishabhb@codeaurora.org> <68b90830d5024ce75a20b017aaf21c05@codeaurora.org> Message-ID: <2aecb7753a305aac081c9c9b981cedc1@codeaurora.org> X-Sender: rishabhb@codeaurora.org User-Agent: Roundcube Webmail/1.2.5 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.