| Message ID | 20201201011513.1627028-5-j.neuschaefer@gmx.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Netronix embedded controller driver for Kobo and Tolino ebook readers | expand |
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
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 --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");
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