* [PATCH v10 0/2] PWM support for HiFive Unleashed @ 2019-03-18 11:47 Yash Shah 2019-03-18 11:47 ` [PATCH v10 1/2] pwm: sifive: Add DT documentation for SiFive PWM Controller Yash Shah 2019-03-18 11:47 ` [PATCH v10 2/2] pwm: sifive: Add a driver for SiFive SoC PWM Yash Shah 0 siblings, 2 replies; 6+ messages in thread From: Yash Shah @ 2019-03-18 11:47 UTC (permalink / raw) To: palmer, linux-pwm, linux-riscv Cc: thierry.reding, robh+dt, mark.rutland, devicetree, linux-kernel, sachin.ghadi, paul.walmsley, Yash Shah This patch series adds a PWM driver and DT documentation for HiFive Unleashed board. The patches are mostly based on Wesley's patch. v10 - Use DIV_ROUND_CLOSEST_ULL instead of div_u64_round - Change 'num' defination to u64 bit (in pwm_sifive_apply). - Remove the usage of pwm_get_state() v9 - Use appropriate bitfield macros - Add approx_period in pwm_sifive_ddata struct and related changes - Correct the eqn for calculation of frac (in pwm_sifive_apply) - Other minor fixes v8 - Typo corrections - Remove active_user and related code - Do not clear PWM_SIFIVE_PWMCFG_EN_ALWAYS - Other minor fixes v7 - Modify description of compatible property in DT documentation - Use mutex locks at appropriate places - Fix all bad line breaks - Allow enabling/disabling PWM only when the user is the only active user - Remove Deglitch logic - Other minor fixes v6 - Remove the global property 'sifive,period-ns' - Implement free and request callbacks to maintain user counts. - Add user_count member to struct pwm_sifive_ddata - Allow period change only if user_count is one - Add pwm_sifive_enable function to enable/disable PWM - Change calculation logic of frac (in pwm_sifive_apply) - Remove state correction - Remove pwm_sifive_xlate function - Clock to be enabled only when PWM is enabled - Other minor fixes v5 - Correct the order of compatible string properties - PWM state correction to be done always - Other minor fixes based upon feedback on v4 v4 - Rename macros with appropriate names - Remove unused macros - Rename struct sifive_pwm_device to struct pwm_sifive_ddata - Rename function prefix as per driver name - Other minor fixes based upon feedback on v3 v3 - Add a link to the reference manaul - Use appropriate apis for division operation - Add check for polarity - Enable clk before calling clk_get_rate - Other minor fixes based upon feedback on v2 V2 changed from V1: - Remove inclusion of dt-bindings/pwm/pwm.h - Remove artificial alignments - Replace ioread32/iowrite32 with readl/writel - Remove camelcase - Change dev_info to dev_dbg for unnecessary log - Correct typo in driver name - Remove use of of_match_ptr macro - Update the DT compatible strings and Add reference to a common versioning document Yash Shah (2): pwm: sifive: Add DT documentation for SiFive PWM Controller pwm: sifive: Add a driver for SiFive SoC PWM .../devicetree/bindings/pwm/pwm-sifive.txt | 33 ++ drivers/pwm/Kconfig | 11 + drivers/pwm/Makefile | 1 + drivers/pwm/pwm-sifive.c | 334 +++++++++++++++++++++ 4 files changed, 379 insertions(+) create mode 100644 Documentation/devicetree/bindings/pwm/pwm-sifive.txt create mode 100644 drivers/pwm/pwm-sifive.c -- 1.9.1 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v10 1/2] pwm: sifive: Add DT documentation for SiFive PWM Controller 2019-03-18 11:47 [PATCH v10 0/2] PWM support for HiFive Unleashed Yash Shah @ 2019-03-18 11:47 ` Yash Shah 2019-03-18 11:47 ` [PATCH v10 2/2] pwm: sifive: Add a driver for SiFive SoC PWM Yash Shah 1 sibling, 0 replies; 6+ messages in thread From: Yash Shah @ 2019-03-18 11:47 UTC (permalink / raw) To: palmer, linux-pwm, linux-riscv Cc: thierry.reding, robh+dt, mark.rutland, devicetree, linux-kernel, sachin.ghadi, paul.walmsley, Yash Shah DT documentation for PWM controller added. Signed-off-by: Wesley W. Terpstra <wesley@sifive.com> [Atish: Compatible string update] Signed-off-by: Atish Patra <atish.patra@wdc.com> Signed-off-by: Yash Shah <yash.shah@sifive.com> Reviewed-by: Rob Herring <robh@kernel.org> --- .../devicetree/bindings/pwm/pwm-sifive.txt | 33 ++++++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 Documentation/devicetree/bindings/pwm/pwm-sifive.txt diff --git a/Documentation/devicetree/bindings/pwm/pwm-sifive.txt b/Documentation/devicetree/bindings/pwm/pwm-sifive.txt new file mode 100644 index 0000000..36447e3 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/pwm-sifive.txt @@ -0,0 +1,33 @@ +SiFive PWM controller + +Unlike most other PWM controllers, the SiFive PWM controller currently only +supports one period for all channels in the PWM. All PWMs need to run at +the same period. The period also has significant restrictions on the values +it can achieve, which the driver rounds to the nearest achievable period. +PWM RTL that corresponds to the IP block version numbers can be found +here: + +https://github.com/sifive/sifive-blocks/tree/master/src/main/scala/devices/pwm + +Required properties: +- compatible: Should be "sifive,<chip>-pwm" and "sifive,pwm<version>". + Supported compatible strings are: "sifive,fu540-c000-pwm" for the SiFive + PWM v0 as integrated onto the SiFive FU540 chip, and "sifive,pwm0" for the + SiFive PWM v0 IP block with no chip integration tweaks. + Please refer to sifive-blocks-ip-versioning.txt for details. +- reg: physical base address and length of the controller's registers +- clocks: Should contain a clock identifier for the PWM's parent clock. +- #pwm-cells: Should be 3. See pwm.txt in this directory + for a description of the cell format. +- interrupts: one interrupt per PWM channel + +Examples: + +pwm: pwm@10020000 { + compatible = "sifive,fu540-c000-pwm", "sifive,pwm0"; + reg = <0x0 0x10020000 0x0 0x1000>; + clocks = <&tlclk>; + interrupt-parent = <&plic>; + interrupts = <42 43 44 45>; + #pwm-cells = <3>; +}; -- 1.9.1 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH v10 2/2] pwm: sifive: Add a driver for SiFive SoC PWM 2019-03-18 11:47 [PATCH v10 0/2] PWM support for HiFive Unleashed Yash Shah 2019-03-18 11:47 ` [PATCH v10 1/2] pwm: sifive: Add DT documentation for SiFive PWM Controller Yash Shah @ 2019-03-18 11:47 ` Yash Shah 2019-03-18 21:46 ` Uwe Kleine-König 1 sibling, 1 reply; 6+ messages in thread From: Yash Shah @ 2019-03-18 11:47 UTC (permalink / raw) To: palmer, linux-pwm, linux-riscv Cc: thierry.reding, robh+dt, mark.rutland, devicetree, linux-kernel, sachin.ghadi, paul.walmsley, Yash Shah Adds a PWM driver for PWM chip present in SiFive's HiFive Unleashed SoC. Signed-off-by: Wesley W. Terpstra <wesley@sifive.com> [Atish: Various fixes and code cleanup] Signed-off-by: Atish Patra <atish.patra@wdc.com> Signed-off-by: Yash Shah <yash.shah@sifive.com> --- drivers/pwm/Kconfig | 11 ++ drivers/pwm/Makefile | 1 + drivers/pwm/pwm-sifive.c | 334 +++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 346 insertions(+) create mode 100644 drivers/pwm/pwm-sifive.c diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig index a8f47df..4a61d1a 100644 --- a/drivers/pwm/Kconfig +++ b/drivers/pwm/Kconfig @@ -380,6 +380,17 @@ config PWM_SAMSUNG To compile this driver as a module, choose M here: the module will be called pwm-samsung. +config PWM_SIFIVE + tristate "SiFive PWM support" + depends on OF + depends on COMMON_CLK + depends on RISCV || COMPILE_TEST + help + Generic PWM framework driver for SiFive SoCs. + + To compile this driver as a module, choose M here: the module + will be called pwm-sifive. + config PWM_SPEAR tristate "STMicroelectronics SPEAr PWM support" depends on PLAT_SPEAR diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile index 9c676a0..30089ca 100644 --- a/drivers/pwm/Makefile +++ b/drivers/pwm/Makefile @@ -37,6 +37,7 @@ obj-$(CONFIG_PWM_RCAR) += pwm-rcar.o obj-$(CONFIG_PWM_RENESAS_TPU) += pwm-renesas-tpu.o obj-$(CONFIG_PWM_ROCKCHIP) += pwm-rockchip.o obj-$(CONFIG_PWM_SAMSUNG) += pwm-samsung.o +obj-$(CONFIG_PWM_SIFIVE) += pwm-sifive.o obj-$(CONFIG_PWM_SPEAR) += pwm-spear.o obj-$(CONFIG_PWM_STI) += pwm-sti.o obj-$(CONFIG_PWM_STM32) += pwm-stm32.o diff --git a/drivers/pwm/pwm-sifive.c b/drivers/pwm/pwm-sifive.c new file mode 100644 index 0000000..4b4d48e --- /dev/null +++ b/drivers/pwm/pwm-sifive.c @@ -0,0 +1,334 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2017-2018 SiFive + * For SiFive's PWM IP block documentation please refer Chapter 14 of + * Reference Manual : https://static.dev.sifive.com/FU540-C000-v1.0.pdf + * + * Limitations: + * - When changing both duty cycle and period, we cannot prevent in + * software that the output might produce a period with mixed + * settings (new period length and old duty cycle). + * - The hardware cannot generate a 100% duty cycle. + * - The hardware generates only inverted output. + */ +#include <linux/clk.h> +#include <linux/io.h> +#include <linux/module.h> +#include <linux/platform_device.h> +#include <linux/pwm.h> +#include <linux/slab.h> +#include <linux/bitfield.h> + +/* Register offsets */ +#define PWM_SIFIVE_PWMCFG 0x0 +#define PWM_SIFIVE_PWMCOUNT 0x8 +#define PWM_SIFIVE_PWMS 0x10 +#define PWM_SIFIVE_PWMCMP0 0x20 + +/* PWMCFG fields */ +#define PWM_SIFIVE_PWMCFG_SCALE GENMASK(3, 0) +#define PWM_SIFIVE_PWMCFG_STICKY BIT(8) +#define PWM_SIFIVE_PWMCFG_ZERO_CMP BIT(9) +#define PWM_SIFIVE_PWMCFG_DEGLITCH BIT(10) +#define PWM_SIFIVE_PWMCFG_EN_ALWAYS BIT(12) +#define PWM_SIFIVE_PWMCFG_EN_ONCE BIT(13) +#define PWM_SIFIVE_PWMCFG_CENTER BIT(16) +#define PWM_SIFIVE_PWMCFG_GANG BIT(24) +#define PWM_SIFIVE_PWMCFG_IP BIT(28) + +/* PWM_SIFIVE_SIZE_PWMCMP is used to calculate offset for pwmcmpX registers */ +#define PWM_SIFIVE_SIZE_PWMCMP 4 +#define PWM_SIFIVE_CMPWIDTH 16 +#define PWM_SIFIVE_DEFAULT_PERIOD 10000000 + +struct pwm_sifive_ddata { + struct pwm_chip chip; + struct mutex lock; /* lock to protect user_count */ + struct notifier_block notifier; + struct clk *clk; + void __iomem *regs; + unsigned int real_period; + unsigned int approx_period; + int user_count; +}; + +static inline +struct pwm_sifive_ddata *pwm_sifive_chip_to_ddata(struct pwm_chip *c) +{ + return container_of(c, struct pwm_sifive_ddata, chip); +} + +static int pwm_sifive_request(struct pwm_chip *chip, struct pwm_device *dev) +{ + struct pwm_sifive_ddata *pwm = pwm_sifive_chip_to_ddata(chip); + + mutex_lock(&pwm->lock); + pwm->user_count++; + mutex_unlock(&pwm->lock); + + return 0; +} + +static void pwm_sifive_free(struct pwm_chip *chip, struct pwm_device *dev) +{ + struct pwm_sifive_ddata *pwm = pwm_sifive_chip_to_ddata(chip); + + mutex_lock(&pwm->lock); + pwm->user_count--; + mutex_unlock(&pwm->lock); +} + +static void pwm_sifive_update_clock(struct pwm_sifive_ddata *pwm, + unsigned long rate) +{ + u32 val; + unsigned long long num; + /* + * The PWM unit is used with pwmzerocmp=0, so the only way to modify the + * period length is using pwmscale which provides the number of bits the + * counter is shifted before being feed to the comparators. A period + * lasts (1 << (PWM_SIFIVE_CMPWIDTH + pwmscale)) clock ticks. + * (1 << (PWM_SIFIVE_CMPWIDTH + scale)) * 10^9/rate = period + */ + unsigned long scale_pow = + div64_ul(pwm->approx_period * (u64)rate, NSEC_PER_SEC); + int scale = clamp(ilog2(scale_pow) - PWM_SIFIVE_CMPWIDTH, 0, 0xf); + + val = PWM_SIFIVE_PWMCFG_EN_ALWAYS | + FIELD_PREP(PWM_SIFIVE_PWMCFG_SCALE, scale); + writel(val, pwm->regs + PWM_SIFIVE_PWMCFG); + + /* As scale <= 15 the shift operation cannot overflow. */ + num = (unsigned long long)NSEC_PER_SEC << (PWM_SIFIVE_CMPWIDTH + scale); + pwm->real_period = div64_ul(num, rate); + dev_dbg(pwm->chip.dev, "New real_period = %u ns\n", pwm->real_period); +} + +static void pwm_sifive_get_state(struct pwm_chip *chip, struct pwm_device *dev, + struct pwm_state *state) +{ + struct pwm_sifive_ddata *pwm = pwm_sifive_chip_to_ddata(chip); + u32 duty, val; + + duty = readl(pwm->regs + PWM_SIFIVE_PWMCMP0 + + dev->hwpwm * PWM_SIFIVE_SIZE_PWMCMP); + + state->enabled = duty > 0; + + val = readl(pwm->regs + PWM_SIFIVE_PWMCFG); + if (!(val & PWM_SIFIVE_PWMCFG_EN_ALWAYS)) + state->enabled = false; + + state->period = pwm->real_period; + state->duty_cycle = + (u64)duty * pwm->real_period >> PWM_SIFIVE_CMPWIDTH; + state->polarity = PWM_POLARITY_INVERSED; +} + +static int pwm_sifive_enable(struct pwm_chip *chip, bool enable) +{ + struct pwm_sifive_ddata *pwm = pwm_sifive_chip_to_ddata(chip); + int ret; + + if (enable) { + ret = clk_enable(pwm->clk); + if (ret) { + dev_err(pwm->chip.dev, "Enable clk failed:%d\n", ret); + return ret; + } + } + + if (!enable) + clk_disable(pwm->clk); + + return 0; +} + +static int pwm_sifive_apply(struct pwm_chip *chip, struct pwm_device *dev, + struct pwm_state *state) +{ + struct pwm_sifive_ddata *pwm = pwm_sifive_chip_to_ddata(chip); + unsigned int duty_cycle; + u32 frac; + struct pwm_state cur_state; + bool enabled; + int ret = 0; + unsigned long long num; + + if (state->polarity != PWM_POLARITY_INVERSED) + return -EINVAL; + + ret = clk_enable(pwm->clk); + if (ret) { + dev_err(pwm->chip.dev, "Enable clk failed:%d\n", ret); + return ret; + } + + mutex_lock(&pwm->lock); + cur_state = dev->state; + enabled = cur_state.enabled; + + if (state->period != pwm->approx_period) { + if (pwm->user_count != 1) { + ret = -EBUSY; + goto exit; + } + pwm->approx_period = state->period; + pwm_sifive_update_clock(pwm, clk_get_rate(pwm->clk)); + } + + duty_cycle = state->duty_cycle; + if (!state->enabled) + duty_cycle = 0; + + num = (u64)duty_cycle * (1U << PWM_SIFIVE_CMPWIDTH); + frac = DIV_ROUND_CLOSEST_ULL(num, state->period); + /* The hardware cannot generate a 100% duty cycle */ + frac = min(frac, (1U << PWM_SIFIVE_CMPWIDTH) - 1); + + writel(frac, pwm->regs + PWM_SIFIVE_PWMCMP0 + + dev->hwpwm * PWM_SIFIVE_SIZE_PWMCMP); + + if (state->enabled != enabled) { + ret = pwm_sifive_enable(chip, state->enabled); + if (ret) + goto exit; + } + +exit: + clk_disable(pwm->clk); + mutex_unlock(&pwm->lock); + return ret; +} + +static const struct pwm_ops pwm_sifive_ops = { + .request = pwm_sifive_request, + .free = pwm_sifive_free, + .get_state = pwm_sifive_get_state, + .apply = pwm_sifive_apply, + .owner = THIS_MODULE, +}; + +static int pwm_sifive_clock_notifier(struct notifier_block *nb, + unsigned long event, void *data) +{ + struct clk_notifier_data *ndata = data; + struct pwm_sifive_ddata *pwm = + container_of(nb, struct pwm_sifive_ddata, notifier); + + if (event == POST_RATE_CHANGE) + pwm_sifive_update_clock(pwm, ndata->new_rate); + + return NOTIFY_OK; +} + +static int pwm_sifive_probe(struct platform_device *pdev) +{ + struct device *dev = &pdev->dev; + struct pwm_sifive_ddata *pwm; + struct pwm_chip *chip; + struct resource *res; + int ret; + + pwm = devm_kzalloc(dev, sizeof(*pwm), GFP_KERNEL); + if (!pwm) + return -ENOMEM; + + mutex_init(&pwm->lock); + chip = &pwm->chip; + chip->dev = dev; + chip->ops = &pwm_sifive_ops; + chip->of_pwm_n_cells = 3; + chip->base = -1; + chip->npwm = 4; + + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + pwm->regs = devm_ioremap_resource(dev, res); + if (IS_ERR(pwm->regs)) { + dev_err(dev, "Unable to map IO resources\n"); + return PTR_ERR(pwm->regs); + } + + pwm->clk = devm_clk_get(dev, NULL); + if (IS_ERR(pwm->clk)) { + if (PTR_ERR(pwm->clk) != -EPROBE_DEFER) + dev_err(dev, "Unable to find controller clock\n"); + return PTR_ERR(pwm->clk); + } + + ret = clk_prepare_enable(pwm->clk); + if (ret) { + dev_err(dev, "failed to enable clock for pwm: %d\n", ret); + return ret; + } + + /* Watch for changes to underlying clock frequency */ + pwm->notifier.notifier_call = pwm_sifive_clock_notifier; + ret = clk_notifier_register(pwm->clk, &pwm->notifier); + if (ret) { + dev_err(dev, "failed to register clock notifier: %d\n", ret); + goto disable_clk; + } + + /* Initialize PWM */ + pwm->approx_period = PWM_SIFIVE_DEFAULT_PERIOD; + pwm_sifive_update_clock(pwm, clk_get_rate(pwm->clk)); + + ret = pwmchip_add(chip); + if (ret < 0) { + dev_err(dev, "cannot register PWM: %d\n", ret); + goto unregister_clk; + } + + platform_set_drvdata(pdev, pwm); + dev_dbg(dev, "SiFive PWM chip registered %d PWMs\n", chip->npwm); + + return 0; + +unregister_clk: + clk_notifier_unregister(pwm->clk, &pwm->notifier); +disable_clk: + clk_disable_unprepare(pwm->clk); + + return ret; +} + +static int pwm_sifive_remove(struct platform_device *dev) +{ + struct pwm_sifive_ddata *pwm = platform_get_drvdata(dev); + int ret, ch; + bool is_enabled = false; + + ret = pwmchip_remove(&pwm->chip); + clk_notifier_unregister(pwm->clk, &pwm->notifier); + + for (ch = 0; ch < pwm->chip.npwm; ch++) { + if (pwm_is_enabled(&pwm->chip.pwms[ch])) { + is_enabled = true; + break; + } + } + if (is_enabled) + clk_disable(pwm->clk); + clk_unprepare(pwm->clk); + return ret; +} + +static const struct of_device_id pwm_sifive_of_match[] = { + { .compatible = "sifive,pwm0" }, + {}, +}; +MODULE_DEVICE_TABLE(of, pwm_sifive_of_match); + +static struct platform_driver pwm_sifive_driver = { + .probe = pwm_sifive_probe, + .remove = pwm_sifive_remove, + .driver = { + .name = "pwm-sifive", + .of_match_table = pwm_sifive_of_match, + }, +}; +module_platform_driver(pwm_sifive_driver); + +MODULE_DESCRIPTION("SiFive PWM driver"); +MODULE_LICENSE("GPL v2"); -- 1.9.1 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v10 2/2] pwm: sifive: Add a driver for SiFive SoC PWM 2019-03-18 11:47 ` [PATCH v10 2/2] pwm: sifive: Add a driver for SiFive SoC PWM Yash Shah @ 2019-03-18 21:46 ` Uwe Kleine-König 2019-03-19 7:22 ` Yash Shah 0 siblings, 1 reply; 6+ messages in thread From: Uwe Kleine-König @ 2019-03-18 21:46 UTC (permalink / raw) To: Yash Shah, Thierry Reding Cc: palmer, linux-pwm, linux-riscv, robh+dt, mark.rutland, devicetree, linux-kernel, sachin.ghadi, paul.walmsley, kernel Hello, [I put Thierry into To: because some remaining questions depend on his views] On Mon, Mar 18, 2019 at 05:17:14PM +0530, Yash Shah wrote: > Adds a PWM driver for PWM chip present in SiFive's HiFive Unleashed SoC. > > Signed-off-by: Wesley W. Terpstra <wesley@sifive.com> > [Atish: Various fixes and code cleanup] > Signed-off-by: Atish Patra <atish.patra@wdc.com> > Signed-off-by: Yash Shah <yash.shah@sifive.com> > --- > drivers/pwm/Kconfig | 11 ++ > drivers/pwm/Makefile | 1 + > drivers/pwm/pwm-sifive.c | 334 +++++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 346 insertions(+) > create mode 100644 drivers/pwm/pwm-sifive.c > > diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig > index a8f47df..4a61d1a 100644 > --- a/drivers/pwm/Kconfig > +++ b/drivers/pwm/Kconfig > @@ -380,6 +380,17 @@ config PWM_SAMSUNG > To compile this driver as a module, choose M here: the module > will be called pwm-samsung. > > +config PWM_SIFIVE > + tristate "SiFive PWM support" > + depends on OF > + depends on COMMON_CLK > + depends on RISCV || COMPILE_TEST > + help > + Generic PWM framework driver for SiFive SoCs. > + > + To compile this driver as a module, choose M here: the module > + will be called pwm-sifive. > + > config PWM_SPEAR > tristate "STMicroelectronics SPEAr PWM support" > depends on PLAT_SPEAR > diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile > index 9c676a0..30089ca 100644 > --- a/drivers/pwm/Makefile > +++ b/drivers/pwm/Makefile > @@ -37,6 +37,7 @@ obj-$(CONFIG_PWM_RCAR) += pwm-rcar.o > obj-$(CONFIG_PWM_RENESAS_TPU) += pwm-renesas-tpu.o > obj-$(CONFIG_PWM_ROCKCHIP) += pwm-rockchip.o > obj-$(CONFIG_PWM_SAMSUNG) += pwm-samsung.o > +obj-$(CONFIG_PWM_SIFIVE) += pwm-sifive.o > obj-$(CONFIG_PWM_SPEAR) += pwm-spear.o > obj-$(CONFIG_PWM_STI) += pwm-sti.o > obj-$(CONFIG_PWM_STM32) += pwm-stm32.o > diff --git a/drivers/pwm/pwm-sifive.c b/drivers/pwm/pwm-sifive.c > new file mode 100644 > index 0000000..4b4d48e > --- /dev/null > +++ b/drivers/pwm/pwm-sifive.c > @@ -0,0 +1,334 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (C) 2017-2018 SiFive > + * For SiFive's PWM IP block documentation please refer Chapter 14 of > + * Reference Manual : https://static.dev.sifive.com/FU540-C000-v1.0.pdf > + * > + * Limitations: > + * - When changing both duty cycle and period, we cannot prevent in > + * software that the output might produce a period with mixed > + * settings (new period length and old duty cycle). > + * - The hardware cannot generate a 100% duty cycle. > + * - The hardware generates only inverted output. > + */ > +#include <linux/clk.h> > +#include <linux/io.h> > +#include <linux/module.h> > +#include <linux/platform_device.h> > +#include <linux/pwm.h> > +#include <linux/slab.h> > +#include <linux/bitfield.h> > + > +/* Register offsets */ > +#define PWM_SIFIVE_PWMCFG 0x0 > +#define PWM_SIFIVE_PWMCOUNT 0x8 > +#define PWM_SIFIVE_PWMS 0x10 > +#define PWM_SIFIVE_PWMCMP0 0x20 > + > +/* PWMCFG fields */ > +#define PWM_SIFIVE_PWMCFG_SCALE GENMASK(3, 0) > +#define PWM_SIFIVE_PWMCFG_STICKY BIT(8) > +#define PWM_SIFIVE_PWMCFG_ZERO_CMP BIT(9) > +#define PWM_SIFIVE_PWMCFG_DEGLITCH BIT(10) > +#define PWM_SIFIVE_PWMCFG_EN_ALWAYS BIT(12) > +#define PWM_SIFIVE_PWMCFG_EN_ONCE BIT(13) > +#define PWM_SIFIVE_PWMCFG_CENTER BIT(16) > +#define PWM_SIFIVE_PWMCFG_GANG BIT(24) > +#define PWM_SIFIVE_PWMCFG_IP BIT(28) > + > +/* PWM_SIFIVE_SIZE_PWMCMP is used to calculate offset for pwmcmpX registers */ > +#define PWM_SIFIVE_SIZE_PWMCMP 4 > +#define PWM_SIFIVE_CMPWIDTH 16 > +#define PWM_SIFIVE_DEFAULT_PERIOD 10000000 > + > +struct pwm_sifive_ddata { > + struct pwm_chip chip; > + struct mutex lock; /* lock to protect user_count */ > + struct notifier_block notifier; > + struct clk *clk; > + void __iomem *regs; > + unsigned int real_period; > + unsigned int approx_period; > + int user_count; > +}; > + > +static inline > +struct pwm_sifive_ddata *pwm_sifive_chip_to_ddata(struct pwm_chip *c) > +{ > + return container_of(c, struct pwm_sifive_ddata, chip); > +} > + > +static int pwm_sifive_request(struct pwm_chip *chip, struct pwm_device *dev) > +{ > + struct pwm_sifive_ddata *pwm = pwm_sifive_chip_to_ddata(chip); > + > + mutex_lock(&pwm->lock); > + pwm->user_count++; > + mutex_unlock(&pwm->lock); > + > + return 0; > +} > + > +static void pwm_sifive_free(struct pwm_chip *chip, struct pwm_device *dev) > +{ > + struct pwm_sifive_ddata *pwm = pwm_sifive_chip_to_ddata(chip); > + > + mutex_lock(&pwm->lock); > + pwm->user_count--; > + mutex_unlock(&pwm->lock); > +} > + > +static void pwm_sifive_update_clock(struct pwm_sifive_ddata *pwm, > + unsigned long rate) > +{ > + u32 val; > + unsigned long long num; > + /* > + * The PWM unit is used with pwmzerocmp=0, so the only way to modify the > + * period length is using pwmscale which provides the number of bits the > + * counter is shifted before being feed to the comparators. A period > + * lasts (1 << (PWM_SIFIVE_CMPWIDTH + pwmscale)) clock ticks. > + * (1 << (PWM_SIFIVE_CMPWIDTH + scale)) * 10^9/rate = period > + */ > + unsigned long scale_pow = > + div64_ul(pwm->approx_period * (u64)rate, NSEC_PER_SEC); > + int scale = clamp(ilog2(scale_pow) - PWM_SIFIVE_CMPWIDTH, 0, 0xf); The situation here is as follows: The actual period length calculates as: period_length = (0x10000 << scale) / rate Consider a clk rate of 600 MHz, then the driver maps "requested period" to "actual period" as follows: if requested_period <= 218453 ns: // scale = 0 actual_period = 109226 ns else if requested_period <= 436906 ns: // scale = 1 actual_period = 218452 ns else if requested_period <= 873812 ns: // scale = 2 actual_period = 436904 ns ... else if requested_period <= 3579139413 ns: // scale = 14 actual_period = 1789569707 ns else: //scale = 15 actual_period = 3579139413 ns There is an obvious rounding issue: If 218452 ns are requested, we should end in the scale = 1 case for sure. (Similar issues exist for the other cases.) And then there are cases that are not that clear: What if 218000 ns are requested? Where should the line be drawn? Thierry? And what about long periods? The longest actually supported period length is around 3.5 seconds. What if a consumer requests 18 seconds? Where should the line be drawn when the driver is supposed to return -EINVAL (or -ERANGE)? Thierry? > + val = PWM_SIFIVE_PWMCFG_EN_ALWAYS | > + FIELD_PREP(PWM_SIFIVE_PWMCFG_SCALE, scale); > + writel(val, pwm->regs + PWM_SIFIVE_PWMCFG); Starting with this write the new period length might be active with the previous duty cycle. Is this worth a comment? I think the window where this can actually happen should be made as small as possible, so it would be great to first calculate both register values and then write them in two consecutive writels. > + /* As scale <= 15 the shift operation cannot overflow. */ > + num = (unsigned long long)NSEC_PER_SEC << (PWM_SIFIVE_CMPWIDTH + scale); > + pwm->real_period = div64_ul(num, rate); What about rounding here? I'd say use "round closest" instead of "round down". > + dev_dbg(pwm->chip.dev, "New real_period = %u ns\n", pwm->real_period); > +} > + > +static void pwm_sifive_get_state(struct pwm_chip *chip, struct pwm_device *dev, > + struct pwm_state *state) > +{ > + struct pwm_sifive_ddata *pwm = pwm_sifive_chip_to_ddata(chip); > + u32 duty, val; > + > + duty = readl(pwm->regs + PWM_SIFIVE_PWMCMP0 + > + dev->hwpwm * PWM_SIFIVE_SIZE_PWMCMP); > + > + state->enabled = duty > 0; > + > + val = readl(pwm->regs + PWM_SIFIVE_PWMCFG); > + if (!(val & PWM_SIFIVE_PWMCFG_EN_ALWAYS)) > + state->enabled = false; > + > + state->period = pwm->real_period; > + state->duty_cycle = > + (u64)duty * pwm->real_period >> PWM_SIFIVE_CMPWIDTH; > + state->polarity = PWM_POLARITY_INVERSED; If the PWM was configured for { .period = 1000000, .duty_cycle = 1000000, .enabled = false, ... }, .get_state still returns .duty_cycle = 0. Is this acceptable? > +} > + > +static int pwm_sifive_enable(struct pwm_chip *chip, bool enable) > +{ > + struct pwm_sifive_ddata *pwm = pwm_sifive_chip_to_ddata(chip); > + int ret; > + > + if (enable) { > + ret = clk_enable(pwm->clk); > + if (ret) { > + dev_err(pwm->chip.dev, "Enable clk failed:%d\n", ret); Space after : please. Also applies to the other error strings. > + return ret; > + } > + } > + > + if (!enable) > + clk_disable(pwm->clk); > + > + return 0; > +} > + > +static int pwm_sifive_apply(struct pwm_chip *chip, struct pwm_device *dev, > + struct pwm_state *state) > +{ > + struct pwm_sifive_ddata *pwm = pwm_sifive_chip_to_ddata(chip); I think it would be more common to call the struct pwm_device pointer "pwm" and the struct pwm_sifive_ddata pointer "ddata". "dev" is usually a pointer to a struct device. The other functions need the same adaption of course. > + unsigned int duty_cycle; > + u32 frac; > + struct pwm_state cur_state; > + bool enabled; > + int ret = 0; > + unsigned long long num; > + > + if (state->polarity != PWM_POLARITY_INVERSED) > + return -EINVAL; > + > + ret = clk_enable(pwm->clk); > + if (ret) { > + dev_err(pwm->chip.dev, "Enable clk failed:%d\n", ret); > + return ret; > + } > + > + mutex_lock(&pwm->lock); > + cur_state = dev->state; > + enabled = cur_state.enabled; > + > + if (state->period != pwm->approx_period) { > + if (pwm->user_count != 1) { > + ret = -EBUSY; > + goto exit; > + } > + pwm->approx_period = state->period; > + pwm_sifive_update_clock(pwm, clk_get_rate(pwm->clk)); > + } > + > + duty_cycle = state->duty_cycle; > + if (!state->enabled) > + duty_cycle = 0; > + > + num = (u64)duty_cycle * (1U << PWM_SIFIVE_CMPWIDTH); > + frac = DIV_ROUND_CLOSEST_ULL(num, state->period); > + /* The hardware cannot generate a 100% duty cycle */ > + frac = min(frac, (1U << PWM_SIFIVE_CMPWIDTH) - 1); > + > + writel(frac, pwm->regs + PWM_SIFIVE_PWMCMP0 + > + dev->hwpwm * PWM_SIFIVE_SIZE_PWMCMP); Here is another rounding question. Given that the period length can only be modified by factors of two there are cases where the real period is off by a factor of at least 1.4 which has an effect on the duty cycle. Consider again an input clk rate of 600 MHz, and: .duty_cycle = 109226 [ns] .period = 152916 [ns] We either have to go for real period = 109226 ns (as is currently implemented) or with 218452 ns. Which one should be chosen I already asked above. Here the question is (probably depending on the former question) how should the actual duty_cycle be calculated? > + if (state->enabled != enabled) { > + ret = pwm_sifive_enable(chip, state->enabled); > + if (ret) > + goto exit; This goto is a noop and so can be dropped. > + } > + > +exit: > + clk_disable(pwm->clk); > + mutex_unlock(&pwm->lock); > + return ret; > +} > + > +static const struct pwm_ops pwm_sifive_ops = { > + .request = pwm_sifive_request, > + .free = pwm_sifive_free, > + .get_state = pwm_sifive_get_state, > + .apply = pwm_sifive_apply, > + .owner = THIS_MODULE, > +}; > + > +static int pwm_sifive_clock_notifier(struct notifier_block *nb, > + unsigned long event, void *data) > +{ > + struct clk_notifier_data *ndata = data; > + struct pwm_sifive_ddata *pwm = > + container_of(nb, struct pwm_sifive_ddata, notifier); > + > + if (event == POST_RATE_CHANGE) > + pwm_sifive_update_clock(pwm, ndata->new_rate); > + > + return NOTIFY_OK; > +} > + > +static int pwm_sifive_probe(struct platform_device *pdev) > +{ > + struct device *dev = &pdev->dev; > + struct pwm_sifive_ddata *pwm; > + struct pwm_chip *chip; > + struct resource *res; > + int ret; > + > + pwm = devm_kzalloc(dev, sizeof(*pwm), GFP_KERNEL); > + if (!pwm) > + return -ENOMEM; > + > + mutex_init(&pwm->lock); > + chip = &pwm->chip; > + chip->dev = dev; > + chip->ops = &pwm_sifive_ops; > + chip->of_pwm_n_cells = 3; > + chip->base = -1; > + chip->npwm = 4; > + > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > + pwm->regs = devm_ioremap_resource(dev, res); > + if (IS_ERR(pwm->regs)) { > + dev_err(dev, "Unable to map IO resources\n"); > + return PTR_ERR(pwm->regs); > + } > + > + pwm->clk = devm_clk_get(dev, NULL); > + if (IS_ERR(pwm->clk)) { > + if (PTR_ERR(pwm->clk) != -EPROBE_DEFER) > + dev_err(dev, "Unable to find controller clock\n"); > + return PTR_ERR(pwm->clk); > + } > + > + ret = clk_prepare_enable(pwm->clk); > + if (ret) { > + dev_err(dev, "failed to enable clock for pwm: %d\n", ret); > + return ret; > + } > + > + /* Watch for changes to underlying clock frequency */ > + pwm->notifier.notifier_call = pwm_sifive_clock_notifier; > + ret = clk_notifier_register(pwm->clk, &pwm->notifier); Is it a problem when the notifier is called before pwmchip_add was called? Out of interest: Is a real problem addressed here? I.e.: Does the input clock actually change in practise? Also note that pwm_sifive_clock_notifier only adapts the period but not the duty cycle (any more). Given that a clk rate change affects the output, I wonder if the change should be declined if the pwm is running. > + if (ret) { > + dev_err(dev, "failed to register clock notifier: %d\n", ret); > + goto disable_clk; > + } > + > + /* Initialize PWM */ > + pwm->approx_period = PWM_SIFIVE_DEFAULT_PERIOD; > + pwm_sifive_update_clock(pwm, clk_get_rate(pwm->clk)); If the bootloader setup a display with a backlight driven by a PWM it would be ideal to not modify the already running hardware here. > + ret = pwmchip_add(chip); > + if (ret < 0) { > + dev_err(dev, "cannot register PWM: %d\n", ret); > + goto unregister_clk; > + } > + > + platform_set_drvdata(pdev, pwm); > + dev_dbg(dev, "SiFive PWM chip registered %d PWMs\n", chip->npwm); > + > + return 0; > + > +unregister_clk: > + clk_notifier_unregister(pwm->clk, &pwm->notifier); > +disable_clk: > + clk_disable_unprepare(pwm->clk); > + > + return ret; > +} > + > +static int pwm_sifive_remove(struct platform_device *dev) > +{ > + struct pwm_sifive_ddata *pwm = platform_get_drvdata(dev); > + int ret, ch; > + bool is_enabled = false; > + > + ret = pwmchip_remove(&pwm->chip); > + clk_notifier_unregister(pwm->clk, &pwm->notifier); > + > + for (ch = 0; ch < pwm->chip.npwm; ch++) { > + if (pwm_is_enabled(&pwm->chip.pwms[ch])) { Here is another consumer API function call. > + is_enabled = true; > + break; > + } > + } > + if (is_enabled) > + clk_disable(pwm->clk); > + clk_unprepare(pwm->clk); I think you're leaking a clk_enable here. The probe function does one unconditionally that is never undone. > + return ret; > +} > + > +static const struct of_device_id pwm_sifive_of_match[] = { > + { .compatible = "sifive,pwm0" }, > + {}, > +}; > +MODULE_DEVICE_TABLE(of, pwm_sifive_of_match); > + > +static struct platform_driver pwm_sifive_driver = { > + .probe = pwm_sifive_probe, > + .remove = pwm_sifive_remove, > + .driver = { > + .name = "pwm-sifive", > + .of_match_table = pwm_sifive_of_match, > + }, > +}; > +module_platform_driver(pwm_sifive_driver); > + > +MODULE_DESCRIPTION("SiFive PWM driver"); > +MODULE_LICENSE("GPL v2"); Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v10 2/2] pwm: sifive: Add a driver for SiFive SoC PWM 2019-03-18 21:46 ` Uwe Kleine-König @ 2019-03-19 7:22 ` Yash Shah 2019-03-19 8:09 ` Uwe Kleine-König 0 siblings, 1 reply; 6+ messages in thread From: Yash Shah @ 2019-03-19 7:22 UTC (permalink / raw) To: Uwe Kleine-König Cc: Thierry Reding, Palmer Dabbelt, linux-pwm, linux-riscv, robh+dt, mark.rutland, devicetree, linux-kernel, Sachin Ghadi, Paul Walmsley, kernel On Tue, Mar 19, 2019 at 3:16 AM Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote: > > Hello, > > [I put Thierry into To: because some remaining questions depend on his > views] > > On Mon, Mar 18, 2019 at 05:17:14PM +0530, Yash Shah wrote: > > Adds a PWM driver for PWM chip present in SiFive's HiFive Unleashed SoC. > > > > Signed-off-by: Wesley W. Terpstra <wesley@sifive.com> > > [Atish: Various fixes and code cleanup] > > Signed-off-by: Atish Patra <atish.patra@wdc.com> > > Signed-off-by: Yash Shah <yash.shah@sifive.com> > > --- > > drivers/pwm/Kconfig | 11 ++ > > drivers/pwm/Makefile | 1 + > > drivers/pwm/pwm-sifive.c | 334 +++++++++++++++++++++++++++++++++++++++++++++++ > > 3 files changed, 346 insertions(+) > > create mode 100644 drivers/pwm/pwm-sifive.c > > > > diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig > > index a8f47df..4a61d1a 100644 > > --- a/drivers/pwm/Kconfig > > +++ b/drivers/pwm/Kconfig > > @@ -380,6 +380,17 @@ config PWM_SAMSUNG > > To compile this driver as a module, choose M here: the module > > will be called pwm-samsung. > > > > +config PWM_SIFIVE > > + tristate "SiFive PWM support" > > + depends on OF > > + depends on COMMON_CLK > > + depends on RISCV || COMPILE_TEST > > + help > > + Generic PWM framework driver for SiFive SoCs. > > + > > + To compile this driver as a module, choose M here: the module > > + will be called pwm-sifive. > > + > > config PWM_SPEAR > > tristate "STMicroelectronics SPEAr PWM support" > > depends on PLAT_SPEAR > > diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile > > index 9c676a0..30089ca 100644 > > --- a/drivers/pwm/Makefile > > +++ b/drivers/pwm/Makefile > > @@ -37,6 +37,7 @@ obj-$(CONFIG_PWM_RCAR) += pwm-rcar.o > > obj-$(CONFIG_PWM_RENESAS_TPU) += pwm-renesas-tpu.o > > obj-$(CONFIG_PWM_ROCKCHIP) += pwm-rockchip.o > > obj-$(CONFIG_PWM_SAMSUNG) += pwm-samsung.o > > +obj-$(CONFIG_PWM_SIFIVE) += pwm-sifive.o > > obj-$(CONFIG_PWM_SPEAR) += pwm-spear.o > > obj-$(CONFIG_PWM_STI) += pwm-sti.o > > obj-$(CONFIG_PWM_STM32) += pwm-stm32.o > > diff --git a/drivers/pwm/pwm-sifive.c b/drivers/pwm/pwm-sifive.c > > new file mode 100644 > > index 0000000..4b4d48e > > --- /dev/null > > +++ b/drivers/pwm/pwm-sifive.c > > @@ -0,0 +1,334 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Copyright (C) 2017-2018 SiFive > > + * For SiFive's PWM IP block documentation please refer Chapter 14 of > > + * Reference Manual : https://static.dev.sifive.com/FU540-C000-v1.0.pdf > > + * > > + * Limitations: > > + * - When changing both duty cycle and period, we cannot prevent in > > + * software that the output might produce a period with mixed > > + * settings (new period length and old duty cycle). > > + * - The hardware cannot generate a 100% duty cycle. > > + * - The hardware generates only inverted output. > > + */ > > +#include <linux/clk.h> > > +#include <linux/io.h> > > +#include <linux/module.h> > > +#include <linux/platform_device.h> > > +#include <linux/pwm.h> > > +#include <linux/slab.h> > > +#include <linux/bitfield.h> > > + > > +/* Register offsets */ > > +#define PWM_SIFIVE_PWMCFG 0x0 > > +#define PWM_SIFIVE_PWMCOUNT 0x8 > > +#define PWM_SIFIVE_PWMS 0x10 > > +#define PWM_SIFIVE_PWMCMP0 0x20 > > + > > +/* PWMCFG fields */ > > +#define PWM_SIFIVE_PWMCFG_SCALE GENMASK(3, 0) > > +#define PWM_SIFIVE_PWMCFG_STICKY BIT(8) > > +#define PWM_SIFIVE_PWMCFG_ZERO_CMP BIT(9) > > +#define PWM_SIFIVE_PWMCFG_DEGLITCH BIT(10) > > +#define PWM_SIFIVE_PWMCFG_EN_ALWAYS BIT(12) > > +#define PWM_SIFIVE_PWMCFG_EN_ONCE BIT(13) > > +#define PWM_SIFIVE_PWMCFG_CENTER BIT(16) > > +#define PWM_SIFIVE_PWMCFG_GANG BIT(24) > > +#define PWM_SIFIVE_PWMCFG_IP BIT(28) > > + > > +/* PWM_SIFIVE_SIZE_PWMCMP is used to calculate offset for pwmcmpX registers */ > > +#define PWM_SIFIVE_SIZE_PWMCMP 4 > > +#define PWM_SIFIVE_CMPWIDTH 16 > > +#define PWM_SIFIVE_DEFAULT_PERIOD 10000000 > > + > > +struct pwm_sifive_ddata { > > + struct pwm_chip chip; > > + struct mutex lock; /* lock to protect user_count */ > > + struct notifier_block notifier; > > + struct clk *clk; > > + void __iomem *regs; > > + unsigned int real_period; > > + unsigned int approx_period; > > + int user_count; > > +}; > > + > > +static inline > > +struct pwm_sifive_ddata *pwm_sifive_chip_to_ddata(struct pwm_chip *c) > > +{ > > + return container_of(c, struct pwm_sifive_ddata, chip); > > +} > > + > > +static int pwm_sifive_request(struct pwm_chip *chip, struct pwm_device *dev) > > +{ > > + struct pwm_sifive_ddata *pwm = pwm_sifive_chip_to_ddata(chip); > > + > > + mutex_lock(&pwm->lock); > > + pwm->user_count++; > > + mutex_unlock(&pwm->lock); > > + > > + return 0; > > +} > > + > > +static void pwm_sifive_free(struct pwm_chip *chip, struct pwm_device *dev) > > +{ > > + struct pwm_sifive_ddata *pwm = pwm_sifive_chip_to_ddata(chip); > > + > > + mutex_lock(&pwm->lock); > > + pwm->user_count--; > > + mutex_unlock(&pwm->lock); > > +} > > + > > +static void pwm_sifive_update_clock(struct pwm_sifive_ddata *pwm, > > + unsigned long rate) > > +{ > > + u32 val; > > + unsigned long long num; > > + /* > > + * The PWM unit is used with pwmzerocmp=0, so the only way to modify the > > + * period length is using pwmscale which provides the number of bits the > > + * counter is shifted before being feed to the comparators. A period > > + * lasts (1 << (PWM_SIFIVE_CMPWIDTH + pwmscale)) clock ticks. > > + * (1 << (PWM_SIFIVE_CMPWIDTH + scale)) * 10^9/rate = period > > + */ > > + unsigned long scale_pow = > > + div64_ul(pwm->approx_period * (u64)rate, NSEC_PER_SEC); > > + int scale = clamp(ilog2(scale_pow) - PWM_SIFIVE_CMPWIDTH, 0, 0xf); > > The situation here is as follows: The actual period length calculates > as: > > period_length = (0x10000 << scale) / rate > > Consider a clk rate of 600 MHz, then the driver maps "requested period" > to "actual period" as follows: > > if requested_period <= 218453 ns: > // scale = 0 > actual_period = 109226 ns > else if requested_period <= 436906 ns: > // scale = 1 > actual_period = 218452 ns > else if requested_period <= 873812 ns: > // scale = 2 > actual_period = 436904 ns > ... > else if requested_period <= 3579139413 ns: > // scale = 14 > actual_period = 1789569707 ns > else: > //scale = 15 > actual_period = 3579139413 ns > > There is an obvious rounding issue: If 218452 ns are requested, we > should end in the scale = 1 case for sure. (Similar issues exist for the > other cases.) > > And then there are cases that are not that clear: What if 218000 ns are > requested? Where should the line be drawn? Thierry? > > And what about long periods? The longest actually supported period > length is around 3.5 seconds. What if a consumer requests 18 seconds? > Where should the line be drawn when the driver is supposed to return > -EINVAL (or -ERANGE)? Thierry? > > > + val = PWM_SIFIVE_PWMCFG_EN_ALWAYS | > > + FIELD_PREP(PWM_SIFIVE_PWMCFG_SCALE, scale); > > + writel(val, pwm->regs + PWM_SIFIVE_PWMCFG); > > Starting with this write the new period length might be active with the > previous duty cycle. Is this worth a comment? I think the window where > this can actually happen should be made as small as possible, so it > would be great to first calculate both register values and then write > them in two consecutive writels. The comment for this scenario has already been mentioned under the limitation on top of this driver. Anyway, I will try to implement your suggestion of consecutive writes > > > + /* As scale <= 15 the shift operation cannot overflow. */ > > + num = (unsigned long long)NSEC_PER_SEC << (PWM_SIFIVE_CMPWIDTH + scale); > > + pwm->real_period = div64_ul(num, rate); > > What about rounding here? I'd say use "round closest" instead of "round > down". > > > + dev_dbg(pwm->chip.dev, "New real_period = %u ns\n", pwm->real_period); > > +} > > + > > +static void pwm_sifive_get_state(struct pwm_chip *chip, struct pwm_device *dev, > > + struct pwm_state *state) > > +{ > > + struct pwm_sifive_ddata *pwm = pwm_sifive_chip_to_ddata(chip); > > + u32 duty, val; > > + > > + duty = readl(pwm->regs + PWM_SIFIVE_PWMCMP0 + > > + dev->hwpwm * PWM_SIFIVE_SIZE_PWMCMP); > > + > > + state->enabled = duty > 0; > > + > > + val = readl(pwm->regs + PWM_SIFIVE_PWMCFG); > > + if (!(val & PWM_SIFIVE_PWMCFG_EN_ALWAYS)) > > + state->enabled = false; > > + > > + state->period = pwm->real_period; > > + state->duty_cycle = > > + (u64)duty * pwm->real_period >> PWM_SIFIVE_CMPWIDTH; > > + state->polarity = PWM_POLARITY_INVERSED; > > If the PWM was configured for { .period = 1000000, .duty_cycle = > 1000000, .enabled = false, ... }, .get_state still returns .duty_cycle = > 0. Is this acceptable? > > > +} > > + > > +static int pwm_sifive_enable(struct pwm_chip *chip, bool enable) > > +{ > > + struct pwm_sifive_ddata *pwm = pwm_sifive_chip_to_ddata(chip); > > + int ret; > > + > > + if (enable) { > > + ret = clk_enable(pwm->clk); > > + if (ret) { > > + dev_err(pwm->chip.dev, "Enable clk failed:%d\n", ret); > > Space after : please. Also applies to the other error strings. Sure > > > + return ret; > > + } > > + } > > + > > + if (!enable) > > + clk_disable(pwm->clk); > > + > > + return 0; > > +} > > + > > +static int pwm_sifive_apply(struct pwm_chip *chip, struct pwm_device *dev, > > + struct pwm_state *state) > > +{ > > + struct pwm_sifive_ddata *pwm = pwm_sifive_chip_to_ddata(chip); > > I think it would be more common to call the struct pwm_device pointer > "pwm" and the struct pwm_sifive_ddata pointer "ddata". > "dev" is usually a pointer to a struct device. The other functions need > the same adaption of course. Ok. Will change that > > > + unsigned int duty_cycle; > > + u32 frac; > > + struct pwm_state cur_state; > > + bool enabled; > > + int ret = 0; > > + unsigned long long num; > > + > > + if (state->polarity != PWM_POLARITY_INVERSED) > > + return -EINVAL; > > + > > + ret = clk_enable(pwm->clk); > > + if (ret) { > > + dev_err(pwm->chip.dev, "Enable clk failed:%d\n", ret); > > + return ret; > > + } > > + > > + mutex_lock(&pwm->lock); > > + cur_state = dev->state; > > + enabled = cur_state.enabled; > > + > > + if (state->period != pwm->approx_period) { > > + if (pwm->user_count != 1) { > > + ret = -EBUSY; > > + goto exit; > > + } > > + pwm->approx_period = state->period; > > + pwm_sifive_update_clock(pwm, clk_get_rate(pwm->clk)); > > + } > > + > > + duty_cycle = state->duty_cycle; > > + if (!state->enabled) > > + duty_cycle = 0; > > + > > + num = (u64)duty_cycle * (1U << PWM_SIFIVE_CMPWIDTH); > > + frac = DIV_ROUND_CLOSEST_ULL(num, state->period); > > + /* The hardware cannot generate a 100% duty cycle */ > > + frac = min(frac, (1U << PWM_SIFIVE_CMPWIDTH) - 1); > > + > > + writel(frac, pwm->regs + PWM_SIFIVE_PWMCMP0 + > > + dev->hwpwm * PWM_SIFIVE_SIZE_PWMCMP); > > Here is another rounding question. Given that the period length can only > be modified by factors of two there are cases where the real period is > off by a factor of at least 1.4 which has an effect on the duty cycle. > Consider again an input clk rate of 600 MHz, and: > > .duty_cycle = 109226 [ns] > .period = 152916 [ns] > > We either have to go for real period = 109226 ns (as is currently > implemented) or with 218452 ns. Which one should be chosen I already > asked above. Here the question is (probably depending on the former > question) how should the actual duty_cycle be calculated? > > > + if (state->enabled != enabled) { > > + ret = pwm_sifive_enable(chip, state->enabled); > > + if (ret) > > + goto exit; > > This goto is a noop and so can be dropped. Sure > > > + } > > + > > +exit: > > + clk_disable(pwm->clk); > > + mutex_unlock(&pwm->lock); > > + return ret; > > +} > > + > > +static const struct pwm_ops pwm_sifive_ops = { > > + .request = pwm_sifive_request, > > + .free = pwm_sifive_free, > > + .get_state = pwm_sifive_get_state, > > + .apply = pwm_sifive_apply, > > + .owner = THIS_MODULE, > > +}; > > + > > +static int pwm_sifive_clock_notifier(struct notifier_block *nb, > > + unsigned long event, void *data) > > +{ > > + struct clk_notifier_data *ndata = data; > > + struct pwm_sifive_ddata *pwm = > > + container_of(nb, struct pwm_sifive_ddata, notifier); > > + > > + if (event == POST_RATE_CHANGE) > > + pwm_sifive_update_clock(pwm, ndata->new_rate); > > + > > + return NOTIFY_OK; > > +} > > + > > +static int pwm_sifive_probe(struct platform_device *pdev) > > +{ > > + struct device *dev = &pdev->dev; > > + struct pwm_sifive_ddata *pwm; > > + struct pwm_chip *chip; > > + struct resource *res; > > + int ret; > > + > > + pwm = devm_kzalloc(dev, sizeof(*pwm), GFP_KERNEL); > > + if (!pwm) > > + return -ENOMEM; > > + > > + mutex_init(&pwm->lock); > > + chip = &pwm->chip; > > + chip->dev = dev; > > + chip->ops = &pwm_sifive_ops; > > + chip->of_pwm_n_cells = 3; > > + chip->base = -1; > > + chip->npwm = 4; > > + > > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > > + pwm->regs = devm_ioremap_resource(dev, res); > > + if (IS_ERR(pwm->regs)) { > > + dev_err(dev, "Unable to map IO resources\n"); > > + return PTR_ERR(pwm->regs); > > + } > > + > > + pwm->clk = devm_clk_get(dev, NULL); > > + if (IS_ERR(pwm->clk)) { > > + if (PTR_ERR(pwm->clk) != -EPROBE_DEFER) > > + dev_err(dev, "Unable to find controller clock\n"); > > + return PTR_ERR(pwm->clk); > > + } > > + > > + ret = clk_prepare_enable(pwm->clk); > > + if (ret) { > > + dev_err(dev, "failed to enable clock for pwm: %d\n", ret); > > + return ret; > > + } > > + > > + /* Watch for changes to underlying clock frequency */ > > + pwm->notifier.notifier_call = pwm_sifive_clock_notifier; > > + ret = clk_notifier_register(pwm->clk, &pwm->notifier); > > Is it a problem when the notifier is called before pwmchip_add was > called? Out of interest: Is a real problem addressed here? I.e.: Does > the input clock actually change in practise? Also note that > pwm_sifive_clock_notifier only adapts the period but not the duty cycle > (any more). > > Given that a clk rate change affects the output, I wonder if the change > should be declined if the pwm is running. > > > + if (ret) { > > + dev_err(dev, "failed to register clock notifier: %d\n", ret); > > + goto disable_clk; > > + } > > + > > + /* Initialize PWM */ > > + pwm->approx_period = PWM_SIFIVE_DEFAULT_PERIOD; > > + pwm_sifive_update_clock(pwm, clk_get_rate(pwm->clk)); > > If the bootloader setup a display with a backlight driven by a PWM it > would be ideal to not modify the already running hardware here. Ok, will drop this initialization. > > > + ret = pwmchip_add(chip); > > + if (ret < 0) { > > + dev_err(dev, "cannot register PWM: %d\n", ret); > > + goto unregister_clk; > > + } > > + > > + platform_set_drvdata(pdev, pwm); > > + dev_dbg(dev, "SiFive PWM chip registered %d PWMs\n", chip->npwm); > > + > > + return 0; > > + > > +unregister_clk: > > + clk_notifier_unregister(pwm->clk, &pwm->notifier); > > +disable_clk: > > + clk_disable_unprepare(pwm->clk); > > + > > + return ret; > > +} > > + > > +static int pwm_sifive_remove(struct platform_device *dev) > > +{ > > + struct pwm_sifive_ddata *pwm = platform_get_drvdata(dev); > > + int ret, ch; > > + bool is_enabled = false; > > + > > + ret = pwmchip_remove(&pwm->chip); > > + clk_notifier_unregister(pwm->clk, &pwm->notifier); > > + > > + for (ch = 0; ch < pwm->chip.npwm; ch++) { > > + if (pwm_is_enabled(&pwm->chip.pwms[ch])) { > > Here is another consumer API function call. Will avoid using it. > > > + is_enabled = true; > > + break; > > + } > > + } > > + if (is_enabled) > > + clk_disable(pwm->clk); > > + clk_unprepare(pwm->clk); > > I think you're leaking a clk_enable here. The probe function does one > unconditionally that is never undone. Will use clk_disable_unprepare instead of clk_unprepare > > > + return ret; > > +} > > + > > +static const struct of_device_id pwm_sifive_of_match[] = { > > + { .compatible = "sifive,pwm0" }, > > + {}, > > +}; > > +MODULE_DEVICE_TABLE(of, pwm_sifive_of_match); > > + > > +static struct platform_driver pwm_sifive_driver = { > > + .probe = pwm_sifive_probe, > > + .remove = pwm_sifive_remove, > > + .driver = { > > + .name = "pwm-sifive", > > + .of_match_table = pwm_sifive_of_match, > > + }, > > +}; > > +module_platform_driver(pwm_sifive_driver); > > + > > +MODULE_DESCRIPTION("SiFive PWM driver"); > > +MODULE_LICENSE("GPL v2"); > > Best regards > Uwe > > -- > Pengutronix e.K. | Uwe Kleine-König | > Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v10 2/2] pwm: sifive: Add a driver for SiFive SoC PWM 2019-03-19 7:22 ` Yash Shah @ 2019-03-19 8:09 ` Uwe Kleine-König 0 siblings, 0 replies; 6+ messages in thread From: Uwe Kleine-König @ 2019-03-19 8:09 UTC (permalink / raw) To: Yash Shah Cc: Thierry Reding, Palmer Dabbelt, linux-pwm, linux-riscv, robh+dt, mark.rutland, devicetree, linux-kernel, Sachin Ghadi, Paul Walmsley, kernel On Tue, Mar 19, 2019 at 12:52:12PM +0530, Yash Shah wrote: > On Tue, Mar 19, 2019 at 3:16 AM Uwe Kleine-König > <u.kleine-koenig@pengutronix.de> wrote: > > On Mon, Mar 18, 2019 at 05:17:14PM +0530, Yash Shah wrote: > > > + val = PWM_SIFIVE_PWMCFG_EN_ALWAYS | > > > + FIELD_PREP(PWM_SIFIVE_PWMCFG_SCALE, scale); > > > + writel(val, pwm->regs + PWM_SIFIVE_PWMCFG); > > > > Starting with this write the new period length might be active with the > > previous duty cycle. Is this worth a comment? I think the window where > > this can actually happen should be made as small as possible, so it > > would be great to first calculate both register values and then write > > them in two consecutive writels. > > The comment for this scenario has already been mentioned under the > limitation on top of this driver. > Anyway, I will try to implement your suggestion of consecutive writes Yeah, the comment at the top is for general information about the shortcomings. The comment here would be to say: The problem occurs *here*. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-03-19 8:09 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-03-18 11:47 [PATCH v10 0/2] PWM support for HiFive Unleashed Yash Shah 2019-03-18 11:47 ` [PATCH v10 1/2] pwm: sifive: Add DT documentation for SiFive PWM Controller Yash Shah 2019-03-18 11:47 ` [PATCH v10 2/2] pwm: sifive: Add a driver for SiFive SoC PWM Yash Shah 2019-03-18 21:46 ` Uwe Kleine-König 2019-03-19 7:22 ` Yash Shah 2019-03-19 8:09 ` Uwe Kleine-König
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).