Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp127601imm; Thu, 2 Aug 2018 15:22:36 -0700 (PDT) X-Google-Smtp-Source: AAOMgpemaw6ndbiLqwgf88sHJO0XxTSFWjiJ/Qwa+zftP8oegdCBe4KARNbTIOcZh3hSLjTXJCiL X-Received: by 2002:a63:1403:: with SMTP id u3-v6mr1174068pgl.13.1533248556284; Thu, 02 Aug 2018 15:22:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533248556; cv=none; d=google.com; s=arc-20160816; b=H2ucjpuwxei0H9Tqad7Qp8Wjv/dS5Pij+bo33h4BrRq3lMoyYlzKYbGlTwUOtjBx0V RT1Gqk12XSE1k6dtBFzkza3HJpscKsYHMBtzv4WCtFPpfobVAggeuHshMToaKwEeMYcT 7FQKCa5PqX2kHu+MfHOvU3j2XvPvnv8OiVuFWyCploR2oUaRIASsUplZkcYb85zyxumG cH+Q0hokJaxQXbVB4WEF6GP5lusgGUnOz5lTtnS04qpPywT6HF49qRcS97sYtM37IiQN gQUHGZ/ArzgcFRsAAJ39W/tVS5XoqyyBRGFSDAuHRYsr0tf52fMovfElSC+npRrYqpeX d03A== 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=owRJb2wNFOhu2diNsD7D7gdd7/OFbXo89zf3JxQWkv8=; b=e/d0S0DDOoHgF+9a05A5aSlHnEX5CfrJd3cJh49cELUq9uTVRNwafAz2jM6/Ud0kg9 sLpeN+7WswS1k2pn9YiPw2ZjErrK77+ngM7aDtp98HXfOBuET60byw0SqW3DOCOMRreD n7aZSbqXH6KeBNJnblujPeJN/HryoO9ebutoFtrpRFbQ3u6QPsq8Yc8rU5vTgDiPKqrn I7Y08YHH7p79hK2jIzD9gbYPxXNoYm9IgrCy4yGszCx8hWl9c6YosFtXwMVx3n4YVWIq yzf82BMyzLnZJWgtvivA9AFFBuZHoixL011FpjTiAh9EE3FbszEIj8qNMs5FtT8ZbBzm 9FJg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=jvjAhCX0; dkim=pass header.i=@codeaurora.org header.s=default header.b=ICBJu285; 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 ba6-v6si2192496plb.364.2018.08.02.15.22.21; Thu, 02 Aug 2018 15:22:36 -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=jvjAhCX0; dkim=pass header.i=@codeaurora.org header.s=default header.b=ICBJu285; 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 S1729639AbeHCAN7 (ORCPT + 99 others); Thu, 2 Aug 2018 20:13:59 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:60528 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726229AbeHCAN7 (ORCPT ); Thu, 2 Aug 2018 20:13:59 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id AA8F36014B; Thu, 2 Aug 2018 22:20:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1533248448; bh=/KFk1HoJaWlJ/uugnWjlRGJsE35J0i+AI9f7fA00zyM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=jvjAhCX0spHOj2lDZFuH2Rif0Yhw8yxiMjcRa+AU80VYByOzIvjmvDY66dH9K0G5i ah+yC0TzEG77QvmSHSSTdtP3wrO8ivNj/tc+d7OpBzPODI465+Qj0BxWFslUWkdhRl e7ri84pElXxqQPBWV6lkFgEY+ZqUglkIlVOS7wfs= 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 DEC826014B; Thu, 2 Aug 2018 22:20:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1533248447; bh=/KFk1HoJaWlJ/uugnWjlRGJsE35J0i+AI9f7fA00zyM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ICBJu285zLZCZYLdIgzOYSbeIySkBpicceyAa/ayCAFoBBT/Oj3OKYhARPFg672Ii Vi3SPKRBLNuCO6i6N3g1R+t5AsdbTtd91PgfmsilEGbzKr98YH5mNf4QIn9iaJ2au/ Dby01fX/KiIPI6UASGLd7ZQN8cn3WkXpqUsSewqU= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 02 Aug 2018 15:20:47 -0700 From: Sodagudi Prasad To: gregkh@linuxfoundation.org, rafael@kernel.org, rishabhb@codeaurora.org Cc: tsoni@codeaurora.org, Vikram Mulukutla , linux-kernel@vger.kernel.org, ckadabi@codeaurora.org, psodagud@codeaurora.org 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: X-Sender: psodagud@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 > 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. > >> 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. -thanks, Prasad -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, Linux Foundation Collaborative Project