diff mbox series

[v5,4/7] pwm: ntxec: Add driver for PWM function in Netronix EC

Message ID 20201201011513.1627028-5-j.neuschaefer@gmx.net
State Changes Requested
Headers show
Series Netronix embedded controller driver for Kobo and Tolino ebook readers | expand

Commit Message

Jonathan Neuschäfer Dec. 1, 2020, 1:15 a.m. UTC
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.

The .get_state callback is not implemented, because the PWM state can't
be read back from the hardware.

Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
---

v5:
- 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

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 variable
- Add missing MODULE_ALIAS line
- Spell out ODM

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 |= ... pattern
- Move 8-bit register conversion to ntxec.h

v2:
- https://lore.kernel.org/lkml/20200905133230.1014581-6-j.neuschaefer@gmx.net/
- Various grammar and style improvements, as suggested by Uwe Kleine-König,
  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 | 173 ++++++++++++++++++++++++++++++++++++++++
 3 files changed, 182 insertions(+)
 create mode 100644 drivers/pwm/pwm-ntxec.c

--
2.29.2

Comments

Uwe Kleine-König Dec. 1, 2020, 7:20 a.m. UTC | #1
Hello Jonathan,

very nice driver, just a few minor comments below.

On Tue, Dec 01, 2020 at 02:15:10AM +0100, Jonathan Neuschäfer wrote:
> +static struct ntxec_pwm *pwmchip_to_priv(struct pwm_chip *chip)

a function prefix would be great here, I'd pick ntxec_pwm_from_chip as
name.

> +{
> +	return container_of(chip, struct ntxec_pwm, chip);
> +}
> +
> +[...]
> +static int ntxec_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm_dev,
> +			   const struct pwm_state *state)
> +{
> +	struct ntxec_pwm *priv = pwmchip_to_priv(pwm_dev->chip);
> +	unsigned int period, duty;
> +	struct reg_sequence regs[] = {
> +		{ NTXEC_REG_PERIOD_HIGH },
> +		{ NTXEC_REG_PERIOD_LOW },
> +		{ NTXEC_REG_DUTY_HIGH },
> +		{ NTXEC_REG_DUTY_LOW }
> +	};
> +	int res;
> +
> +	if (state->polarity != PWM_POLARITY_NORMAL)
> +		return -EINVAL;
> +
> +	period = min_t(u64, state->period, MAX_PERIOD_NS);
> +	duty   = min_t(u64, state->duty_cycle, period);

I'm not a big fan of aligning =. (As if you have to add a longer
variable you have to realign all otherwise unrelated lines.) But that's
subjective and it's up to you if you want to change this.

> +	period /= TIME_BASE_NS;
> +	duty   /= TIME_BASE_NS;
> +
> +	/*
> +	 * 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.
> +	 */
> +
> +	regs[0].def = ntxec_reg8(period >> 8);
> +	regs[1].def = ntxec_reg8(period);
> +	regs[2].def = ntxec_reg8(duty >> 8);
> +	regs[3].def = ntxec_reg8(duty);

You could even minimize the window by changing the order here to

	NTXEC_REG_PERIOD_HIGH
	NTXEC_REG_DUTY_HIGH
	NTXEC_REG_PERIOD_LOW
	NTXEC_REG_DUTY_LOW

but it gets less readable. Maybe move that to a function to have the
reg_sequence and the actual write nearer together? Or somehow name the
indexes to make it more obvious?

> +	res = regmap_multi_reg_write(priv->ec->regmap, regs, ARRAY_SIZE(regs));
> +	if (res)
> +		return res;
> +
> +	/*
> +	 * 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=0 when the duty cycle is zero.

If the device already has duty_cycle = 0 but ENABLE = 1, you might get
a failure. But I guess this doesn't need addressing in the code. But
maybe point it out in a comment?

> +	 */
> +	if (state->enabled && duty != 0) {
> +		res = regmap_write(priv->ec->regmap, NTXEC_REG_ENABLE, ntxec_reg8(1));
> +		if (res)
> +			return res;
> +
> +		/* Disable the auto-off timer */
> +		res = regmap_write(priv->ec->regmap, NTXEC_REG_AUTO_OFF_HI, ntxec_reg8(0xff));
> +		if (res)
> +			return res;
> +
> +		return regmap_write(priv->ec->regmap, NTXEC_REG_AUTO_OFF_LO, ntxec_reg8(0xff));

Given that you cannot read back period and duty anyhow: Does it make
sense to write these only if (state->enabled && duty != 0)?

> +	} else {
> +		return regmap_write(priv->ec->regmap, NTXEC_REG_ENABLE, ntxec_reg8(0));
> +	}
> +}

