From patchwork Mon Aug 20 14:43:56 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= X-Patchwork-Id: 959776 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=linux-pwm-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=pengutronix.de Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 41vGll5J4Pz9s9F for ; Tue, 21 Aug 2018 00:44:03 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726221AbeHTR75 (ORCPT ); Mon, 20 Aug 2018 13:59:57 -0400 Received: from metis.ext.pengutronix.de ([85.220.165.71]:35625 "EHLO metis.ext.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726277AbeHTR75 (ORCPT ); Mon, 20 Aug 2018 13:59:57 -0400 Received: from pty.hi.pengutronix.de ([2001:67c:670:100:1d::c5]) by metis.ext.pengutronix.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1frlPU-0004xi-TO; Mon, 20 Aug 2018 16:44:00 +0200 Received: from ukl by pty.hi.pengutronix.de with local (Exim 4.89) (envelope-from ) id 1frlPT-0000mp-QN; Mon, 20 Aug 2018 16:43:59 +0200 From: =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= To: Thierry Reding Cc: linux-pwm@vger.kernel.org, Gavin Schenk , kernel@pengutronix.de Subject: [PATCH 1/2] pwm: document the pin state after pwm_disable() to be undefined Date: Mon, 20 Aug 2018 16:43:56 +0200 Message-Id: <20180820144357.7206-2-u.kleine-koenig@pengutronix.de> X-Mailer: git-send-email 2.18.0 In-Reply-To: <20180820144357.7206-1-u.kleine-koenig@pengutronix.de> References: <20180820095221.fydcvtz7ppcymrta@pengutronix.de> <20180820144357.7206-1-u.kleine-koenig@pengutronix.de> MIME-Version: 1.0 X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::c5 X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-pwm@vger.kernel.org Sender: linux-pwm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pwm@vger.kernel.org Contrarily to the common assumption that pwm_disable() stops the output at the state where it just happens to be, this isn't what the hardware does on some machines. For example on i.MX6 the pin goes to 0 level instead. Note this doesn't reduce the expressiveness of the pwm-API because if you want the PWM-Pin to stay at a given state, you are supposed to configure it to 0% or 100% duty cycle without calling pwm_disable(). The backend driver is free to implement potential power savings already when the duty cycle changes to one of these two cases so this doesn't come at an increased runtime power cost (once the respective drivers are fixed). In return this allows to adhere to the API more easily for drivers that currently cannot know if it's ok to disable the hardware on pwm_disable() because the caller might or might not rely on the pin stopping at a certain level. Signed-off-by: Uwe Kleine-König --- Documentation/pwm.txt | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/Documentation/pwm.txt b/Documentation/pwm.txt index 8fbf0aa3ba2d..36cbcd353e37 100644 --- a/Documentation/pwm.txt +++ b/Documentation/pwm.txt @@ -49,11 +49,15 @@ After being requested, a PWM has to be configured using:: This API controls both the PWM period/duty_cycle config and the enable/disable state. +Note that it is explicitly undefined what happens to the PWM pin when the +pwm-device is disabled, even if the duty cycle was configured to 0% or 100% +before. It might stay at the last configured state, it might go to 0 or High-Z. + The pwm_config(), pwm_enable() and pwm_disable() functions are just wrappers around pwm_apply_state() and should not be used if the user wants to change several parameter at once. For example, if you see pwm_config() and -pwm_{enable,disable}() calls in the same function, this probably means you -should switch to pwm_apply_state(). +pwm_enable() calls in the same function, this probably means you should switch +to pwm_apply_state(). The PWM user API also allows one to query the PWM state with pwm_get_state(). From patchwork Mon Aug 20 14:43:57 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= X-Patchwork-Id: 959777 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=linux-pwm-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=pengutronix.de Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 41vGlm5H8mz9s3C for ; Tue, 21 Aug 2018 00:44:04 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726277AbeHTR75 (ORCPT ); Mon, 20 Aug 2018 13:59:57 -0400 Received: from metis.ext.pengutronix.de ([85.220.165.71]:56783 "EHLO metis.ext.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726641AbeHTR75 (ORCPT ); Mon, 20 Aug 2018 13:59:57 -0400 Received: from pty.hi.pengutronix.de ([2001:67c:670:100:1d::c5]) by metis.ext.pengutronix.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1frlPU-0004xl-TO; Mon, 20 Aug 2018 16:44:00 +0200 Received: from ukl by pty.hi.pengutronix.de with local (Exim 4.89) (envelope-from ) id 1frlPT-0000ms-VD; Mon, 20 Aug 2018 16:43:59 +0200 From: =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= To: Thierry Reding Cc: linux-pwm@vger.kernel.org, Gavin Schenk , kernel@pengutronix.de Subject: [PATCH 2/2] pwm: warn callers of pwm_apply_state() that expect a certain level after disabling Date: Mon, 20 Aug 2018 16:43:57 +0200 Message-Id: <20180820144357.7206-3-u.kleine-koenig@pengutronix.de> X-Mailer: git-send-email 2.18.0 In-Reply-To: <20180820144357.7206-1-u.kleine-koenig@pengutronix.de> References: <20180820095221.fydcvtz7ppcymrta@pengutronix.de> <20180820144357.7206-1-u.kleine-koenig@pengutronix.de> MIME-Version: 1.0 X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::c5 X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-pwm@vger.kernel.org Sender: linux-pwm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pwm@vger.kernel.org If a pwm-API user changes the duty cycle to 0% or 100% and setting the state to disabled, probably the old implicit behaviour is expected that the pin state stays where it is after pwm_disable(). While there might be some users that trigger this warning as false positive, it is probably good to have this anyhow at least until the newly introduced undefined behaviour sunk in a bit. Signed-off-by: Uwe Kleine-König --- drivers/pwm/core.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c index 1581f6ab1b1f..a076d58127ac 100644 --- a/drivers/pwm/core.c +++ b/drivers/pwm/core.c @@ -475,6 +475,18 @@ int pwm_apply_state(struct pwm_device *pwm, struct pwm_state *state) if (!memcmp(state, &pwm->state, sizeof(*state))) return 0; + /* + * If period, duty_cycle and/or polarity changes and the pwm should be + * disabled the user might expect something that is explicitly undefined + * (i.e. a certain state of the pin in disabled state). + */ + WARN_ONCE((state->period != pwm->state.period || + state->duty_cycle != pwm->state.duty_cycle || + state->polarity != pwm->state.polarity) && + (state->duty_cycle == 0 || + state->duty_cycle == state->period) && + state->enabled == false, "%s: config changed for disabled pin", pwm->label); + if (pwm->chip->ops->apply) { err = pwm->chip->ops->apply(pwm->chip, pwm, state); if (err)