Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp3325518pxb; Tue, 12 Jan 2021 11:41:33 -0800 (PST) X-Google-Smtp-Source: ABdhPJw/7Ux2hqhTjvndA4QOMtnPtlZAbsrnXhUObrdvdxdqpKaqV1Pvawxs2h2IYs9GRtSSPStz X-Received: by 2002:a17:906:58f:: with SMTP id 15mr278069ejn.67.1610480493166; Tue, 12 Jan 2021 11:41:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610480493; cv=none; d=google.com; s=arc-20160816; b=haeHFcTMwVsRSs7Dd0u4l2UC9JyeqkuCVzEZUxo3nBko5/YCZ/Zs4oDytuJth+43h5 YbCD+9Yogy1GvHX2BuyOtrPsgaF9IvpYeud0M91F0dVSnYHV3QnSoPB9YPo4BAYfJCCj CojejGRg85J7Wt3boU+QtQDFfThh5Pa9/GfkyLLT1aMHPiBwhDktyZcuTT7/t4Gc+Jrj ty9BBrNzq3yfq4yWEP4Csv79NdhsKkHZS77dRvuGYtOwO+/3DDBw7raAQb1a3TXbn7EX Qoua8dpIvT4QOFsNIkqv/TsukI8rIP4YCvz3sE/B5jrzWaIeIZobUuJlZN5iViLscvwI FJ/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=cS9C/2XYzsbjYTZ0aJ7zWNeNcxrmFX1E76BcBqiBK3c=; b=H7wgZF5rJIEIWzYaOOEmMM71qbmDCO6vgRxqgKaIT3AxSqyivsJ+RC8tZ54ATq0y0F gSicFPGLo0zdgSA829O6JWKogQNu1yE9uT6dSUVpI9+UOlJEImWqlXECSX9whmo3Yuru Hgk+6MQcJeVpuzN6y0Gzc0U5IN8yszEFslmymTtIiSogrMHlw9w5waIEiptEg3puMZ00 h4Zk3DIHd35lV4QqxIKuqUmMdV37KRt8VRyMje+mpNQdm8ttvqiqLr8U0CEv8UGFQjqZ RZ2Meeb48q+d4C60pdasC3CCnCWRcugRMS+avP+FfVwWyC2e2HH4VIiehKXSdJt3vnvc t4FQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@kemnade.info header.s=20180802 header.b=INxkXnT9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q7si1836644edt.86.2021.01.12.11.41.06; Tue, 12 Jan 2021 11:41:33 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail header.i=@kemnade.info header.s=20180802 header.b=INxkXnT9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2393216AbhALTj4 (ORCPT + 99 others); Tue, 12 Jan 2021 14:39:56 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47680 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2392926AbhALTj4 (ORCPT ); Tue, 12 Jan 2021 14:39:56 -0500 Received: from mail.andi.de1.cc (mail.andi.de1.cc [IPv6:2a01:238:4321:8900:456f:ecd6:43e:202c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 90099C061575; Tue, 12 Jan 2021 11:39:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kemnade.info; s=20180802; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date:Sender :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=cS9C/2XYzsbjYTZ0aJ7zWNeNcxrmFX1E76BcBqiBK3c=; b=INxkXnT9LshF4+KSR5QhbpCd6w lqtWX/XifPwQgxQuq2fAMh21xFNLj76YmfvJsRsFYZ4DyFI3WpdSfakUWFPqDMegLbF4l65eYcaoR qpjCYCDtYybCUDwovkPsot+MueW/Ujjb59crkFGeS7GlicyC5fv/JPzuM1eKZXRIrXHY=; Received: from p200300ccff1586001a3da2fffebfd33a.dip0.t-ipconnect.de ([2003:cc:ff15:8600:1a3d:a2ff:febf:d33a] helo=aktux) by mail.andi.de1.cc with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1kzPVP-0003kv-Hc; Tue, 12 Jan 2021 20:39:03 +0100 Date: Tue, 12 Jan 2021 20:39:02 +0100 From: Andreas Kemnade To: Jonathan =?UTF-8?B?TmV1c2Now6RmZXI=?= Cc: linux-kernel@vger.kernel.org, Lee Jones , Rob Herring , Thierry Reding , Uwe =?UTF-8?B?S2xlaW5lLUvDtm5pZw==?= , Alessandro Zummo , Alexandre Belloni , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , Sam Ravnborg , Linus Walleij , Heiko Stuebner , Stephan Gerhold , Lubomir Rintel , Mark Brown , allen , Mauro Carvalho Chehab , "David S. Miller" , devicetree@vger.kernel.org, linux-pwm@vger.kernel.org, linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Heiko Stuebner , Josua Mayer , Arnd Bergmann , Daniel Palmer , Andy Shevchenko Subject: Re: [PATCH v7 4/7] pwm: ntxec: Add driver for PWM function in Netronix EC Message-ID: <20210112203902.4e196d11@aktux> In-Reply-To: <20210109180220.121511-5-j.neuschaefer@gmx.net> References: <20210109180220.121511-1-j.neuschaefer@gmx.net> <20210109180220.121511-5-j.neuschaefer@gmx.net> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.0 (-) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 9 Jan 2021 19:02:17 +0100 Jonathan Neusch=C3=A4fer wrote: > The Netronix EC provides a PWM output which is used for the backlight > on some ebook readers. This patches adds a driver for the PWM output. >=20 > The .get_state callback is not implemented, because the PWM state can't > be read back from the hardware. >=20 > Signed-off-by: Jonathan Neusch=C3=A4fer > --- > v7: > - no changes >=20 > v6: > - https://lore.kernel.org/lkml/20201208011000.3060239-5-j.neuschaefer@gmx= .net/ > - Move period / duty cycle setting code to a function > - Rename pwmchip_to_priv to ntxec_pwm_from_chip > - Set period and duty cycle only before enabling the output > - Mention that duty=3D0, enable=3D1 is assumed not to happen > - Interleave writes to the period and duty cycle registers, to minimize t= he > window of time that an inconsistent state is configured >=20 > v5: > - https://lore.kernel.org/lkml/20201201011513.1627028-5-j.neuschaefer@gmx= .net/ > - Avoid truncation of period and duty cycle to 32 bits > - Make ntxec_pwm_ops const > - Use regmap_multi_reg_write > - Add comment about get_state to ntxec_pwm_ops > - Add comments about non-atomicity of (period, duty cycle) update >=20 > v4: > - https://lore.kernel.org/lkml/20201122222739.1455132-5-j.neuschaefer@gmx= .net/ > - Document hardware/driver limitations > - Only accept normal polarity > - Fix a typo ("zone" -> "zero") > - change MAX_PERIOD_NS to 0xffff * 125 > - Clamp period to the maximum rather than returning an error > - Rename private struct pointer to priv > - Rearrage control flow in _probe to save a few lines and a temporary var= iable > - Add missing MODULE_ALIAS line > - Spell out ODM >=20 > v3: > - https://lore.kernel.org/lkml/20200924192455.2484005-5-j.neuschaefer@gmx= .net/ > - Relicense as GPLv2 or later > - Add email address to copyright line > - Remove OF compatible string and don't include linux/of_device.h > - Fix bogus ?: in return line > - Don't use a comma after sentinels > - Avoid ret |=3D ... pattern > - Move 8-bit register conversion to ntxec.h >=20 > v2: > - https://lore.kernel.org/lkml/20200905133230.1014581-6-j.neuschaefer@gmx= .net/ > - Various grammar and style improvements, as suggested by Uwe Kleine-K=C3= =B6nig, > Lee Jones, and Alexandre Belloni > - Switch to regmap > - Prefix registers with NTXEC_REG_ > - Add help text to the Kconfig option > - Use the .apply callback instead of the old API > - Add a #define for the time base (125ns) > - Don't change device state in .probe; this avoids multiple problems > - Rework division and overflow check logic to perform divisions in 32 bits > - Avoid setting duty cycle to zero, to work around a hardware quirk > --- > drivers/pwm/Kconfig | 8 ++ > drivers/pwm/Makefile | 1 + > drivers/pwm/pwm-ntxec.c | 182 ++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 191 insertions(+) > create mode 100644 drivers/pwm/pwm-ntxec.c >=20 > diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig > index 0937e1c047acb..a2830b8832b97 100644 > --- a/drivers/pwm/Kconfig > +++ b/drivers/pwm/Kconfig > @@ -393,6 +393,14 @@ config PWM_MXS > To compile this driver as a module, choose M here: the module > will be called pwm-mxs. >=20 > +config PWM_NTXEC > + tristate "Netronix embedded controller PWM support" > + depends on MFD_NTXEC > + help > + Say yes here if you want to support the PWM output of the embedded > + controller found in certain e-book readers designed by the original > + design manufacturer Netronix. > + > config PWM_OMAP_DMTIMER > tristate "OMAP Dual-Mode Timer PWM support" > depends on OF > diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile > index 18b89d7fd092a..7d97eb595bbef 100644 > --- a/drivers/pwm/Makefile > +++ b/drivers/pwm/Makefile > @@ -35,6 +35,7 @@ obj-$(CONFIG_PWM_MESON) +=3D pwm-meson.o > obj-$(CONFIG_PWM_MEDIATEK) +=3D pwm-mediatek.o > obj-$(CONFIG_PWM_MTK_DISP) +=3D pwm-mtk-disp.o > obj-$(CONFIG_PWM_MXS) +=3D pwm-mxs.o > +obj-$(CONFIG_PWM_NTXEC) +=3D pwm-ntxec.o > obj-$(CONFIG_PWM_OMAP_DMTIMER) +=3D pwm-omap-dmtimer.o > obj-$(CONFIG_PWM_PCA9685) +=3D pwm-pca9685.o > obj-$(CONFIG_PWM_PXA) +=3D pwm-pxa.o > diff --git a/drivers/pwm/pwm-ntxec.c b/drivers/pwm/pwm-ntxec.c > new file mode 100644 > index 0000000000000..1db30a6caa3ad > --- /dev/null > +++ b/drivers/pwm/pwm-ntxec.c > @@ -0,0 +1,182 @@ > +// SPDX-License-Identifier: GPL-2.0-or-later > +/* > + * The Netronix embedded controller is a microcontroller found in some > + * e-book readers designed by the original design manufacturer Netronix,= Inc. > + * It contains RTC, battery monitoring, system power management, and PWM > + * functionality. > + * > + * This driver implements PWM output. > + * > + * Copyright 2020 Jonathan Neusch=C3=A4fer > + * > + * Limitations: > + * - The get_state callback is not implemented, because the current stat= e of > + * the PWM output can't be read back from the hardware. > + * - The hardware can only generate normal polarity output. > + * - The period and duty cycle can't be changed together in one atomic a= ction. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > + > +struct ntxec_pwm { > + struct device *dev; > + struct ntxec *ec; > + struct pwm_chip chip; > +}; > + > +static struct ntxec_pwm *ntxec_pwm_from_chip(struct pwm_chip *chip) > +{ > + return container_of(chip, struct ntxec_pwm, chip); > +} > + > +#define NTXEC_REG_AUTO_OFF_HI 0xa1 > +#define NTXEC_REG_AUTO_OFF_LO 0xa2 > +#define NTXEC_REG_ENABLE 0xa3 > +#define NTXEC_REG_PERIOD_LOW 0xa4 > +#define NTXEC_REG_PERIOD_HIGH 0xa5 > +#define NTXEC_REG_DUTY_LOW 0xa6 > +#define NTXEC_REG_DUTY_HIGH 0xa7 > + > +/* > + * The time base used in the EC is 8MHz, or 125ns. Period and duty cycle= are > + * measured in this unit. > + */ > +#define TIME_BASE_NS 125 > + > +/* > + * The maximum input value (in nanoseconds) is determined by the time ba= se and > + * the range of the hardware registers that hold the converted value. > + * It fits into 32 bits, so we can do our calculations in 32 bits as wel= l. > + */ > +#define MAX_PERIOD_NS (TIME_BASE_NS * 0xffff) > + > +static int ntxec_pwm_set_raw_period_and_duty_cycle(struct pwm_chip *chip, > + int period, int duty) > +{ > + struct ntxec_pwm *priv =3D ntxec_pwm_from_chip(chip); > + > + /* > + * Changes to the period and duty cycle take effect as soon as the > + * corresponding low byte is written, so the hardware may be configured > + * to an inconsistent state after the period is written and before the > + * duty cycle is fully written. If, in such a case, the old duty cycle > + * is longer than the new period, the EC may output 100% for a moment. > + * > + * To minimize the time between the changes to period and duty cycle > + * taking effect, the writes are interleaved. > + */ > + > + struct reg_sequence regs[] =3D { > + { NTXEC_REG_PERIOD_HIGH, ntxec_reg8(period >> 8) }, > + { NTXEC_REG_DUTY_HIGH, ntxec_reg8(duty >> 8) }, > + { NTXEC_REG_PERIOD_LOW, ntxec_reg8(period) }, > + { NTXEC_REG_DUTY_LOW, ntxec_reg8(duty) }, > + }; > + > + return regmap_multi_reg_write(priv->ec->regmap, regs, ARRAY_SIZE(regs)); > +} > + > +static int ntxec_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm= _dev, > + const struct pwm_state *state) > +{ > + struct ntxec_pwm *priv =3D ntxec_pwm_from_chip(chip); > + unsigned int period, duty; > + int res; > + > + if (state->polarity !=3D PWM_POLARITY_NORMAL) > + return -EINVAL; > + > + period =3D min_t(u64, state->period, MAX_PERIOD_NS); > + duty =3D min_t(u64, state->duty_cycle, period); > + > + period /=3D TIME_BASE_NS; > + duty /=3D TIME_BASE_NS; > + > + /* > + * Writing a duty cycle of zero puts the device into a state where > + * writing a higher duty cycle doesn't result in the brightness that it > + * usually results in. This can be fixed by cycling the ENABLE register. > + * > + * As a workaround, write ENABLE=3D0 when the duty cycle is zero. > + * The case that something has previously set the duty cycle to zero > + * but ENABLE=3D1, is not handled. > + */ > + if (state->enabled && duty !=3D 0) { > + res =3D ntxec_pwm_set_raw_period_and_duty_cycle(chip, period, duty); > + if (res) > + return res; > + > + res =3D regmap_write(priv->ec->regmap, NTXEC_REG_ENABLE, ntxec_reg8(1)= ); > + if (res) > + return res; > + > + /* Disable the auto-off timer */ > + res =3D regmap_write(priv->ec->regmap, NTXEC_REG_AUTO_OFF_HI, ntxec_re= g8(0xff)); > + if (res) > + return res; > + > + return regmap_write(priv->ec->regmap, NTXEC_REG_AUTO_OFF_LO, ntxec_reg= 8(0xff)); > + } else { > + return regmap_write(priv->ec->regmap, NTXEC_REG_ENABLE, ntxec_reg8(0)); > + } > +} > + > +static const struct pwm_ops ntxec_pwm_ops =3D { > + .owner =3D THIS_MODULE, > + .apply =3D ntxec_pwm_apply, > + /* > + * No .get_state callback, because the current state cannot be read > + * back from the hardware. > + */ > +}; > + > +static int ntxec_pwm_probe(struct platform_device *pdev) > +{ > + struct ntxec *ec =3D dev_get_drvdata(pdev->dev.parent); > + struct ntxec_pwm *priv; > + struct pwm_chip *chip; > + > + priv =3D devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL); > + if (!priv) > + return -ENOMEM; > + > + priv->ec =3D ec; > + priv->dev =3D &pdev->dev; > + > + platform_set_drvdata(pdev, priv); > + > + chip =3D &priv->chip; > + chip->dev =3D &pdev->dev; Hmm, I needed chip->dev =3D &pdev->dev.parent to use the backlight example in patch 2/7. Not sure what the correct solution is. Maybe the pwm deserves its own devicetree node. Regards, Andreas