On 6/25/21 2:19 AM, Uwe Kleine-König wrote: > On Fri, May 28, 2021 at 05:45:22PM -0400, Sean Anderson wrote: >> This adds PWM support for Xilinx LogiCORE IP AXI soft timers commonly >> found on Xilinx FPGAs. At the moment clock control is very basic: we >> just enable the clock during probe and pin the frequency. In the future, >> someone could add support for disabling the clock when not in use. >> >> This driver was written with reference to Xilinx DS764 for v1.03.a [1]. >> >> [1] https://www.xilinx.com/support/documentation/ip_documentation/axi_timer/v1_03_a/axi_timer_ds764.pdf >> >> Signed-off-by: Sean Anderson <sean.anderson@xxxxxxxx> >> --- >> >> Changes in v4: >> - Remove references to properties which are not good enough for Linux. >> - Don't use volatile in read/write replacements. Some arches have it and >> some don't. >> - Put common timer properties into their own struct to better reuse >> code. >> >> Changes in v3: >> - Add clockevent and clocksource support >> - Rewrite probe to only use a device_node, since timers may need to be >> initialized before we have proper devices. This does bloat the code a bit >> since we can no longer rely on helpers such as dev_err_probe. We also >> cannot rely on device resources being free'd on failure, so we must free >> them manually. >> - We now access registers through xilinx_timer_(read|write). This allows us >> to deal with endianness issues, as originally seen in the microblaze >> driver. CAVEAT EMPTOR: I have not tested this on big-endian! >> - Remove old microblaze driver >> >> Changes in v2: >> - Don't compile this module by default for arm64 >> - Add dependencies on COMMON_CLK and HAS_IOMEM >> - Add comment explaining why we depend on !MICROBLAZE >> - Add comment describing device >> - Rename TCSR_(SET|CLEAR) to TCSR_RUN_(SET|CLEAR) >> - Use NSEC_TO_SEC instead of defining our own >> - Use TCSR_RUN_MASK to check if the PWM is enabled, as suggested by Uwe >> - Cast dividends to u64 to avoid overflow >> - Check for over- and underflow when calculating TLR >> - Set xilinx_pwm_ops.owner >> - Don't set pwmchip.base to -1 >> - Check range of xlnx,count-width >> - Ensure the clock is always running when the pwm is registered >> - Remove debugfs file :l >> - Report errors with dev_error_probe >> >> drivers/mfd/Makefile | 2 +- >> drivers/pwm/Kconfig | 12 +++ >> drivers/pwm/Makefile | 1 + >> drivers/pwm/pwm-xilinx.c | 219 +++++++++++++++++++++++++++++++++++++++ >> 4 files changed, 233 insertions(+), 1 deletion(-) >> create mode 100644 drivers/pwm/pwm-xilinx.c >> >> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile >> index f0f9fbdde7dc..89769affe251 100644 >> --- a/drivers/mfd/Makefile >> +++ b/drivers/mfd/Makefile >> @@ -269,6 +269,6 @@ obj-$(CONFIG_SGI_MFD_IOC3) += ioc3.o >> obj-$(CONFIG_MFD_SIMPLE_MFD_I2C) += simple-mfd-i2c.o >> obj-$(CONFIG_MFD_INTEL_M10_BMC) += intel-m10-bmc.o >> >> -ifneq ($(CONFIG_XILINX_TIMER),) >> +ifneq ($(CONFIG_PWM_XILINX)$(CONFIG_XILINX_TIMER),) >> obj-y += xilinx-timer.o >> endif >> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig >> index 8ae68d6203fb..ebf8d9014758 100644 >> --- a/drivers/pwm/Kconfig >> +++ b/drivers/pwm/Kconfig >> @@ -620,4 +620,16 @@ config PWM_VT8500 >> To compile this driver as a module, choose M here: the module >> will be called pwm-vt8500. >> >> +config PWM_XILINX >> + tristate "Xilinx AXI Timer PWM support" >> + depends on HAS_IOMEM && COMMON_CLK >> + help >> + PWM driver for Xilinx LogiCORE IP AXI timers. This timer is >> + typically a soft core which may be present in Xilinx FPGAs. >> + This device may also be present in Microblaze soft processors. >> + If you don't have this IP in your design, choose N. >> + >> + To compile this driver as a module, choose M here: the module >> + will be called pwm-xilinx. >> + >> endif >> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile >> index d43b1e17e8e1..655df169b895 100644 >> --- a/drivers/pwm/Makefile >> +++ b/drivers/pwm/Makefile >> @@ -58,3 +58,4 @@ obj-$(CONFIG_PWM_TWL) += pwm-twl.o >> obj-$(CONFIG_PWM_TWL_LED) += pwm-twl-led.o >> obj-$(CONFIG_PWM_VISCONTI) += pwm-visconti.o >> obj-$(CONFIG_PWM_VT8500) += pwm-vt8500.o >> +obj-$(CONFIG_PWM_XILINX) += pwm-xilinx.o >> diff --git a/drivers/pwm/pwm-xilinx.c b/drivers/pwm/pwm-xilinx.c >> new file mode 100644 >> index 000000000000..f05321496717 >> --- /dev/null >> +++ b/drivers/pwm/pwm-xilinx.c >> @@ -0,0 +1,219 @@ >> +// SPDX-License-Identifier: GPL-2.0+ >> +/* >> + * Copyright (C) 2021 Sean Anderson <sean.anderson@xxxxxxxx> >> + * >> + * Hardware limitations: >> + * - When changing both duty cycle and period, we may end up with one cycle >> + * with the old duty cycle and the new period. > > That means it doesn't reset the counter when a new period is set, right? Correct. The only way to write to the counter is to stop the timer and restart it. > >> + * - Cannot produce 100% duty cycle. > > Can it produce a 0% duty cycle? Below you're calling > xilinx_timer_tlr_period(..., ..., ..., 0) then which returns -ERANGE. Yes. This is what you get when you try to specify 100% duty cycle (e.g. TLR0 == TLR1). > >> + * - Only produces "normal" output. > > Does the output emit a low level when it's disabled? I believe so. > >> + */ >> + >> [...] >> +static int xilinx_pwm_apply(struct pwm_chip *chip, struct pwm_device *unused, >> + const struct pwm_state *state) >> +{ >> + int ret; >> + struct xilinx_timer_priv *priv = xilinx_pwm_chip_to_priv(chip); >> + u32 tlr0, tlr1; >> + u32 tcsr0 = xilinx_timer_read(priv, TCSR0); >> + u32 tcsr1 = xilinx_timer_read(priv, TCSR1); >> + bool enabled = xilinx_timer_pwm_enabled(tcsr0, tcsr1); >> + >> + if (state->polarity != PWM_POLARITY_NORMAL) >> + return -EINVAL; >> + >> + ret = xilinx_timer_tlr_period(priv, &tlr0, tcsr0, state->period); >> + if (ret) >> + return ret; > > The implementation of xilinx_timer_tlr_period (in patch 2/3) returns > -ERANGE for big periods. The good behaviour to implement is to cap to > the biggest period possible in this case. Ok. Is this documented anywhere? And wouldn't this result in the wrong duty cycle? E.g. say the max value is 100 and I try to apply a period of 150 and a duty_cycle of 75 (for a 50% duty cycle). If we cap at 100, then I will instead have a 75% duty cycle, and there will be no error. So I will silently get the wrong duty cycle, even when that duty cycle is probably more important than the period. > > Also note that state->period is an u64 but it is casted to unsigned int > as this is the type of the forth parameter of xilinx_timer_tlr_period. Hm, it looks like I immediately cast period to a u64. I will change the signature for this function next revision. > >> + ret = xilinx_timer_tlr_period(priv, &tlr1, tcsr1, state->duty_cycle); >> + if (ret) >> + return ret; >> + >> + xilinx_timer_write(priv, tlr0, TLR0); >> + xilinx_timer_write(priv, tlr1, TLR1); >> + >> + if (state->enabled) { >> + /* Only touch the TCSRs if we aren't already running */ >> + if (!enabled) { >> + /* Load TLR into TCR */ >> + xilinx_timer_write(priv, tcsr0 | TCSR_LOAD, TCSR0); >> + xilinx_timer_write(priv, tcsr1 | TCSR_LOAD, TCSR1); >> + /* Enable timers all at once with ENALL */ >> + tcsr0 = (TCSR_PWM_SET & ~TCSR_ENT) | (tcsr0 & TCSR_UDT); >> + tcsr1 = TCSR_PWM_SET | TCSR_ENALL | (tcsr1 & TCSR_UDT); >> + xilinx_timer_write(priv, tcsr0, TCSR0); >> + xilinx_timer_write(priv, tcsr1, TCSR1); >> + } >> + } else { >> + xilinx_timer_write(priv, 0, TCSR0); >> + xilinx_timer_write(priv, 0, TCSR1); >> + } >> + >> + return 0; >> +} >> + >> +static void xilinx_pwm_get_state(struct pwm_chip *chip, >> + struct pwm_device *unused, >> + struct pwm_state *state) >> +{ >> + struct xilinx_timer_priv *priv = xilinx_pwm_chip_to_priv(chip); >> + u32 tlr0 = xilinx_timer_read(priv, TLR0); >> + u32 tlr1 = xilinx_timer_read(priv, TLR1); >> + u32 tcsr0 = xilinx_timer_read(priv, TCSR0); >> + u32 tcsr1 = xilinx_timer_read(priv, TCSR1); >> + >> + state->period = xilinx_timer_get_period(priv, tlr0, tcsr0); >> + state->duty_cycle = xilinx_timer_get_period(priv, tlr1, tcsr1); >> + state->enabled = xilinx_timer_pwm_enabled(tcsr0, tcsr1); >> + state->polarity = PWM_POLARITY_NORMAL; > > Are the values returned here sensible if the hardware isn't in PWM mode? Yes. If the hardware isn't in PWM mode, then state->enabled will be false. > >> +} >> + >> +static const struct pwm_ops xilinx_pwm_ops = { >> + .apply = xilinx_pwm_apply, >> + .get_state = xilinx_pwm_get_state, >> + .owner = THIS_MODULE, >> +}; >> + >> +static int xilinx_timer_probe(struct platform_device *pdev) >> +{ >> + int ret; >> + struct device *dev = &pdev->dev; >> + struct device_node *np = dev->of_node; >> + struct xilinx_timer_priv *priv; >> + struct xilinx_pwm_device *pwm; >> + u32 pwm_cells, one_timer; >> + >> + ret = of_property_read_u32(np, "#pwm-cells", &pwm_cells); >> + if (ret == -EINVAL) >> + return -ENODEV; >> + else if (ret) >> + return dev_err_probe(dev, ret, "#pwm-cells\n"); > > Very sparse error message. Ok, will elaborate. > >> + else if (pwm_cells) >> + return dev_err_probe(dev, -EINVAL, "#pwm-cells must be 0\n"); > > What is the rationale here to not support #pwm-cells = <2>? Only one PWM is supported. But otherwise there is no particular reason. >> + pwm = devm_kzalloc(dev, sizeof(*pwm), GFP_KERNEL); >> + if (!pwm) >> + return -ENOMEM; >> + platform_set_drvdata(pdev, pwm); >> + priv = &pwm->priv; >> + >> + priv->regs = devm_platform_ioremap_resource(pdev, 0); >> + if (IS_ERR(priv->regs)) >> + return PTR_ERR(priv->regs); >> + >> + ret = xilinx_timer_common_init(np, priv, &one_timer); >> + if (ret) >> + return ret; >> + >> + if (one_timer) >> + return dev_err_probe(dev, -EINVAL, >> + "two timers required for PWM mode\n"); >> + >> + /* >> + * The polarity of the generate outputs must be active high for PWM >> + * mode to work. We could determine this from the device tree, but >> + * alas, such properties are not allowed to be used. >> + */ >> + >> + priv->clk = devm_clk_get(dev, "s_axi_aclk"); >> + if (IS_ERR(priv->clk)) >> + return dev_err_probe(dev, PTR_ERR(priv->clk), "clock\n"); > > again a sparse error message. > >> + >> + ret = clk_prepare_enable(priv->clk); >> + if (ret) >> + return dev_err_probe(dev, ret, "clock enable failed\n"); >> + clk_rate_exclusive_get(priv->clk); >> + >> + pwm->chip.dev = dev; >> + pwm->chip.ops = &xilinx_pwm_ops; >> + pwm->chip.npwm = 1; >> + ret = pwmchip_add(&pwm->chip); >> + if (ret) { >> + clk_rate_exclusive_put(priv->clk); >> + clk_disable_unprepare(priv->clk); >> + return dev_err_probe(dev, ret, "could not register pwm chip\n"); >> + } >> + >> + return 0; >> +} Thanks for the review. --Sean