Thanks
Uwe
Jonathan Neuschäfer Dec. 1, 2020, 1:22 p.m. UTC | #2
On Tue, Dec 01, 2020 at 08:20:26AM +0100, Uwe Kleine-König wrote:
> Hello Jonathan,
> 
> very nice driver, just a few minor comments below.
> 
> On Tue, Dec 01, 2020 at 02:15:10AM +0100, Jonathan Neuschäfer wrote:
> > +static struct ntxec_pwm *pwmchip_to_priv(struct pwm_chip *chip)
> 
> a function prefix would be great here, I'd pick ntxec_pwm_from_chip as
> name.

Good point, will do.

> 
> > +{
> > +	return container_of(chip, struct ntxec_pwm, chip);
> > +}
> > +
> > +[...]
> > +static int ntxec_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm_dev,
> > +			   const struct pwm_state *state)
> > +{
> > +	struct ntxec_pwm *priv = pwmchip_to_priv(pwm_dev->chip);
> > +	unsigned int period, duty;
> > +	struct reg_sequence regs[] = {
> > +		{ NTXEC_REG_PERIOD_HIGH },
> > +		{ NTXEC_REG_PERIOD_LOW },
> > +		{ NTXEC_REG_DUTY_HIGH },
> > +		{ NTXEC_REG_DUTY_LOW }
> > +	};
> > +	int res;
> > +
> > +	if (state->polarity != PWM_POLARITY_NORMAL)
> > +		return -EINVAL;
> > +
> > +	period = min_t(u64, state->period, MAX_PERIOD_NS);
> > +	duty   = min_t(u64, state->duty_cycle, period);
> 
> I'm not a big fan of aligning =. (As if you have to add a longer
> variable you have to realign all otherwise unrelated lines.) But that's
> subjective and it's up to you if you want to change this.

In this case, I thought it helps the readability, because the lines are
quite similar.

> > +	period /= TIME_BASE_NS;
> > +	duty   /= TIME_BASE_NS;

Here, I did it because I had already aligned the previous two lines.

> > +
> > +	/*
> > +	 * 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.
> > +	 */
> > +
> > +	regs[0].def = ntxec_reg8(period >> 8);
> > +	regs[1].def = ntxec_reg8(period);
> > +	regs[2].def = ntxec_reg8(duty >> 8);
> > +	regs[3].def = ntxec_reg8(duty);
> 
> You could even minimize the window by changing the order here to
> 
> 	NTXEC_REG_PERIOD_HIGH
> 	NTXEC_REG_DUTY_HIGH
> 	NTXEC_REG_PERIOD_LOW
> 	NTXEC_REG_DUTY_LOW

Good idea, but I'm not sure if the EC handles this kind of interleaving
correctly.

> but it gets less readable. Maybe move that to a function to have the
> reg_sequence and the actual write nearer together?

Indeed, a separate function would keep register names and values
together (without resorting to declarations-after-statements).

> Or somehow name the indexes to make it more obvious?

Too much unnecessary complexity, IMHO.

