Hello,
over all the driver looks good. Just a few smaller issues below.
I wonder if it's a good idea to call this driver "apple". SoC vendors
seem to reinvent their peripherals (or buy them somewhere else) for
their different generations of processors. Maybe call it "apple-s5l"
already today and not only when the next generation SoC appears?
(I don't feel strong here, if you want to delay that renaming until
there is an incompatible SoC that's fine for me.)
On Fri, Dec 09, 2022 at 02:13:11PM +0300, Sasha Finkelstein wrote:
> diff --git a/drivers/pwm/pwm-apple.c b/drivers/pwm/pwm-apple.c
> new file mode 100644
> index 000000000000..a85fecb20105
> --- /dev/null
> +++ b/drivers/pwm/pwm-apple.c
> @@ -0,0 +1,150 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +/*
> + * Driver for the Apple SoC PWM controller
> + *
> + * Copyright The Asahi Linux Contributors
> + *
> + * Limitations:
> + * - The writes to cycle registers are shadowed until a write to
> + * the control register.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/pwm.h>
> +#include <linux/io.h>
> +#include <linux/clk.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/math64.h>
I didn't test, but I think you don't need pm_runtime.h here. Also maybe
the of headers are not needed?
> +#define APPLE_PWM_CONTROL 0x00
> +#define APPLE_PWM_ON_CYCLES 0x1c
> +#define APPLE_PWM_OFF_CYCLES 0x18
> +
> +#define APPLE_CTRL_ENABLE BIT(0)
> +#define APPLE_CTRL_MODE BIT(2)
> +#define APPLE_CTRL_UPDATE BIT(5)
> +#define APPLE_CTRL_TRIGGER BIT(9)
> +#define APPLE_CTRL_INVERT BIT(10)
> +#define APPLE_CTRL_OUTPUT_ENABLE BIT(14)
Would be nice if the register prefix would match the register name. That
is please either rename APPLE_PWM_CONTROL to APPLE_PWM_CTRL or use
APPLE_PWM_CONTROL as prefix for the bit fields in that register.
> +
> +struct apple_pwm {
> + struct pwm_chip chip;
> + void __iomem *base;
> + u64 clkrate;
> +};
> +
> +static inline struct apple_pwm *to_apple_pwm(struct pwm_chip *chip)
> +{
> + return container_of(chip, struct apple_pwm, chip);
> +}
> +
> +static int apple_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> + const struct pwm_state *state)
> +{
> + struct apple_pwm *fpwm;
> + u64 on_cycles, off_cycles;
The declaration can move into the if block below.
> +
> + fpwm = to_apple_pwm(chip);
> + if (state->enabled) {
> + on_cycles = mul_u64_u64_div_u64(fpwm->clkrate,
> + state->duty_cycle, NSEC_PER_SEC);
> + if (on_cycles > 0xFFFFFFFF)
> + return -ERANGE;
> +
> + off_cycles = mul_u64_u64_div_u64(fpwm->clkrate,
> + state->period, NSEC_PER_SEC) - on_cycles;
> + if (off_cycles > 0xFFFFFFFF)
> + return -ERANGE;
> +
> + writel(on_cycles, fpwm->base + APPLE_PWM_ON_CYCLES);
> + writel(off_cycles, fpwm->base + APPLE_PWM_OFF_CYCLES);
> + writel(APPLE_CTRL_ENABLE | APPLE_CTRL_OUTPUT_ENABLE | APPLE_CTRL_UPDATE,
> + fpwm->base + APPLE_PWM_CONTROL);
> + } else {
> + writel(0, fpwm->base + APPLE_PWM_CONTROL);
> + }
> + return 0;
Assuming clkrate = 24000000, I wonder what happens if (duty_cycle and)
period are so small that on_cycles and off_cycles are both zero. How
does the hardware behave in this case?
> +}
> +
> +static void apple_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
> + struct pwm_state *state)
> +{
> + struct apple_pwm *fpwm;
> + u32 on_cycles, off_cycles, ctrl;
> +
> + fpwm = to_apple_pwm(chip);
> +
> + ctrl = readl(fpwm->base + APPLE_PWM_CONTROL);
> + on_cycles = readl(fpwm->base + APPLE_PWM_ON_CYCLES);
> + off_cycles = readl(fpwm->base + APPLE_PWM_OFF_CYCLES);
> +
> + state->enabled = (ctrl & APPLE_CTRL_ENABLE) && (ctrl & APPLE_CTRL_OUTPUT_ENABLE);
> + state->polarity = PWM_POLARITY_NORMAL;
> + state->duty_cycle = mul_u64_u64_div_u64(on_cycles, NSEC_PER_SEC, fpwm->clkrate);
> + state->period = mul_u64_u64_div_u64(off_cycles + on_cycles,
> + NSEC_PER_SEC, fpwm->clkrate);
Wrong rounding direction, you need to round up. Did you test with
PWM_DEBUG on? This should point out the more obvious cases. Assuming
clkrate = 24000000 for example setting .duty_cycle = 3 should trigger a
warning.
Unfortunately there is no variant of mul_u64_u64_div_u64 that rounds up,
maybe we need to introduce one.
> +}
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
Attachment:
signature.asc
Description: PGP signature
