From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F1C9CC4332B for ; Sat, 4 Apr 2020 17:58:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A788E206F8 for ; Sat, 4 Apr 2020 17:58:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=pqgruber.com header.i=@pqgruber.com header.b="ZqGj66iw" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726443AbgDDR6k (ORCPT ); Sat, 4 Apr 2020 13:58:40 -0400 Received: from mail.pqgruber.com ([52.59.78.55]:33680 "EHLO mail.pqgruber.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726207AbgDDR6k (ORCPT ); Sat, 4 Apr 2020 13:58:40 -0400 Received: from workstation.tuxnet (213-47-165-233.cable.dynamic.surfer.at [213.47.165.233]) by mail.pqgruber.com (Postfix) with ESMTPSA id 7A939C726E3; Sat, 4 Apr 2020 19:58:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pqgruber.com; s=mail; t=1586023117; bh=FSaQXyl6p5dDf1hyRrzuS++ijCcj+bUa5tWL8aMZrlE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ZqGj66iw/5w2R3m+qc759I+GUdOvqwOW4NGJjT82stJNkXXTkP3wYFMsmJ614v/hH KDARReV5jqhcNr6Wucf9qcmnrVjZ8RVIgnXaINlJ2x0zewiKBJvpCjBvx1kr4sNvg/ eqeooYkPAZCKLOHVj1GxA94NWtvqRsjYGD6kEtKk= Date: Sat, 4 Apr 2020 19:58:36 +0200 From: Clemens Gruber To: Sven Van Asbroeck Cc: Thierry Reding , Matthias Schiffer , Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= , Andy Shevchenko , linux-pwm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v1] pwm: pca9685: re-enable active pwm channels on pwm period change Message-ID: <20200404175836.GB55833@workstation.tuxnet> References: <20200403235324.27437-1-TheSven73@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200403235324.27437-1-TheSven73@gmail.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Fri, Apr 03, 2020 at 07:53:24PM -0400, Sven Van Asbroeck wrote: > In order to change the pwm period, this chip must be put in sleep > mode. However, when coming out of sleep mode, the pwm channel > state is not completely restored: all pwm channels are off by > default. > > This results in a bug in this driver: when the pwm period is changed > on a pwm channel, all other pwm channels will be deactivated. > > Fix by clearing the RESTART bit when coming out of sleep mode - this > will restore all pwm channels to their pre-sleep on/off state. > > Reported-by: Matthias Schiffer > Cc: Matthias Schiffer > Cc: Uwe Kleine-König > Cc: Clemens Gruber > Cc: Andy Shevchenko > Cc: linux-pwm@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Link: https://lore.kernel.org/lkml/32ec35c2b3da119dd2c7bc09742796a0d8a9607e.camel@ew.tq-group.com/ > Signed-off-by: Sven Van Asbroeck > --- > > I no longer have access to pca9685 hardware, so I'm unable to test: > - if this is indeed a bug > - if this patch fixes it > > Made against: > Tree-repo: git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git > Tree-branch: for-next > Tree-git-id: 9cc5f232a4b6a0ef6e9b57876d61b88f61bdd7c2 > > drivers/pwm/pwm-pca9685.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/drivers/pwm/pwm-pca9685.c b/drivers/pwm/pwm-pca9685.c > index 76cd22bd6614..0a16f0122e0e 100644 > --- a/drivers/pwm/pwm-pca9685.c > +++ b/drivers/pwm/pwm-pca9685.c > @@ -59,6 +59,7 @@ > > #define LED_FULL (1 << 4) > #define MODE1_SLEEP (1 << 4) > +#define MODE1_RESTART (1 << 7) > #define MODE2_INVRT (1 << 4) > #define MODE2_OUTDRV (1 << 2) > > @@ -271,6 +272,15 @@ static int pca9685_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm, > /* Wake the chip up */ > pca9685_set_sleep_mode(pca, false); > > + /* If any pwm channels were active when the chip was put > + * in sleep mode, re-activate them. > + */ > + if (!regmap_read(pca->regmap, PCA9685_MODE1, ®) && > + reg & MODE1_RESTART) > + regmap_update_bits(pca->regmap, PCA9685_MODE1, > + MODE1_RESTART, > + MODE1_RESTART); > + > pca->period_ns = period_ns; > } else { > dev_err(chip->dev, > -- > 2.17.1 > According to the PCA9685 datasheet revision 4, page 15, the RESTART bit is not only cleared by writing a 1 to it, but also by other actions like a write to any of the PWM registers. This seems to be the reason why I could not reproduce the reported problem. If I understand this correctly, clearing the RESTART bit would only be necessary if we wanted every ON/OFF register to stay the same, but in .config we might also get a different duty_ns value, so we have to reprogram the ON/OFF time regs. (Optimization: We could check if duty_ns to period_ns ratio stayed the same and if so, clear the RESTART bit and return without reg writes) Clemens