> > +	res = regmap_multi_reg_write(priv->ec->regmap, regs, ARRAY_SIZE(regs));
> > +	if (res)
> > +		return res;
> > +
> > +	/*
> > +	 * 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=0 when the duty cycle is zero.
> 
> If the device already has duty_cycle = 0 but ENABLE = 1, you might get
> a failure. But I guess this doesn't need addressing in the code. But
> maybe point it out in a comment?

Good point. I'll add something to the comment.

> > +	 */
> > +	if (state->enabled && duty != 0) {
> > +		res = regmap_write(priv->ec->regmap, NTXEC_REG_ENABLE, ntxec_reg8(1));
> > +		if (res)
> > +			return res;
> > +
> > +		/* Disable the auto-off timer */
> > +		res = regmap_write(priv->ec->regmap, NTXEC_REG_AUTO_OFF_HI, ntxec_reg8(0xff));
> > +		if (res)
> > +			return res;
> > +
> > +		return regmap_write(priv->ec->regmap, NTXEC_REG_AUTO_OFF_LO, ntxec_reg8(0xff));
> 
> Given that you cannot read back period and duty anyhow: Does it make
> sense to write these only if (state->enabled && duty != 0)?

I think it does.


Thanks,
Jonathan
diff mbox series

Patch

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 63be5362fd3a5..815f329ed5b46 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -350,6 +350,14 @@  config PWM_MXS
 	  To compile this driver as a module, choose M here: the module
 	  will be called pwm-mxs.

+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 cbdcd55d69eef..1deb29e6ae8e5 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -32,6 +32,7 @@  obj-$(CONFIG_PWM_MESON)		+= pwm-meson.o
 obj-$(CONFIG_PWM_MEDIATEK)	+= pwm-mediatek.o
 obj-$(CONFIG_PWM_MTK_DISP)	+= pwm-mtk-disp.o
 obj-$(CONFIG_PWM_MXS)		+= pwm-mxs.o
+obj-$(CONFIG_PWM_NTXEC)		+= pwm-ntxec.o
 obj-$(CONFIG_PWM_OMAP_DMTIMER)	+= pwm-omap-dmtimer.o
 obj-$(CONFIG_PWM_PCA9685)	+= pwm-pca9685.o
 obj-$(CONFIG_PWM_PXA)		+= pwm-pxa.o
diff --git a/drivers/pwm/pwm-ntxec.c b/drivers/pwm/pwm-ntxec.c
new file mode 100644
index 0000000000000..d36c8f8c0a958
--- /dev/null
+++ b/drivers/pwm/pwm-ntxec.c
@@ -0,0 +1,173 @@ 
+// 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äfer <j.neuschaefer@gmx.net>
+ *
+ * Limitations:
+ * - The get_state callback is not implemented, because the current state 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 action.
+ */
+
+#include <linux/mfd/ntxec.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/pwm.h>
+#include <linux/regmap.h>
+#include <linux/types.h>
+
+struct ntxec_pwm {
+	struct device *dev;
+	struct ntxec *ec;
+	struct pwm_chip chip;
+};
+
+static struct ntxec_pwm *pwmchip_to_priv(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 base 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 well.
+ */
+#define MAX_PERIOD_NS (TIME_BASE_NS * 0xffff)
+
+static int ntxec_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm_dev,
+			   const struct pwm_state *state)
+{
+	struct ntxec_pwm *priv = pwmchip_to_priv(pwm_dev->chip);
+	unsigned int period, duty;
+	struct reg_sequence regs[] = {
+		{ NTXEC_REG_PERIOD_HIGH },
+		{ NTXEC_REG_PERIOD_LOW },
+		{ NTXEC_REG_DUTY_HIGH },
+		{ NTXEC_REG_DUTY_LOW }
+	};
+	int res;
+
+	if (state->polarity != PWM_POLARITY_NORMAL)
+		return -EINVAL;
+
+	period = min_t(u64, state->period, MAX_PERIOD_NS);
+	duty   = min_t(u64, state->duty_cycle, period);
+
+	period /= TIME_BASE_NS;
+	duty   /= TIME_BASE_NS;
+
+	/*
+	 * 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.
+	 */
+
+	regs[0].def = ntxec_reg8(period >> 8);
+	regs[1].def = ntxec_reg8(period);
+	regs[2].def = ntxec_reg8(duty >> 8);
+	regs[3].def = ntxec_reg8(duty);
+
+	res = regmap_multi_reg_write(priv->ec->regmap, regs, ARRAY_SIZE(regs));
+	if (res)
+		return res;
+
+	/*
+	 * 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=0 when the duty cycle is zero.
+	 */
+	if (state->enabled && duty != 0) {
+		res = regmap_write(priv->ec->regmap, NTXEC_REG_ENABLE, ntxec_reg8(1));
+		if (res)
+			return res;
+
+		/* Disable the auto-off timer */
+		res = regmap_write(priv->ec->regmap, NTXEC_REG_AUTO_OFF_HI, ntxec_reg8(0xff));
+		if (res)
+			return res;
+
+		return regmap_write(priv->ec->regmap, NTXEC_REG_AUTO_OFF_LO, ntxec_reg8(0xff));
+	} else {
+		return regmap_write(priv->ec->regmap, NTXEC_REG_ENABLE, ntxec_reg8(0));
+	}
+}
+
+static const struct pwm_ops ntxec_pwm_ops = {
+	.owner = THIS_MODULE,
+	.apply = 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 = dev_get_drvdata(pdev->dev.parent);
+	struct ntxec_pwm *priv;
+	struct pwm_chip *chip;
+
+	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	priv->ec = ec;
+	priv->dev = &pdev->dev;
+
+	platform_set_drvdata(pdev, priv);
+
+	chip = &priv->chip;
+	chip->dev = &pdev->dev;
+	chip->ops = &ntxec_pwm_ops;
+	chip->base = -1;
+	chip->npwm = 1;
+
+	return pwmchip_add(chip);
+}
+
+static int ntxec_pwm_remove(struct platform_device *pdev)
+{
+	struct ntxec_pwm *priv = platform_get_drvdata(pdev);
+	struct pwm_chip *chip = &priv->chip;
+
+	return pwmchip_remove(chip);
+}
+
+static struct platform_driver ntxec_pwm_driver = {
+	.driver = {
+		.name = "ntxec-pwm",
+	},
+	.probe = ntxec_pwm_probe,
+	.remove = ntxec_pwm_remove,
+};
+module_platform_driver(ntxec_pwm_driver);
+
+MODULE_AUTHOR("Jonathan Neuschäfer <j.neuschaefer@gmx.net>");
+MODULE_DESCRIPTION("PWM driver for Netronix EC");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:ntxec-pwm");