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=-15.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 E8175C433DB for ; Thu, 14 Jan 2021 22:29:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B291E23A7C for ; Thu, 14 Jan 2021 22:29:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730265AbhANW3C (ORCPT ); Thu, 14 Jan 2021 17:29:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55626 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729586AbhANW3C (ORCPT ); Thu, 14 Jan 2021 17:29:02 -0500 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [IPv6:2001:4d48:ad52:32c8:5054:ff:fe00:142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 90C6EC061757; Thu, 14 Jan 2021 14:28:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=+c27JvaG+gyEJ2essLvjqsTpAebaaMjXRpDRTZS4lnw=; b=YxlVRLcvHz4lnPRWymzjv3YzN iKbQBygqTA+prJsHeB+ccZVZ2dPnxs4bcbW6RbH1oY/O36r8+aqboK6nynPAfRwZHhKI/OTfGZXrN uDzQEzDKhMQxjK0pAaaGySnKWg0PAZpKY7Q75O5tAA/jYd/BVheHORO16oT41bH1I9or543fMgQHz 8FRz8nF2oH4cFIwqYN/vbpKCWeJvLnWOf4a5AA8gKxkKHjI7LqRELWx4qoIiGWTab6OWdJL8ycAVA jc6TYc2ZBGBl3wzDH8FhijlVlD1XCW74O0Ql4BuK7NL4I53g6McEB6jgUmXbaHy8z4PMhLUQz3nTX DQ6cCBg1Q==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:48046) by pandora.armlinux.org.uk with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l0B6A-00030H-QS; Thu, 14 Jan 2021 22:28:10 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1l0B62-0000Ha-LP; Thu, 14 Jan 2021 22:28:02 +0000 Date: Thu, 14 Jan 2021 22:28:02 +0000 From: Russell King - ARM Linux admin To: Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= Cc: Baruch Siach , Andrew Lunn , Sascha Hauer , linux-pwm@vger.kernel.org, Linus Walleij , Chris Packham , Bartosz Golaszewski , Thierry Reding , Thomas Petazzoni , linux-gpio@vger.kernel.org, Ralph Sennhauser , Lee Jones , Gregory Clement , linux-arm-kernel@lists.infradead.org, Sebastian Hesselbarth Subject: Re: [PATCH v3 5/5] gpio: mvebu: document zero pwm duty cycle limitation Message-ID: <20210114222802.GY1551@shell.armlinux.org.uk> References: <7c18dd67d3bf3e3ed9a8efa2edd33e8f29f09a7a.1610628807.git.baruch@tkos.co.il> <20210114202545.7wnc5ikeffc45xk5@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210114202545.7wnc5ikeffc45xk5@pengutronix.de> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: Russell King - ARM Linux admin Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On Thu, Jan 14, 2021 at 09:25:45PM +0100, Uwe Kleine-König wrote: > Hello Baruch, > > On Thu, Jan 14, 2021 at 08:57:37PM +0200, Baruch Siach wrote: > > Add a comment on why the code never sets on/off registers to zero. > > > > Reported-by: Uwe Kleine-König > > Analyzed-by: Russell King > > Signed-off-by: Baruch Siach > > --- > > drivers/gpio/gpio-mvebu.c | 4 ++++ > > 1 file changed, 4 insertions(+) > > > > diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c > > index 6b017854ce61..09780944bef9 100644 > > --- a/drivers/gpio/gpio-mvebu.c > > +++ b/drivers/gpio/gpio-mvebu.c > > @@ -706,6 +706,10 @@ static int mvebu_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm, > > do_div(val, NSEC_PER_SEC); > > if (val > UINT_MAX) > > return -EINVAL; > > + /* > > + * Zero on/off values don't work as expected. Experimentation shows > > + * that zero value is treated as 2^32. This behavior is not documented. > > + */ > > This is too easy. The right thing to do is to adapt .apply and > .get_state to use this new information. What exactly do you expect the changes to be? Bear in mind that the hardware is not capable of atomically updating e.g. the duty cycle without affecting the period, because any change in duty cycle needs the "on" and "off" durations to be separately programmed, and there's a chance that the hardware could start using either value mid-update. Also, disabling "blink" mode to achieve a steady output (for 0% or 100% duty cycle) would require further investigation to find out how the hardware behaves at the moment where blink mode is disabled: does the output retain its current state (does the bit in the output register toggle with the blink) or does it revert to the value in the output register that was programmed before blink mode was enabled. Again, none of that is documented, so would need experimentation with the hardware to work out how to achieve it. And then if you want even more complexity, I suppose we could try and read the current state of the pin, add a delay, recheck it and try and work out the optimal place to disable the blink mode. Exactly how far do you want to go with this? All of this is likely getting rediculously complicated for the use cases of it today that don't need it. Yes, it's annoying that we can't achieve 0% or 100% duty cycle with this hardware that was never designed as a PWM without jumping through a lot of hoops but currently settle for a minimum pulse width of 4ns at each end of the range. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!