2021-11-30 05:59:49

by Billy Tsai

[permalink] [raw]
Subject: [v14 0/2] Support pwm driver for aspeed ast26xx

The legacy driver of aspeed pwm is binding with tach controller and it
doesn't follow the pwm framworks usage. In addition, the pwm register
usage of the 6th generation of ast26xx has drastic change. So these
patch serials add the new aspeed pwm driver to fix up the problem above.

Change since v13:
- pwm-aspeed-ast2600.c
- Fix the usage of the braces to meet the coding-style.rst
- Use min function to reduce the times of division.

Change since v12:
- pwm-aspeed-ast2600.c
- Fix the comment about the duty cycle and period of the PWM.
- Configured to max period when request period > max period.
- Remove unnecessary curly braces.

Change since v11:
- pwm-aspeed-ast2600.c
- Request reset controller before clock enable.

Change since v10:
- pwm-aspeed-ast2600.c
- Add more comment to explain the feature of PWM
- Fix the naming of some parameters.
- Set pin_enable and clk_enable at the same time.
- Always set fixed divisor to hw register when apply.

Change since v9:
- dt-bindings:
- Change the naming of tach subnode channel setting property to
aspeed,tach-ch.
- pwm-aspeed-ast2600.c
- Fix the naming of some parameters.
- Capitalise error messages.
- Handling potentially mult overflow when .apply

Change since v8:
- pwm-aspeed-ast2600.c
- Replace "* _BITULL(div_h)" to "<< div_h"
- Fix duty_cycle precision problem.
- Add the comment about the formula of duty_cycle.

Change since v7:
- pwm-aspeed-g6.c
- Rename the driver: pwm-aspeed-g6.c -> pwm-aspeed-ast2600.c.
- Macro remove "_CH" part of the register name.
- Unroll the aspeed_pwm_get_period and remove it.
- Simplify the formula to get duty_pt
- Reduce the number of writing register. Organize all the fields and
write them at once.

Change since v6:
- dt-bindings:
- Add blank line between each DT property.
- Change the sub-node name from fan to tach-ch.
- pwm-aspeed-g6.c
- Merge aspeed_pwm_set_period and aspeed_pwm_set_duty into .apply.
- Convert the factor type to u64 when calculating the period value.
- Using ROUND_UP strategy to calculate div_h for finer resolution.

Change since v5:
- pwm-aspeed-g6.c suggested by Uwe Kleine-König
- Move the divide at the end of the calculation.
- Unified the prefix of the function name.
- Use div64_u64 to calculate the divider of frequency.

Change since v4:
- dt_binding:
- pwm/tach yaml: Replace child-node with additionalProperties
- pwm-tach yaml: Replace child-node with patternProperties
- pwm-aspeed-g6.c suggested by Uwe Kleine-König
- The bit definitions contained the name of the register.
- Remove single caller function and fold it to the caller.
- Avoid to divide by the result of a division.
- Remove unnecessary condition in .apply().
- Use goto for error handling

Changes since v3:
- Add the dt_binding for aspeed,ast2600-tach.
- Describe the pwm/tach as child-node of pwm-tach mfd.
- Complete the properties of pwm node.

Changes since v2:
- Remove the tach node, #address-cells and #size-cells from pwm-tach.yaml
- Add clocks and reset properties to pwm-tach.yaml
- Kconfig/Makfile sorted alphabetically
- pwm-aspeed-g6.c suggested by Uwe Kleine-König
- Add more hardware descriptions at top of the driver.
- Remove unused api request and free
- Move the initialize settings of all pwm channel to probe.
- Change the method of getting the approximate period.
- Read the hardware register values to fill the state for .get_state()

Changes since v1:
- Fix the dt_binding_check fail suggested by Rob Herring
- Add depends to PWM_ASPEED_G6 configure suggested by Uwe Kleine-Konig
- pwm-aspeed-g6.c suggested by Uwe Kleine-König
- Fix license header
- Use bitfiled.h macro to define register fields
- Implement .remove device function
- Implement .get_state pwm api

