From patchwork Mon Oct 24 20:52:09 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paul Cercueil X-Patchwork-Id: 10404 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp707032wru; Mon, 24 Oct 2022 16:43:26 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7UAxbqc9wys/uQCu62fiOz+PcAiV4iE0PRFNx1Iy6se+jrl6O8KD3Ueo3qT2yX6z1ps5hm X-Received: by 2002:a17:902:f54f:b0:186:a987:c733 with SMTP id h15-20020a170902f54f00b00186a987c733mr7610305plf.170.1666655006596; Mon, 24 Oct 2022 16:43:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666655006; cv=none; d=google.com; s=arc-20160816; b=vPuGolf3D63mr3qJajaKs7d305A0MEpY1UU0+rI/jqKvoU1jD7RikSGqzzJmuoZMqX IG2FbStKMHgANcC855gc8NAk/RAIhuVZvOjovhN+ZNvAWlWtlXABnPNjXj1v6T1tRl1C NiHm+VT0o2o29cqMuGXnF85njGXpE17k4zlswpxUsRF6Cxd6a4G+k3rEnv3haPOLZ0ez S0qek9rTdX6BGW4yJvdfXFplHH2q9SO17U2OVrTwpY4ZRxSb6B5DJoW+tavq3HPh60Jt cpoF/Fxgq/gOAIp7FSjk97qodndR0xbBC5vO/d5XqgvA5cGYj5NGRcUpu7Uer8+G0ChV m66Q== 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 :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=avcN02YNvaxpZRdy8N6BP2+uTVrnwX31SrzsZGCAp0c=; b=GQcB8HFttUEhuRzYaSCXaXjxeQcjWJf6/kvvos3HlkyO6S4ZB0BfqcvQQMyDIE91/c dS19gAJWy5xtSpQH1cL0d9XBaLb9zUce4maoIb2X+cUCp3mWRB+9D1X6pCBv4Ss6wOdd Wlr2+kQ+TSd4/D2W4XMgRBdb2WPK9OQWM7GVGb01mrPz4xpV3pYtMvS3Q3tt9HKyHvOt gkK/7jlsZESWCBUJuJKmoDdArvF1mGRV2Eftx8XZy+UnPmzNUU7jcViES2vbZXKXizoq qstT9HZRUM+W7WBffDqCLhenqdJcvTw3E2TShxeWC20hUSkVES+rsKCm4cRPi6YHM+MX ZUHA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@crapouillou.net header.s=mail header.b=Bmyh2YOh; 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=crapouillou.net Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y10-20020a170902d64a00b0017f5ea2e8easi893226plh.357.2022.10.24.16.43.14; Mon, 24 Oct 2022 16:43:26 -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=@crapouillou.net header.s=mail header.b=Bmyh2YOh; 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=crapouillou.net Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231384AbiJXXdE (ORCPT + 99 others); Mon, 24 Oct 2022 19:33:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49984 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230405AbiJXXcZ (ORCPT ); Mon, 24 Oct 2022 19:32:25 -0400 Received: from aposti.net (aposti.net [89.234.176.197]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EE040107A8C; Mon, 24 Oct 2022 14:53:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crapouillou.net; s=mail; t=1666644740; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=avcN02YNvaxpZRdy8N6BP2+uTVrnwX31SrzsZGCAp0c=; b=Bmyh2YOhAjfg1GSy4ncnAj+0uagLOdl4JNbxAeyUKnYnHQsPI4htDWCoHQuYlBqCsqa7qz a1TvbaO2+3VP3gUDS4UmlqXfBkR5Tze5O7MPfwSi++v+pk0pHtro5AQCZftppjugDkmdxZ IqWyRrP0D7KxE5peHD5QjkDZvR7LGAI= From: Paul Cercueil To: Thierry Reding , =?utf-8?q?Uwe_Kleine-K=C3=B6n?= =?utf-8?q?ig?= Cc: od@opendingux.net, linux-pwm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org, Paul Cercueil , stable@vger.kernel.org Subject: [PATCH 1/5] pwm: jz4740: Fix pin level of disabled TCU2 channels, part 1 Date: Mon, 24 Oct 2022 21:52:09 +0100 Message-Id: <20221024205213.327001-2-paul@crapouillou.net> In-Reply-To: <20221024205213.327001-1-paul@crapouillou.net> References: <20221024205213.327001-1-paul@crapouillou.net> MIME-Version: 1.0 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS 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 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747614439856556216?= X-GMAIL-MSGID: =?utf-8?q?1747614439856556216?= The "duty > cycle" trick to force the pin level of a disabled TCU2 channel would only work when the channel had been enabled previously. Address this issue by enabling the PWM mode in jz4740_pwm_disable (I know, right) so that the "duty > cycle" trick works before disabling the PWM channel right after. This issue went unnoticed, as the PWM pins on the majority of the boards tested would default to the inactive level once the corresponding TCU clock was enabled, so the first call to jz4740_pwm_disable() would not actually change the pin levels. On the GCW Zero however, the PWM pin for the backlight (PWM1, which is a TCU2 channel) goes active as soon as the timer1 clock is enabled. Since the jz4740_pwm_disable() function did not work on channels not previously enabled, the backlight would shine at full brightness from the moment the backlight driver would probe, until the backlight driver tried to *enable* the PWM output. With this fix, the PWM pins will be forced inactive as soon as jz4740_pwm_apply() is called (and might be reconfigured to active if dictated by the pwm_state). This means that there is still a tiny time frame between the .request() and .apply() callbacks where the PWM pin might be active. Sadly, there is no way to fix this issue: it is impossible to write a PWM channel's registers if the corresponding clock is not enabled, and enabling the clock is what causes the PWM pin to go active. There is a workaround, though, which complements this fix: simply starting the backlight driver (or any PWM client driver) with a "init" pinctrl state that sets the pin as an inactive GPIO. Once the driver is probed and the pinctrl state switches to "default", the regular PWM pin configuration can be used as it will be properly driven. Fixes: c2693514a0a1 ("pwm: jz4740: Obtain regmap from parent node") Signed-off-by: Paul Cercueil Cc: stable@vger.kernel.org --- drivers/pwm/pwm-jz4740.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/pwm/pwm-jz4740.c b/drivers/pwm/pwm-jz4740.c index a5fdf97c0d2e..228eb104bf1e 100644 --- a/drivers/pwm/pwm-jz4740.c +++ b/drivers/pwm/pwm-jz4740.c @@ -102,11 +102,14 @@ static void jz4740_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm) struct jz4740_pwm_chip *jz = to_jz4740(chip); /* - * Set duty > period. This trick allows the TCU channels in TCU2 mode to - * properly return to their init level. + * Set duty > period, then enable PWM mode and start the counter. + * This trick allows to force the inactive pin level for the TCU2 + * channels. */ regmap_write(jz->map, TCU_REG_TDHRc(pwm->hwpwm), 0xffff); regmap_write(jz->map, TCU_REG_TDFRc(pwm->hwpwm), 0x0); + regmap_set_bits(jz->map, TCU_REG_TCSRc(pwm->hwpwm), TCU_TCSR_PWM_EN); + regmap_write(jz->map, TCU_REG_TESR, BIT(pwm->hwpwm)); /* * Disable PWM output.