v2:
- fix dt-bindings
- fix a remark in the driver
v3:
- fix dt-bindings
- fix sunxi-d1s-t113.dtsi
v4:
- fix a remark in the driver
v5:
- dropped unused varibale in the driver
- fix dt-bindings
v6:
- add apb0 clock
v7:
- fix a remark in the driver
- add maintainer
v8:
- fix compile driver for 6.8-rc
v9:
- fix a remark in the driver
- fix dt-bindings
- rename apb0 -> apb
Aleksandr Shubin (3):
dt-bindings: pwm: Add binding for Allwinner D1/T113-S3/R329 PWM
controller
pwm: Add Allwinner's D1/T113-S3/R329 SoCs PWM support
riscv: dts: allwinner: d1: Add pwm node
.../bindings/pwm/allwinner,sun20i-pwm.yaml | 84 ++++
.../boot/dts/allwinner/sunxi-d1s-t113.dtsi | 12 +
drivers/pwm/Kconfig | 10 +
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-sun20i.c | 387 ++++++++++++++++++
5 files changed, 494 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/allwinner,sun20i-pwm.yaml
create mode 100644 drivers/pwm/pwm-sun20i.c
--
2.25.1
Allwinner's D1, T113-S3 and R329 SoCs have a new pwm
controller witch is different from the previous pwm-sun4i.
The D1 and T113 are identical in terms of peripherals,
they differ only in the architecture of the CPU core, and
even share the majority of their DT. Because of that,
using the same compatible makes sense.
The R329 is a different SoC though, and should have
a different compatible string added, especially as there
is a difference in the number of channels.
D1 and T113s SoCs have one PWM controller with 8 channels.
R329 SoC has two PWM controllers in both power domains, one of
them has 9 channels (CPUX one) and the other has 6 (CPUS one).
Add a device tree binding for them.
Signed-off-by: Aleksandr Shubin <[email protected]>
Reviewed-by: Conor Dooley <[email protected]>
---
.../bindings/pwm/allwinner,sun20i-pwm.yaml | 84 +++++++++++++++++++
1 file changed, 84 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/allwinner,sun20i-pwm.yaml
diff --git a/Documentation/devicetree/bindings/pwm/allwinner,sun20i-pwm.yaml b/Documentation/devicetree/bindings/pwm/allwinner,sun20i-pwm.yaml
new file mode 100644
index 000000000000..89cebf7841a6
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/allwinner,sun20i-pwm.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/allwinner,sun20i-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner D1, T113-S3 and R329 PWM
+
+maintainers:
+ - Aleksandr Shubin <[email protected]>
+ - Brandon Cheo Fusi <[email protected]>
+
+properties:
+ compatible:
+ oneOf:
+ - const: allwinner,sun20i-d1-pwm
+ - items:
+ - const: allwinner,sun50i-r329-pwm
+ - const: allwinner,sun20i-d1-pwm
+
+ reg:
+ maxItems: 1
+
+ "#pwm-cells":
+ const: 3
+
+ clocks:
+ items:
+ - description: Bus clock
+ - description: 24 MHz oscillator
+ - description: APB clock
+
+ clock-names:
+ items:
+ - const: bus
+ - const: hosc
+ - const: apb
+
+ resets:
+ maxItems: 1
+
+ allwinner,pwm-channels:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: The number of PWM channels configured for this instance
+ enum: [6, 9]
+
+allOf:
+ - $ref: pwm.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: allwinner,sun50i-r329-pwm
+
+ then:
+ required:
+ - allwinner,pwm-channels
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - "#pwm-cells"
+ - clocks
+ - clock-names
+ - resets
+
+examples:
+ - |
+ #include <dt-bindings/clock/sun20i-d1-ccu.h>
+ #include <dt-bindings/reset/sun20i-d1-ccu.h>
+
+ pwm: pwm@2000c00 {
+ compatible = "allwinner,sun20i-d1-pwm";
+ reg = <0x02000c00 0x400>;
+ clocks = <&ccu CLK_BUS_PWM>, <&dcxo>, <&ccu CLK_APB0>;
+ clock-names = "bus", "hosc", "apb";
+ resets = <&ccu RST_BUS_PWM>;
+ #pwm-cells = <0x3>;
+ };
+
+...
--
2.25.1
Allwinner's D1, T113-S3 and R329 SoCs have a quite different PWM
controllers with ones supported by pwm-sun4i driver.
This patch adds a PWM controller driver for Allwinner's D1,
T113-S3 and R329 SoCs. The main difference between these SoCs
is the number of channels defined by the DT property.
Co-developed-by: Brandon Cheo Fusi <[email protected]>
Signed-off-by: Brandon Cheo Fusi <[email protected]>
Signed-off-by: Aleksandr Shubin <[email protected]>
---
drivers/pwm/Kconfig | 10 +
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-sun20i.c | 387 +++++++++++++++++++++++++++++++++++++++
3 files changed, 398 insertions(+)
create mode 100644 drivers/pwm/pwm-sun20i.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 4b956d661755..d2e0a080eb3c 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -625,6 +625,16 @@ config PWM_SUN4I
To compile this driver as a module, choose M here: the module
will be called pwm-sun4i.
+config PWM_SUN20I
+ tristate "Allwinner D1/T113s/R329 PWM support"
+ depends on ARCH_SUNXI || COMPILE_TEST
+ depends on COMMON_CLK
+ help
+ Generic PWM framework driver for Allwinner D1/T113s/R329 SoCs.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-sun20i.
+
config PWM_SUNPLUS
tristate "Sunplus PWM support"
depends on ARCH_SUNPLUS || COMPILE_TEST
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index c5ec9e168ee7..dcad0d5a2430 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -58,6 +58,7 @@ obj-$(CONFIG_PWM_STM32) += pwm-stm32.o
obj-$(CONFIG_PWM_STM32_LP) += pwm-stm32-lp.o
obj-$(CONFIG_PWM_STMPE) += pwm-stmpe.o
obj-$(CONFIG_PWM_SUN4I) += pwm-sun4i.o
+obj-$(CONFIG_PWM_SUN20I) += pwm-sun20i.o
obj-$(CONFIG_PWM_SUNPLUS) += pwm-sunplus.o
obj-$(CONFIG_PWM_TEGRA) += pwm-tegra.o
obj-$(CONFIG_PWM_TIECAP) += pwm-tiecap.o
diff --git a/drivers/pwm/pwm-sun20i.c b/drivers/pwm/pwm-sun20i.c
new file mode 100644
index 000000000000..3e3b5b138b30
--- /dev/null
+++ b/drivers/pwm/pwm-sun20i.c
@@ -0,0 +1,387 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * PWM Controller Driver for sunxi platforms (D1, T113-S3 and R329)
+ *
+ * Limitations:
+ * - When the parameters change, current running period will not be completed
+ * and run new settings immediately.
+ * - It output HIGH-Z state when PWM channel disabled.
+ *
+ * Copyright (c) 2023 Aleksandr Shubin <[email protected]>
+ */
+
+#include <linux/bitfield.h>
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pwm.h>
+#include <linux/reset.h>
+
+#define SUN20I_PWM_CLK_CFG(chan) (0x20 + (((chan) >> 1) * 0x4))
+#define SUN20I_PWM_CLK_CFG_SRC GENMASK(8, 7)
+#define SUN20I_PWM_CLK_CFG_DIV_M GENMASK(3, 0)
+#define SUN20I_PWM_CLK_DIV_M_MAX 8
+
+#define SUN20I_PWM_CLK_GATE 0x40
+#define SUN20I_PWM_CLK_GATE_BYPASS(chan) BIT((chan) + 16)
+#define SUN20I_PWM_CLK_GATE_GATING(chan) BIT(chan)
+
+#define SUN20I_PWM_ENABLE 0x80
+#define SUN20I_PWM_ENABLE_EN(chan) BIT(chan)
+
+#define SUN20I_PWM_CTL(chan) (0x100 + (chan) * 0x20)
+#define SUN20I_PWM_CTL_ACT_STA BIT(8)
+#define SUN20I_PWM_CTL_PRESCAL_K GENMASK(7, 0)
+#define SUN20I_PWM_CTL_PRESCAL_K_MAX field_max(SUN20I_PWM_CTL_PRESCAL_K)
+
+#define SUN20I_PWM_PERIOD(chan) (0x104 + (chan) * 0x20)
+#define SUN20I_PWM_PERIOD_ENTIRE_CYCLE GENMASK(31, 16)
+#define SUN20I_PWM_PERIOD_ACT_CYCLE GENMASK(15, 0)
+
+#define SUN20I_PWM_PCNTR_SIZE BIT(16)
+
+/*
+ * SUN20I_PWM_MAGIC is used to quickly compute the values of the clock dividers
+ * div_m (SUN20I_PWM_CLK_CFG_DIV_M) & prescale_k (SUN20I_PWM_CTL_PRESCAL_K)
+ * without using a loop. These dividers limit the # of cycles in a period
+ * to SUN20I_PWM_PCNTR_SIZE by applying a scaling factor of
+ * 1/(div_m * (prescale_k + 1)) to the clock source.
+ *
+ * SUN20I_PWM_MAGIC is derived by solving for div_m and prescale_k
+ * such that for a given requested period,
+ *
+ * i) div_m is minimized for any prescale_k ≤ SUN20I_PWM_CTL_PRESCAL_K_MAX,
+ * ii) prescale_k is minimized.
+ *
+ * The derivation proceeds as follows, with val = # of cycles for requested
+ * period:
+ *
+ * for a given value of div_m we want the smallest prescale_k such that
+ *
+ * (val >> div_m) // (prescale_k + 1) ≤ 65536 (SUN20I_PWM_PCNTR_SIZE)
+ *
+ * This is equivalent to:
+ *
+ * (val >> div_m) ≤ 65536 * (prescale_k + 1) + prescale_k
+ * ⟺ (val >> div_m) ≤ 65537 * prescale_k + 65536
+ * ⟺ (val >> div_m) - 65536 ≤ 65537 * prescale_k
+ * ⟺ ((val >> div_m) - 65536) / 65537 ≤ prescale_k
+ *
+ * As prescale_k is integer, this becomes
+ *
+ * ((val >> div_m) - 65536) // 65537 ≤ prescale_k
+ *
+ * And is minimized at
+ *
+ * ((val >> div_m) - 65536) // 65537
+ *
+ * Now we pick the smallest div_m that satifies prescale_k ≤ 255
+ * (i.e SUN20I_PWM_CTL_PRESCAL_K_MAX),
+ *
+ * ((val >> div_m) - 65536) // 65537 ≤ 255
+ * ⟺ (val >> div_m) - 65536 ≤ 255 * 65537 + 65536
+ * ⟺ val >> div_m ≤ 255 * 65537 + 2 * 65536
+ * ⟺ val >> div_m < (255 * 65537 + 2 * 65536 + 1)
+ * ⟺ div_m = fls((val) / (255 * 65537 + 2 * 65536 + 1))
+ *
+ * Suggested by Uwe Kleine-König
+ */
+#define SUN20I_PWM_MAGIC (255 * 65537 + 2 * 65536 + 1)
+
+struct sun20i_pwm_chip {
+ struct clk *clk_bus, *clk_hosc, *clk_apb;
+ struct reset_control *rst;
+ struct pwm_chip chip;
+ void __iomem *base;
+ /* Mutex to protect pwm apply state */
+ struct mutex mutex;
+};
+
+static inline struct sun20i_pwm_chip *to_sun20i_pwm_chip(struct pwm_chip *chip)
+{
+ return container_of(chip, struct sun20i_pwm_chip, chip);
+}
+
+static inline u32 sun20i_pwm_readl(struct sun20i_pwm_chip *chip,
+ unsigned long offset)
+{
+ return readl(chip->base + offset);
+}
+
+static inline void sun20i_pwm_writel(struct sun20i_pwm_chip *chip,
+ u32 val, unsigned long offset)
+{
+ writel(val, chip->base + offset);
+}
+
+static int sun20i_pwm_get_state(struct pwm_chip *chip,
+ struct pwm_device *pwm,
+ struct pwm_state *state)
+{
+ struct sun20i_pwm_chip *sun20i_chip = to_sun20i_pwm_chip(chip);
+ u16 ent_cycle, act_cycle, prescale_k;
+ u64 clk_rate, tmp;
+ u8 div_m;
+ u32 val;
+
+ mutex_lock(&sun20i_chip->mutex);
+
+ val = sun20i_pwm_readl(sun20i_chip, SUN20I_PWM_CLK_CFG(pwm->hwpwm));
+ div_m = FIELD_GET(SUN20I_PWM_CLK_CFG_DIV_M, val);
+ if (div_m > SUN20I_PWM_CLK_DIV_M_MAX)
+ div_m = SUN20I_PWM_CLK_DIV_M_MAX;
+
+ if (FIELD_GET(SUN20I_PWM_CLK_CFG_SRC, val) == 0)
+ clk_rate = clk_get_rate(sun20i_chip->clk_hosc);
+ else
+ clk_rate = clk_get_rate(sun20i_chip->clk_apb);
+
+ val = sun20i_pwm_readl(sun20i_chip, SUN20I_PWM_CTL(pwm->hwpwm));
+ state->polarity = (SUN20I_PWM_CTL_ACT_STA & val) ?
+ PWM_POLARITY_NORMAL : PWM_POLARITY_INVERSED;
+
+ prescale_k = FIELD_GET(SUN20I_PWM_CTL_PRESCAL_K, val) + 1;
+
+ val = sun20i_pwm_readl(sun20i_chip, SUN20I_PWM_ENABLE);
+ state->enabled = (SUN20I_PWM_ENABLE_EN(pwm->hwpwm) & val) ? true : false;
+
+ val = sun20i_pwm_readl(sun20i_chip, SUN20I_PWM_PERIOD(pwm->hwpwm));
+
+ mutex_unlock(&sun20i_chip->mutex);
+
+ act_cycle = FIELD_GET(SUN20I_PWM_PERIOD_ACT_CYCLE, val);
+ ent_cycle = FIELD_GET(SUN20I_PWM_PERIOD_ENTIRE_CYCLE, val);
+
+ /*
+ * The duration of the active phase should not be longer
+ * than the duration of the period
+ */
+ if (act_cycle > ent_cycle)
+ act_cycle = ent_cycle;
+
+ /*
+ * We have act_cycle <= ent_cycle <= 0xffff, prescale_k <= 0x100,
+ * div_m <= 8. So the multiplication fits into an u64 without
+ * overflow.
+ */
+ tmp = ((u64)(act_cycle) * prescale_k << div_m) * NSEC_PER_SEC;
+ state->duty_cycle = DIV_ROUND_UP_ULL(tmp, clk_rate);
+ tmp = ((u64)(ent_cycle) * prescale_k << div_m) * NSEC_PER_SEC;
+ state->period = DIV_ROUND_UP_ULL(tmp, clk_rate);
+
+ return 0;
+}
+
+static int sun20i_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+ const struct pwm_state *state)
+{
+ struct sun20i_pwm_chip *sun20i_chip = to_sun20i_pwm_chip(chip);
+ u64 bus_rate, hosc_rate, val, ent_cycle, act_cycle;
+ u32 clk_gate, clk_cfg, pwm_en, ctl, reg_period;
+ u32 prescale_k, div_m;
+ bool use_bus_clk;
+ int ret = 0;
+
+ mutex_lock(&sun20i_chip->mutex);
+
+ pwm_en = sun20i_pwm_readl(sun20i_chip, SUN20I_PWM_ENABLE);
+
+ if (state->enabled != pwm->state.enabled) {
+ clk_gate = sun20i_pwm_readl(sun20i_chip, SUN20I_PWM_CLK_GATE);
+
+ if (!state->enabled) {
+ clk_gate &= ~SUN20I_PWM_CLK_GATE_GATING(pwm->hwpwm);
+ pwm_en &= ~SUN20I_PWM_ENABLE_EN(pwm->hwpwm);
+ sun20i_pwm_writel(sun20i_chip, pwm_en, SUN20I_PWM_ENABLE);
+ sun20i_pwm_writel(sun20i_chip, clk_gate, SUN20I_PWM_CLK_GATE);
+ }
+ }
+
+ if (state->polarity != pwm->state.polarity ||
+ state->duty_cycle != pwm->state.duty_cycle ||
+ state->period != pwm->state.period) {
+ ctl = sun20i_pwm_readl(sun20i_chip, SUN20I_PWM_CTL(pwm->hwpwm));
+ clk_cfg = sun20i_pwm_readl(sun20i_chip, SUN20I_PWM_CLK_CFG(pwm->hwpwm));
+ hosc_rate = clk_get_rate(sun20i_chip->clk_hosc);
+ bus_rate = clk_get_rate(sun20i_chip->clk_apb);
+ if (pwm_en & SUN20I_PWM_ENABLE_EN(pwm->hwpwm ^ 1)) {
+ /* if the neighbor channel is enable, check period only */
+ use_bus_clk = FIELD_GET(SUN20I_PWM_CLK_CFG_SRC, clk_cfg) != 0;
+ val = mul_u64_u64_div_u64(state->period,
+ (use_bus_clk ? bus_rate : hosc_rate),
+ NSEC_PER_SEC);
+
+ div_m = FIELD_GET(SUN20I_PWM_CLK_CFG_DIV_M, clk_cfg);
+ } else {
+ /* check period and select clock source */
+ use_bus_clk = false;
+ val = mul_u64_u64_div_u64(state->period, hosc_rate, NSEC_PER_SEC);
+ if (val <= 1) {
+ use_bus_clk = true;
+ val = mul_u64_u64_div_u64(state->period, bus_rate, NSEC_PER_SEC);
+ if (val <= 1) {
+ ret = -EINVAL;
+ goto unlock_mutex;
+ }
+ }
+ div_m = fls(DIV_ROUND_DOWN_ULL(val, SUN20I_PWM_MAGIC));
+ if (div_m > SUN20I_PWM_CLK_DIV_M_MAX) {
+ ret = -EINVAL;
+ goto unlock_mutex;
+ }
+
+ /* set up the CLK_DIV_M and clock CLK_SRC */
+ clk_cfg = FIELD_PREP(SUN20I_PWM_CLK_CFG_DIV_M, div_m);
+ clk_cfg |= FIELD_PREP(SUN20I_PWM_CLK_CFG_SRC, use_bus_clk);
+
+ sun20i_pwm_writel(sun20i_chip, clk_cfg, SUN20I_PWM_CLK_CFG(pwm->hwpwm));
+ }
+
+ /* calculate prescale_k, PWM entire cycle */
+ ent_cycle = val >> div_m;
+ prescale_k = DIV_ROUND_DOWN_ULL(ent_cycle, 65537);
+ if (prescale_k > SUN20I_PWM_CTL_PRESCAL_K_MAX)
+ prescale_k = SUN20I_PWM_CTL_PRESCAL_K_MAX;
+
+ do_div(ent_cycle, prescale_k + 1);
+
+ /* for N cycles, PPRx.PWM_ENTIRE_CYCLE = (N-1) */
+ reg_period = FIELD_PREP(SUN20I_PWM_PERIOD_ENTIRE_CYCLE, ent_cycle - 1);
+
+ /* set duty cycle */
+ val = mul_u64_u64_div_u64(state->duty_cycle,
+ (use_bus_clk ? bus_rate : hosc_rate),
+ NSEC_PER_SEC);
+ act_cycle = val >> div_m;
+ do_div(act_cycle, prescale_k + 1);
+
+ /*
+ * The formula of the output period and the duty-cycle for PWM are as follows.
+ * T period = (PWM01_CLK / PWM0_PRESCALE_K)^-1 * (PPR0.PWM_ENTIRE_CYCLE + 1)
+ * T high-level = (PWM01_CLK / PWM0_PRESCALE_K)^-1 * PPR0.PWM_ACT_CYCLE
+ * Duty-cycle = T high-level / T period
+ */
+ reg_period |= FIELD_PREP(SUN20I_PWM_PERIOD_ACT_CYCLE, act_cycle);
+ sun20i_pwm_writel(sun20i_chip, reg_period, SUN20I_PWM_PERIOD(pwm->hwpwm));
+
+ ctl = FIELD_PREP(SUN20I_PWM_CTL_PRESCAL_K, prescale_k);
+ if (state->polarity == PWM_POLARITY_NORMAL)
+ ctl |= SUN20I_PWM_CTL_ACT_STA;
+
+ sun20i_pwm_writel(sun20i_chip, ctl, SUN20I_PWM_CTL(pwm->hwpwm));
+ }
+
+ if (state->enabled != pwm->state.enabled && state->enabled) {
+ clk_gate &= ~SUN20I_PWM_CLK_GATE_BYPASS(pwm->hwpwm);
+ clk_gate |= SUN20I_PWM_CLK_GATE_GATING(pwm->hwpwm);
+ pwm_en |= SUN20I_PWM_ENABLE_EN(pwm->hwpwm);
+ sun20i_pwm_writel(sun20i_chip, pwm_en, SUN20I_PWM_ENABLE);
+ sun20i_pwm_writel(sun20i_chip, clk_gate, SUN20I_PWM_CLK_GATE);
+ }
+
+unlock_mutex:
+ mutex_unlock(&sun20i_chip->mutex);
+
+ return ret;
+}
+
+static const struct pwm_ops sun20i_pwm_ops = {
+ .apply = sun20i_pwm_apply,
+ .get_state = sun20i_pwm_get_state,
+};
+
+static const struct of_device_id sun20i_pwm_dt_ids[] = {
+ { .compatible = "allwinner,sun20i-d1-pwm" },
+ { },
+};
+MODULE_DEVICE_TABLE(of, sun20i_pwm_dt_ids);
+
+static void sun20i_pwm_reset_ctrl_release(void *data)
+{
+ struct reset_control *rst = data;
+
+ reset_control_assert(rst);
+}
+
+static int sun20i_pwm_probe(struct platform_device *pdev)
+{
+ struct sun20i_pwm_chip *sun20i_chip;
+ int ret;
+
+ sun20i_chip = devm_kzalloc(&pdev->dev, sizeof(*sun20i_chip), GFP_KERNEL);
+ if (!sun20i_chip)
+ return -ENOMEM;
+
+ sun20i_chip->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(sun20i_chip->base))
+ return PTR_ERR(sun20i_chip->base);
+
+ sun20i_chip->clk_bus = devm_clk_get_enabled(&pdev->dev, "bus");
+ if (IS_ERR(sun20i_chip->clk_bus))
+ return dev_err_probe(&pdev->dev, PTR_ERR(sun20i_chip->clk_bus),
+ "failed to get bus clock\n");
+
+ sun20i_chip->clk_hosc = devm_clk_get_enabled(&pdev->dev, "hosc");
+ if (IS_ERR(sun20i_chip->clk_hosc))
+ return dev_err_probe(&pdev->dev, PTR_ERR(sun20i_chip->clk_hosc),
+ "failed to get hosc clock\n");
+
+ sun20i_chip->clk_apb = devm_clk_get_enabled(&pdev->dev, "apb");
+ if (IS_ERR(sun20i_chip->clk_apb))
+ return dev_err_probe(&pdev->dev, PTR_ERR(sun20i_chip->clk_apb),
+ "failed to get apb clock\n");
+
+ sun20i_chip->rst = devm_reset_control_get_exclusive(&pdev->dev, NULL);
+ if (IS_ERR(sun20i_chip->rst))
+ return dev_err_probe(&pdev->dev, PTR_ERR(sun20i_chip->rst),
+ "failed to get bus reset\n");
+
+ ret = of_property_read_u32(pdev->dev.of_node, "allwinner,pwm-channels",
+ &sun20i_chip->chip.npwm);
+ if (ret)
+ sun20i_chip->chip.npwm = 8;
+
+ if (sun20i_chip->chip.npwm > 16) {
+ dev_info(&pdev->dev, "Limiting number of PWM lines from %u to 16",
+ sun20i_chip->chip.npwm);
+ sun20i_chip->chip.npwm = 16;
+ }
+
+ /* Deassert reset */
+ ret = reset_control_deassert(sun20i_chip->rst);
+ if (ret)
+ return dev_err_probe(&pdev->dev, ret, "failed to deassert reset\n");
+
+ ret = devm_add_action_or_reset(&pdev->dev, sun20i_pwm_reset_ctrl_release, sun20i_chip->rst);
+ if (ret)
+ return ret;
+
+ sun20i_chip->chip.dev = &pdev->dev;
+ sun20i_chip->chip.ops = &sun20i_pwm_ops;
+
+ mutex_init(&sun20i_chip->mutex);
+
+ ret = devm_pwmchip_add(&pdev->dev, &sun20i_chip->chip);
+ if (ret < 0)
+ return dev_err_probe(&pdev->dev, ret, "failed to add PWM chip\n");
+
+ platform_set_drvdata(pdev, sun20i_chip);
+
+ return 0;
+}
+
+static struct platform_driver sun20i_pwm_driver = {
+ .driver = {
+ .name = "sun20i-pwm",
+ .of_match_table = sun20i_pwm_dt_ids,
+ },
+ .probe = sun20i_pwm_probe,
+};
+module_platform_driver(sun20i_pwm_driver);
+
+MODULE_AUTHOR("Aleksandr Shubin <[email protected]>");
+MODULE_DESCRIPTION("Allwinner sun20i PWM driver");
+MODULE_LICENSE("GPL");
--
2.25.1
D1 and T113s contain a pwm controller with 8 channels.
This controller is supported by the sun20i-pwm driver.
Add a device tree node for it.
Signed-off-by: Aleksandr Shubin <[email protected]>
---
arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi b/arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi
index 5a9d7f5a75b4..22821b21b9a2 100644
--- a/arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi
+++ b/arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi
@@ -145,6 +145,18 @@ uart3_pb_pins: uart3-pb-pins {
};
};
+ pwm: pwm@2000c00 {
+ compatible = "allwinner,sun20i-d1-pwm";
+ reg = <0x02000c00 0x400>;
+ clocks = <&ccu CLK_BUS_PWM>,
+ <&dcxo>,
+ <&ccu CLK_APB0>;
+ clock-names = "bus", "hosc", "apb";
+ resets = <&ccu RST_BUS_PWM>;
+ status = "disabled";
+ #pwm-cells = <0x3>;
+ };
+
ccu: clock-controller@2001000 {
compatible = "allwinner,sun20i-d1-ccu";
reg = <0x2001000 0x1000>;
--
2.25.1
Hello Aleksandr,
I had coincidentally developed a PWM driver for the device.
Based on my experience, I find that dynamically changing the coupled
DIV_M value is quite complex.
The current approach has limitations, especially with resolution
changes, which can be unpredictable for users. For example:
1. Enabling channel A automatically selects DIV_M.
2. Enabling coupled channel B with a specific period may result in
poor resolution for channel B, as the DIV_M value depends on the
period of channel A.
3. If channel B is enabled first, channel A may not be enabled if
its period doesn't fit the DIV_M range selected by channel B.
Additionally, using APB as a clock source for the channels would
further complicate the process.
To simplify this, I suggest (maybe for the future) specifying these
values directly in the Device Tree like this:
```
allwinner,pwm-coupled-channel-clock-sources="hosc", "apb", "hosc";
allwinner,pwm-coupled-channel-clock-prescales=<0>, <3>, <8>;
```
This would delegate the complexity to the DT, making the resolution
predictable for users.
As a bonus, it introduces a way to select clock sources for each
coupled channels.
For the meantime, I think it is enough to use fixed "hosc" and <0> for
regular use.
Looking forward to your thoughts.
Best regards,
kikuchan.
On Thu, May 23, 2024 at 11:26:07AM +0900, きくちゃんさん wrote:
> Hello Aleksandr,
>
> I had coincidentally developed a PWM driver for the device.
> Based on my experience, I find that dynamically changing the coupled
> DIV_M value is quite complex.
> The current approach has limitations, especially with resolution
> changes, which can be unpredictable for users. For example:
>
> 1. Enabling channel A automatically selects DIV_M.
> 2. Enabling coupled channel B with a specific period may result in
> poor resolution for channel B, as the DIV_M value depends on the
> period of channel A.
> 3. If channel B is enabled first, channel A may not be enabled if
> its period doesn't fit the DIV_M range selected by channel B.
>
> Additionally, using APB as a clock source for the channels would
> further complicate the process.
>
> To simplify this, I suggest (maybe for the future) specifying these
> values directly in the Device Tree like this:
> ```
> allwinner,pwm-coupled-channel-clock-sources="hosc", "apb", "hosc";
> allwinner,pwm-coupled-channel-clock-prescales=<0>, <3>, <8>;
> ```
> This would delegate the complexity to the DT, making the resolution
> predictable for users.
> As a bonus, it introduces a way to select clock sources for each
> coupled channels.
>
> For the meantime, I think it is enough to use fixed "hosc" and <0> for
> regular use.
>
> Looking forward to your thoughts.
>
> Best regards,
> kikuchan.
I have a somewhat opposite opinion. I've developed a driver too and posted it
on the u-boot mailing list that is deterministic and handles both channels:
https://lore.kernel.org/all/[email protected]/
It does this by remembering the settings for channels and disabling then
setting both channels at once whenever there's an update.
I think this is a decent enough solution to the problem and just works
automatically without people having to micromanage the controller.
John.
Hello John,
Your method is quite impressive and challenging.
I think PWM is not only for LCD backlighting, but also for signal generation.
For instance, imagine an application software that sends a stream to
one PWM channel to synthesize sound by changing its period (plays a
square wave).
By your method, if the other PWM channel is used for LCD backlighting,
it may flicker repeatedly on DIV_M changes.
(Or simply both channels for streo sound synthesize, you may hear lots
of pop noise)
It means the setting of one channel can affect the other, which users
may not anticipate.
Best regards,
kikuchan.
On Thu, May 23, 2024 at 02:30:32PM +0900, きくちゃんさん wrote:
> Hello John,
Hello,
>
> Your method is quite impressive and challenging.
>
> I think PWM is not only for LCD backlighting, but also for signal generation.
> For instance, imagine an application software that sends a stream to
> one PWM channel to synthesize sound by changing its period (plays a
> square wave).
> By your method, if the other PWM channel is used for LCD backlighting,
> it may flicker repeatedly on DIV_M changes.
> (Or simply both channels for streo sound synthesize, you may hear lots
> of pop noise)
>
> It means the setting of one channel can affect the other, which users
> may not anticipate.
Does Linux guarantee a flicker-free experience with setting up PWM
channels, or that it doesn't affect other channels?
How do other drivers handle this situation?
Maybe out-sourcing the clocking to the device tree and letting people set the
clock and common divisor in the DT would be a good idea, with the HOSC and a
common divisor of 1 by default, then error if the value can't be found.
This would work for periods from 41ns up to 687ms by default. Using APB would
give a better resolution as by default it hangs around 5ns which is nice and
divisible by 10.
>
> Best regards,
> kikuchan.
John.
Hi,
Here's a quick review based on the experience of me writing my own driver.
On Mon, May 20, 2024 at 09:42:20PM +0300, Aleksandr Shubin wrote:
> + act_cycle = FIELD_GET(SUN20I_PWM_PERIOD_ACT_CYCLE, val);
> + ent_cycle = FIELD_GET(SUN20I_PWM_PERIOD_ENTIRE_CYCLE, val);
> +
> + /*
> + * The duration of the active phase should not be longer
> + * than the duration of the period
> + */
> + if (act_cycle > ent_cycle)
> + act_cycle = ent_cycle;
> +
> + /*
> + * We have act_cycle <= ent_cycle <= 0xffff, prescale_k <= 0x100,
> + * div_m <= 8. So the multiplication fits into an u64 without
> + * overflow.
> + */
> + tmp = ((u64)(act_cycle) * prescale_k << div_m) * NSEC_PER_SEC;
> + state->duty_cycle = DIV_ROUND_UP_ULL(tmp, clk_rate);
> + tmp = ((u64)(ent_cycle) * prescale_k << div_m) * NSEC_PER_SEC;
> + state->period = DIV_ROUND_UP_ULL(tmp, clk_rate);
Doesn't ent_cycle require a + 1 here?
Shouldn't act_cycle be > ent_cycle on 0% duty cycles?
> + /* if the neighbor channel is enable, check period only */
> + use_bus_clk = FIELD_GET(SUN20I_PWM_CLK_CFG_SRC, clk_cfg) != 0;
> + val = mul_u64_u64_div_u64(state->period,
> + (use_bus_clk ? bus_rate : hosc_rate),
> + NSEC_PER_SEC);
It would be nice if it reclocked both channels.
> + /* calculate prescale_k, PWM entire cycle */
> + ent_cycle = val >> div_m;
> + prescale_k = DIV_ROUND_DOWN_ULL(ent_cycle, 65537);
> + if (prescale_k > SUN20I_PWM_CTL_PRESCAL_K_MAX)
> + prescale_k = SUN20I_PWM_CTL_PRESCAL_K_MAX;
> +
> + do_div(ent_cycle, prescale_k + 1);
> +
> + /* for N cycles, PPRx.PWM_ENTIRE_CYCLE = (N-1) */
> + reg_period = FIELD_PREP(SUN20I_PWM_PERIOD_ENTIRE_CYCLE, ent_cycle - 1);
> +
> + /* set duty cycle */
> + val = mul_u64_u64_div_u64(state->duty_cycle,
> + (use_bus_clk ? bus_rate : hosc_rate),
> + NSEC_PER_SEC);
> + act_cycle = val >> div_m;
> + do_div(act_cycle, prescale_k + 1);
I'm not sure about this code. I don't quite get where the 65537 comes from or
what's really happening here.
To my understanding you either want to limit PWM_ENTIRE_CYCLE to 0xFFFE so and
scale PWM_ACTIVE_CYCLE from 0 to 65535 so it can be 0x0 at 100% duty cycles and
0xFFFF at 0% duty cycles, OR you want to scale it from 0 to 65536 and check if
the value is 65536, and if it is wrap it around to 0 and flip the polarity.
Thanks,
John.
Hi John,
> Does Linux guarantee a flicker-free experience with setting up PWM
> channels, or that it doesn't affect other channels?
> How do other drivers handle this situation?
I've noticed that drivers/pwm/pwm-fsl-ftm.c and
drivers/pwm/pwm-microchip-core.c use a similar approach for shared
resources between PWM channels.
They simply fail if the settings are not applicable to the hardware,
much like this driver does. However, I have yet to find a driver that
aggressively changes another channel that is already running.
Maybe you're right; Linux might not guarantee anything about this.
I think all we can do is deliver the best experience to users within
such limitations.
Best regards,
kikuchan.