Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp463026yba; Thu, 9 May 2019 00:21:46 -0700 (PDT) X-Google-Smtp-Source: APXvYqw0DwjY9g3PNb4/myu14qWtq/hhxGVOYuYWdR7z58VAtmTtGPhFdU9BBMdssgNCoOoAPD64 X-Received: by 2002:a62:1897:: with SMTP id 145mr2990629pfy.122.1557386506582; Thu, 09 May 2019 00:21:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557386506; cv=none; d=google.com; s=arc-20160816; b=LfUPIN1sEh9rNfTD7uQkOVuTCfoBZIFZuA8UncCjtNe10u6823VOz1FdQvvS+/Qhcd EfYXeBp707h4nwhTI6mtWVBF8GuTO4+AgOQEdJHz4B/J6HmjrIxPsyt74rKNwDmWFpQR yvfxYBFnBBH5k0PZi/vcr7UMBweb8drovMStSyjRT9v/gmF4ihtOjlH5RcMf7OaHABFG Qm+Wf4zlk2emgR5WIcGP+ZB2uiQ1C+4xKzv8/aiPXtkDdiWTsU13qAzKjBq/vJtABoYU vQDZRnI5IRpuG/jOlcCPBLUmGYXDDpDie400r578AHZLCo69DFsENTT8jUqAyMud/zLv lQiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=TJHrToYqha8IP9itkAeqOyU7dcTM6OcolCF78VW5b8A=; b=pttM5MJklU/BlM/DvcsBwIfp3cQY+PqFCK0GH5HhND0Yzk5cMS7nRrvAGKbLtGRYfk B7OFfU0jFpAFjN2Qz2CCDOWARE6zZWR2MduuzVR51Kz6/zIb4pMtjvQj8T33AMI6dVPZ DD2MRUC62toNAWxXcWPgQpvI/FePd0PoQtUnNSJYMx6ijxOM63ooLQltj0QQb+YiEFTq ppqIvTOIPrKvD/AXisR+EyygiSOf5YWBFBkw+eOH1/Vi7xXCufRTUr5sxuei0iEjVjGR UDVYUTmpuNUYDS2PkLQ6X6cPAb5KTenwPkiFl9SRORzPmBFKOA4PWBOyVQZaDjvOgCbz 0JJQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 17si1827515pfw.148.2019.05.09.00.21.29; Thu, 09 May 2019 00:21:46 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726603AbfEIHUf (ORCPT + 99 others); Thu, 9 May 2019 03:20:35 -0400 Received: from metis.ext.pengutronix.de ([85.220.165.71]:45077 "EHLO metis.ext.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726525AbfEIHUf (ORCPT ); Thu, 9 May 2019 03:20:35 -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 1hOdLo-0001DW-QJ; Thu, 09 May 2019 09:20:20 +0200 Received: from ukl by pty.hi.pengutronix.de with local (Exim 4.89) (envelope-from ) id 1hOdLm-0007dA-Ad; Thu, 09 May 2019 09:20:18 +0200 Date: Thu, 9 May 2019 09:20:18 +0200 From: Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= To: Anson Huang Cc: "thierry.reding@gmail.com" , "robh+dt@kernel.org" , "mark.rutland@arm.com" , "shawnguo@kernel.org" , "s.hauer@pengutronix.de" , "kernel@pengutronix.de" , "festevam@gmail.com" , "linux@armlinux.org.uk" , "stefan@agner.ch" , "otavio@ossystems.com.br" , Leonard Crestez , Robin Gong , "linux-pwm@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , dl-linux-imx Subject: Re: [PATCH V11 2/5] pwm: Add i.MX TPM PWM driver support Message-ID: <20190509072018.cenumkgbysfba57l@pengutronix.de> References: <1554860547-18237-1-git-send-email-Anson.Huang@nxp.com> <1554860547-18237-3-git-send-email-Anson.Huang@nxp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1554860547-18237-3-git-send-email-Anson.Huang@nxp.com> User-Agent: NeoMutt/20170113 (1.7.2) 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-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Wed, Apr 10, 2019 at 01:47:40AM +0000, Anson Huang wrote: > i.MX7ULP has TPM(Low Power Timer/Pulse Width Modulation Module) > inside, it can support multiple PWM channels, all the channels > share same counter and period setting, but each channel can > configure its duty and polarity independently. > > There are several TPM modules in i.MX7ULP, the number of channels > in TPM modules are different, it can be read from each TPM module's > PARAM register. > > Signed-off-by: Anson Huang > --- > Changes since V10: > - remove channel private data which is ONLY for storing polarity, just read it from HW register; > - improve pwm_imx_tpm_round_state() and pwm_imx_tpm_apply_hw() parameters sequence; > - improve comments for polarity setting; > - refuse polarity change if PWM is active. > --- > drivers/pwm/Kconfig | 11 ++ > drivers/pwm/Makefile | 1 + > drivers/pwm/pwm-imx-tpm.c | 442 ++++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 454 insertions(+) > create mode 100644 drivers/pwm/pwm-imx-tpm.c > > diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig > index c054bd1..1311b540 100644 > --- a/drivers/pwm/Kconfig > +++ b/drivers/pwm/Kconfig > @@ -210,6 +210,17 @@ config PWM_IMX27 > To compile this driver as a module, choose M here: the module > will be called pwm-imx27. > > +config PWM_IMX_TPM > + tristate "i.MX TPM PWM support" > + depends on ARCH_MXC || COMPILE_TEST > + depends on HAVE_CLK && HAS_IOMEM > + help > + Generic PWM framework driver for i.MX7ULP TPM module, TPM's full > + name is Low Power Timer/Pulse Width Modulation Module. > + > + To compile this driver as a module, choose M here: the module > + will be called pwm-imx-tpm. > + > config PWM_JZ4740 > tristate "Ingenic JZ47xx PWM support" > depends on MACH_INGENIC > diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile > index 448825e..c368599 100644 > --- a/drivers/pwm/Makefile > +++ b/drivers/pwm/Makefile > @@ -19,6 +19,7 @@ obj-$(CONFIG_PWM_HIBVT) += pwm-hibvt.o > obj-$(CONFIG_PWM_IMG) += pwm-img.o > obj-$(CONFIG_PWM_IMX1) += pwm-imx1.o > obj-$(CONFIG_PWM_IMX27) += pwm-imx27.o > +obj-$(CONFIG_PWM_IMX_TPM) += pwm-imx-tpm.o > obj-$(CONFIG_PWM_JZ4740) += pwm-jz4740.o > obj-$(CONFIG_PWM_LP3943) += pwm-lp3943.o > obj-$(CONFIG_PWM_LPC18XX_SCT) += pwm-lpc18xx-sct.o > diff --git a/drivers/pwm/pwm-imx-tpm.c b/drivers/pwm/pwm-imx-tpm.c > new file mode 100644 > index 0000000..9349f4f > --- /dev/null > +++ b/drivers/pwm/pwm-imx-tpm.c > @@ -0,0 +1,442 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright 2018-2019 NXP. > + * > + * Limitations: > + * - The TPM counter and period counter are shared between > + * multiple channels, so all channels should use same period > + * settings. > + * - Changes to polarity cannot be latched at the time of the > + * next period start. > + * - Changing period and duty cycle together isn't atomic, > + * with the wrong timing it might happen that a period is > + * produced with old duty cycle but new period settings. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define PWM_IMX_TPM_PARAM 0x4 > +#define PWM_IMX_TPM_GLOBAL 0x8 > +#define PWM_IMX_TPM_SC 0x10 > +#define PWM_IMX_TPM_CNT 0x14 > +#define PWM_IMX_TPM_MOD 0x18 > +#define PWM_IMX_TPM_CnSC(n) (0x20 + (n) * 0x8) > +#define PWM_IMX_TPM_CnV(n) (0x24 + (n) * 0x8) > + > +#define PWM_IMX_TPM_PARAM_CHAN GENMASK(7, 0) > + > +#define PWM_IMX_TPM_SC_PS GENMASK(2, 0) > +#define PWM_IMX_TPM_SC_CMOD GENMASK(4, 3) > +#define PWM_IMX_TPM_SC_CMOD_INC_EVERY_CLK FIELD_PREP(PWM_IMX_TPM_SC_CMOD, 1) > +#define PWM_IMX_TPM_SC_CPWMS BIT(5) > + > +#define PWM_IMX_TPM_CnSC_CHF BIT(7) > +#define PWM_IMX_TPM_CnSC_MSB BIT(5) > +#define PWM_IMX_TPM_CnSC_MSA BIT(4) > + > +/* > + * The reference manual describes this field as two separate bits. The > + * semantic of the two bits isn't orthogonal though, so they are treated > + * together as a 2-bit field here. > + */ > +#define PWM_IMX_TPM_CnSC_ELS GENMASK(3, 2) > +#define PWM_IMX_TPM_CnSC_ELS_INVERSED FIELD_PREP(PWM_IMX_TPM_CnSC_ELS, 1) > +#define PWM_IMX_TPM_CnSC_ELS_NORMAL FIELD_PREP(PWM_IMX_TPM_CnSC_ELS, 2) > + > + > +#define PWM_IMX_TPM_MOD_WIDTH 16 > +#define PWM_IMX_TPM_MOD_MOD GENMASK(PWM_IMX_TPM_MOD_WIDTH - 1, 0) > + > +struct imx_tpm_pwm_chip { > + struct pwm_chip chip; > + struct clk *clk; > + void __iomem *base; > + struct mutex lock; > + u32 user_count; > + u32 enable_count; > + u32 real_period; > +}; > + > +struct imx_tpm_pwm_param { > + u8 prescale; > + u32 mod; > + u32 val; > +}; > + > +static inline struct imx_tpm_pwm_chip *to_imx_tpm_pwm_chip(struct pwm_chip *chip) > +{ > + return container_of(chip, struct imx_tpm_pwm_chip, chip); > +} > + Maybe add a comment here describing the purpose of this function. Something like: /* * This function determines for a given pwm_state *state that a consumer * might request the pwm_state *realstate that eventually is implemented * by the hardware and the necessary register values (in *p) to achive * this. */ I didn't revalidate all the maths in this driver but assume they are still right from the previous rounds. If you add the comment I suggested above, feel free to also add Reviewed-by: Uwe Kleine-K?nig > +static int pwm_imx_tpm_round_state(struct pwm_chip *chip, > + struct imx_tpm_pwm_param *p, > + struct pwm_state *real_state, > + struct pwm_state *state) > +{ > + struct imx_tpm_pwm_chip *tpm = to_imx_tpm_pwm_chip(chip); > + u32 rate, prescale, period_count, clock_unit; > + u64 tmp; > + > + rate = clk_get_rate(tpm->clk); > + tmp = (u64)state->period * rate; > + clock_unit = DIV_ROUND_CLOSEST_ULL(tmp, NSEC_PER_SEC); > + if (clock_unit <= PWM_IMX_TPM_MOD_MOD) > + prescale = 0; > + else > + prescale = ilog2(clock_unit) + 1 - PWM_IMX_TPM_MOD_WIDTH; > + > + if ((!FIELD_FIT(PWM_IMX_TPM_SC_PS, prescale))) > + return -ERANGE; It's a bit sad that my ideas for the core concerning a round_rate callback don't go down particularly well on Thierry's side. With the way I suggested we'd continue with prescale = 7 in this case. As of now there is no rule which kind of deviation to accept and which not. :-| (Nothing this patch can change of course.) Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-K?nig | Industrial Linux Solutions | http://www.pengutronix.de/ |