From patchwork Wed Sep 4 12:42:50 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Brown X-Patchwork-Id: 172929 Delivered-To: patch@linaro.org Received: by 2002:a92:d204:0:0:0:0:0 with SMTP id y4csp1177513ily; Wed, 4 Sep 2019 05:43:08 -0700 (PDT) X-Google-Smtp-Source: APXvYqyq4g9V4BKGUHP5ghpJUwnIhknkfkPy8b2BNxSkcQXy+8HTxBuUBBtCC4I/2xZrfKw7VP/e X-Received: by 2002:a62:f80a:: with SMTP id d10mr7538488pfh.98.1567600987909; Wed, 04 Sep 2019 05:43:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567600987; cv=none; d=google.com; s=arc-20160816; b=lbw46zleiTAXOLtijRdiVhisYnz5hyKLYKUarf8e5KBT/sw0EGun0om8O253ZF3LOq JfS12dcjL/5op/8s302Yy6JnpZX+noKQC+cZuWSfPvZNWJ23UDfEhEi8ncQeJWtF2E4T sMWM4NDxIpjzyg5xjojCvefgJomCymlNoxUbhWHDq3Bhm0XOUZggHzuuP5gNxBoST95r RMB+9DPdBRMzpr06oII+PfkPLUR5eFzwXqN/VlkHm5qmannYxHXKRG2kOLXH5fWHIVzW mircBYc1esBSip1noGiow+W7YtbjIP4kcwXkpXJTaHV63OgWVAhiMoAQylvBOwGjxd2h 5IZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=kT6JiKSS9HwgRZeLeoXhpFd1kRtgRGK+0O09M9Xb7A4=; b=0alXs9ZRXFHxgsZ64YB7gUNeDkHDbWqcEDs9M/3haKxH+HiWHTqYJL157VYE+3I4uQ C4pO2SovqJ56PzOabLPht6prWyu7cDbypuFa1+GTXJFImU81gzFZJ1pITZMXo0PavUKW ArEWdBsYOHrCCexMIW/XmQXL5DWB+tq7PFau9WRi+fb3nCR+4yPyBpYLTTBUyGuKEW6L W0heNKDZLWMOQ/Wo2PcyDEStelkBXg4yWZVjATfEbOBkT2YgyADsiuhZ3sSFdsK9JisG czj5qDp+40yeFJWussxDCKu4Ug0pg5Bvc+lJEu3W6pi0iKBoOn4Q5ddWwyAX+W3HEF9f 1vEw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@sirena.org.uk header.s=20170815-heliosphere header.b=bLOgq8Hq; 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 b3si17424231pld.356.2019.09.04.05.43.07; Wed, 04 Sep 2019 05:43:07 -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=@sirena.org.uk header.s=20170815-heliosphere header.b=bLOgq8Hq; 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 S1729881AbfIDMnG (ORCPT + 28 others); Wed, 4 Sep 2019 08:43:06 -0400 Received: from heliosphere.sirena.org.uk ([172.104.155.198]:35990 "EHLO heliosphere.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726943AbfIDMnG (ORCPT ); Wed, 4 Sep 2019 08:43:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sirena.org.uk; s=20170815-heliosphere; h=Content-Transfer-Encoding: MIME-Version:Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:Content-Type: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=kT6JiKSS9HwgRZeLeoXhpFd1kRtgRGK+0O09M9Xb7A4=; b=bLOgq8Hq7J4RrL6Ex2KHUEO52 5CfCv2ZZeEOLWUyigJX9wVVFaEGiYFO6UlzH0P12zjIv9WTtjVe/mbHtpTEq+iTOPO6RLvzVQKYLn K3TkC3br3bLefWytp4Ztv6RY/+Gm6Y3MAnVsoszwYI0wvjhuWAeFbDHAMstUXIviLB0yE=; Received: from cpc102320-sgyl38-2-0-cust46.18-2.cable.virginm.net ([82.37.168.47] helo=ypsilon.sirena.org.uk) by heliosphere.sirena.org.uk with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1i5Ucq-0005XK-FK; Wed, 04 Sep 2019 12:43:04 +0000 Received: by ypsilon.sirena.org.uk (Postfix, from userid 1000) id 925622742B45; Wed, 4 Sep 2019 13:43:03 +0100 (BST) From: Mark Brown To: Liam Girdwood Cc: linux-kernel@vger.kernel.org, Mark Brown , Lee Jones Subject: [PATCH] regulator: Defer init completion for a while after late_initcall Date: Wed, 4 Sep 2019 13:42:50 +0100 Message-Id: <20190904124250.25844-1-broonie@kernel.org> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The kernel has no way of knowing when we have finished instantiating drivers, between deferred probe and systems that build key drivers as modules we might be doing this long after userspace has booted. This has always been a bit of an issue with regulator_init_complete since it can power off hardware that's not had it's driver loaded which can result in user visible effects, the main case is powering off displays. Practically speaking it's not been an issue in real systems since most systems that use the regulator API are embedded and build in key drivers anyway but with Arm laptops coming on the market it's becoming more of an issue so let's do something about it. In the absence of any better idea just defer the powering off for 30s after late_initcall(), this is obviously a hack but it should mask the issue for now and it's no more arbitrary than late_initcall() itself. Ideally we'd have some heuristics to detect if we're on an affected system and tune or skip the delay appropriately, and there may be some need for a command line option to be added. Signed-off-by: Mark Brown Tested-by: Lee Jones --- drivers/regulator/core.c | 42 +++++++++++++++++++++++++++++----------- 1 file changed, 31 insertions(+), 11 deletions(-) -- 2.20.1 diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index 4a27a46ec6e7..340db986b67f 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -5644,7 +5644,7 @@ static int __init regulator_init(void) /* init early to allow our consumers to complete system booting */ core_initcall(regulator_init); -static int __init regulator_late_cleanup(struct device *dev, void *data) +static int regulator_late_cleanup(struct device *dev, void *data) { struct regulator_dev *rdev = dev_to_rdev(dev); const struct regulator_ops *ops = rdev->desc->ops; @@ -5693,17 +5693,8 @@ static int __init regulator_late_cleanup(struct device *dev, void *data) return 0; } -static int __init regulator_init_complete(void) +static void regulator_init_complete_work_function(struct work_struct *work) { - /* - * Since DT doesn't provide an idiomatic mechanism for - * enabling full constraints and since it's much more natural - * with DT to provide them just assume that a DT enabled - * system has full constraints. - */ - if (of_have_populated_dt()) - has_full_constraints = true; - /* * Regulators may had failed to resolve their input supplies * when were registered, either because the input supply was @@ -5721,6 +5712,35 @@ static int __init regulator_init_complete(void) */ class_for_each_device(®ulator_class, NULL, NULL, regulator_late_cleanup); +} + +static DECLARE_DELAYED_WORK(regulator_init_complete_work, + regulator_init_complete_work_function); + +static int __init regulator_init_complete(void) +{ + /* + * Since DT doesn't provide an idiomatic mechanism for + * enabling full constraints and since it's much more natural + * with DT to provide them just assume that a DT enabled + * system has full constraints. + */ + if (of_have_populated_dt()) + has_full_constraints = true; + + /* + * We punt completion for an arbitrary amount of time since + * systems like distros will load many drivers from userspace + * so consumers might not always be ready yet, this is + * particularly an issue with laptops where this might bounce + * the display off then on. Ideally we'd get a notification + * from userspace when this happens but we don't so just wait + * a bit and hope we waited long enough. It'd be better if + * we'd only do this on systems that need it, and a kernel + * command line option might be useful. + */ + schedule_delayed_work(®ulator_init_complete_work, + msecs_to_jiffies(30000)); return 0; }