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.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 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 A378AC433E0 for ; Thu, 14 Jan 2021 22:32:59 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6845723107 for ; Thu, 14 Jan 2021 22:32:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6845723107 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=armlinux.org.uk Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=eZ1bVItg3+93fPD+YSa7u1gHD1zkyjNJWIOubqZRx6M=; b=Em9JtyhOmeasTOTep/Y0WsJwJ laCp5e2RIOTxnT+LC7QeoUmyWl0Z3nzX8f2RB8sWZ2KkrEyr/5l3aLSAoDCxI771Mhg4f4pw126yS Vxur3kxuA7FZP656OQMvrZN1/x0XvreZqP1wazjtEaMY2DO4b7B2CmDCrruvYBeNuGHyqBJcVpE1M UtAktjxHaiy7qSC6td+kIAfCowJaPpPR+DWIjKC3eXsRY/XvJiWL5HtZP6KZMSiDp7+8I0YaLge8C CMkgm2hroEHfVbLuMli0G4Trh56HA695OOOB6KpdrbDjeFrVSq4z8FouQjQNq675AS11BheP71VDf 9YNrbCcmg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l0B9S-00021A-1X; Thu, 14 Jan 2021 22:31:34 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:32c8:5054:ff:fe00:142]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l0B9O-0001hp-HV for linux-arm-kernel@lists.infradead.org; Thu, 14 Jan 2021 22:31:32 +0000 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?= 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-Disposition: inline In-Reply-To: <20210114202545.7wnc5ikeffc45xk5@pengutronix.de> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210114_173130_611396_3DBF98DD X-CRM114-Status: GOOD ( 24.44 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Andrew Lunn , Baruch Siach , linux-pwm@vger.kernel.org, Sascha Hauer , Bartosz Golaszewski , Chris Packham , Thierry Reding , linux-arm-kernel@lists.infradead.org, Thomas Petazzoni , linux-gpio@vger.kernel.org, Ralph Sennhauser , Lee Jones , Linus Walleij , Gregory Clement , Sebastian Hesselbarth Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Jan 14, 2021 at 09:25:45PM +0100, Uwe Kleine-K=F6nig 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=F6nig > > 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 documente= d. > > + */ > = > 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! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel