From patchwork Sun Aug 30 12:57:42 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans de Goede X-Patchwork-Id: 11744921 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 4E38313B1 for ; Sun, 30 Aug 2020 12:58:34 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2CA112087D for ; Sun, 30 Aug 2020 12:58:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="cQQzygEd" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2CA112087D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id C28E96E2EA; Sun, 30 Aug 2020 12:58:29 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) by gabe.freedesktop.org (Postfix) with ESMTPS id C052C6E2E2 for ; Sun, 30 Aug 2020 12:58:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1598792301; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=y9AuNYLGu06i5bj0iiRfB2Pq9KBPBvi3vak13kj5YjA=; b=cQQzygEdEJH46cGYWohJuKsf4gq3riFaYrBQtZejFAaWhEarX/FAz9QNYbLkc/CZg9xAwK 2q6iO8M7cEfL4QjPfPIZ8lYLEqjHU3y5WhDQh3KwSZwymale5pobrgKIywFJyXzogzy1Mm sMSWmQi+BfAswIXdwJTUZIIwo/euAec= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-155-EUpFBF6-N0yV6g1tv4BKVQ-1; Sun, 30 Aug 2020 08:58:19 -0400 X-MC-Unique: EUpFBF6-N0yV6g1tv4BKVQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E9A9BADC86; Sun, 30 Aug 2020 12:58:17 +0000 (UTC) Received: from x1.localdomain.com (ovpn-112-77.ams2.redhat.com [10.36.112.77]) by smtp.corp.redhat.com (Postfix) with ESMTP id 596E2171C6; Sun, 30 Aug 2020 12:58:15 +0000 (UTC) From: Hans de Goede To: Thierry Reding , =?utf-8?q?Uwe_Kleine-K=C3=B6n?= =?utf-8?q?ig?= , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , =?utf-8?b?VmlsbGUgU3lyasOkbMOk?= , "Rafael J . Wysocki" , Len Brown Date: Sun, 30 Aug 2020 14:57:42 +0200 Message-Id: <20200830125753.230420-7-hdegoede@redhat.com> In-Reply-To: <20200830125753.230420-1-hdegoede@redhat.com> References: <20200830125753.230420-1-hdegoede@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Subject: [Intel-gfx] [PATCH v8 06/17] pwm: lpss: Use pwm_lpss_restore() when restoring state on resume X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-pwm@vger.kernel.org, linux-acpi@vger.kernel.org, intel-gfx , dri-devel@lists.freedesktop.org, Andy Shevchenko , Mika Westerberg Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" Before this commit a suspend + resume of the LPSS PWM controller would result in the controller being reset to its defaults of output-freq = clock/256, duty-cycle=100%, until someone changes to the output-freq and/or duty-cycle are made. This problem has been masked so far because the main consumer (the i915 driver) was always making duty-cycle changes on resume. With the conversion of the i915 driver to the atomic PWM API the driver now only disables/enables the PWM on suspend/resume leaving the output-freq and duty as is, triggering this problem. The LPSS PWM controller has a mechanism where the ctrl register value and the actual base-unit and on-time-div values used are latched. When software sets the SW_UPDATE bit then at the end of the current PWM cycle, the new values from the ctrl-register will be latched into the actual registers, and the SW_UPDATE bit will be cleared. The problem is that before this commit our suspend/resume handling consisted of simply saving the PWM ctrl register on suspend and restoring it on resume, without setting the PWM_SW_UPDATE bit. When the controller has lost its state over a suspend/resume and thus has been reset to the defaults, just restoring the register is not enough. We must also set the SW_UPDATE bit to tell the controller to latch the restored values into the actual registers. Fixing this problem is not as simple as just or-ing in the value which is being restored with SW_UPDATE. If the PWM was enabled before we must write the new settings + PWM_SW_UPDATE before setting PWM_ENABLE. We must also wait for PWM_SW_UPDATE to become 0 again and depending on the model we must do this either before or after the setting of PWM_ENABLE. All the necessary logic for doing this is already present inside pwm_lpss_apply(), so instead of duplicating this inside the resume handler, this commit adds a new pwm_lpss_restore() helper which mirrors pwm_lpss_apply() minus the runtime-pm reference handling (which we should not change on resume). This fixes the output-freq and duty-cycle being reset to their defaults on resume. Reviewed-by: Andy Shevchenko Signed-off-by: Hans de Goede --- Changes in v8: - Drop optimization to skip restore if current ctrl reg is the same as our saved ctrl reg value (because this causes issues on some devices) - Simplify pwm_lpss_restore_state() to not rely on the current state - Modify commit message to mention the new pwm_lpss_restore_state() helper Changes in v6: - Add a pwm_lpss_restore_state() helper for re-applying the PWM state on resume Changes in v5: - The changes to pwm_lpss_apply() are much cleaner now thanks to the new pwm_lpss_prepare_enable() helper. Changes in v3: - This replaces the "pwm: lpss: Set SW_UPDATE bit when enabling the PWM" patch from previous versions of this patch-set, which really was a hack working around the resume issue which this patch fixes properly. --- drivers/pwm/pwm-lpss.c | 40 +++++++++++++++++++++++++++++++++++++--- 1 file changed, 37 insertions(+), 3 deletions(-) diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c index 8a136ba2a583..9a7400c6fb6e 100644 --- a/drivers/pwm/pwm-lpss.c +++ b/drivers/pwm/pwm-lpss.c @@ -166,6 +166,25 @@ static int pwm_lpss_apply(struct pwm_chip *chip, struct pwm_device *pwm, return ret; } +/* + * This is a mirror of pwm_lpss_apply() without relying on the current state + * (no pwm_is_enabled() calls) and without pm_runtime reference handling, + * for restoring the PWM state on resume. + */ +static int pwm_lpss_restore_state(struct pwm_lpss_chip *lpwm, + struct pwm_device *pwm, + const struct pwm_state *state) +{ + int ret = 0; + + if (state->enabled) + ret = pwm_lpss_prepare_enable(lpwm, pwm, state, true); + else + pwm_lpss_write(pwm, pwm_lpss_read(pwm) & ~PWM_ENABLE); + + return ret; +} + static void pwm_lpss_get_state(struct pwm_chip *chip, struct pwm_device *pwm, struct pwm_state *state) { @@ -278,10 +297,25 @@ EXPORT_SYMBOL_GPL(pwm_lpss_suspend); int pwm_lpss_resume(struct device *dev) { struct pwm_lpss_chip *lpwm = dev_get_drvdata(dev); - int i; + struct pwm_device *pwm; + int i, ret; - for (i = 0; i < lpwm->info->npwm; i++) - writel(lpwm->saved_ctrl[i], lpwm->regs + i * PWM_SIZE + PWM); + for (i = 0; i < lpwm->info->npwm; i++) { + pwm = &lpwm->chip.pwms[i]; + + /* + * We cannot just blindly restore the old value here. Since we + * are changing the settings we must set SW_UPDATE and if the + * PWM was enabled before we must write the new settings + + * PWM_SW_UPDATE before setting PWM_ENABLE. We must also wait + * for PWM_SW_UPDATE to become 0 again and depending on the + * model we must do this either before or after the setting of + * PWM_ENABLE. + */ + ret = pwm_lpss_restore_state(lpwm, pwm, &pwm->state); + if (ret) + dev_err(dev, "Error restoring state on resume\n"); + } return 0; }