Billy Tsai (2):
dt-bindings: Add bindings for aspeed pwm-tach.
pwm: Add Aspeed ast2600 PWM support

.../bindings/hwmon/aspeed,ast2600-tach.yaml | 68 ++++
.../bindings/mfd/aspeed,ast2600-pwm-tach.yaml | 76 ++++
.../bindings/pwm/aspeed,ast2600-pwm.yaml | 64 ++++
drivers/pwm/Kconfig | 10 +
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-aspeed-ast2600.c | 325 ++++++++++++++++++
6 files changed, 544 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/aspeed,ast2600-tach.yaml
create mode 100644 Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml
create mode 100644 Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml
create mode 100644 drivers/pwm/pwm-aspeed-ast2600.c

--
2.25.1



2021-11-30 05:59:51

by Billy Tsai

[permalink] [raw]
Subject: [v14 2/2] pwm: Add Aspeed ast2600 PWM support

This patch add the support of PWM controller which can be found at aspeed
ast2600 soc. The pwm supoorts up to 16 channels and it's part function
of multi-function device "pwm-tach controller".

Signed-off-by: Billy Tsai <[email protected]>
---
drivers/pwm/Kconfig | 10 +
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-aspeed-ast2600.c | 325 +++++++++++++++++++++++++++++++
3 files changed, 336 insertions(+)
create mode 100644 drivers/pwm/pwm-aspeed-ast2600.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 63be5362fd3a..b0d26f6c2a8f 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -51,6 +51,16 @@ config PWM_AB8500
To compile this driver as a module, choose M here: the module
will be called pwm-ab8500.

