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=-10.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 81EA4C433DB for ; Mon, 29 Mar 2021 17:34:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5654C61981 for ; Mon, 29 Mar 2021 17:34:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229557AbhC2Re2 (ORCPT ); Mon, 29 Mar 2021 13:34:28 -0400 Received: from mail.pqgruber.com ([52.59.78.55]:57490 "EHLO mail.pqgruber.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230258AbhC2Rd6 (ORCPT ); Mon, 29 Mar 2021 13:33:58 -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 60714C729F1; Mon, 29 Mar 2021 19:33:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pqgruber.com; s=mail; t=1617039237; bh=ZFwt0JGTIyq6uB7FeKFEuWXBuJCfFDDYJw0dZcvtP3U=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=l0FKQTSNCWdepn5bTdxYgxAfBkGqtH9ZwxHp2jdv/DQHk7WdtJx2wDQZfzhiAzq+n U0jadktl0PdrQcIBeKhrr+6BlACUcNCrzg3ptf67z4WPj16gDJPoqxu7/HRu+9l9sA t3ETewZMQ8fjRsPQo1NRdIwqTom3TmP80u3fk+p8= Date: Mon, 29 Mar 2021 19:33:56 +0200 From: Clemens Gruber To: Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= Cc: linux-pwm@vger.kernel.org, Thierry Reding , Sven Van Asbroeck , linux-kernel@vger.kernel.org, kernel@pengutronix.de Subject: Re: [PATCH v6 6/7] pwm: pca9685: Restrict period change for prescaler users Message-ID: References: <20210329125707.182732-1-clemens.gruber@pqgruber.com> <20210329125707.182732-6-clemens.gruber@pqgruber.com> <20210329171559.rfelpt42shlebct5@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210329171559.rfelpt42shlebct5@pengutronix.de> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 29, 2021 at 07:15:59PM +0200, Uwe Kleine-König wrote: > On Mon, Mar 29, 2021 at 02:57:06PM +0200, Clemens Gruber wrote: > > @@ -330,14 +345,22 @@ static int pca9685_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm, > > > > if (!state->enabled || duty < 1) { > > pca9685_pwm_set_duty(pca, pwm->hwpwm, 0); > > + clear_bit(pwm->hwpwm, pca->prescaler_users); > > Hmm, so if "my" channel runs at say > > .duty_cycle = 2539520 ns > .period = 5079040 ns > > and I call pwm_apply_state(mypwm, { .duty_cycle = 0, .period = 5079040, > enabled = true }); it might happen that another channel modifies the > period and I won't be able to return to the initial setting. Yes, that's correct. But that also applies to PWMs set to 100%: pwm_apply_state(mypwm, { .duty_cycle = 5079040, .period = 5079040, enabled = true }); As this sets the full ON bit and does not use the prescaler, with the current code, another channel could modify the period and you wouldn't be able to return to the initial setting of 50%. > > So I think it's sensible to only clear the user bit if the PWM is > disabled, but not if it is configured for duty_cycle = 0. > > Does this make sense? With both cases in mind, you are suggesting we block modifications of the prescaler if other PWMs are enabled and not if other PWMs are using the prescaler? Clemens