Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp4450714pxb; Wed, 20 Apr 2022 03:36:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwKM1hFT6+ITWFrRzhAPrSNxONDkjaWAqTHSNiRwBac6S5P4ehGqrl3ONhioq1FHWGF4MLa X-Received: by 2002:a05:6402:e96:b0:41d:1a0f:e70a with SMTP id h22-20020a0564020e9600b0041d1a0fe70amr22603352eda.411.1650450978916; Wed, 20 Apr 2022 03:36:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650450978; cv=none; d=google.com; s=arc-20160816; b=pfVO0txYNcvUbnsNnSyPwabL3fpSnc6l9+Q2mQwpzKQ6upyOQQ3X2TaFiL1C/UQWzm PBrsN2mt8Ykx0a8fMiIbXKiMe7DuO6jwz739dw+qF2pwsvQXAbSGjYecYssgF8kz1la5 qrwJoMKF2dh5cOkjuR9C4wlrkW28zrudIwzdH0wEBV9pL7aZakAUbi4UZ+7Pkou10/ym 0HUVsMaUJE9j2l/jHWWeyDaslY6eZjgI3WplWI9D1L5BUAKbAdLUwWdtvyOGsuP/rDbB C9x8A1J9q3wsRRtZU0Edzj6Cpp37YtBJJ02dTHaxdzUBWy3/VYDfUtY590BiqtLf0SXx xvkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=7bFlDtoHqXrD/bV3CCVWd42azNRMgyWRb3PBwzvLmRA=; b=PntP0pA9rdnCxK7opDQcR38Xt7NUiRhQBvB6M9UiesT8Xt8yyo47yV/StkgfPMSYNN sCme3+dM+HBj0XlWVP5OMhvdqOVf6iVYOSEgdX0mgqMGJMj4g5eLQ8MwPxPkHrEGOyLL Y8SllwTYIcLA4MYz1R95HmKEQ9DqzDM5lEwsb+Gr9vJZymwSopWJBXdByWrsjGltws2m 8tC6A2EmXX/MfeJo/TYupN0vPJo+6BX66LEuP1lHjPrm+F2LXAgP3oIRCBiwwmydzUTQ LgeQJB+I7l1ADA342qoFRpdqX9pMZW8EBh6ccTVu9uDBmyBGCeoZGD/22Jj1b8a0K6YJ d1nA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=XicyQjyU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f21-20020a170906391500b006df76385d13si1382011eje.435.2022.04.20.03.35.48; Wed, 20 Apr 2022 03:36:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=XicyQjyU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347949AbiDRVPe (ORCPT + 99 others); Mon, 18 Apr 2022 17:15:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49712 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234528AbiDRVPc (ORCPT ); Mon, 18 Apr 2022 17:15:32 -0400 Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D2F522CCA7 for ; Mon, 18 Apr 2022 14:12:51 -0700 (PDT) Received: by mail-pg1-x52a.google.com with SMTP id j71so7573827pge.11 for ; Mon, 18 Apr 2022 14:12:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=7bFlDtoHqXrD/bV3CCVWd42azNRMgyWRb3PBwzvLmRA=; b=XicyQjyUvi05/iutniPuMM7K/ZIg7rOgo0edexrYUl6iATTuzsKgLxN4MgE7us9tVL Kc84lk2VAuMxMY3tRRT5g1hR5Fo6zT7g+bYA66lcPAccx74mJu7h6Lq0A7hxuDcrkcCC jptHBs4budj0AjcghfUZplUrvNjzrNfPiiPXQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=7bFlDtoHqXrD/bV3CCVWd42azNRMgyWRb3PBwzvLmRA=; b=4VLsURDed3MhKmKy0HpNO7vAAgd6TDbd/luAjEA51d62ml3WfN6GCH1qN0C6Irq+ai cJi9ONGYmKLqsQ5hVkejsRK+nlDHpbIM6JtNJT+yA15M+FblsALOvKlkXU/hFkPD3EV/ 391xs/EV6jrJCJnhkbXEbws7skLaM3AhSH/9j1WnlWm+jBgLBkT8Ssx2SQoMP70mAR2j G7zYmFmbA5R3l5Bb96mwIj+oVcaGKr41+BeiNK05IlG3c0QBHVpZGEfKbC2vt7fKzn0w eB3/4uQr2zXPrbMeIZCH9cpG2GbhEDkgW4E6HdppMju35UzchUg3tA0HthhtuX6cAsrv p8bQ== X-Gm-Message-State: AOAM530G7Utax0eHyS39yuQktsjomY7+npKVu7YwL3J1QtuIBhrlBhO/ wHr4ie5VLyn8AP/PdJV/fh2lxQ== X-Received: by 2002:a62:7bc9:0:b0:508:2e2a:c36c with SMTP id w192-20020a627bc9000000b005082e2ac36cmr14235811pfc.67.1650316371335; Mon, 18 Apr 2022 14:12:51 -0700 (PDT) Received: from localhost ([2620:15c:202:201:c240:3b46:d799:c833]) by smtp.gmail.com with UTF8SMTPSA id x39-20020a056a0018a700b004fa7e6ceafesm14282202pfh.169.2022.04.18.14.12.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 Apr 2022 14:12:50 -0700 (PDT) From: Brian Norris To: Liam Girdwood , Mark Brown Cc: Matthias Kaehlcke , linux-kernel@vger.kernel.org, Brian Norris Subject: [PATCH 1/2] regulator: core: Sleep (not delay) in set_voltage() Date: Mon, 18 Apr 2022 14:12:39 -0700 Message-Id: <20220418141158.1.If0fc61a894f537b052ca41572aff098cf8e7e673@changeid> X-Mailer: git-send-email 2.36.0.rc0.470.gd361397f0d-goog MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org These delays can be relatively large (e.g., hundreds of microseconds on RK3399 Gru systems). Per Documentation/timers/timers-howto.rst, that should usually use a sleeping delay. Let's use fsleep() to handle both large and small delays appropriately. This avoids burning a bunch of CPU time and hurting scheduling latencies when hitting regulators a lot (e.g., during cpufreq). The sleep vs. delay issue choice has been made differently over time -- early versions of RK3399 Gru PWM-regulator support used usleep_range() in pwm-regulator.c. More of this got moved into the regulator core, in commits like: 73e705bf81ce regulator: core: Add set_voltage_time op At the same time, the sleep turned into a delay. It's OK to sleep here, as we aren't in an atomic contexts. (All our callers grab various mutexes already.) Signed-off-by: Brian Norris --- drivers/regulator/core.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index d2553970a67b..223c6d71a2b2 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -3548,12 +3548,7 @@ static int _regulator_do_set_voltage(struct regulator_dev *rdev, } /* Insert any necessary delays */ - if (delay >= 1000) { - mdelay(delay / 1000); - udelay(delay % 1000); - } else if (delay) { - udelay(delay); - } + fsleep(delay); if (best_val >= 0) { unsigned long data = best_val; -- 2.36.0.rc0.470.gd361397f0d-goog