+config PWM_ASPEED_AST2600
+ tristate "Aspeed ast2600 PWM support"
+ depends on ARCH_ASPEED || COMPILE_TEST
+ depends on HAVE_CLK && HAS_IOMEM
+ help
+ This driver provides support for Aspeed ast2600 PWM controllers.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-aspeed-ast2600.
+
config PWM_ATMEL
tristate "Atmel PWM support"
depends on OF
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index cbdcd55d69ee..ada454f9129a 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_PWM) += core.o
obj-$(CONFIG_PWM_SYSFS) += sysfs.o
obj-$(CONFIG_PWM_AB8500) += pwm-ab8500.o
+obj-$(CONFIG_PWM_ASPEED_AST2600) += pwm-aspeed-ast2600.o
obj-$(CONFIG_PWM_ATMEL) += pwm-atmel.o
obj-$(CONFIG_PWM_ATMEL_HLCDC_PWM) += pwm-atmel-hlcdc.o
obj-$(CONFIG_PWM_ATMEL_TCB) += pwm-atmel-tcb.o
diff --git a/drivers/pwm/pwm-aspeed-ast2600.c b/drivers/pwm/pwm-aspeed-ast2600.c
new file mode 100644
index 000000000000..bf54eeb70372
--- /dev/null
+++ b/drivers/pwm/pwm-aspeed-ast2600.c
@@ -0,0 +1,325 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2021 Aspeed Technology Inc.
+ *
+ * PWM controller driver for Aspeed ast2600 SoCs.
+ * This drivers doesn't support earlier version of the IP.
+ *
+ * The hardware operates in time quantities of length
+ * Q := (DIV_L + 1) << DIV_H / input-clk
+ * The length of a PWM period is (DUTY_CYCLE_PERIOD + 1) * Q.
+ * The maximal value for DUTY_CYCLE_PERIOD is used here to provide
+ * a fine grained selection for the duty cycle.
+ *
+ * This driver uses DUTY_CYCLE_RISING_POINT = 0, so from the start of a
+ * period the output is active until DUTY_CYCLE_FALLING_POINT * Q. Note
+ * that if DUTY_CYCLE_RISING_POINT = DUTY_CYCLE_FALLING_POINT the output is
+ * always active.
+ *
+ * Register usage:
+ * PIN_ENABLE: When it is unset the pwm controller will emit inactive level to the external.
+ * Use to determine whether the PWM channel is enabled or disabled
+ * CLK_ENABLE: When it is unset the pwm controller will assert the duty counter reset and
+ * emit inactive level to the PIN_ENABLE mux after that the driver can still change the pwm period
+ * and duty and the value will apply when CLK_ENABLE be set again.
+ * Use to determine whether duty_cycle bigger than 0.
+ * PWM_ASPEED_CTRL_INVERSE: When it is toggled the output value will inverse immediately.
+ * PWM_ASPEED_DUTY_CYCLE_FALLING_POINT/PWM_ASPEED_DUTY_CYCLE_RISING_POINT: When these two
+ * values are equal it means the duty cycle = 100%.
+ *
+ * The glitch may generate at:
+ * - Enabled changing when the duty_cycle bigger than 0% and less than 100%.
+ * - Polarity changing when the duty_cycle bigger than 0% and less than 100%.
+ *
+ * Limitations:
+ * - When changing both duty cycle and period, we cannot prevent in
+ * software that the output might produce a period with mixed
+ * settings.
+ * - Disabling the PWM doesn't complete the current period.
+ *
+ * Improvements:
+ * - When only changing one of duty cycle or period, our pwm controller will not
+ * generate the glitch, the configure will change at next cycle of pwm.
+ * This improvement can disable/enable through PWM_ASPEED_CTRL_DUTY_SYNC_DISABLE.
+ */
+
+#include <linux/clk.h>
+#include <linux/errno.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/sysfs.h>
+#include <linux/reset.h>
+#include <linux/regmap.h>
+#include <linux/bitfield.h>
+#include <linux/slab.h>
+#include <linux/pwm.h>
+#include <linux/math64.h>
+
+/* The channel number of Aspeed pwm controller */
+#define PWM_ASPEED_NR_PWMS 16
+
+/* PWM Control Register */
+#define PWM_ASPEED_CTRL(ch) ((ch) * 0x10 + 0x00)
+#define PWM_ASPEED_CTRL_LOAD_SEL_RISING_AS_WDT BIT(19)
+#define PWM_ASPEED_CTRL_DUTY_LOAD_AS_WDT_ENABLE BIT(18)
+#define PWM_ASPEED_CTRL_DUTY_SYNC_DISABLE BIT(17)
+#define PWM_ASPEED_CTRL_CLK_ENABLE BIT(16)
+#define PWM_ASPEED_CTRL_LEVEL_OUTPUT BIT(15)
+#define PWM_ASPEED_CTRL_INVERSE BIT(14)
+#define PWM_ASPEED_CTRL_OPEN_DRAIN_ENABLE BIT(13)
+#define PWM_ASPEED_CTRL_PIN_ENABLE BIT(12)
+#define PWM_ASPEED_CTRL_CLK_DIV_H GENMASK(11, 8)
+#define PWM_ASPEED_CTRL_CLK_DIV_L GENMASK(7, 0)
+
+/* PWM Duty Cycle Register */
+#define PWM_ASPEED_DUTY_CYCLE(ch) ((ch) * 0x10 + 0x04)
+#define PWM_ASPEED_DUTY_CYCLE_PERIOD GENMASK(31, 24)
+#define PWM_ASPEED_DUTY_CYCLE_POINT_AS_WDT GENMASK(23, 16)
+#define PWM_ASPEED_DUTY_CYCLE_FALLING_POINT GENMASK(15, 8)
+#define PWM_ASPEED_DUTY_CYCLE_RISING_POINT GENMASK(7, 0)
+
+/* PWM fixed value */
+#define PWM_ASPEED_FIXED_PERIOD FIELD_MAX(PWM_ASPEED_DUTY_CYCLE_PERIOD)
+
+struct aspeed_pwm_data {
+ struct pwm_chip chip;
+ struct clk *clk;
+ struct regmap *regmap;
+ struct reset_control *reset;
+};
+
+static inline struct aspeed_pwm_data *
+aspeed_pwm_chip_to_data(struct pwm_chip *chip)
+{
+ return container_of(chip, struct aspeed_pwm_data, chip);
+}
+
+static void aspeed_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
+ struct pwm_state *state)
+{
+ struct device *dev = chip->dev;
+ struct aspeed_pwm_data *priv = aspeed_pwm_chip_to_data(chip);
+ u32 hwpwm = pwm->hwpwm;
+ bool polarity, pin_en, clk_en;
+ u32 duty_pt, val;
+ unsigned long rate;
+ u64 div_h, div_l, duty_cycle_period, dividend;
+
+ regmap_read(priv->regmap, PWM_ASPEED_CTRL(hwpwm), &val);
+ polarity = FIELD_GET(PWM_ASPEED_CTRL_INVERSE, val);
+ pin_en = FIELD_GET(PWM_ASPEED_CTRL_PIN_ENABLE, val);
+ clk_en = FIELD_GET(PWM_ASPEED_CTRL_CLK_ENABLE, val);
+ div_h = FIELD_GET(PWM_ASPEED_CTRL_CLK_DIV_H, val);
+ div_l = FIELD_GET(PWM_ASPEED_CTRL_CLK_DIV_L, val);
+ regmap_read(priv->regmap, PWM_ASPEED_DUTY_CYCLE(hwpwm), &val);
+ duty_pt = FIELD_GET(PWM_ASPEED_DUTY_CYCLE_FALLING_POINT, val);
+ duty_cycle_period = FIELD_GET(PWM_ASPEED_DUTY_CYCLE_PERIOD, val);
+
+ rate = clk_get_rate(priv->clk);
+
+ /*
+ * This multiplication doesn't overflow, the upper bound is
+ * 1000000000 * 256 * 256 << 15 = 0x1dcd650000000000
+ */
+ dividend = (u64)NSEC_PER_SEC * (div_l + 1) * (duty_cycle_period + 1)
+ << div_h;
+ state->period = DIV_ROUND_UP_ULL(dividend, rate);
+
+ if (clk_en && duty_pt) {
+ dividend = (u64)NSEC_PER_SEC * (div_l + 1) * duty_pt
+ << div_h;
+ state->duty_cycle = DIV_ROUND_UP_ULL(dividend, rate);
+ } else {
+ state->duty_cycle = clk_en ? state->period : 0;
+ }
+ state->polarity = polarity ? PWM_POLARITY_INVERSED : PWM_POLARITY_NORMAL;
+ state->enabled = pin_en;
+ dev_dbg(dev, "get period: %lldns, duty_cycle: %lldns", state->period,
+ state->duty_cycle);
+}
+
+static int aspeed_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+ const struct pwm_state *state)
+{
+ struct device *dev = chip->dev;
+ struct aspeed_pwm_data *priv = aspeed_pwm_chip_to_data(chip);
+ u32 hwpwm = pwm->hwpwm, duty_pt;
+ unsigned long rate;
+ u64 div_h, div_l, divisor, expect_period;
+ bool clk_en;
+
+ rate = clk_get_rate(priv->clk);
+ expect_period = min(div64_u64(ULLONG_MAX, (u64)rate), state->period);
+ dev_dbg(dev, "expect period: %lldns, duty_cycle: %lldns", expect_period,
+ state->duty_cycle);
+ /*
+ * Pick the smallest value for div_h so that div_l can be the biggest
+ * which results in a finer resolution near the target period value.
+ */
+ divisor = (u64)NSEC_PER_SEC * (PWM_ASPEED_FIXED_PERIOD + 1) *
+ (FIELD_MAX(PWM_ASPEED_CTRL_CLK_DIV_L) + 1);
+ div_h = order_base_2(DIV64_U64_ROUND_UP(rate * expect_period, divisor));
+ if (div_h > 0xf)
+ div_h = 0xf;
+
+ divisor = ((u64)NSEC_PER_SEC * (PWM_ASPEED_FIXED_PERIOD + 1)) << div_h;
+ div_l = div64_u64(rate * expect_period, divisor);
+
+ if (div_l == 0)
+ return -ERANGE;
+
+ div_l -= 1;
+
+ if (div_l > 255)
+ div_l = 255;
+
+ dev_dbg(dev, "clk source: %ld div_h %lld, div_l : %lld\n", rate, div_h,
+ div_l);
+ /* duty_pt = duty_cycle * (PERIOD + 1) / period */
+ duty_pt = div64_u64(state->duty_cycle * rate,
+ (u64)NSEC_PER_SEC * (div_l + 1) << div_h);
+ dev_dbg(dev, "duty_cycle = %lld, duty_pt = %d\n", state->duty_cycle,
+ duty_pt);
+
+ /*
+ * Fixed DUTY_CYCLE_PERIOD to its max value to get a
+ * fine-grained resolution for duty_cycle at the expense of a
+ * coarser period resolution.
+ */
+ regmap_update_bits(priv->regmap, PWM_ASPEED_DUTY_CYCLE(hwpwm),
+ PWM_ASPEED_DUTY_CYCLE_PERIOD,
+ FIELD_PREP(PWM_ASPEED_DUTY_CYCLE_PERIOD,
+ PWM_ASPEED_FIXED_PERIOD));
+ if (duty_pt == 0) {
+ /* emit inactive level and assert the duty counter reset */
+ clk_en = 0;
+ } else {
+ clk_en = 1;
+ if (duty_pt >= (PWM_ASPEED_FIXED_PERIOD + 1))
+ duty_pt = 0;
+ regmap_update_bits(
+ priv->regmap, PWM_ASPEED_DUTY_CYCLE(hwpwm),
+ PWM_ASPEED_DUTY_CYCLE_RISING_POINT |
+ PWM_ASPEED_DUTY_CYCLE_FALLING_POINT,
+ FIELD_PREP(PWM_ASPEED_DUTY_CYCLE_FALLING_POINT,
+ duty_pt));
+ }
+
+ regmap_update_bits(
+ priv->regmap, PWM_ASPEED_CTRL(hwpwm),
+ PWM_ASPEED_CTRL_CLK_DIV_H | PWM_ASPEED_CTRL_CLK_DIV_L |
+ PWM_ASPEED_CTRL_PIN_ENABLE |
+ PWM_ASPEED_CTRL_CLK_ENABLE | PWM_ASPEED_CTRL_INVERSE,
+ FIELD_PREP(PWM_ASPEED_CTRL_CLK_DIV_H, div_h) |
+ FIELD_PREP(PWM_ASPEED_CTRL_CLK_DIV_L, div_l) |
+ FIELD_PREP(PWM_ASPEED_CTRL_PIN_ENABLE, state->enabled) |
+ FIELD_PREP(PWM_ASPEED_CTRL_CLK_ENABLE, clk_en) |
+ FIELD_PREP(PWM_ASPEED_CTRL_INVERSE, state->polarity));
+ return 0;
+}
+
+static const struct pwm_ops aspeed_pwm_ops = {
+ .apply = aspeed_pwm_apply,
+ .get_state = aspeed_pwm_get_state,
+ .owner = THIS_MODULE,
+};
+
+static int aspeed_pwm_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ int ret;
+ struct aspeed_pwm_data *priv;
+ struct device_node *np;
+ struct platform_device *parent_dev;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ np = pdev->dev.parent->of_node;
+ if (!of_device_is_compatible(np, "aspeed,ast2600-pwm-tach"))
+ return dev_err_probe(dev, -ENODEV,
+ "Unsupported pwm device binding\n");
+
+ priv->regmap = syscon_node_to_regmap(np);
+ if (IS_ERR(priv->regmap))
+ return dev_err_probe(dev, PTR_ERR(priv->regmap),
+ "Couldn't get regmap\n");
+
+ parent_dev = of_find_device_by_node(np);
+ priv->clk = devm_clk_get(&parent_dev->dev, 0);
+ if (IS_ERR(priv->clk))
+ return dev_err_probe(dev, PTR_ERR(priv->clk),
+ "Couldn't get clock\n");
+
+ priv->reset = devm_reset_control_get_shared(&parent_dev->dev, NULL);
+ if (IS_ERR(priv->reset))
+ return dev_err_probe(dev, PTR_ERR(priv->reset),
+ "Couldn't get reset control\n");
+
+ ret = clk_prepare_enable(priv->clk);
+ if (ret)
+ return dev_err_probe(dev, ret, "Couldn't enable clock\n");
+
+ ret = reset_control_deassert(priv->reset);
+ if (ret) {
+ dev_err_probe(dev, ret, "Couldn't deassert reset control\n");
+ goto err_disable_clk;
+ }
+
+ priv->chip.dev = dev;
+ priv->chip.ops = &aspeed_pwm_ops;
+ priv->chip.npwm = PWM_ASPEED_NR_PWMS;
+
+ ret = pwmchip_add(&priv->chip);
+ if (ret < 0) {
+ dev_err_probe(dev, ret, "Failed to add PWM chip\n");
+ goto err_assert_reset;
+ }
+ dev_set_drvdata(dev, priv);
+ return 0;
+err_assert_reset:
+ reset_control_assert(priv->reset);
+err_disable_clk:
+ clk_disable_unprepare(priv->clk);
+ return ret;
+}
+
+static int aspeed_pwm_remove(struct platform_device *dev)
+{
+ struct aspeed_pwm_data *priv = platform_get_drvdata(dev);
+
+ pwmchip_remove(&priv->chip);
+ reset_control_assert(priv->reset);
+ clk_disable_unprepare(priv->clk);
+
+ return 0;
+}
+
+static const struct of_device_id of_pwm_match_table[] = {
+ {
+ .compatible = "aspeed,ast2600-pwm",
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, of_pwm_match_table);
+
+static struct platform_driver aspeed_pwm_driver = {
+ .probe = aspeed_pwm_probe,
+ .remove = aspeed_pwm_remove,
+ .driver = {
+ .name = "aspeed-pwm",
+ .of_match_table = of_pwm_match_table,
+ },
+};
+
+module_platform_driver(aspeed_pwm_driver);
+
+MODULE_AUTHOR("Billy Tsai <[email protected]>");
+MODULE_DESCRIPTION("Aspeed ast2600 PWM device driver");
+MODULE_LICENSE("GPL v2");
--
2.25.1


2021-11-30 06:59:26

by Uwe Kleine-König

[permalink] [raw]
Subject: Re: [v14 2/2] pwm: Add Aspeed ast2600 PWM support

Hello Billy,

On Tue, Nov 30, 2021 at 01:59:33PM +0800, Billy Tsai wrote:
> This patch add the support of PWM controller which can be found at aspeed
> ast2600 soc. The pwm supoorts up to 16 channels and it's part function
> of multi-function device "pwm-tach controller".
>
> Signed-off-by: Billy Tsai <[email protected]>

Reviewed-by: Uwe Kleine-K?nig <[email protected]>

Thanks
Uwe

--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |


Attachments:
(No filename) (563.00 B)
signature.asc (488.00 B)
Download all attachments

2021-12-07 06:46:03

by Joel Stanley

[permalink] [raw]
Subject: Re: [v14 0/2] Support pwm driver for aspeed ast26xx

Hi Billy,

On Tue, 30 Nov 2021 at 05:58, Billy Tsai <[email protected]> wrote:
>
> The legacy driver of aspeed pwm is binding with tach controller and it
> doesn't follow the pwm framworks usage. In addition, the pwm register
> usage of the 6th generation of ast26xx has drastic change. So these
> patch serials add the new aspeed pwm driver to fix up the problem above.

Sorry for not taking a look earlier. Well done on making it this far.

There's a few things that need to be addressed before merging this.

Firstly, the bindings need fixing up. I think these should be the one
file. The device tree bindings are supposed to describe the hardware,
and it doesn't make sense to separate them out just because we plan on
using two subsystems to implement the functionality.

Rob, please chime in if you would prefer something different.

Secondly, we need to clarify why this is a pwm driver and not a hwmon
driver like we had for the 2500 hardware, and that you're planning on
submitting a hwmon driver for the other half of the registers.

Finally, do you really need to use regmap? It's lots of overhead for a
mmio driver, and I like to see it avoided where possible. I know the
regions are shared, but are there any individual registers shared?

Cheers,

Joel



>
> Change since v13:
> - pwm-aspeed-ast2600.c
> - Fix the usage of the braces to meet the coding-style.rst
> - Use min function to reduce the times of division.
>
> Change since v12:
> - pwm-aspeed-ast2600.c
> - Fix the comment about the duty cycle and period of the PWM.
> - Configured to max period when request period > max period.
> - Remove unnecessary curly braces.
>
> Change since v11:
> - pwm-aspeed-ast2600.c
> - Request reset controller before clock enable.
>
> Change since v10:
> - pwm-aspeed-ast2600.c
> - Add more comment to explain the feature of PWM
> - Fix the naming of some parameters.
> - Set pin_enable and clk_enable at the same time.
> - Always set fixed divisor to hw register when apply.
>
> Change since v9:
> - dt-bindings:
> - Change the naming of tach subnode channel setting property to
> aspeed,tach-ch.
> - pwm-aspeed-ast2600.c
> - Fix the naming of some parameters.
> - Capitalise error messages.
> - Handling potentially mult overflow when .apply
>
> Change since v8:
> - pwm-aspeed-ast2600.c
> - Replace "* _BITULL(div_h)" to "<< div_h"
> - Fix duty_cycle precision problem.
> - Add the comment about the formula of duty_cycle.
>
> Change since v7:
> - pwm-aspeed-g6.c
> - Rename the driver: pwm-aspeed-g6.c -> pwm-aspeed-ast2600.c.
> - Macro remove "_CH" part of the register name.
> - Unroll the aspeed_pwm_get_period and remove it.
> - Simplify the formula to get duty_pt
> - Reduce the number of writing register. Organize all the fields and
> write them at once.
>
> Change since v6:
> - dt-bindings:
> - Add blank line between each DT property.
> - Change the sub-node name from fan to tach-ch.
> - pwm-aspeed-g6.c
> - Merge aspeed_pwm_set_period and aspeed_pwm_set_duty into .apply.
> - Convert the factor type to u64 when calculating the period value.
> - Using ROUND_UP strategy to calculate div_h for finer resolution.
>
> Change since v5:
> - pwm-aspeed-g6.c suggested by Uwe Kleine-König
> - Move the divide at the end of the calculation.
> - Unified the prefix of the function name.
> - Use div64_u64 to calculate the divider of frequency.
>
> Change since v4:
> - dt_binding:
> - pwm/tach yaml: Replace child-node with additionalProperties
> - pwm-tach yaml: Replace child-node with patternProperties
> - pwm-aspeed-g6.c suggested by Uwe Kleine-König
> - The bit definitions contained the name of the register.
> - Remove single caller function and fold it to the caller.
> - Avoid to divide by the result of a division.
> - Remove unnecessary condition in .apply().
> - Use goto for error handling
>
> Changes since v3:
> - Add the dt_binding for aspeed,ast2600-tach.
> - Describe the pwm/tach as child-node of pwm-tach mfd.
> - Complete the properties of pwm node.
>
> Changes since v2:
> - Remove the tach node, #address-cells and #size-cells from pwm-tach.yaml
> - Add clocks and reset properties to pwm-tach.yaml
> - Kconfig/Makfile sorted alphabetically
> - pwm-aspeed-g6.c suggested by Uwe Kleine-König
> - Add more hardware descriptions at top of the driver.
> - Remove unused api request and free
> - Move the initialize settings of all pwm channel to probe.
> - Change the method of getting the approximate period.
> - Read the hardware register values to fill the state for .get_state()
>
> Changes since v1:
> - Fix the dt_binding_check fail suggested by Rob Herring
> - Add depends to PWM_ASPEED_G6 configure suggested by Uwe Kleine-Konig
> - pwm-aspeed-g6.c suggested by Uwe Kleine-König
> - Fix license header
> - Use bitfiled.h macro to define register fields
> - Implement .remove device function
> - Implement .get_state pwm api
>
> Billy Tsai (2):
> dt-bindings: Add bindings for aspeed pwm-tach.
> pwm: Add Aspeed ast2600 PWM support
>
> .../bindings/hwmon/aspeed,ast2600-tach.yaml | 68 ++++
> .../bindings/mfd/aspeed,ast2600-pwm-tach.yaml | 76 ++++
> .../bindings/pwm/aspeed,ast2600-pwm.yaml | 64 ++++
> drivers/pwm/Kconfig | 10 +
> drivers/pwm/Makefile | 1 +
> drivers/pwm/pwm-aspeed-ast2600.c | 325 ++++++++++++++++++
> 6 files changed, 544 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/aspeed,ast2600-tach.yaml
> create mode 100644 Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml
> create mode 100644 Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml
> create mode 100644 drivers/pwm/pwm-aspeed-ast2600.c
>
> --
> 2.25.1
>

2021-12-07 21:20:03

by Rob Herring (Arm)

[permalink] [raw]
Subject: Re: [v14 0/2] Support pwm driver for aspeed ast26xx

On Tue, Dec 07, 2021 at 06:45:47AM +0000, Joel Stanley wrote:
> Hi Billy,
>
> On Tue, 30 Nov 2021 at 05:58, Billy Tsai <[email protected]> wrote:
> >
> > The legacy driver of aspeed pwm is binding with tach controller and it
> > doesn't follow the pwm framworks usage. In addition, the pwm register
> > usage of the 6th generation of ast26xx has drastic change. So these
> > patch serials add the new aspeed pwm driver to fix up the problem above.
>
> Sorry for not taking a look earlier. Well done on making it this far.
>
> There's a few things that need to be addressed before merging this.
>
> Firstly, the bindings need fixing up. I think these should be the one
> file. The device tree bindings are supposed to describe the hardware,
> and it doesn't make sense to separate them out just because we plan on
> using two subsystems to implement the functionality.
>
> Rob, please chime in if you would prefer something different.

I prefer to see a common binding for fans which I said multiple times
on this series. As the same thing keeps getting posted, I've stopped
looking at this one.

Rob

2021-12-08 04:02:32

by Billy Tsai

[permalink] [raw]
Subject: Re: [v14 0/2] Support pwm driver for aspeed ast26xx

Hi Rob,

On 2021/12/8, 5:20 AM, "Rob Herring" <[email protected]> wrote:

On Tue, Dec 07, 2021 at 06:45:47AM +0000, Joel Stanley wrote:
> > Hi Billy,
> >
> > On Tue, 30 Nov 2021 at 05:58, Billy Tsai <[email protected]> wrote:
> > >
> > > The legacy driver of aspeed pwm is binding with tach controller and it
> > > doesn't follow the pwm framworks usage. In addition, the pwm register
> > > usage of the 6th generation of ast26xx has drastic change. So these
> > > patch serials add the new aspeed pwm driver to fix up the problem above.
> >
> > Sorry for not taking a look earlier. Well done on making it this far.
> >
> > There's a few things that need to be addressed before merging this.
> >
> > Firstly, the bindings need fixing up. I think these should be the one
> > file. The device tree bindings are supposed to describe the hardware,
> > and it doesn't make sense to separate them out just because we plan on
> > using two subsystems to implement the functionality.
> >
> > Rob, please chime in if you would prefer something different.

> I prefer to see a common binding for fans which I said multiple times
> on this series. As the same thing keeps getting posted, I've stopped
> looking at this one.

Sorry to have bothered you so many times.
As I mention in v9:
"This patch doesn't use to binding the fan control h/w. It is used to binding the two independent h/w blocks.
One is used to provide pwm output and another is used to monitor the speed of the input.
It is different from "aspeed-pwm-tacho.txt" and "npcm750-pwm-fan.txt" which only focus on fan usage.
It is more like the "kontron,sl28cpld.yaml" the device includes a fan monitor and PWM output devices."
My purpose is to give more flexibility to our drivers and can use the existing driver "pwm-fan" to control
the fan instead of creating the code like XXX-pwm-fan to do the same thing.

Thanks

Best Regards,
Billy Tsai