* [v9 0/2] Support pwm driver for aspeed ast26xx
@ 2021-07-09 6:52 ` Billy Tsai
0 siblings, 0 replies; 34+ messages in thread
From: Billy Tsai @ 2021-07-09 6:52 UTC (permalink / raw)
To: lee.jones, robh+dt, joel, andrew, thierry.reding,
u.kleine-koenig, p.zabel, billy_tsai, devicetree,
linux-arm-kernel, linux-aspeed, linux-kernel, linux-pwm
Cc: BMC-SW
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 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 writting 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 | 69 ++++
.../bindings/mfd/aspeed,ast2600-pwm-tach.yaml | 87 +++++
.../bindings/pwm/aspeed,ast2600-pwm.yaml | 64 ++++
drivers/pwm/Kconfig | 9 +
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-aspeed-ast2600.c | 316 ++++++++++++++++++
6 files changed, 546 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
^ permalink raw reply [flat|nested] 34+ messages in thread
* [v9 0/2] Support pwm driver for aspeed ast26xx
@ 2021-07-09 6:52 ` Billy Tsai
0 siblings, 0 replies; 34+ messages in thread
From: Billy Tsai @ 2021-07-09 6:52 UTC (permalink / raw)
To: lee.jones, robh+dt, joel, andrew, thierry.reding,
u.kleine-koenig, p.zabel, billy_tsai, devicetree,
linux-arm-kernel, linux-aspeed, linux-kernel, linux-pwm
Cc: BMC-SW
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 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 writting 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 | 69 ++++
.../bindings/mfd/aspeed,ast2600-pwm-tach.yaml | 87 +++++
.../bindings/pwm/aspeed,ast2600-pwm.yaml | 64 ++++
drivers/pwm/Kconfig | 9 +
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-aspeed-ast2600.c | 316 ++++++++++++++++++
6 files changed, 546 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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 34+ messages in thread
* [v9 1/2] dt-bindings: Add bindings for aspeed pwm-tach.
2021-07-09 6:52 ` Billy Tsai
@ 2021-07-09 6:52 ` Billy Tsai
-1 siblings, 0 replies; 34+ messages in thread
From: Billy Tsai @ 2021-07-09 6:52 UTC (permalink / raw)
To: lee.jones, robh+dt, joel, andrew, thierry.reding,
u.kleine-koenig, p.zabel, billy_tsai, devicetree,
linux-arm-kernel, linux-aspeed, linux-kernel, linux-pwm
Cc: BMC-SW
This patch adds device binding for aspeed pwm-tach device which is a
multi-function device include pwm and tach function and pwm/tach device
bindings which should be the child-node of pwm-tach device.
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
---
.../bindings/hwmon/aspeed,ast2600-tach.yaml | 69 +++++++++++++++
.../bindings/mfd/aspeed,ast2600-pwm-tach.yaml | 87 +++++++++++++++++++
.../bindings/pwm/aspeed,ast2600-pwm.yaml | 64 ++++++++++++++
3 files changed, 220 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
diff --git a/Documentation/devicetree/bindings/hwmon/aspeed,ast2600-tach.yaml b/Documentation/devicetree/bindings/hwmon/aspeed,ast2600-tach.yaml
new file mode 100644
index 000000000000..a08471f96a61
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/aspeed,ast2600-tach.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2021 Aspeed, Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/aspeed,ast2600-tach.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Aspeed Ast2600 Tach controller
+
+maintainers:
+ - Billy Tsai <billy_tsai@aspeedtech.com>
+
+description: |
+ The Aspeed Tach controller can support upto 16 fan input.
+ This module is part of the ast2600-pwm-tach multi-function device. For more
+ details see ../mfd/aspeed,ast2600-pwm-tach.yaml.
+
+properties:
+ compatible:
+ enum:
+ - aspeed,ast2600-tach
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ pinctrl-0: true
+
+ pinctrl-names:
+ const: default
+
+required:
+ - compatible
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties:
+ type: object
+ properties:
+ reg:
+ description:
+ The tach channel used for this fan.
+ maxItems: 1
+
+ aspeed,min-rpm:
+ description:
+ define the minimal revolutions per minute of the measure fan
+ used to calculate the sample period of tach
+ default: 1000
+
+ aspeed,pulse-pr:
+ description:
+ Value specifying the number of pulses per revolution of the
+ monitored FAN.
+ default: 2
+
+ aspeed,tach-div:
+ description:
+ define the tachometer clock divider as an integer. Formula of
+ tach clock = clock source / (2^tach-div)^2
+ minimum: 0
+ maximum: 15
+ # The value that should be used if the property is not present
+ default: 5
+
+ required:
+ - reg
diff --git a/Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml b/Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml
new file mode 100644
index 000000000000..ab49aff1928a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2021 Aspeed, Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/aspeed,ast2600-pwm-tach.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PWM Tach controller Device Tree Bindings
+
+description: |
+ The PWM Tach controller is represented as a multi-function device which
+ includes:
+ PWM
+ Tach
+
+maintainers:
+ - Billy Tsai <billy_tsai@aspeedtech.com>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - aspeed,ast2600-pwm-tach
+ - const: syscon
+ - const: simple-mfd
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - resets
+
+patternProperties:
+ "^pwm(@[0-9a-f]+)?$":
+ $ref: ../pwm/aspeed,ast2600-pwm.yaml
+
+ "^tach(@[0-9a-f]+)?$":
+ $ref: ../hwmon/aspeed,ast2600-tach.yaml
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/ast2600-clock.h>
+ pwm_tach: pwm_tach@1e610000 {
+ compatible = "aspeed,ast2600-pwm-tach", "syscon", "simple-mfd";
+ reg = <0x1e610000 0x100>;
+ clocks = <&syscon ASPEED_CLK_AHB>;
+ resets = <&syscon ASPEED_RESET_PWM>;
+
+ pwm: pwm {
+ compatible = "aspeed,ast2600-pwm";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #pwm-cells = <3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm0_default>;
+ pwm-ch@0 {
+ reg = <0>;
+ aspeed,wdt-reload-enable;
+ aspeed,wdt-reload-duty-point = <32>;
+ };
+ };
+
+ tach: tach {
+ compatible = "aspeed,ast2600-tach";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tach0_default>;
+ tach-ch@0 {
+ reg = <0>;
+ aspeed,min-rpm = <1000>;
+ aspeed,pulse-pr = <2>;
+ aspeed,tach-div = <5>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml b/Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml
new file mode 100644
index 000000000000..f501f8a769df
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2021 Aspeed, Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/aspeed,ast2600-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Aspeed Ast2600 PWM controller
+
+maintainers:
+ - Billy Tsai <billy_tsai@aspeedtech.com>
+
+description: |
+ The Aspeed PWM controller can support upto 16 PWM outputs.
+ This module is part of the ast2600-pwm-tach multi-function device. For more
+ details see ../mfd/aspeed,ast2600-pwm-tach.yaml.
+
+properties:
+ compatible:
+ enum:
+ - aspeed,ast2600-pwm
+
+ "#pwm-cells":
+ const: 3
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ pinctrl-0: true
+
+ pinctrl-names:
+ const: default
+
+required:
+ - compatible
+ - "#pwm-cells"
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties:
+ description: Set extend properties for each pwm channel.
+ type: object
+ properties:
+ reg:
+ description:
+ The pwm channel index.
+ maxItems: 1
+
+ aspeed,wdt-reload-enable:
+ type: boolean
+ description:
+ Enable the function of wdt reset reload duty point.
+
+ aspeed,wdt-reload-duty-point:
+ description:
+ Define the duty point after wdt reset, 0 = 100%
+ minimum: 0
+ maximum: 255
+
+ required:
+ - reg
--
2.25.1
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [v9 1/2] dt-bindings: Add bindings for aspeed pwm-tach.
@ 2021-07-09 6:52 ` Billy Tsai
0 siblings, 0 replies; 34+ messages in thread
From: Billy Tsai @ 2021-07-09 6:52 UTC (permalink / raw)
To: lee.jones, robh+dt, joel, andrew, thierry.reding,
u.kleine-koenig, p.zabel, billy_tsai, devicetree,
linux-arm-kernel, linux-aspeed, linux-kernel, linux-pwm
Cc: BMC-SW
This patch adds device binding for aspeed pwm-tach device which is a
multi-function device include pwm and tach function and pwm/tach device
bindings which should be the child-node of pwm-tach device.
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
---
.../bindings/hwmon/aspeed,ast2600-tach.yaml | 69 +++++++++++++++
.../bindings/mfd/aspeed,ast2600-pwm-tach.yaml | 87 +++++++++++++++++++
.../bindings/pwm/aspeed,ast2600-pwm.yaml | 64 ++++++++++++++
3 files changed, 220 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
diff --git a/Documentation/devicetree/bindings/hwmon/aspeed,ast2600-tach.yaml b/Documentation/devicetree/bindings/hwmon/aspeed,ast2600-tach.yaml
new file mode 100644
index 000000000000..a08471f96a61
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/aspeed,ast2600-tach.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2021 Aspeed, Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/aspeed,ast2600-tach.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Aspeed Ast2600 Tach controller
+
+maintainers:
+ - Billy Tsai <billy_tsai@aspeedtech.com>
+
+description: |
+ The Aspeed Tach controller can support upto 16 fan input.
+ This module is part of the ast2600-pwm-tach multi-function device. For more
+ details see ../mfd/aspeed,ast2600-pwm-tach.yaml.
+
+properties:
+ compatible:
+ enum:
+ - aspeed,ast2600-tach
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ pinctrl-0: true
+
+ pinctrl-names:
+ const: default
+
+required:
+ - compatible
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties:
+ type: object
+ properties:
+ reg:
+ description:
+ The tach channel used for this fan.
+ maxItems: 1
+
+ aspeed,min-rpm:
+ description:
+ define the minimal revolutions per minute of the measure fan
+ used to calculate the sample period of tach
+ default: 1000
+
+ aspeed,pulse-pr:
+ description:
+ Value specifying the number of pulses per revolution of the
+ monitored FAN.
+ default: 2
+
+ aspeed,tach-div:
+ description:
+ define the tachometer clock divider as an integer. Formula of
+ tach clock = clock source / (2^tach-div)^2
+ minimum: 0
+ maximum: 15
+ # The value that should be used if the property is not present
+ default: 5
+
+ required:
+ - reg
diff --git a/Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml b/Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml
new file mode 100644
index 000000000000..ab49aff1928a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2021 Aspeed, Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/aspeed,ast2600-pwm-tach.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PWM Tach controller Device Tree Bindings
+
+description: |
+ The PWM Tach controller is represented as a multi-function device which
+ includes:
+ PWM
+ Tach
+
+maintainers:
+ - Billy Tsai <billy_tsai@aspeedtech.com>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - aspeed,ast2600-pwm-tach
+ - const: syscon
+ - const: simple-mfd
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - resets
+
+patternProperties:
+ "^pwm(@[0-9a-f]+)?$":
+ $ref: ../pwm/aspeed,ast2600-pwm.yaml
+
+ "^tach(@[0-9a-f]+)?$":
+ $ref: ../hwmon/aspeed,ast2600-tach.yaml
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/ast2600-clock.h>
+ pwm_tach: pwm_tach@1e610000 {
+ compatible = "aspeed,ast2600-pwm-tach", "syscon", "simple-mfd";
+ reg = <0x1e610000 0x100>;
+ clocks = <&syscon ASPEED_CLK_AHB>;
+ resets = <&syscon ASPEED_RESET_PWM>;
+
+ pwm: pwm {
+ compatible = "aspeed,ast2600-pwm";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #pwm-cells = <3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm0_default>;
+ pwm-ch@0 {
+ reg = <0>;
+ aspeed,wdt-reload-enable;
+ aspeed,wdt-reload-duty-point = <32>;
+ };
+ };
+
+ tach: tach {
+ compatible = "aspeed,ast2600-tach";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tach0_default>;
+ tach-ch@0 {
+ reg = <0>;
+ aspeed,min-rpm = <1000>;
+ aspeed,pulse-pr = <2>;
+ aspeed,tach-div = <5>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml b/Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml
new file mode 100644
index 000000000000..f501f8a769df
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2021 Aspeed, Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/aspeed,ast2600-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Aspeed Ast2600 PWM controller
+
+maintainers:
+ - Billy Tsai <billy_tsai@aspeedtech.com>
+
+description: |
+ The Aspeed PWM controller can support upto 16 PWM outputs.
+ This module is part of the ast2600-pwm-tach multi-function device. For more
+ details see ../mfd/aspeed,ast2600-pwm-tach.yaml.
+
+properties:
+ compatible:
+ enum:
+ - aspeed,ast2600-pwm
+
+ "#pwm-cells":
+ const: 3
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ pinctrl-0: true
+
+ pinctrl-names:
+ const: default
+
+required:
+ - compatible
+ - "#pwm-cells"
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties:
+ description: Set extend properties for each pwm channel.
+ type: object
+ properties:
+ reg:
+ description:
+ The pwm channel index.
+ maxItems: 1
+
+ aspeed,wdt-reload-enable:
+ type: boolean
+ description:
+ Enable the function of wdt reset reload duty point.
+
+ aspeed,wdt-reload-duty-point:
+ description:
+ Define the duty point after wdt reset, 0 = 100%
+ minimum: 0
+ maximum: 255
+
+ required:
+ - reg
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [v9 2/2] pwm: Add Aspeed ast2600 PWM support
2021-07-09 6:52 ` Billy Tsai
@ 2021-07-09 6:52 ` Billy Tsai
-1 siblings, 0 replies; 34+ messages in thread
From: Billy Tsai @ 2021-07-09 6:52 UTC (permalink / raw)
To: lee.jones, robh+dt, joel, andrew, thierry.reding,
u.kleine-koenig, p.zabel, billy_tsai, devicetree,
linux-arm-kernel, linux-aspeed, linux-kernel, linux-pwm
Cc: BMC-SW
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 <billy_tsai@aspeedtech.com>
---
drivers/pwm/Kconfig | 9 +
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-aspeed-ast2600.c | 316 +++++++++++++++++++++++++++++++
3 files changed, 326 insertions(+)
create mode 100644 drivers/pwm/pwm-aspeed-ast2600.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 63be5362fd3a..a5aac3ca4ac7 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -51,6 +51,15 @@ 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
+ 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..68a45ba3b32b
--- /dev/null
+++ b/drivers/pwm/pwm-aspeed-ast2600.c
@@ -0,0 +1,316 @@
+// 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 formula of pwm period duration:
+ * period duration = ((DIV_L + 1) * (PERIOD + 1) << DIV_H) / input-clk
+ *
+ * The formula of pwm duty cycle duration:
+ * duty cycle duration = period duration * DUTY_CYCLE_FALLING_POINT / (PERIOD + 1)
+ * = ((DIV_L + 1) * DUTY_CYCLE_FALLING_POINT << DIV_H) / input-clk
+ *
+ * The software driver fixes the period to 255, which causes the high-frequency
+ * precision of the PWM to be coarse, in exchange for the fineness of the duty cycle.
+ *
+ * Register usage:
+ * PIN_ENABLE: When it is unset the pwm controller will always output low to the extern.
+ * Use to determine whether the PWM channel is enabled or disabled
+ * CLK_ENABLE: When it is unset the pwm controller will reset the duty counter to 0 and
+ * output low 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%.
+ *
+ * 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 index = pwm->hwpwm;
+ bool polarity, ch_en, clk_en;
+ u32 duty_pt, val;
+ unsigned long rate;
+ u64 div_h, div_l, clk_period;
+
+ regmap_read(priv->regmap, PWM_ASPEED_CTRL(index), &val);
+ polarity = FIELD_GET(PWM_ASPEED_CTRL_INVERSE, val);
+ ch_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(index), &val);
+ duty_pt = FIELD_GET(PWM_ASPEED_DUTY_CYCLE_FALLING_POINT, val);
+ clk_period = FIELD_GET(PWM_ASPEED_DUTY_CYCLE_PERIOD, val);
+
+ rate = clk_get_rate(priv->clk);
+ state->period = DIV_ROUND_UP_ULL(
+ (u64)NSEC_PER_SEC * (div_l + 1) * (clk_period + 1) << div_h,
+ rate);
+
+ if (clk_en && duty_pt)
+ state->duty_cycle = DIV_ROUND_UP_ULL(
+ (u64)NSEC_PER_SEC * (div_l + 1) * duty_pt << div_h,
+ rate);
+ else
+ state->duty_cycle = clk_en ? state->period : 0;
+ state->polarity = polarity;
+ state->enabled = ch_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 index = pwm->hwpwm, duty_pt;
+ unsigned long rate;
+ u64 div_h, div_l, divisor;
+ bool clk_en;
+
+ dev_dbg(dev, "expect period: %lldns, duty_cycle: %lldns", state->period,
+ state->duty_cycle);
+
+ rate = clk_get_rate(priv->clk);
+ /*
+ * 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 * state->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 * state->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);
+
+ regmap_update_bits(priv->regmap, PWM_ASPEED_CTRL(index),
+ PWM_ASPEED_CTRL_PIN_ENABLE,
+ state->enabled ? PWM_ASPEED_CTRL_PIN_ENABLE : 0);
+
+ if (duty_pt == 0)
+ clk_en = 0;
+ else {
+ clk_en = 1;
+ if (duty_pt >= (PWM_ASPEED_FIXED_PERIOD + 1))
+ duty_pt = 0;
+ /*
+ * 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(index),
+ PWM_ASPEED_DUTY_CYCLE_PERIOD |
+ PWM_ASPEED_DUTY_CYCLE_RISING_POINT |
+ PWM_ASPEED_DUTY_CYCLE_FALLING_POINT,
+ FIELD_PREP(PWM_ASPEED_DUTY_CYCLE_PERIOD,
+ PWM_ASPEED_FIXED_PERIOD) |
+ FIELD_PREP(PWM_ASPEED_DUTY_CYCLE_FALLING_POINT,
+ duty_pt));
+ }
+
+ regmap_update_bits(priv->regmap, PWM_ASPEED_CTRL(index),
+ PWM_ASPEED_CTRL_CLK_DIV_H |
+ PWM_ASPEED_CTRL_CLK_DIV_L |
+ 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_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");
+
+ ret = clk_prepare_enable(priv->clk);
+ if (ret)
+ return dev_err_probe(dev, ret, "couldn't enable clock\n");
+
+ priv->reset = devm_reset_control_get_shared(&parent_dev->dev, NULL);
+ if (IS_ERR(priv->reset)) {
+ ret = dev_err_probe(dev, PTR_ERR(priv->reset),
+ "get reset failed\n");
+ goto err_disable_clk;
+ }
+ ret = reset_control_deassert(priv->reset);
+ if (ret) {
+ dev_err_probe(dev, ret, "cannot 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 <billy_tsai@aspeedtech.com>");
+MODULE_DESCRIPTION("Aspeed ast2600 PWM device driver");
+MODULE_LICENSE("GPL v2");
--
2.25.1
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [v9 2/2] pwm: Add Aspeed ast2600 PWM support
@ 2021-07-09 6:52 ` Billy Tsai
0 siblings, 0 replies; 34+ messages in thread
From: Billy Tsai @ 2021-07-09 6:52 UTC (permalink / raw)
To: lee.jones, robh+dt, joel, andrew, thierry.reding,
u.kleine-koenig, p.zabel, billy_tsai, devicetree,
linux-arm-kernel, linux-aspeed, linux-kernel, linux-pwm
Cc: BMC-SW
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 <billy_tsai@aspeedtech.com>
---
drivers/pwm/Kconfig | 9 +
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-aspeed-ast2600.c | 316 +++++++++++++++++++++++++++++++
3 files changed, 326 insertions(+)
create mode 100644 drivers/pwm/pwm-aspeed-ast2600.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 63be5362fd3a..a5aac3ca4ac7 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -51,6 +51,15 @@ 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
+ 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..68a45ba3b32b
--- /dev/null
+++ b/drivers/pwm/pwm-aspeed-ast2600.c
@@ -0,0 +1,316 @@
+// 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 formula of pwm period duration:
+ * period duration = ((DIV_L + 1) * (PERIOD + 1) << DIV_H) / input-clk
+ *
+ * The formula of pwm duty cycle duration:
+ * duty cycle duration = period duration * DUTY_CYCLE_FALLING_POINT / (PERIOD + 1)
+ * = ((DIV_L + 1) * DUTY_CYCLE_FALLING_POINT << DIV_H) / input-clk
+ *
+ * The software driver fixes the period to 255, which causes the high-frequency
+ * precision of the PWM to be coarse, in exchange for the fineness of the duty cycle.
+ *
+ * Register usage:
+ * PIN_ENABLE: When it is unset the pwm controller will always output low to the extern.
+ * Use to determine whether the PWM channel is enabled or disabled
+ * CLK_ENABLE: When it is unset the pwm controller will reset the duty counter to 0 and
+ * output low 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%.
+ *
+ * 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 index = pwm->hwpwm;
+ bool polarity, ch_en, clk_en;
+ u32 duty_pt, val;
+ unsigned long rate;
+ u64 div_h, div_l, clk_period;
+
+ regmap_read(priv->regmap, PWM_ASPEED_CTRL(index), &val);
+ polarity = FIELD_GET(PWM_ASPEED_CTRL_INVERSE, val);
+ ch_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(index), &val);
+ duty_pt = FIELD_GET(PWM_ASPEED_DUTY_CYCLE_FALLING_POINT, val);
+ clk_period = FIELD_GET(PWM_ASPEED_DUTY_CYCLE_PERIOD, val);
+
+ rate = clk_get_rate(priv->clk);
+ state->period = DIV_ROUND_UP_ULL(
+ (u64)NSEC_PER_SEC * (div_l + 1) * (clk_period + 1) << div_h,
+ rate);
+
+ if (clk_en && duty_pt)
+ state->duty_cycle = DIV_ROUND_UP_ULL(
+ (u64)NSEC_PER_SEC * (div_l + 1) * duty_pt << div_h,
+ rate);
+ else
+ state->duty_cycle = clk_en ? state->period : 0;
+ state->polarity = polarity;
+ state->enabled = ch_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 index = pwm->hwpwm, duty_pt;
+ unsigned long rate;
+ u64 div_h, div_l, divisor;
+ bool clk_en;
+
+ dev_dbg(dev, "expect period: %lldns, duty_cycle: %lldns", state->period,
+ state->duty_cycle);
+
+ rate = clk_get_rate(priv->clk);
+ /*
+ * 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 * state->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 * state->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);
+
+ regmap_update_bits(priv->regmap, PWM_ASPEED_CTRL(index),
+ PWM_ASPEED_CTRL_PIN_ENABLE,
+ state->enabled ? PWM_ASPEED_CTRL_PIN_ENABLE : 0);
+
+ if (duty_pt == 0)
+ clk_en = 0;
+ else {
+ clk_en = 1;
+ if (duty_pt >= (PWM_ASPEED_FIXED_PERIOD + 1))
+ duty_pt = 0;
+ /*
+ * 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(index),
+ PWM_ASPEED_DUTY_CYCLE_PERIOD |
+ PWM_ASPEED_DUTY_CYCLE_RISING_POINT |
+ PWM_ASPEED_DUTY_CYCLE_FALLING_POINT,
+ FIELD_PREP(PWM_ASPEED_DUTY_CYCLE_PERIOD,
+ PWM_ASPEED_FIXED_PERIOD) |
+ FIELD_PREP(PWM_ASPEED_DUTY_CYCLE_FALLING_POINT,
+ duty_pt));
+ }
+
+ regmap_update_bits(priv->regmap, PWM_ASPEED_CTRL(index),
+ PWM_ASPEED_CTRL_CLK_DIV_H |
+ PWM_ASPEED_CTRL_CLK_DIV_L |
+ 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_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");
+
+ ret = clk_prepare_enable(priv->clk);
+ if (ret)
+ return dev_err_probe(dev, ret, "couldn't enable clock\n");
+
+ priv->reset = devm_reset_control_get_shared(&parent_dev->dev, NULL);
+ if (IS_ERR(priv->reset)) {
+ ret = dev_err_probe(dev, PTR_ERR(priv->reset),
+ "get reset failed\n");
+ goto err_disable_clk;
+ }
+ ret = reset_control_deassert(priv->reset);
+ if (ret) {
+ dev_err_probe(dev, ret, "cannot 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 <billy_tsai@aspeedtech.com>");
+MODULE_DESCRIPTION("Aspeed ast2600 PWM device driver");
+MODULE_LICENSE("GPL v2");
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [v9 1/2] dt-bindings: Add bindings for aspeed pwm-tach.
2021-07-09 6:52 ` Billy Tsai
@ 2021-07-13 22:14 ` Rob Herring
-1 siblings, 0 replies; 34+ messages in thread
From: Rob Herring @ 2021-07-13 22:14 UTC (permalink / raw)
To: Billy Tsai
Cc: lee.jones, joel, andrew, thierry.reding, u.kleine-koenig,
p.zabel, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, linux-pwm, BMC-SW
On Fri, Jul 09, 2021 at 02:52:16PM +0800, Billy Tsai wrote:
> This patch adds device binding for aspeed pwm-tach device which is a
> multi-function device include pwm and tach function and pwm/tach device
> bindings which should be the child-node of pwm-tach device.
I'll say it again, the fan control h/w needs some common bindings for
describing fans and fan connections to pwm and tach. I'm not going to
sign off on more fan bindings just doing their own thing.
>
> Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
> ---
> .../bindings/hwmon/aspeed,ast2600-tach.yaml | 69 +++++++++++++++
> .../bindings/mfd/aspeed,ast2600-pwm-tach.yaml | 87 +++++++++++++++++++
> .../bindings/pwm/aspeed,ast2600-pwm.yaml | 64 ++++++++++++++
> 3 files changed, 220 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
>
> diff --git a/Documentation/devicetree/bindings/hwmon/aspeed,ast2600-tach.yaml b/Documentation/devicetree/bindings/hwmon/aspeed,ast2600-tach.yaml
> new file mode 100644
> index 000000000000..a08471f96a61
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/aspeed,ast2600-tach.yaml
> @@ -0,0 +1,69 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (C) 2021 Aspeed, Inc.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/hwmon/aspeed,ast2600-tach.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Aspeed Ast2600 Tach controller
> +
> +maintainers:
> + - Billy Tsai <billy_tsai@aspeedtech.com>
> +
> +description: |
> + The Aspeed Tach controller can support upto 16 fan input.
> + This module is part of the ast2600-pwm-tach multi-function device. For more
> + details see ../mfd/aspeed,ast2600-pwm-tach.yaml.
> +
> +properties:
> + compatible:
> + enum:
> + - aspeed,ast2600-tach
> +
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 0
> +
> + pinctrl-0: true
> +
> + pinctrl-names:
> + const: default
> +
> +required:
> + - compatible
> + - "#address-cells"
> + - "#size-cells"
> +
> +additionalProperties:
> + type: object
> + properties:
> + reg:
> + description:
> + The tach channel used for this fan.
> + maxItems: 1
> +
> + aspeed,min-rpm:
> + description:
> + define the minimal revolutions per minute of the measure fan
> + used to calculate the sample period of tach
> + default: 1000
> +
> + aspeed,pulse-pr:
> + description:
> + Value specifying the number of pulses per revolution of the
> + monitored FAN.
> + default: 2
> +
> + aspeed,tach-div:
> + description:
> + define the tachometer clock divider as an integer. Formula of
> + tach clock = clock source / (2^tach-div)^2
> + minimum: 0
> + maximum: 15
> + # The value that should be used if the property is not present
> + default: 5
> +
> + required:
> + - reg
> diff --git a/Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml b/Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml
> new file mode 100644
> index 000000000000..ab49aff1928a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml
> @@ -0,0 +1,87 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (C) 2021 Aspeed, Inc.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mfd/aspeed,ast2600-pwm-tach.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: PWM Tach controller Device Tree Bindings
> +
> +description: |
> + The PWM Tach controller is represented as a multi-function device which
> + includes:
> + PWM
> + Tach
> +
> +maintainers:
> + - Billy Tsai <billy_tsai@aspeedtech.com>
> +
> +properties:
> + compatible:
> + items:
> + - enum:
> + - aspeed,ast2600-pwm-tach
> + - const: syscon
> + - const: simple-mfd
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> + resets:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - resets
> +
> +patternProperties:
> + "^pwm(@[0-9a-f]+)?$":
> + $ref: ../pwm/aspeed,ast2600-pwm.yaml
> +
> + "^tach(@[0-9a-f]+)?$":
> + $ref: ../hwmon/aspeed,ast2600-tach.yaml
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/ast2600-clock.h>
> + pwm_tach: pwm_tach@1e610000 {
> + compatible = "aspeed,ast2600-pwm-tach", "syscon", "simple-mfd";
> + reg = <0x1e610000 0x100>;
> + clocks = <&syscon ASPEED_CLK_AHB>;
> + resets = <&syscon ASPEED_RESET_PWM>;
> +
> + pwm: pwm {
> + compatible = "aspeed,ast2600-pwm";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + #pwm-cells = <3>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pwm0_default>;
> + pwm-ch@0 {
> + reg = <0>;
> + aspeed,wdt-reload-enable;
> + aspeed,wdt-reload-duty-point = <32>;
> + };
> + };
> +
> + tach: tach {
> + compatible = "aspeed,ast2600-tach";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_tach0_default>;
> + tach-ch@0 {
> + reg = <0>;
> + aspeed,min-rpm = <1000>;
> + aspeed,pulse-pr = <2>;
> + aspeed,tach-div = <5>;
> + };
> + };
> + };
> diff --git a/Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml b/Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml
> new file mode 100644
> index 000000000000..f501f8a769df
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml
> @@ -0,0 +1,64 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (C) 2021 Aspeed, Inc.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pwm/aspeed,ast2600-pwm.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Aspeed Ast2600 PWM controller
> +
> +maintainers:
> + - Billy Tsai <billy_tsai@aspeedtech.com>
> +
> +description: |
> + The Aspeed PWM controller can support upto 16 PWM outputs.
> + This module is part of the ast2600-pwm-tach multi-function device. For more
> + details see ../mfd/aspeed,ast2600-pwm-tach.yaml.
> +
> +properties:
> + compatible:
> + enum:
> + - aspeed,ast2600-pwm
> +
> + "#pwm-cells":
> + const: 3
> +
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 0
> +
> + pinctrl-0: true
> +
> + pinctrl-names:
> + const: default
> +
> +required:
> + - compatible
> + - "#pwm-cells"
> + - "#address-cells"
> + - "#size-cells"
> +
> +additionalProperties:
> + description: Set extend properties for each pwm channel.
> + type: object
> + properties:
> + reg:
> + description:
> + The pwm channel index.
> + maxItems: 1
> +
> + aspeed,wdt-reload-enable:
> + type: boolean
> + description:
> + Enable the function of wdt reset reload duty point.
> +
> + aspeed,wdt-reload-duty-point:
> + description:
> + Define the duty point after wdt reset, 0 = 100%
> + minimum: 0
> + maximum: 255
> +
> + required:
> + - reg
> --
> 2.25.1
>
>
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [v9 1/2] dt-bindings: Add bindings for aspeed pwm-tach.
@ 2021-07-13 22:14 ` Rob Herring
0 siblings, 0 replies; 34+ messages in thread
From: Rob Herring @ 2021-07-13 22:14 UTC (permalink / raw)
To: Billy Tsai
Cc: lee.jones, joel, andrew, thierry.reding, u.kleine-koenig,
p.zabel, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, linux-pwm, BMC-SW
On Fri, Jul 09, 2021 at 02:52:16PM +0800, Billy Tsai wrote:
> This patch adds device binding for aspeed pwm-tach device which is a
> multi-function device include pwm and tach function and pwm/tach device
> bindings which should be the child-node of pwm-tach device.
I'll say it again, the fan control h/w needs some common bindings for
describing fans and fan connections to pwm and tach. I'm not going to
sign off on more fan bindings just doing their own thing.
>
> Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
> ---
> .../bindings/hwmon/aspeed,ast2600-tach.yaml | 69 +++++++++++++++
> .../bindings/mfd/aspeed,ast2600-pwm-tach.yaml | 87 +++++++++++++++++++
> .../bindings/pwm/aspeed,ast2600-pwm.yaml | 64 ++++++++++++++
> 3 files changed, 220 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
>
> diff --git a/Documentation/devicetree/bindings/hwmon/aspeed,ast2600-tach.yaml b/Documentation/devicetree/bindings/hwmon/aspeed,ast2600-tach.yaml
> new file mode 100644
> index 000000000000..a08471f96a61
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/aspeed,ast2600-tach.yaml
> @@ -0,0 +1,69 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (C) 2021 Aspeed, Inc.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/hwmon/aspeed,ast2600-tach.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Aspeed Ast2600 Tach controller
> +
> +maintainers:
> + - Billy Tsai <billy_tsai@aspeedtech.com>
> +
> +description: |
> + The Aspeed Tach controller can support upto 16 fan input.
> + This module is part of the ast2600-pwm-tach multi-function device. For more
> + details see ../mfd/aspeed,ast2600-pwm-tach.yaml.
> +
> +properties:
> + compatible:
> + enum:
> + - aspeed,ast2600-tach
> +
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 0
> +
> + pinctrl-0: true
> +
> + pinctrl-names:
> + const: default
> +
> +required:
> + - compatible
> + - "#address-cells"
> + - "#size-cells"
> +
> +additionalProperties:
> + type: object
> + properties:
> + reg:
> + description:
> + The tach channel used for this fan.
> + maxItems: 1
> +
> + aspeed,min-rpm:
> + description:
> + define the minimal revolutions per minute of the measure fan
> + used to calculate the sample period of tach
> + default: 1000
> +
> + aspeed,pulse-pr:
> + description:
> + Value specifying the number of pulses per revolution of the
> + monitored FAN.
> + default: 2
> +
> + aspeed,tach-div:
> + description:
> + define the tachometer clock divider as an integer. Formula of
> + tach clock = clock source / (2^tach-div)^2
> + minimum: 0
> + maximum: 15
> + # The value that should be used if the property is not present
> + default: 5
> +
> + required:
> + - reg
> diff --git a/Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml b/Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml
> new file mode 100644
> index 000000000000..ab49aff1928a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml
> @@ -0,0 +1,87 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (C) 2021 Aspeed, Inc.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mfd/aspeed,ast2600-pwm-tach.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: PWM Tach controller Device Tree Bindings
> +
> +description: |
> + The PWM Tach controller is represented as a multi-function device which
> + includes:
> + PWM
> + Tach
> +
> +maintainers:
> + - Billy Tsai <billy_tsai@aspeedtech.com>
> +
> +properties:
> + compatible:
> + items:
> + - enum:
> + - aspeed,ast2600-pwm-tach
> + - const: syscon
> + - const: simple-mfd
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> + resets:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - resets
> +
> +patternProperties:
> + "^pwm(@[0-9a-f]+)?$":
> + $ref: ../pwm/aspeed,ast2600-pwm.yaml
> +
> + "^tach(@[0-9a-f]+)?$":
> + $ref: ../hwmon/aspeed,ast2600-tach.yaml
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/ast2600-clock.h>
> + pwm_tach: pwm_tach@1e610000 {
> + compatible = "aspeed,ast2600-pwm-tach", "syscon", "simple-mfd";
> + reg = <0x1e610000 0x100>;
> + clocks = <&syscon ASPEED_CLK_AHB>;
> + resets = <&syscon ASPEED_RESET_PWM>;
> +
> + pwm: pwm {
> + compatible = "aspeed,ast2600-pwm";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + #pwm-cells = <3>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pwm0_default>;
> + pwm-ch@0 {
> + reg = <0>;
> + aspeed,wdt-reload-enable;
> + aspeed,wdt-reload-duty-point = <32>;
> + };
> + };
> +
> + tach: tach {
> + compatible = "aspeed,ast2600-tach";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_tach0_default>;
> + tach-ch@0 {
> + reg = <0>;
> + aspeed,min-rpm = <1000>;
> + aspeed,pulse-pr = <2>;
> + aspeed,tach-div = <5>;
> + };
> + };
> + };
> diff --git a/Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml b/Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml
> new file mode 100644
> index 000000000000..f501f8a769df
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml
> @@ -0,0 +1,64 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (C) 2021 Aspeed, Inc.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pwm/aspeed,ast2600-pwm.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Aspeed Ast2600 PWM controller
> +
> +maintainers:
> + - Billy Tsai <billy_tsai@aspeedtech.com>
> +
> +description: |
> + The Aspeed PWM controller can support upto 16 PWM outputs.
> + This module is part of the ast2600-pwm-tach multi-function device. For more
> + details see ../mfd/aspeed,ast2600-pwm-tach.yaml.
> +
> +properties:
> + compatible:
> + enum:
> + - aspeed,ast2600-pwm
> +
> + "#pwm-cells":
> + const: 3
> +
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 0
> +
> + pinctrl-0: true
> +
> + pinctrl-names:
> + const: default
> +
> +required:
> + - compatible
> + - "#pwm-cells"
> + - "#address-cells"
> + - "#size-cells"
> +
> +additionalProperties:
> + description: Set extend properties for each pwm channel.
> + type: object
> + properties:
> + reg:
> + description:
> + The pwm channel index.
> + maxItems: 1
> +
> + aspeed,wdt-reload-enable:
> + type: boolean
> + description:
> + Enable the function of wdt reset reload duty point.
> +
> + aspeed,wdt-reload-duty-point:
> + description:
> + Define the duty point after wdt reset, 0 = 100%
> + minimum: 0
> + maximum: 255
> +
> + required:
> + - reg
> --
> 2.25.1
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [v9 1/2] dt-bindings: Add bindings for aspeed pwm-tach.
2021-07-13 22:14 ` Rob Herring
@ 2021-07-14 4:02 ` Billy Tsai
-1 siblings, 0 replies; 34+ messages in thread
From: Billy Tsai @ 2021-07-14 4:02 UTC (permalink / raw)
To: Rob Herring
Cc: lee.jones, joel, andrew, thierry.reding, u.kleine-koenig,
p.zabel, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, linux-pwm, BMC-SW
On 2021/7/14, 6:14 AM, "Rob Herring" <robh@kernel.org> wrote:
On Fri, Jul 09, 2021 at 02:52:16PM +0800, Billy Tsai wrote:
>> This patch adds device binding for aspeed pwm-tach device which is a
>> multi-function device include pwm and tach function and pwm/tach device
>> bindings which should be the child-node of pwm-tach device.
>I'll say it again, the fan control h/w needs some common bindings for
>describing fans and fan connections to pwm and tach. I'm not going to
>sign off on more fan bindings just doing their own thing.
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.
>>
>> Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
>> ---
>> .../bindings/hwmon/aspeed,ast2600-tach.yaml | 69 +++++++++++++++
>> .../bindings/mfd/aspeed,ast2600-pwm-tach.yaml | 87 +++++++++++++++++++
>> .../bindings/pwm/aspeed,ast2600-pwm.yaml | 64 ++++++++++++++
>> 3 files changed, 220 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
>>
>> diff --git a/Documentation/devicetree/bindings/hwmon/aspeed,ast2600-tach.yaml b/Documentation/devicetree/bindings/hwmon/aspeed,ast2600-tach.yaml
>> new file mode 100644
>> index 000000000000..a08471f96a61
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/hwmon/aspeed,ast2600-tach.yaml
>> @@ -0,0 +1,69 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +# Copyright (C) 2021 Aspeed, Inc.
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/hwmon/aspeed,ast2600-tach.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Aspeed Ast2600 Tach controller
>> +
>> +maintainers:
>> + - Billy Tsai <billy_tsai@aspeedtech.com>
>> +
>> +description: |
>> + The Aspeed Tach controller can support upto 16 fan input.
>> + This module is part of the ast2600-pwm-tach multi-function device. For more
>> + details see ../mfd/aspeed,ast2600-pwm-tach.yaml.
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - aspeed,ast2600-tach
>> +
>> + "#address-cells":
>> + const: 1
>> +
>> + "#size-cells":
>> + const: 0
>> +
>> + pinctrl-0: true
>> +
>> + pinctrl-names:
>> + const: default
>> +
>> +required:
>> + - compatible
>> + - "#address-cells"
>> + - "#size-cells"
>> +
>> +additionalProperties:
>> + type: object
>> + properties:
>> + reg:
>> + description:
>> + The tach channel used for this fan.
>> + maxItems: 1
>> +
>> + aspeed,min-rpm:
>> + description:
>> + define the minimal revolutions per minute of the measure fan
>> + used to calculate the sample period of tach
>> + default: 1000
>> +
>> + aspeed,pulse-pr:
>> + description:
>> + Value specifying the number of pulses per revolution of the
>> + monitored FAN.
>> + default: 2
>> +
>> + aspeed,tach-div:
>> + description:
>> + define the tachometer clock divider as an integer. Formula of
>> + tach clock = clock source / (2^tach-div)^2
>> + minimum: 0
>> + maximum: 15
>> + # The value that should be used if the property is not present
>> + default: 5
>> +
>> + required:
>> + - reg
>> diff --git a/Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml b/Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml
>> new file mode 100644
>> index 000000000000..ab49aff1928a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml
>> @@ -0,0 +1,87 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +# Copyright (C) 2021 Aspeed, Inc.
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/mfd/aspeed,ast2600-pwm-tach.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: PWM Tach controller Device Tree Bindings
>> +
>> +description: |
>> + The PWM Tach controller is represented as a multi-function device which
>> + includes:
>> + PWM
>> + Tach
>> +
>> +maintainers:
>> + - Billy Tsai <billy_tsai@aspeedtech.com>
>> +
>> +properties:
>> + compatible:
>> + items:
>> + - enum:
>> + - aspeed,ast2600-pwm-tach
>> + - const: syscon
>> + - const: simple-mfd
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + clocks:
>> + maxItems: 1
>> +
>> + resets:
>> + maxItems: 1
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - clocks
>> + - resets
>> +
>> +patternProperties:
>> + "^pwm(@[0-9a-f]+)?$":
>> + $ref: ../pwm/aspeed,ast2600-pwm.yaml
>> +
>> + "^tach(@[0-9a-f]+)?$":
>> + $ref: ../hwmon/aspeed,ast2600-tach.yaml
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> + #include <dt-bindings/clock/ast2600-clock.h>
>> + pwm_tach: pwm_tach@1e610000 {
>> + compatible = "aspeed,ast2600-pwm-tach", "syscon", "simple-mfd";
>> + reg = <0x1e610000 0x100>;
>> + clocks = <&syscon ASPEED_CLK_AHB>;
>> + resets = <&syscon ASPEED_RESET_PWM>;
>> +
>> + pwm: pwm {
>> + compatible = "aspeed,ast2600-pwm";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + #pwm-cells = <3>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_pwm0_default>;
>> + pwm-ch@0 {
>> + reg = <0>;
>> + aspeed,wdt-reload-enable;
>> + aspeed,wdt-reload-duty-point = <32>;
>> + };
>> + };
>> +
>> + tach: tach {
>> + compatible = "aspeed,ast2600-tach";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_tach0_default>;
>> + tach-ch@0 {
>> + reg = <0>;
>> + aspeed,min-rpm = <1000>;
>> + aspeed,pulse-pr = <2>;
>> + aspeed,tach-div = <5>;
>> + };
>> + };
>> + };
>> diff --git a/Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml b/Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml
>> new file mode 100644
>> index 000000000000..f501f8a769df
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml
>> @@ -0,0 +1,64 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +# Copyright (C) 2021 Aspeed, Inc.
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/pwm/aspeed,ast2600-pwm.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Aspeed Ast2600 PWM controller
>> +
>> +maintainers:
>> + - Billy Tsai <billy_tsai@aspeedtech.com>
>> +
>> +description: |
>> + The Aspeed PWM controller can support upto 16 PWM outputs.
>> + This module is part of the ast2600-pwm-tach multi-function device. For more
>> + details see ../mfd/aspeed,ast2600-pwm-tach.yaml.
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - aspeed,ast2600-pwm
>> +
>> + "#pwm-cells":
>> + const: 3
>> +
>> + "#address-cells":
>> + const: 1
>> +
>> + "#size-cells":
>> + const: 0
>> +
>> + pinctrl-0: true
>> +
>> + pinctrl-names:
>> + const: default
>> +
>> +required:
>> + - compatible
>> + - "#pwm-cells"
>> + - "#address-cells"
>> + - "#size-cells"
>> +
>> +additionalProperties:
>> + description: Set extend properties for each pwm channel.
>> + type: object
>> + properties:
>> + reg:
>> + description:
>> + The pwm channel index.
>> + maxItems: 1
>> +
>> + aspeed,wdt-reload-enable:
>> + type: boolean
>> + description:
>> + Enable the function of wdt reset reload duty point.
>> +
>> + aspeed,wdt-reload-duty-point:
>> + description:
>> + Define the duty point after wdt reset, 0 = 100%
>> + minimum: 0
>> + maximum: 255
>> +
>> + required:
>> + - reg
>> --
>> 2.25.1
>>
>>
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [v9 1/2] dt-bindings: Add bindings for aspeed pwm-tach.
@ 2021-07-14 4:02 ` Billy Tsai
0 siblings, 0 replies; 34+ messages in thread
From: Billy Tsai @ 2021-07-14 4:02 UTC (permalink / raw)
To: Rob Herring
Cc: lee.jones, joel, andrew, thierry.reding, u.kleine-koenig,
p.zabel, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, linux-pwm, BMC-SW
On 2021/7/14, 6:14 AM, "Rob Herring" <robh@kernel.org> wrote:
On Fri, Jul 09, 2021 at 02:52:16PM +0800, Billy Tsai wrote:
>> This patch adds device binding for aspeed pwm-tach device which is a
>> multi-function device include pwm and tach function and pwm/tach device
>> bindings which should be the child-node of pwm-tach device.
>I'll say it again, the fan control h/w needs some common bindings for
>describing fans and fan connections to pwm and tach. I'm not going to
>sign off on more fan bindings just doing their own thing.
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.
>>
>> Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
>> ---
>> .../bindings/hwmon/aspeed,ast2600-tach.yaml | 69 +++++++++++++++
>> .../bindings/mfd/aspeed,ast2600-pwm-tach.yaml | 87 +++++++++++++++++++
>> .../bindings/pwm/aspeed,ast2600-pwm.yaml | 64 ++++++++++++++
>> 3 files changed, 220 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
>>
>> diff --git a/Documentation/devicetree/bindings/hwmon/aspeed,ast2600-tach.yaml b/Documentation/devicetree/bindings/hwmon/aspeed,ast2600-tach.yaml
>> new file mode 100644
>> index 000000000000..a08471f96a61
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/hwmon/aspeed,ast2600-tach.yaml
>> @@ -0,0 +1,69 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +# Copyright (C) 2021 Aspeed, Inc.
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/hwmon/aspeed,ast2600-tach.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Aspeed Ast2600 Tach controller
>> +
>> +maintainers:
>> + - Billy Tsai <billy_tsai@aspeedtech.com>
>> +
>> +description: |
>> + The Aspeed Tach controller can support upto 16 fan input.
>> + This module is part of the ast2600-pwm-tach multi-function device. For more
>> + details see ../mfd/aspeed,ast2600-pwm-tach.yaml.
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - aspeed,ast2600-tach
>> +
>> + "#address-cells":
>> + const: 1
>> +
>> + "#size-cells":
>> + const: 0
>> +
>> + pinctrl-0: true
>> +
>> + pinctrl-names:
>> + const: default
>> +
>> +required:
>> + - compatible
>> + - "#address-cells"
>> + - "#size-cells"
>> +
>> +additionalProperties:
>> + type: object
>> + properties:
>> + reg:
>> + description:
>> + The tach channel used for this fan.
>> + maxItems: 1
>> +
>> + aspeed,min-rpm:
>> + description:
>> + define the minimal revolutions per minute of the measure fan
>> + used to calculate the sample period of tach
>> + default: 1000
>> +
>> + aspeed,pulse-pr:
>> + description:
>> + Value specifying the number of pulses per revolution of the
>> + monitored FAN.
>> + default: 2
>> +
>> + aspeed,tach-div:
>> + description:
>> + define the tachometer clock divider as an integer. Formula of
>> + tach clock = clock source / (2^tach-div)^2
>> + minimum: 0
>> + maximum: 15
>> + # The value that should be used if the property is not present
>> + default: 5
>> +
>> + required:
>> + - reg
>> diff --git a/Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml b/Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml
>> new file mode 100644
>> index 000000000000..ab49aff1928a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml
>> @@ -0,0 +1,87 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +# Copyright (C) 2021 Aspeed, Inc.
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/mfd/aspeed,ast2600-pwm-tach.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: PWM Tach controller Device Tree Bindings
>> +
>> +description: |
>> + The PWM Tach controller is represented as a multi-function device which
>> + includes:
>> + PWM
>> + Tach
>> +
>> +maintainers:
>> + - Billy Tsai <billy_tsai@aspeedtech.com>
>> +
>> +properties:
>> + compatible:
>> + items:
>> + - enum:
>> + - aspeed,ast2600-pwm-tach
>> + - const: syscon
>> + - const: simple-mfd
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + clocks:
>> + maxItems: 1
>> +
>> + resets:
>> + maxItems: 1
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - clocks
>> + - resets
>> +
>> +patternProperties:
>> + "^pwm(@[0-9a-f]+)?$":
>> + $ref: ../pwm/aspeed,ast2600-pwm.yaml
>> +
>> + "^tach(@[0-9a-f]+)?$":
>> + $ref: ../hwmon/aspeed,ast2600-tach.yaml
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> + #include <dt-bindings/clock/ast2600-clock.h>
>> + pwm_tach: pwm_tach@1e610000 {
>> + compatible = "aspeed,ast2600-pwm-tach", "syscon", "simple-mfd";
>> + reg = <0x1e610000 0x100>;
>> + clocks = <&syscon ASPEED_CLK_AHB>;
>> + resets = <&syscon ASPEED_RESET_PWM>;
>> +
>> + pwm: pwm {
>> + compatible = "aspeed,ast2600-pwm";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + #pwm-cells = <3>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_pwm0_default>;
>> + pwm-ch@0 {
>> + reg = <0>;
>> + aspeed,wdt-reload-enable;
>> + aspeed,wdt-reload-duty-point = <32>;
>> + };
>> + };
>> +
>> + tach: tach {
>> + compatible = "aspeed,ast2600-tach";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_tach0_default>;
>> + tach-ch@0 {
>> + reg = <0>;
>> + aspeed,min-rpm = <1000>;
>> + aspeed,pulse-pr = <2>;
>> + aspeed,tach-div = <5>;
>> + };
>> + };
>> + };
>> diff --git a/Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml b/Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml
>> new file mode 100644
>> index 000000000000..f501f8a769df
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml
>> @@ -0,0 +1,64 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +# Copyright (C) 2021 Aspeed, Inc.
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/pwm/aspeed,ast2600-pwm.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Aspeed Ast2600 PWM controller
>> +
>> +maintainers:
>> + - Billy Tsai <billy_tsai@aspeedtech.com>
>> +
>> +description: |
>> + The Aspeed PWM controller can support upto 16 PWM outputs.
>> + This module is part of the ast2600-pwm-tach multi-function device. For more
>> + details see ../mfd/aspeed,ast2600-pwm-tach.yaml.
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - aspeed,ast2600-pwm
>> +
>> + "#pwm-cells":
>> + const: 3
>> +
>> + "#address-cells":
>> + const: 1
>> +
>> + "#size-cells":
>> + const: 0
>> +
>> + pinctrl-0: true
>> +
>> + pinctrl-names:
>> + const: default
>> +
>> +required:
>> + - compatible
>> + - "#pwm-cells"
>> + - "#address-cells"
>> + - "#size-cells"
>> +
>> +additionalProperties:
>> + description: Set extend properties for each pwm channel.
>> + type: object
>> + properties:
>> + reg:
>> + description:
>> + The pwm channel index.
>> + maxItems: 1
>> +
>> + aspeed,wdt-reload-enable:
>> + type: boolean
>> + description:
>> + Enable the function of wdt reset reload duty point.
>> +
>> + aspeed,wdt-reload-duty-point:
>> + description:
>> + Define the duty point after wdt reset, 0 = 100%
>> + minimum: 0
>> + maximum: 255
>> +
>> + required:
>> + - reg
>> --
>> 2.25.1
>>
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [v9 2/2] pwm: Add Aspeed ast2600 PWM support
2021-07-09 6:52 ` Billy Tsai
@ 2021-07-15 15:05 ` Uwe Kleine-König
-1 siblings, 0 replies; 34+ messages in thread
From: Uwe Kleine-König @ 2021-07-15 15:05 UTC (permalink / raw)
To: Billy Tsai
Cc: lee.jones, robh+dt, joel, andrew, thierry.reding, p.zabel,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-pwm, BMC-SW
[-- Attachment #1: Type: text/plain, Size: 12765 bytes --]
Hello Billy,
On Fri, Jul 09, 2021 at 02:52:17PM +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 <billy_tsai@aspeedtech.com>
> ---
> drivers/pwm/Kconfig | 9 +
> drivers/pwm/Makefile | 1 +
> drivers/pwm/pwm-aspeed-ast2600.c | 316 +++++++++++++++++++++++++++++++
> 3 files changed, 326 insertions(+)
> create mode 100644 drivers/pwm/pwm-aspeed-ast2600.c
>
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 63be5362fd3a..a5aac3ca4ac7 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -51,6 +51,15 @@ 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
I think you need
depdens on HAVE_CLK && HAS_IOMEM
here.
> + 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..68a45ba3b32b
> --- /dev/null
> +++ b/drivers/pwm/pwm-aspeed-ast2600.c
> @@ -0,0 +1,316 @@
> +// 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 formula of pwm period duration:
> + * period duration = ((DIV_L + 1) * (PERIOD + 1) << DIV_H) / input-clk
> + *
> + * The formula of pwm duty cycle duration:
> + * duty cycle duration = period duration * DUTY_CYCLE_FALLING_POINT / (PERIOD + 1)
> + * = ((DIV_L + 1) * DUTY_CYCLE_FALLING_POINT << DIV_H) / input-clk
> + *
> + * The software driver fixes the period to 255, which causes the high-frequency
> + * precision of the PWM to be coarse, in exchange for the fineness of the duty cycle.
> + *
> + * Register usage:
> + * PIN_ENABLE: When it is unset the pwm controller will always output low to the extern.
> + * Use to determine whether the PWM channel is enabled or disabled
> + * CLK_ENABLE: When it is unset the pwm controller will reset the duty counter to 0 and
> + * output low 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%.
> + *
> + * 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.
Another is: The PWM doesn't support duty_cycle 0, on such a request the
PWM is disabled which results in a constant inactive level.
(This is correct, is it? Or does it yield a constant 0 level?)
> + *
> + * 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 index = pwm->hwpwm;
> + bool polarity, ch_en, clk_en;
> + u32 duty_pt, val;
> + unsigned long rate;
> + u64 div_h, div_l, clk_period;
> +
> + regmap_read(priv->regmap, PWM_ASPEED_CTRL(index), &val);
> + polarity = FIELD_GET(PWM_ASPEED_CTRL_INVERSE, val);
> + ch_en = FIELD_GET(PWM_ASPEED_CTRL_PIN_ENABLE, val);
pin_en?
> + 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(index), &val);
> + duty_pt = FIELD_GET(PWM_ASPEED_DUTY_CYCLE_FALLING_POINT, val);
> + clk_period = FIELD_GET(PWM_ASPEED_DUTY_CYCLE_PERIOD, val);
I wouldn't call this "clk_..." if the register field isn't named
"CLK_...". I'd go for "dcp" or dutycycleperiod or similar.
> + rate = clk_get_rate(priv->clk);
> + state->period = DIV_ROUND_UP_ULL(
> + (u64)NSEC_PER_SEC * (div_l + 1) * (clk_period + 1) << div_h,
> + rate);
If you split this into several lines it (IMHO) becomes better readable,
something like:
/*
* This multiplication doesn't overflow, the upper bound is
* 1000000000 * 256 * 256 << 15 = 0x1dcd650000000000
*/
period_steps = (u64)NSEC_PER_SEC * (div_l + 1) * (clk_period + 1) << div_h;
state->period = DIV_ROUND_UP_ULL(period_steps, rate);
> + if (clk_en && duty_pt)
> + state->duty_cycle = DIV_ROUND_UP_ULL(
> + (u64)NSEC_PER_SEC * (div_l + 1) * duty_pt << div_h,
> + rate);
> + else
> + state->duty_cycle = clk_en ? state->period : 0;
> + state->polarity = polarity;
I'd write
state->polarity = polarity ? PWM_POLARITY_INVERSED : PWM_POLARITY_NORMAL;
here to get the type right and not depend on the actual numbers behind
these enum values.
> + state->enabled = ch_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 index = pwm->hwpwm, duty_pt;
> + unsigned long rate;
> + u64 div_h, div_l, divisor;
> + bool clk_en;
I'd use "hwid" or "hwpwm" instead of "index"
> + dev_dbg(dev, "expect period: %lldns, duty_cycle: %lldns", state->period,
> + state->duty_cycle);
> +
> + rate = clk_get_rate(priv->clk);
> + /*
> + * 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 * state->period, divisor));
Please care for rate * state->period not overflowing.
> + if (div_h > 0xf)
> + div_h = 0xf;
> +
> + divisor = ((u64)NSEC_PER_SEC * (PWM_ASPEED_FIXED_PERIOD + 1)) << div_h;
> + div_l = div64_u64(rate * state->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);
> +
> + regmap_update_bits(priv->regmap, PWM_ASPEED_CTRL(index),
> + PWM_ASPEED_CTRL_PIN_ENABLE,
> + state->enabled ? PWM_ASPEED_CTRL_PIN_ENABLE : 0);
> +
> + if (duty_pt == 0)
> + clk_en = 0;
> + else {
> + clk_en = 1;
> + if (duty_pt >= (PWM_ASPEED_FIXED_PERIOD + 1))
> + duty_pt = 0;
> + /*
> + * 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(index),
> + PWM_ASPEED_DUTY_CYCLE_PERIOD |
> + PWM_ASPEED_DUTY_CYCLE_RISING_POINT |
> + PWM_ASPEED_DUTY_CYCLE_FALLING_POINT,
> + FIELD_PREP(PWM_ASPEED_DUTY_CYCLE_PERIOD,
> + PWM_ASPEED_FIXED_PERIOD) |
> + FIELD_PREP(PWM_ASPEED_DUTY_CYCLE_FALLING_POINT,
> + duty_pt));
> + }
> +
> + regmap_update_bits(priv->regmap, PWM_ASPEED_CTRL(index),
> + PWM_ASPEED_CTRL_CLK_DIV_H |
> + PWM_ASPEED_CTRL_CLK_DIV_L |
> + 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_CLK_ENABLE, clk_en) |
> + FIELD_PREP(PWM_ASPEED_CTRL_INVERSE,
> + state->polarity));
Indention is wrong here, please align the last line to the opening ( on
the previous line. Ditto for the regmap_update_bits call above.
> + 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");
It is (more) usual to capitalise error messages, so "Unsupported .."
please. Here and below.
> +
> + 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");
> [...]
Rest looks fine for me.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [v9 2/2] pwm: Add Aspeed ast2600 PWM support
@ 2021-07-15 15:05 ` Uwe Kleine-König
0 siblings, 0 replies; 34+ messages in thread
From: Uwe Kleine-König @ 2021-07-15 15:05 UTC (permalink / raw)
To: Billy Tsai
Cc: lee.jones, robh+dt, joel, andrew, thierry.reding, p.zabel,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-pwm, BMC-SW
[-- Attachment #1.1: Type: text/plain, Size: 12765 bytes --]
Hello Billy,
On Fri, Jul 09, 2021 at 02:52:17PM +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 <billy_tsai@aspeedtech.com>
> ---
> drivers/pwm/Kconfig | 9 +
> drivers/pwm/Makefile | 1 +
> drivers/pwm/pwm-aspeed-ast2600.c | 316 +++++++++++++++++++++++++++++++
> 3 files changed, 326 insertions(+)
> create mode 100644 drivers/pwm/pwm-aspeed-ast2600.c
>
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 63be5362fd3a..a5aac3ca4ac7 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -51,6 +51,15 @@ 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
I think you need
depdens on HAVE_CLK && HAS_IOMEM
here.
> + 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..68a45ba3b32b
> --- /dev/null
> +++ b/drivers/pwm/pwm-aspeed-ast2600.c
> @@ -0,0 +1,316 @@
> +// 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 formula of pwm period duration:
> + * period duration = ((DIV_L + 1) * (PERIOD + 1) << DIV_H) / input-clk
> + *
> + * The formula of pwm duty cycle duration:
> + * duty cycle duration = period duration * DUTY_CYCLE_FALLING_POINT / (PERIOD + 1)
> + * = ((DIV_L + 1) * DUTY_CYCLE_FALLING_POINT << DIV_H) / input-clk
> + *
> + * The software driver fixes the period to 255, which causes the high-frequency
> + * precision of the PWM to be coarse, in exchange for the fineness of the duty cycle.
> + *
> + * Register usage:
> + * PIN_ENABLE: When it is unset the pwm controller will always output low to the extern.
> + * Use to determine whether the PWM channel is enabled or disabled
> + * CLK_ENABLE: When it is unset the pwm controller will reset the duty counter to 0 and
> + * output low 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%.
> + *
> + * 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.
Another is: The PWM doesn't support duty_cycle 0, on such a request the
PWM is disabled which results in a constant inactive level.
(This is correct, is it? Or does it yield a constant 0 level?)
> + *
> + * 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 index = pwm->hwpwm;
> + bool polarity, ch_en, clk_en;
> + u32 duty_pt, val;
> + unsigned long rate;
> + u64 div_h, div_l, clk_period;
> +
> + regmap_read(priv->regmap, PWM_ASPEED_CTRL(index), &val);
> + polarity = FIELD_GET(PWM_ASPEED_CTRL_INVERSE, val);
> + ch_en = FIELD_GET(PWM_ASPEED_CTRL_PIN_ENABLE, val);
pin_en?
> + 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(index), &val);
> + duty_pt = FIELD_GET(PWM_ASPEED_DUTY_CYCLE_FALLING_POINT, val);
> + clk_period = FIELD_GET(PWM_ASPEED_DUTY_CYCLE_PERIOD, val);
I wouldn't call this "clk_..." if the register field isn't named
"CLK_...". I'd go for "dcp" or dutycycleperiod or similar.
> + rate = clk_get_rate(priv->clk);
> + state->period = DIV_ROUND_UP_ULL(
> + (u64)NSEC_PER_SEC * (div_l + 1) * (clk_period + 1) << div_h,
> + rate);
If you split this into several lines it (IMHO) becomes better readable,
something like:
/*
* This multiplication doesn't overflow, the upper bound is
* 1000000000 * 256 * 256 << 15 = 0x1dcd650000000000
*/
period_steps = (u64)NSEC_PER_SEC * (div_l + 1) * (clk_period + 1) << div_h;
state->period = DIV_ROUND_UP_ULL(period_steps, rate);
> + if (clk_en && duty_pt)
> + state->duty_cycle = DIV_ROUND_UP_ULL(
> + (u64)NSEC_PER_SEC * (div_l + 1) * duty_pt << div_h,
> + rate);
> + else
> + state->duty_cycle = clk_en ? state->period : 0;
> + state->polarity = polarity;
I'd write
state->polarity = polarity ? PWM_POLARITY_INVERSED : PWM_POLARITY_NORMAL;
here to get the type right and not depend on the actual numbers behind
these enum values.
> + state->enabled = ch_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 index = pwm->hwpwm, duty_pt;
> + unsigned long rate;
> + u64 div_h, div_l, divisor;
> + bool clk_en;
I'd use "hwid" or "hwpwm" instead of "index"
> + dev_dbg(dev, "expect period: %lldns, duty_cycle: %lldns", state->period,
> + state->duty_cycle);
> +
> + rate = clk_get_rate(priv->clk);
> + /*
> + * 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 * state->period, divisor));
Please care for rate * state->period not overflowing.
> + if (div_h > 0xf)
> + div_h = 0xf;
> +
> + divisor = ((u64)NSEC_PER_SEC * (PWM_ASPEED_FIXED_PERIOD + 1)) << div_h;
> + div_l = div64_u64(rate * state->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);
> +
> + regmap_update_bits(priv->regmap, PWM_ASPEED_CTRL(index),
> + PWM_ASPEED_CTRL_PIN_ENABLE,
> + state->enabled ? PWM_ASPEED_CTRL_PIN_ENABLE : 0);
> +
> + if (duty_pt == 0)
> + clk_en = 0;
> + else {
> + clk_en = 1;
> + if (duty_pt >= (PWM_ASPEED_FIXED_PERIOD + 1))
> + duty_pt = 0;
> + /*
> + * 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(index),
> + PWM_ASPEED_DUTY_CYCLE_PERIOD |
> + PWM_ASPEED_DUTY_CYCLE_RISING_POINT |
> + PWM_ASPEED_DUTY_CYCLE_FALLING_POINT,
> + FIELD_PREP(PWM_ASPEED_DUTY_CYCLE_PERIOD,
> + PWM_ASPEED_FIXED_PERIOD) |
> + FIELD_PREP(PWM_ASPEED_DUTY_CYCLE_FALLING_POINT,
> + duty_pt));
> + }
> +
> + regmap_update_bits(priv->regmap, PWM_ASPEED_CTRL(index),
> + PWM_ASPEED_CTRL_CLK_DIV_H |
> + PWM_ASPEED_CTRL_CLK_DIV_L |
> + 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_CLK_ENABLE, clk_en) |
> + FIELD_PREP(PWM_ASPEED_CTRL_INVERSE,
> + state->polarity));
Indention is wrong here, please align the last line to the opening ( on
the previous line. Ditto for the regmap_update_bits call above.
> + 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");
It is (more) usual to capitalise error messages, so "Unsupported .."
please. Here and below.
> +
> + 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");
> [...]
Rest looks fine for me.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [v9 2/2] pwm: Add Aspeed ast2600 PWM support
2021-07-15 15:05 ` Uwe Kleine-König
@ 2021-07-16 1:48 ` Billy Tsai
-1 siblings, 0 replies; 34+ messages in thread
From: Billy Tsai @ 2021-07-16 1:48 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: lee.jones, robh+dt, joel, andrew, thierry.reding, p.zabel,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-pwm, BMC-SW
Hello Uwe Kleine-König,
On 2021/7/15, 11:06 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>> wrote:
On Fri, Jul 09, 2021 at 02:52:17PM +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 <billy_tsai@aspeedtech.com>
>> ---
>> drivers/pwm/Kconfig | 9 +
>> drivers/pwm/Makefile | 1 +
>> drivers/pwm/pwm-aspeed-ast2600.c | 316 +++++++++++++++++++++++++++++++
>> 3 files changed, 326 insertions(+)
>> create mode 100644 drivers/pwm/pwm-aspeed-ast2600.c
>>
>> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
>> index 63be5362fd3a..a5aac3ca4ac7 100644
>> --- a/drivers/pwm/Kconfig
>> +++ b/drivers/pwm/Kconfig
>> @@ -51,6 +51,15 @@ 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
> I think you need
> depdens on HAVE_CLK && HAS_IOMEM
> here.
Ok, I will add it to next version.
>> + 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..68a45ba3b32b
>> --- /dev/null
>> +++ b/drivers/pwm/pwm-aspeed-ast2600.c
>> @@ -0,0 +1,316 @@
>> +// 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 formula of pwm period duration:
>> + * period duration = ((DIV_L + 1) * (PERIOD + 1) << DIV_H) / input-clk
>> + *
>> + * The formula of pwm duty cycle duration:
>> + * duty cycle duration = period duration * DUTY_CYCLE_FALLING_POINT / (PERIOD + 1)
>> + * = ((DIV_L + 1) * DUTY_CYCLE_FALLING_POINT << DIV_H) / input-clk
>> + *
>> + * The software driver fixes the period to 255, which causes the high-frequency
>> + * precision of the PWM to be coarse, in exchange for the fineness of the duty cycle.
>> + *
>> + * Register usage:
>> + * PIN_ENABLE: When it is unset the pwm controller will always output low to the extern.
>> + * Use to determine whether the PWM channel is enabled or disabled
>> + * CLK_ENABLE: When it is unset the pwm controller will reset the duty counter to 0 and
>> + * output low 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%.
>> + *
>> + * 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.
> Another is: The PWM doesn't support duty_cycle 0, on such a request the
> PWM is disabled which results in a constant inactive level.
> (This is correct, is it? Or does it yield a constant 0 level?)
Our pwm can support duty_cycle 0 by unset CLK_ENABLE.
Other naming suggestion I will fix in the next version.
Thanks
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [v9 2/2] pwm: Add Aspeed ast2600 PWM support
@ 2021-07-16 1:48 ` Billy Tsai
0 siblings, 0 replies; 34+ messages in thread
From: Billy Tsai @ 2021-07-16 1:48 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: lee.jones, robh+dt, joel, andrew, thierry.reding, p.zabel,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-pwm, BMC-SW
Hello Uwe Kleine-König,
On 2021/7/15, 11:06 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>> wrote:
On Fri, Jul 09, 2021 at 02:52:17PM +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 <billy_tsai@aspeedtech.com>
>> ---
>> drivers/pwm/Kconfig | 9 +
>> drivers/pwm/Makefile | 1 +
>> drivers/pwm/pwm-aspeed-ast2600.c | 316 +++++++++++++++++++++++++++++++
>> 3 files changed, 326 insertions(+)
>> create mode 100644 drivers/pwm/pwm-aspeed-ast2600.c
>>
>> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
>> index 63be5362fd3a..a5aac3ca4ac7 100644
>> --- a/drivers/pwm/Kconfig
>> +++ b/drivers/pwm/Kconfig
>> @@ -51,6 +51,15 @@ 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
> I think you need
> depdens on HAVE_CLK && HAS_IOMEM
> here.
Ok, I will add it to next version.
>> + 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..68a45ba3b32b
>> --- /dev/null
>> +++ b/drivers/pwm/pwm-aspeed-ast2600.c
>> @@ -0,0 +1,316 @@
>> +// 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 formula of pwm period duration:
>> + * period duration = ((DIV_L + 1) * (PERIOD + 1) << DIV_H) / input-clk
>> + *
>> + * The formula of pwm duty cycle duration:
>> + * duty cycle duration = period duration * DUTY_CYCLE_FALLING_POINT / (PERIOD + 1)
>> + * = ((DIV_L + 1) * DUTY_CYCLE_FALLING_POINT << DIV_H) / input-clk
>> + *
>> + * The software driver fixes the period to 255, which causes the high-frequency
>> + * precision of the PWM to be coarse, in exchange for the fineness of the duty cycle.
>> + *
>> + * Register usage:
>> + * PIN_ENABLE: When it is unset the pwm controller will always output low to the extern.
>> + * Use to determine whether the PWM channel is enabled or disabled
>> + * CLK_ENABLE: When it is unset the pwm controller will reset the duty counter to 0 and
>> + * output low 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%.
>> + *
>> + * 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.
> Another is: The PWM doesn't support duty_cycle 0, on such a request the
> PWM is disabled which results in a constant inactive level.
> (This is correct, is it? Or does it yield a constant 0 level?)
Our pwm can support duty_cycle 0 by unset CLK_ENABLE.
Other naming suggestion I will fix in the next version.
Thanks
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [v9 2/2] pwm: Add Aspeed ast2600 PWM support
2021-07-16 1:48 ` Billy Tsai
@ 2021-07-16 7:09 ` Uwe Kleine-König
-1 siblings, 0 replies; 34+ messages in thread
From: Uwe Kleine-König @ 2021-07-16 7:09 UTC (permalink / raw)
To: Billy Tsai
Cc: lee.jones, robh+dt, joel, andrew, thierry.reding, p.zabel,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-pwm, BMC-SW
[-- Attachment #1: Type: text/plain, Size: 1207 bytes --]
Hello Billy,
On Fri, Jul 16, 2021 at 01:48:20AM +0000, Billy Tsai wrote:
> On 2021/7/15, 11:06 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>> wrote:
> > Another is: The PWM doesn't support duty_cycle 0, on such a request the
> > PWM is disabled which results in a constant inactive level.
>
> > (This is correct, is it? Or does it yield a constant 0 level?)
>
> Our pwm can support duty_cycle 0 by unset CLK_ENABLE.
This has a slightly different semantic though. Some consumer might
expect that the following sequence:
pwm_apply(mypwm, { .period = 10000, .duty_cycle = 10000, .enabled = true })
pwm_apply(mypwm, { .period = 10000, .duty_cycle = 0, .enabled = true })
pwm_apply(mypwm, { .period = 10000, .duty_cycle = 10000, .enabled = true })
results in the output being low for an integer multiple of 10 µs. This
isn't given with setting CLK_ENABLE to zero, is it? (I didn't recheck,
if the PWM doesn't complete periods on reconfiguration this doesn't
matter much though.)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [v9 2/2] pwm: Add Aspeed ast2600 PWM support
@ 2021-07-16 7:09 ` Uwe Kleine-König
0 siblings, 0 replies; 34+ messages in thread
From: Uwe Kleine-König @ 2021-07-16 7:09 UTC (permalink / raw)
To: Billy Tsai
Cc: lee.jones, robh+dt, joel, andrew, thierry.reding, p.zabel,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-pwm, BMC-SW
[-- Attachment #1.1: Type: text/plain, Size: 1207 bytes --]
Hello Billy,
On Fri, Jul 16, 2021 at 01:48:20AM +0000, Billy Tsai wrote:
> On 2021/7/15, 11:06 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>> wrote:
> > Another is: The PWM doesn't support duty_cycle 0, on such a request the
> > PWM is disabled which results in a constant inactive level.
>
> > (This is correct, is it? Or does it yield a constant 0 level?)
>
> Our pwm can support duty_cycle 0 by unset CLK_ENABLE.
This has a slightly different semantic though. Some consumer might
expect that the following sequence:
pwm_apply(mypwm, { .period = 10000, .duty_cycle = 10000, .enabled = true })
pwm_apply(mypwm, { .period = 10000, .duty_cycle = 0, .enabled = true })
pwm_apply(mypwm, { .period = 10000, .duty_cycle = 10000, .enabled = true })
results in the output being low for an integer multiple of 10 µs. This
isn't given with setting CLK_ENABLE to zero, is it? (I didn't recheck,
if the PWM doesn't complete periods on reconfiguration this doesn't
matter much though.)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [v9 2/2] pwm: Add Aspeed ast2600 PWM support
2021-07-16 7:09 ` Uwe Kleine-König
@ 2021-07-16 9:22 ` Billy Tsai
-1 siblings, 0 replies; 34+ messages in thread
From: Billy Tsai @ 2021-07-16 9:22 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: lee.jones, robh+dt, joel, andrew, thierry.reding, p.zabel,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-pwm, BMC-SW
Hello Uwe,
On 2021/7/16, 3:10 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> wrote:
Hello Billy,
On Fri, Jul 16, 2021 at 01:48:20AM +0000, Billy Tsai wrote:
>> On 2021/7/15, 11:06 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>> wrote:
>> > Another is: The PWM doesn't support duty_cycle 0, on such a request the
>> > PWM is disabled which results in a constant inactive level.
>>
>> > (This is correct, is it? Or does it yield a constant 0 level?)
>>
>> Our pwm can support duty_cycle 0 by unset CLK_ENABLE.
> This has a slightly different semantic though. Some consumer might
> expect that the following sequence:
> pwm_apply(mypwm, { .period = 10000, .duty_cycle = 10000, .enabled = true })
> pwm_apply(mypwm, { .period = 10000, .duty_cycle = 0, .enabled = true })
> pwm_apply(mypwm, { .period = 10000, .duty_cycle = 10000, .enabled = true })
> results in the output being low for an integer multiple of 10 µs. This
> isn't given with setting CLK_ENABLE to zero, is it? (I didn't recheck,
> if the PWM doesn't complete periods on reconfiguration this doesn't
> matter much though.)
Thanks for the explanation.
Our hardware actually can only support duty from 1/256 to 256/256.
For this situation I can do possible solution:
We can though change polarity to meet this requirement. Inverse the pin and use
duty_cycle 100.
But I think this is not a good solution for this problem right?
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [v9 2/2] pwm: Add Aspeed ast2600 PWM support
@ 2021-07-16 9:22 ` Billy Tsai
0 siblings, 0 replies; 34+ messages in thread
From: Billy Tsai @ 2021-07-16 9:22 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: lee.jones, robh+dt, joel, andrew, thierry.reding, p.zabel,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-pwm, BMC-SW
Hello Uwe,
On 2021/7/16, 3:10 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> wrote:
Hello Billy,
On Fri, Jul 16, 2021 at 01:48:20AM +0000, Billy Tsai wrote:
>> On 2021/7/15, 11:06 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>> wrote:
>> > Another is: The PWM doesn't support duty_cycle 0, on such a request the
>> > PWM is disabled which results in a constant inactive level.
>>
>> > (This is correct, is it? Or does it yield a constant 0 level?)
>>
>> Our pwm can support duty_cycle 0 by unset CLK_ENABLE.
> This has a slightly different semantic though. Some consumer might
> expect that the following sequence:
> pwm_apply(mypwm, { .period = 10000, .duty_cycle = 10000, .enabled = true })
> pwm_apply(mypwm, { .period = 10000, .duty_cycle = 0, .enabled = true })
> pwm_apply(mypwm, { .period = 10000, .duty_cycle = 10000, .enabled = true })
> results in the output being low for an integer multiple of 10 µs. This
> isn't given with setting CLK_ENABLE to zero, is it? (I didn't recheck,
> if the PWM doesn't complete periods on reconfiguration this doesn't
> matter much though.)
Thanks for the explanation.
Our hardware actually can only support duty from 1/256 to 256/256.
For this situation I can do possible solution:
We can though change polarity to meet this requirement. Inverse the pin and use
duty_cycle 100.
But I think this is not a good solution for this problem right?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [v9 2/2] pwm: Add Aspeed ast2600 PWM support
2021-07-16 9:22 ` Billy Tsai
@ 2021-07-16 10:13 ` Uwe Kleine-König
-1 siblings, 0 replies; 34+ messages in thread
From: Uwe Kleine-König @ 2021-07-16 10:13 UTC (permalink / raw)
To: Billy Tsai
Cc: lee.jones, robh+dt, joel, andrew, thierry.reding, p.zabel,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-pwm, BMC-SW
[-- Attachment #1: Type: text/plain, Size: 1954 bytes --]
Hello Billy,
On Fri, Jul 16, 2021 at 09:22:22AM +0000, Billy Tsai wrote:
> On 2021/7/16, 3:10 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> wrote:
>
> On Fri, Jul 16, 2021 at 01:48:20AM +0000, Billy Tsai wrote:
> >> On 2021/7/15, 11:06 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>> wrote:
> >> > Another is: The PWM doesn't support duty_cycle 0, on such a request the
> >> > PWM is disabled which results in a constant inactive level.
> >>
> >> > (This is correct, is it? Or does it yield a constant 0 level?)
> >>
> >> Our pwm can support duty_cycle 0 by unset CLK_ENABLE.
>
> > This has a slightly different semantic though. Some consumer might
> > expect that the following sequence:
>
> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 10000, .enabled = true })
> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 0, .enabled = true })
> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 10000, .enabled = true })
>
> > results in the output being low for an integer multiple of 10 µs. This
> > isn't given with setting CLK_ENABLE to zero, is it? (I didn't recheck,
> > if the PWM doesn't complete periods on reconfiguration this doesn't
> > matter much though.)
> Thanks for the explanation.
> Our hardware actually can only support duty from 1/256 to 256/256.
> For this situation I can do possible solution:
> We can though change polarity to meet this requirement. Inverse the pin and use
> duty_cycle 100.
> But I think this is not a good solution for this problem right?
If this doesn't result in more glitches that would be fine for me.
(Assuming it is documented good enough in the code to be
understandable.)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [v9 2/2] pwm: Add Aspeed ast2600 PWM support
@ 2021-07-16 10:13 ` Uwe Kleine-König
0 siblings, 0 replies; 34+ messages in thread
From: Uwe Kleine-König @ 2021-07-16 10:13 UTC (permalink / raw)
To: Billy Tsai
Cc: lee.jones, robh+dt, joel, andrew, thierry.reding, p.zabel,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-pwm, BMC-SW
[-- Attachment #1.1: Type: text/plain, Size: 1954 bytes --]
Hello Billy,
On Fri, Jul 16, 2021 at 09:22:22AM +0000, Billy Tsai wrote:
> On 2021/7/16, 3:10 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> wrote:
>
> On Fri, Jul 16, 2021 at 01:48:20AM +0000, Billy Tsai wrote:
> >> On 2021/7/15, 11:06 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>> wrote:
> >> > Another is: The PWM doesn't support duty_cycle 0, on such a request the
> >> > PWM is disabled which results in a constant inactive level.
> >>
> >> > (This is correct, is it? Or does it yield a constant 0 level?)
> >>
> >> Our pwm can support duty_cycle 0 by unset CLK_ENABLE.
>
> > This has a slightly different semantic though. Some consumer might
> > expect that the following sequence:
>
> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 10000, .enabled = true })
> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 0, .enabled = true })
> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 10000, .enabled = true })
>
> > results in the output being low for an integer multiple of 10 µs. This
> > isn't given with setting CLK_ENABLE to zero, is it? (I didn't recheck,
> > if the PWM doesn't complete periods on reconfiguration this doesn't
> > matter much though.)
> Thanks for the explanation.
> Our hardware actually can only support duty from 1/256 to 256/256.
> For this situation I can do possible solution:
> We can though change polarity to meet this requirement. Inverse the pin and use
> duty_cycle 100.
> But I think this is not a good solution for this problem right?
If this doesn't result in more glitches that would be fine for me.
(Assuming it is documented good enough in the code to be
understandable.)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [v9 2/2] pwm: Add Aspeed ast2600 PWM support
2021-07-16 10:13 ` Uwe Kleine-König
@ 2021-07-16 10:56 ` Billy Tsai
-1 siblings, 0 replies; 34+ messages in thread
From: Billy Tsai @ 2021-07-16 10:56 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: lee.jones, robh+dt, joel, andrew, thierry.reding, p.zabel,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-pwm, BMC-SW
Hi Uwe,
On 2021/7/16, 6:13 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> wrote:
On Fri, Jul 16, 2021 at 09:22:22AM +0000, Billy Tsai wrote:
>> On 2021/7/16, 3:10 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> wrote:
>>
>> On Fri, Jul 16, 2021 at 01:48:20AM +0000, Billy Tsai wrote:
>> >> On 2021/7/15, 11:06 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>> wrote:
>> >> > Another is: The PWM doesn't support duty_cycle 0, on such a request the
>> >> > PWM is disabled which results in a constant inactive level.
>> >>
>> >> > (This is correct, is it? Or does it yield a constant 0 level?)
>> >>
>> >> Our pwm can support duty_cycle 0 by unset CLK_ENABLE.
>>
>> > This has a slightly different semantic though. Some consumer might
>> > expect that the following sequence:
>>
>> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 10000, .enabled = true })
>> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 0, .enabled = true })
>> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 10000, .enabled = true })
>>
>> > results in the output being low for an integer multiple of 10 µs. This
>> > isn't given with setting CLK_ENABLE to zero, is it? (I didn't recheck,
>> > if the PWM doesn't complete periods on reconfiguration this doesn't
>> > matter much though.)
>> Thanks for the explanation.
>> Our hardware actually can only support duty from 1/256 to 256/256.
>> For this situation I can do possible solution:
>> We can though change polarity to meet this requirement. Inverse the pin and use
>> duty_cycle 100.
>> But I think this is not a good solution for this problem right?
> If this doesn't result in more glitches that would be fine for me.
> (Assuming it is documented good enough in the code to be
> understandable.)
The polarity of our pwm controller will affect the duty cycle range:
PWM_POLARITY_INVERSED : Support duty_cycle from 0% to 99%
PWM_POLARITY_NORMAL: Support duty_cycle from 1% to 100%
Dynamic change polarity will result in more glitches. Thus, this will become
a trade-off between 100% and 0% duty_cycle support for user to use our pwm device.
I will document it and send next patch.
Thanks
Best Regards,
Billy Tsai
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [v9 2/2] pwm: Add Aspeed ast2600 PWM support
@ 2021-07-16 10:56 ` Billy Tsai
0 siblings, 0 replies; 34+ messages in thread
From: Billy Tsai @ 2021-07-16 10:56 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: lee.jones, robh+dt, joel, andrew, thierry.reding, p.zabel,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-pwm, BMC-SW
Hi Uwe,
On 2021/7/16, 6:13 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> wrote:
On Fri, Jul 16, 2021 at 09:22:22AM +0000, Billy Tsai wrote:
>> On 2021/7/16, 3:10 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> wrote:
>>
>> On Fri, Jul 16, 2021 at 01:48:20AM +0000, Billy Tsai wrote:
>> >> On 2021/7/15, 11:06 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>> wrote:
>> >> > Another is: The PWM doesn't support duty_cycle 0, on such a request the
>> >> > PWM is disabled which results in a constant inactive level.
>> >>
>> >> > (This is correct, is it? Or does it yield a constant 0 level?)
>> >>
>> >> Our pwm can support duty_cycle 0 by unset CLK_ENABLE.
>>
>> > This has a slightly different semantic though. Some consumer might
>> > expect that the following sequence:
>>
>> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 10000, .enabled = true })
>> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 0, .enabled = true })
>> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 10000, .enabled = true })
>>
>> > results in the output being low for an integer multiple of 10 µs. This
>> > isn't given with setting CLK_ENABLE to zero, is it? (I didn't recheck,
>> > if the PWM doesn't complete periods on reconfiguration this doesn't
>> > matter much though.)
>> Thanks for the explanation.
>> Our hardware actually can only support duty from 1/256 to 256/256.
>> For this situation I can do possible solution:
>> We can though change polarity to meet this requirement. Inverse the pin and use
>> duty_cycle 100.
>> But I think this is not a good solution for this problem right?
> If this doesn't result in more glitches that would be fine for me.
> (Assuming it is documented good enough in the code to be
> understandable.)
The polarity of our pwm controller will affect the duty cycle range:
PWM_POLARITY_INVERSED : Support duty_cycle from 0% to 99%
PWM_POLARITY_NORMAL: Support duty_cycle from 1% to 100%
Dynamic change polarity will result in more glitches. Thus, this will become
a trade-off between 100% and 0% duty_cycle support for user to use our pwm device.
I will document it and send next patch.
Thanks
Best Regards,
Billy Tsai
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [v9 2/2] pwm: Add Aspeed ast2600 PWM support
2021-07-16 10:56 ` Billy Tsai
@ 2021-07-21 10:52 ` Billy Tsai
-1 siblings, 0 replies; 34+ messages in thread
From: Billy Tsai @ 2021-07-21 10:52 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: lee.jones, robh+dt, joel, andrew, thierry.reding, p.zabel,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-pwm, BMC-SW
Hi Uwe,
On 2021/7/16, 6:13 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> wrote:
On Fri, Jul 16, 2021 at 09:22:22AM +0000, Billy Tsai wrote:
>> On 2021/7/16, 3:10 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> wrote:
>>
>> On Fri, Jul 16, 2021 at 01:48:20AM +0000, Billy Tsai wrote:
>> >> On 2021/7/15, 11:06 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>> wrote:
>> >> > Another is: The PWM doesn't support duty_cycle 0, on such a request the
>> >> > PWM is disabled which results in a constant inactive level.
>> >>
>> >> > (This is correct, is it? Or does it yield a constant 0 level?)
>> >>
>> >> Our pwm can support duty_cycle 0 by unset CLK_ENABLE.
>>
>> > This has a slightly different semantic though. Some consumer might
>> > expect that the following sequence:
>>
>> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 10000, .enabled = true })
>> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 0, .enabled = true })
>> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 10000, .enabled = true })
>>
>> > results in the output being low for an integer multiple of 10 µs. This
>> > isn't given with setting CLK_ENABLE to zero, is it? (I didn't recheck,
>> > if the PWM doesn't complete periods on reconfiguration this doesn't
>> > matter much though.)
>> Thanks for the explanation.
>> Our hardware actually can only support duty from 1/256 to 256/256.
>> For this situation I can do possible solution:
>> We can though change polarity to meet this requirement. Inverse the pin and use
>> duty_cycle 100.
>> But I think this is not a good solution for this problem right?
> If this doesn't result in more glitches that would be fine for me.
> (Assuming it is documented good enough in the code to be
> understandable.)
> The polarity of our pwm controller will affect the duty cycle range:
> PWM_POLARITY_INVERSED : Support duty_cycle from 0% to 99%
> PWM_POLARITY_NORMAL: Support duty_cycle from 1% to 100%
> Dynamic change polarity will result in more glitches. Thus, this will become
> a trade-off between 100% and 0% duty_cycle support for user to use our pwm device.
> I will document it and send next patch.
For handling the situation that the user want to set the duty cycle to 0%, the driver can:
1. Just return the error.
2. Use the minimum duty cycle value.
I don't know which solution will be the better way or others.
I would be grateful if you can give me some suggestion about this problem.
Thanks
Best Regards,
Billy Tsai
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [v9 2/2] pwm: Add Aspeed ast2600 PWM support
@ 2021-07-21 10:52 ` Billy Tsai
0 siblings, 0 replies; 34+ messages in thread
From: Billy Tsai @ 2021-07-21 10:52 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: lee.jones, robh+dt, joel, andrew, thierry.reding, p.zabel,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-pwm, BMC-SW
Hi Uwe,
On 2021/7/16, 6:13 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> wrote:
On Fri, Jul 16, 2021 at 09:22:22AM +0000, Billy Tsai wrote:
>> On 2021/7/16, 3:10 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> wrote:
>>
>> On Fri, Jul 16, 2021 at 01:48:20AM +0000, Billy Tsai wrote:
>> >> On 2021/7/15, 11:06 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>> wrote:
>> >> > Another is: The PWM doesn't support duty_cycle 0, on such a request the
>> >> > PWM is disabled which results in a constant inactive level.
>> >>
>> >> > (This is correct, is it? Or does it yield a constant 0 level?)
>> >>
>> >> Our pwm can support duty_cycle 0 by unset CLK_ENABLE.
>>
>> > This has a slightly different semantic though. Some consumer might
>> > expect that the following sequence:
>>
>> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 10000, .enabled = true })
>> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 0, .enabled = true })
>> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 10000, .enabled = true })
>>
>> > results in the output being low for an integer multiple of 10 µs. This
>> > isn't given with setting CLK_ENABLE to zero, is it? (I didn't recheck,
>> > if the PWM doesn't complete periods on reconfiguration this doesn't
>> > matter much though.)
>> Thanks for the explanation.
>> Our hardware actually can only support duty from 1/256 to 256/256.
>> For this situation I can do possible solution:
>> We can though change polarity to meet this requirement. Inverse the pin and use
>> duty_cycle 100.
>> But I think this is not a good solution for this problem right?
> If this doesn't result in more glitches that would be fine for me.
> (Assuming it is documented good enough in the code to be
> understandable.)
> The polarity of our pwm controller will affect the duty cycle range:
> PWM_POLARITY_INVERSED : Support duty_cycle from 0% to 99%
> PWM_POLARITY_NORMAL: Support duty_cycle from 1% to 100%
> Dynamic change polarity will result in more glitches. Thus, this will become
> a trade-off between 100% and 0% duty_cycle support for user to use our pwm device.
> I will document it and send next patch.
For handling the situation that the user want to set the duty cycle to 0%, the driver can:
1. Just return the error.
2. Use the minimum duty cycle value.
I don't know which solution will be the better way or others.
I would be grateful if you can give me some suggestion about this problem.
Thanks
Best Regards,
Billy Tsai
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [v9 2/2] pwm: Add Aspeed ast2600 PWM support
2021-07-21 10:52 ` Billy Tsai
@ 2021-07-21 12:48 ` Uwe Kleine-König
-1 siblings, 0 replies; 34+ messages in thread
From: Uwe Kleine-König @ 2021-07-21 12:48 UTC (permalink / raw)
To: Billy Tsai
Cc: lee.jones, robh+dt, joel, andrew, thierry.reding, p.zabel,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-pwm, BMC-SW
[-- Attachment #1: Type: text/plain, Size: 3345 bytes --]
On Wed, Jul 21, 2021 at 10:52:21AM +0000, Billy Tsai wrote:
> Hi Uwe,
>
> On 2021/7/16, 6:13 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> wrote:
>
> On Fri, Jul 16, 2021 at 09:22:22AM +0000, Billy Tsai wrote:
> >> On 2021/7/16, 3:10 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> wrote:
> >>
> >> On Fri, Jul 16, 2021 at 01:48:20AM +0000, Billy Tsai wrote:
> >> >> On 2021/7/15, 11:06 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>> wrote:
> >> >> > Another is: The PWM doesn't support duty_cycle 0, on such a request the
> >> >> > PWM is disabled which results in a constant inactive level.
> >> >>
> >> >> > (This is correct, is it? Or does it yield a constant 0 level?)
> >> >>
> >> >> Our pwm can support duty_cycle 0 by unset CLK_ENABLE.
> >>
> >> > This has a slightly different semantic though. Some consumer might
> >> > expect that the following sequence:
> >>
> >> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 10000, .enabled = true })
> >> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 0, .enabled = true })
> >> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 10000, .enabled = true })
> >>
> >> > results in the output being low for an integer multiple of 10 µs. This
> >> > isn't given with setting CLK_ENABLE to zero, is it? (I didn't recheck,
> >> > if the PWM doesn't complete periods on reconfiguration this doesn't
> >> > matter much though.)
> >> Thanks for the explanation.
> >> Our hardware actually can only support duty from 1/256 to 256/256.
> >> For this situation I can do possible solution:
> >> We can though change polarity to meet this requirement. Inverse the pin and use
> >> duty_cycle 100.
> >> But I think this is not a good solution for this problem right?
>
> > If this doesn't result in more glitches that would be fine for me.
> > (Assuming it is documented good enough in the code to be
> > understandable.)
>
> > The polarity of our pwm controller will affect the duty cycle range:
> > PWM_POLARITY_INVERSED : Support duty_cycle from 0% to 99%
> > PWM_POLARITY_NORMAL: Support duty_cycle from 1% to 100%
> > Dynamic change polarity will result in more glitches. Thus, this will become
> > a trade-off between 100% and 0% duty_cycle support for user to use our pwm device.
> > I will document it and send next patch.
>
> For handling the situation that the user want to set the duty cycle to 0%, the driver can:
> 1. Just return the error.
> 2. Use the minimum duty cycle value.
> I don't know which solution will be the better way or others.
> I would be grateful if you can give me some suggestion about this problem.
I thought if you disable the PWM it emits the inactive level? Then this
is the best you can do if duty_cycle = 0 is requested.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [v9 2/2] pwm: Add Aspeed ast2600 PWM support
@ 2021-07-21 12:48 ` Uwe Kleine-König
0 siblings, 0 replies; 34+ messages in thread
From: Uwe Kleine-König @ 2021-07-21 12:48 UTC (permalink / raw)
To: Billy Tsai
Cc: lee.jones, robh+dt, joel, andrew, thierry.reding, p.zabel,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-pwm, BMC-SW
[-- Attachment #1.1: Type: text/plain, Size: 3345 bytes --]
On Wed, Jul 21, 2021 at 10:52:21AM +0000, Billy Tsai wrote:
> Hi Uwe,
>
> On 2021/7/16, 6:13 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> wrote:
>
> On Fri, Jul 16, 2021 at 09:22:22AM +0000, Billy Tsai wrote:
> >> On 2021/7/16, 3:10 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> wrote:
> >>
> >> On Fri, Jul 16, 2021 at 01:48:20AM +0000, Billy Tsai wrote:
> >> >> On 2021/7/15, 11:06 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>> wrote:
> >> >> > Another is: The PWM doesn't support duty_cycle 0, on such a request the
> >> >> > PWM is disabled which results in a constant inactive level.
> >> >>
> >> >> > (This is correct, is it? Or does it yield a constant 0 level?)
> >> >>
> >> >> Our pwm can support duty_cycle 0 by unset CLK_ENABLE.
> >>
> >> > This has a slightly different semantic though. Some consumer might
> >> > expect that the following sequence:
> >>
> >> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 10000, .enabled = true })
> >> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 0, .enabled = true })
> >> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 10000, .enabled = true })
> >>
> >> > results in the output being low for an integer multiple of 10 µs. This
> >> > isn't given with setting CLK_ENABLE to zero, is it? (I didn't recheck,
> >> > if the PWM doesn't complete periods on reconfiguration this doesn't
> >> > matter much though.)
> >> Thanks for the explanation.
> >> Our hardware actually can only support duty from 1/256 to 256/256.
> >> For this situation I can do possible solution:
> >> We can though change polarity to meet this requirement. Inverse the pin and use
> >> duty_cycle 100.
> >> But I think this is not a good solution for this problem right?
>
> > If this doesn't result in more glitches that would be fine for me.
> > (Assuming it is documented good enough in the code to be
> > understandable.)
>
> > The polarity of our pwm controller will affect the duty cycle range:
> > PWM_POLARITY_INVERSED : Support duty_cycle from 0% to 99%
> > PWM_POLARITY_NORMAL: Support duty_cycle from 1% to 100%
> > Dynamic change polarity will result in more glitches. Thus, this will become
> > a trade-off between 100% and 0% duty_cycle support for user to use our pwm device.
> > I will document it and send next patch.
>
> For handling the situation that the user want to set the duty cycle to 0%, the driver can:
> 1. Just return the error.
> 2. Use the minimum duty cycle value.
> I don't know which solution will be the better way or others.
> I would be grateful if you can give me some suggestion about this problem.
I thought if you disable the PWM it emits the inactive level? Then this
is the best you can do if duty_cycle = 0 is requested.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [v9 2/2] pwm: Add Aspeed ast2600 PWM support
2021-07-21 12:48 ` Uwe Kleine-König
@ 2021-07-23 4:23 ` Billy Tsai
-1 siblings, 0 replies; 34+ messages in thread
From: Billy Tsai @ 2021-07-23 4:23 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: lee.jones, robh+dt, joel, andrew, thierry.reding, p.zabel,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-pwm, BMC-SW
On 2021/7/23, 3:17 AM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> wrote:
On Wed, Jul 21, 2021 at 10:52:21AM +0000, Billy Tsai wrote:
>> Hi Uwe,
>>
>> On 2021/7/16, 6:13 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> wrote:
>>
>> On Fri, Jul 16, 2021 at 09:22:22AM +0000, Billy Tsai wrote:
>> >> On 2021/7/16, 3:10 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> wrote:
>> >>
>> >> On Fri, Jul 16, 2021 at 01:48:20AM +0000, Billy Tsai wrote:
>> >> >> On 2021/7/15, 11:06 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>> wrote:
>> >> >> > Another is: The PWM doesn't support duty_cycle 0, on such a request the
>> >> >> > PWM is disabled which results in a constant inactive level.
>> >> >>
>> >> >> > (This is correct, is it? Or does it yield a constant 0 level?)
>> >> >>
>> >> >> Our pwm can support duty_cycle 0 by unset CLK_ENABLE.
>> >>
>> >> > This has a slightly different semantic though. Some consumer might
>> >> > expect that the following sequence:
>> >>
>> >> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 10000, .enabled = true })
>> >> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 0, .enabled = true })
>> >> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 10000, .enabled = true })
>> >>
>> >> > results in the output being low for an integer multiple of 10 µs. This
>> >> > isn't given with setting CLK_ENABLE to zero, is it? (I didn't recheck,
>> >> > if the PWM doesn't complete periods on reconfiguration this doesn't
>> >> > matter much though.)
>> >> Thanks for the explanation.
>> >> Our hardware actually can only support duty from 1/256 to 256/256.
>> >> For this situation I can do possible solution:
>> >> We can though change polarity to meet this requirement. Inverse the pin and use
>> >> duty_cycle 100.
>> >> But I think this is not a good solution for this problem right?
>>
>> > If this doesn't result in more glitches that would be fine for me.
>> > (Assuming it is documented good enough in the code to be
>> > understandable.)
>>
>> > The polarity of our pwm controller will affect the duty cycle range:
>> > PWM_POLARITY_INVERSED : Support duty_cycle from 0% to 99%
>> > PWM_POLARITY_NORMAL: Support duty_cycle from 1% to 100%
>> > Dynamic change polarity will result in more glitches. Thus, this will become
>> > a trade-off between 100% and 0% duty_cycle support for user to use our pwm device.
>> > I will document it and send next patch.
>>
>> For handling the situation that the user want to set the duty cycle to 0%, the driver can:
>> 1. Just return the error.
>> 2. Use the minimum duty cycle value.
>> I don't know which solution will be the better way or others.
>> I would be grateful if you can give me some suggestion about this problem.
> I thought if you disable the PWM it emits the inactive level? Then this
> is the best you can do if duty_cycle = 0 is requested.
Thanks for your quick reply.
When duty_cycle = 0 is requested my driver currently will emit the inactive level.
So, the next patch I need to do is to add the comment about this?
Best Regards,
Billy Tsai
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [v9 2/2] pwm: Add Aspeed ast2600 PWM support
@ 2021-07-23 4:23 ` Billy Tsai
0 siblings, 0 replies; 34+ messages in thread
From: Billy Tsai @ 2021-07-23 4:23 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: lee.jones, robh+dt, joel, andrew, thierry.reding, p.zabel,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-pwm, BMC-SW
On 2021/7/23, 3:17 AM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> wrote:
On Wed, Jul 21, 2021 at 10:52:21AM +0000, Billy Tsai wrote:
>> Hi Uwe,
>>
>> On 2021/7/16, 6:13 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> wrote:
>>
>> On Fri, Jul 16, 2021 at 09:22:22AM +0000, Billy Tsai wrote:
>> >> On 2021/7/16, 3:10 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> wrote:
>> >>
>> >> On Fri, Jul 16, 2021 at 01:48:20AM +0000, Billy Tsai wrote:
>> >> >> On 2021/7/15, 11:06 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>> wrote:
>> >> >> > Another is: The PWM doesn't support duty_cycle 0, on such a request the
>> >> >> > PWM is disabled which results in a constant inactive level.
>> >> >>
>> >> >> > (This is correct, is it? Or does it yield a constant 0 level?)
>> >> >>
>> >> >> Our pwm can support duty_cycle 0 by unset CLK_ENABLE.
>> >>
>> >> > This has a slightly different semantic though. Some consumer might
>> >> > expect that the following sequence:
>> >>
>> >> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 10000, .enabled = true })
>> >> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 0, .enabled = true })
>> >> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 10000, .enabled = true })
>> >>
>> >> > results in the output being low for an integer multiple of 10 µs. This
>> >> > isn't given with setting CLK_ENABLE to zero, is it? (I didn't recheck,
>> >> > if the PWM doesn't complete periods on reconfiguration this doesn't
>> >> > matter much though.)
>> >> Thanks for the explanation.
>> >> Our hardware actually can only support duty from 1/256 to 256/256.
>> >> For this situation I can do possible solution:
>> >> We can though change polarity to meet this requirement. Inverse the pin and use
>> >> duty_cycle 100.
>> >> But I think this is not a good solution for this problem right?
>>
>> > If this doesn't result in more glitches that would be fine for me.
>> > (Assuming it is documented good enough in the code to be
>> > understandable.)
>>
>> > The polarity of our pwm controller will affect the duty cycle range:
>> > PWM_POLARITY_INVERSED : Support duty_cycle from 0% to 99%
>> > PWM_POLARITY_NORMAL: Support duty_cycle from 1% to 100%
>> > Dynamic change polarity will result in more glitches. Thus, this will become
>> > a trade-off between 100% and 0% duty_cycle support for user to use our pwm device.
>> > I will document it and send next patch.
>>
>> For handling the situation that the user want to set the duty cycle to 0%, the driver can:
>> 1. Just return the error.
>> 2. Use the minimum duty cycle value.
>> I don't know which solution will be the better way or others.
>> I would be grateful if you can give me some suggestion about this problem.
> I thought if you disable the PWM it emits the inactive level? Then this
> is the best you can do if duty_cycle = 0 is requested.
Thanks for your quick reply.
When duty_cycle = 0 is requested my driver currently will emit the inactive level.
So, the next patch I need to do is to add the comment about this?
Best Regards,
Billy Tsai
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [v9 2/2] pwm: Add Aspeed ast2600 PWM support
2021-07-23 4:23 ` Billy Tsai
@ 2021-07-23 20:12 ` Uwe Kleine-König
-1 siblings, 0 replies; 34+ messages in thread
From: Uwe Kleine-König @ 2021-07-23 20:12 UTC (permalink / raw)
To: Billy Tsai
Cc: lee.jones, robh+dt, joel, andrew, thierry.reding, p.zabel,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-pwm, BMC-SW
[-- Attachment #1: Type: text/plain, Size: 4585 bytes --]
On Fri, Jul 23, 2021 at 04:23:23AM +0000, Billy Tsai wrote:
> On 2021/7/23, 3:17 AM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> wrote:
>
> On Wed, Jul 21, 2021 at 10:52:21AM +0000, Billy Tsai wrote:
> >> Hi Uwe,
> >>
> >> On 2021/7/16, 6:13 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> wrote:
> >>
> >> On Fri, Jul 16, 2021 at 09:22:22AM +0000, Billy Tsai wrote:
> >> >> On 2021/7/16, 3:10 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> wrote:
> >> >>
> >> >> On Fri, Jul 16, 2021 at 01:48:20AM +0000, Billy Tsai wrote:
> >> >> >> On 2021/7/15, 11:06 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>> wrote:
> >> >> >> > Another is: The PWM doesn't support duty_cycle 0, on such a request the
> >> >> >> > PWM is disabled which results in a constant inactive level.
> >> >> >>
> >> >> >> > (This is correct, is it? Or does it yield a constant 0 level?)
> >> >> >>
> >> >> >> Our pwm can support duty_cycle 0 by unset CLK_ENABLE.
> >> >>
> >> >> > This has a slightly different semantic though. Some consumer might
> >> >> > expect that the following sequence:
> >> >>
> >> >> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 10000, .enabled = true })
> >> >> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 0, .enabled = true })
> >> >> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 10000, .enabled = true })
> >> >>
> >> >> > results in the output being low for an integer multiple of 10 µs. This
> >> >> > isn't given with setting CLK_ENABLE to zero, is it? (I didn't recheck,
> >> >> > if the PWM doesn't complete periods on reconfiguration this doesn't
> >> >> > matter much though.)
> >> >> Thanks for the explanation.
> >> >> Our hardware actually can only support duty from 1/256 to 256/256.
> >> >> For this situation I can do possible solution:
> >> >> We can though change polarity to meet this requirement. Inverse the pin and use
> >> >> duty_cycle 100.
> >> >> But I think this is not a good solution for this problem right?
> >>
> >> > If this doesn't result in more glitches that would be fine for me.
> >> > (Assuming it is documented good enough in the code to be
> >> > understandable.)
> >>
> >> > The polarity of our pwm controller will affect the duty cycle range:
> >> > PWM_POLARITY_INVERSED : Support duty_cycle from 0% to 99%
> >> > PWM_POLARITY_NORMAL: Support duty_cycle from 1% to 100%
> >> > Dynamic change polarity will result in more glitches. Thus, this will become
> >> > a trade-off between 100% and 0% duty_cycle support for user to use our pwm device.
> >> > I will document it and send next patch.
> >>
> >> For handling the situation that the user want to set the duty cycle to 0%, the driver can:
> >> 1. Just return the error.
> >> 2. Use the minimum duty cycle value.
> >> I don't know which solution will be the better way or others.
> >> I would be grateful if you can give me some suggestion about this problem.
>
> > I thought if you disable the PWM it emits the inactive level? Then this
> > is the best you can do if duty_cycle = 0 is requested.
>
> Thanks for your quick reply.
> When duty_cycle = 0 is requested my driver currently will emit the inactive level.
> So, the next patch I need to do is to add the comment about this?
Not sure I got the complete picture now. The things I consider important
are:
- If your hardware cannot emit a 100% or 0% relative duty cycle, note
this in the Limitations section
- Assuming your PWM emits the inactive level when disabled (that is 0
for PWM_POLARITY_NORMAL and 1 for PWM_POLARITY_INVERSED) this is the
best that can be done when a 0% relative duty cycle is requested
(assuming the hardware cannot implement that in a normal way).
I hope this answered your remaining questions.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [v9 2/2] pwm: Add Aspeed ast2600 PWM support
@ 2021-07-23 20:12 ` Uwe Kleine-König
0 siblings, 0 replies; 34+ messages in thread
From: Uwe Kleine-König @ 2021-07-23 20:12 UTC (permalink / raw)
To: Billy Tsai
Cc: lee.jones, robh+dt, joel, andrew, thierry.reding, p.zabel,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-pwm, BMC-SW
[-- Attachment #1.1: Type: text/plain, Size: 4585 bytes --]
On Fri, Jul 23, 2021 at 04:23:23AM +0000, Billy Tsai wrote:
> On 2021/7/23, 3:17 AM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> wrote:
>
> On Wed, Jul 21, 2021 at 10:52:21AM +0000, Billy Tsai wrote:
> >> Hi Uwe,
> >>
> >> On 2021/7/16, 6:13 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> wrote:
> >>
> >> On Fri, Jul 16, 2021 at 09:22:22AM +0000, Billy Tsai wrote:
> >> >> On 2021/7/16, 3:10 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> wrote:
> >> >>
> >> >> On Fri, Jul 16, 2021 at 01:48:20AM +0000, Billy Tsai wrote:
> >> >> >> On 2021/7/15, 11:06 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>> wrote:
> >> >> >> > Another is: The PWM doesn't support duty_cycle 0, on such a request the
> >> >> >> > PWM is disabled which results in a constant inactive level.
> >> >> >>
> >> >> >> > (This is correct, is it? Or does it yield a constant 0 level?)
> >> >> >>
> >> >> >> Our pwm can support duty_cycle 0 by unset CLK_ENABLE.
> >> >>
> >> >> > This has a slightly different semantic though. Some consumer might
> >> >> > expect that the following sequence:
> >> >>
> >> >> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 10000, .enabled = true })
> >> >> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 0, .enabled = true })
> >> >> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 10000, .enabled = true })
> >> >>
> >> >> > results in the output being low for an integer multiple of 10 µs. This
> >> >> > isn't given with setting CLK_ENABLE to zero, is it? (I didn't recheck,
> >> >> > if the PWM doesn't complete periods on reconfiguration this doesn't
> >> >> > matter much though.)
> >> >> Thanks for the explanation.
> >> >> Our hardware actually can only support duty from 1/256 to 256/256.
> >> >> For this situation I can do possible solution:
> >> >> We can though change polarity to meet this requirement. Inverse the pin and use
> >> >> duty_cycle 100.
> >> >> But I think this is not a good solution for this problem right?
> >>
> >> > If this doesn't result in more glitches that would be fine for me.
> >> > (Assuming it is documented good enough in the code to be
> >> > understandable.)
> >>
> >> > The polarity of our pwm controller will affect the duty cycle range:
> >> > PWM_POLARITY_INVERSED : Support duty_cycle from 0% to 99%
> >> > PWM_POLARITY_NORMAL: Support duty_cycle from 1% to 100%
> >> > Dynamic change polarity will result in more glitches. Thus, this will become
> >> > a trade-off between 100% and 0% duty_cycle support for user to use our pwm device.
> >> > I will document it and send next patch.
> >>
> >> For handling the situation that the user want to set the duty cycle to 0%, the driver can:
> >> 1. Just return the error.
> >> 2. Use the minimum duty cycle value.
> >> I don't know which solution will be the better way or others.
> >> I would be grateful if you can give me some suggestion about this problem.
>
> > I thought if you disable the PWM it emits the inactive level? Then this
> > is the best you can do if duty_cycle = 0 is requested.
>
> Thanks for your quick reply.
> When duty_cycle = 0 is requested my driver currently will emit the inactive level.
> So, the next patch I need to do is to add the comment about this?
Not sure I got the complete picture now. The things I consider important
are:
- If your hardware cannot emit a 100% or 0% relative duty cycle, note
this in the Limitations section
- Assuming your PWM emits the inactive level when disabled (that is 0
for PWM_POLARITY_NORMAL and 1 for PWM_POLARITY_INVERSED) this is the
best that can be done when a 0% relative duty cycle is requested
(assuming the hardware cannot implement that in a normal way).
I hope this answered your remaining questions.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [v9 2/2] pwm: Add Aspeed ast2600 PWM support
2021-07-23 20:12 ` Uwe Kleine-König
@ 2021-07-26 5:14 ` Billy Tsai
-1 siblings, 0 replies; 34+ messages in thread
From: Billy Tsai @ 2021-07-26 5:14 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: lee.jones, robh+dt, joel, andrew, thierry.reding, p.zabel,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-pwm, BMC-SW
Hi Uwe
On 2021/7/24, 4:13 AM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> wrote:
> On Fri, Jul 23, 2021 at 04:23:23AM +0000, Billy Tsai wrote:
> > On 2021/7/23, 3:17 AM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> wrote:
> >
> > On Wed, Jul 21, 2021 at 10:52:21AM +0000, Billy Tsai wrote:
> > >> Hi Uwe,
> > >>
> > >> On 2021/7/16, 6:13 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> wrote:
> > >>
> > >> On Fri, Jul 16, 2021 at 09:22:22AM +0000, Billy Tsai wrote:
> > >> >> On 2021/7/16, 3:10 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> wrote:
> > >> >>
> > >> >> On Fri, Jul 16, 2021 at 01:48:20AM +0000, Billy Tsai wrote:
> > >> >> >> On 2021/7/15, 11:06 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>> wrote:
> > >> >> >> > Another is: The PWM doesn't support duty_cycle 0, on such a request the
> > >> >> >> > PWM is disabled which results in a constant inactive level.
> > >> >> >>
> > >> >> >> > (This is correct, is it? Or does it yield a constant 0 level?)
> > >> >> >>
> > >> >> >> Our pwm can support duty_cycle 0 by unset CLK_ENABLE.
> > >> >>
> > >> >> > This has a slightly different semantic though. Some consumer might
> > >> >> > expect that the following sequence:
> > >> >>
> > >> >> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 10000, .enabled = true })
> > >> >> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 0, .enabled = true })
> > >> >> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 10000, .enabled = true })
> > >> >>
> > >> >> > results in the output being low for an integer multiple of 10 µs. This
> > >> >> > isn't given with setting CLK_ENABLE to zero, is it? (I didn't recheck,
> > >> >> > if the PWM doesn't complete periods on reconfiguration this doesn't
> > >> >> > matter much though.)
> > >> >> Thanks for the explanation.
> > >> >> Our hardware actually can only support duty from 1/256 to 256/256.
> > >> >> For this situation I can do possible solution:
> > >> >> We can though change polarity to meet this requirement. Inverse the pin and use
> > >> >> duty_cycle 100.
> > >> >> But I think this is not a good solution for this problem right?
> > >>
> > >> > If this doesn't result in more glitches that would be fine for me.
> > >> > (Assuming it is documented good enough in the code to be
> > >> > understandable.)
> > >>
> > >> > The polarity of our pwm controller will affect the duty cycle range:
> > >> > PWM_POLARITY_INVERSED : Support duty_cycle from 0% to 99%
> > >> > PWM_POLARITY_NORMAL: Support duty_cycle from 1% to 100%
> > >> > Dynamic change polarity will result in more glitches. Thus, this will become
> > >> > a trade-off between 100% and 0% duty_cycle support for user to use our pwm device.
> > >> > I will document it and send next patch.
> > >>
> > >> For handling the situation that the user want to set the duty cycle to 0%, the driver can:
> > >> 1. Just return the error.
> > >> 2. Use the minimum duty cycle value.
> > >> I don't know which solution will be the better way or others.
> > >> I would be grateful if you can give me some suggestion about this problem.
> >
> > > I thought if you disable the PWM it emits the inactive level? Then this
> > > is the best you can do if duty_cycle = 0 is requested.
> >
> > Thanks for your quick reply.
> > When duty_cycle = 0 is requested my driver currently will emit the inactive level.
> > So, the next patch I need to do is to add the comment about this?
> Not sure I got the complete picture now. The things I consider important
> are:
> - If your hardware cannot emit a 100% or 0% relative duty cycle, note
> this in the Limitations section
> - Assuming your PWM emits the inactive level when disabled (that is 0
> for PWM_POLARITY_NORMAL and 1 for PWM_POLARITY_INVERSED) this is the
> best that can be done when a 0% relative duty cycle is requested
> (assuming the hardware cannot implement that in a normal way).
Our hardware is the same as this description.
So I didn't need to add the limitations about the duty cycle, right?
Or I need to note that the duty cycle 0% is just the inactive output that doesn't have the period concept.
> I hope this answered your remaining questions.
Thanks.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [v9 2/2] pwm: Add Aspeed ast2600 PWM support
@ 2021-07-26 5:14 ` Billy Tsai
0 siblings, 0 replies; 34+ messages in thread
From: Billy Tsai @ 2021-07-26 5:14 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: lee.jones, robh+dt, joel, andrew, thierry.reding, p.zabel,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-pwm, BMC-SW
Hi Uwe
On 2021/7/24, 4:13 AM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> wrote:
> On Fri, Jul 23, 2021 at 04:23:23AM +0000, Billy Tsai wrote:
> > On 2021/7/23, 3:17 AM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> wrote:
> >
> > On Wed, Jul 21, 2021 at 10:52:21AM +0000, Billy Tsai wrote:
> > >> Hi Uwe,
> > >>
> > >> On 2021/7/16, 6:13 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> wrote:
> > >>
> > >> On Fri, Jul 16, 2021 at 09:22:22AM +0000, Billy Tsai wrote:
> > >> >> On 2021/7/16, 3:10 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> wrote:
> > >> >>
> > >> >> On Fri, Jul 16, 2021 at 01:48:20AM +0000, Billy Tsai wrote:
> > >> >> >> On 2021/7/15, 11:06 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>> wrote:
> > >> >> >> > Another is: The PWM doesn't support duty_cycle 0, on such a request the
> > >> >> >> > PWM is disabled which results in a constant inactive level.
> > >> >> >>
> > >> >> >> > (This is correct, is it? Or does it yield a constant 0 level?)
> > >> >> >>
> > >> >> >> Our pwm can support duty_cycle 0 by unset CLK_ENABLE.
> > >> >>
> > >> >> > This has a slightly different semantic though. Some consumer might
> > >> >> > expect that the following sequence:
> > >> >>
> > >> >> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 10000, .enabled = true })
> > >> >> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 0, .enabled = true })
> > >> >> > pwm_apply(mypwm, { .period = 10000, .duty_cycle = 10000, .enabled = true })
> > >> >>
> > >> >> > results in the output being low for an integer multiple of 10 µs. This
> > >> >> > isn't given with setting CLK_ENABLE to zero, is it? (I didn't recheck,
> > >> >> > if the PWM doesn't complete periods on reconfiguration this doesn't
> > >> >> > matter much though.)
> > >> >> Thanks for the explanation.
> > >> >> Our hardware actually can only support duty from 1/256 to 256/256.
> > >> >> For this situation I can do possible solution:
> > >> >> We can though change polarity to meet this requirement. Inverse the pin and use
> > >> >> duty_cycle 100.
> > >> >> But I think this is not a good solution for this problem right?
> > >>
> > >> > If this doesn't result in more glitches that would be fine for me.
> > >> > (Assuming it is documented good enough in the code to be
> > >> > understandable.)
> > >>
> > >> > The polarity of our pwm controller will affect the duty cycle range:
> > >> > PWM_POLARITY_INVERSED : Support duty_cycle from 0% to 99%
> > >> > PWM_POLARITY_NORMAL: Support duty_cycle from 1% to 100%
> > >> > Dynamic change polarity will result in more glitches. Thus, this will become
> > >> > a trade-off between 100% and 0% duty_cycle support for user to use our pwm device.
> > >> > I will document it and send next patch.
> > >>
> > >> For handling the situation that the user want to set the duty cycle to 0%, the driver can:
> > >> 1. Just return the error.
> > >> 2. Use the minimum duty cycle value.
> > >> I don't know which solution will be the better way or others.
> > >> I would be grateful if you can give me some suggestion about this problem.
> >
> > > I thought if you disable the PWM it emits the inactive level? Then this
> > > is the best you can do if duty_cycle = 0 is requested.
> >
> > Thanks for your quick reply.
> > When duty_cycle = 0 is requested my driver currently will emit the inactive level.
> > So, the next patch I need to do is to add the comment about this?
> Not sure I got the complete picture now. The things I consider important
> are:
> - If your hardware cannot emit a 100% or 0% relative duty cycle, note
> this in the Limitations section
> - Assuming your PWM emits the inactive level when disabled (that is 0
> for PWM_POLARITY_NORMAL and 1 for PWM_POLARITY_INVERSED) this is the
> best that can be done when a 0% relative duty cycle is requested
> (assuming the hardware cannot implement that in a normal way).
Our hardware is the same as this description.
So I didn't need to add the limitations about the duty cycle, right?
Or I need to note that the duty cycle 0% is just the inactive output that doesn't have the period concept.
> I hope this answered your remaining questions.
Thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [v9 1/2] dt-bindings: Add bindings for aspeed pwm-tach.
2021-07-14 4:02 ` Billy Tsai
@ 2021-10-04 1:46 ` Billy Tsai
-1 siblings, 0 replies; 34+ messages in thread
From: Billy Tsai @ 2021-10-04 1:46 UTC (permalink / raw)
To: Rob Herring
Cc: lee.jones, joel, andrew, thierry.reding, u.kleine-koenig,
p.zabel, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, linux-pwm, BMC-SW
Hi Rob,
On 2021/7/14, 12:02 PM, "Billy Tsai" <billy_tsai@aspeedtech.com> wrote:
On 2021/7/14, 6:14 AM, "Rob Herring" <robh@kernel.org> wrote:
On Fri, Jul 09, 2021 at 02:52:16PM +0800, Billy Tsai wrote:
>>> This patch adds device binding for aspeed pwm-tach device which is a
>>> multi-function device include pwm and tach function and pwm/tach device
>>> bindings which should be the child-node of pwm-tach device.
>>I'll say it again, the fan control h/w needs some common bindings for
>>describing fans and fan connections to pwm and tach. I'm not going to
>>sign off on more fan bindings just doing their own thing.
> 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.
Can you give me more suggestions about this patch?
Thanks
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [v9 1/2] dt-bindings: Add bindings for aspeed pwm-tach.
@ 2021-10-04 1:46 ` Billy Tsai
0 siblings, 0 replies; 34+ messages in thread
From: Billy Tsai @ 2021-10-04 1:46 UTC (permalink / raw)
To: Rob Herring
Cc: lee.jones, joel, andrew, thierry.reding, u.kleine-koenig,
p.zabel, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, linux-pwm, BMC-SW
Hi Rob,
On 2021/7/14, 12:02 PM, "Billy Tsai" <billy_tsai@aspeedtech.com> wrote:
On 2021/7/14, 6:14 AM, "Rob Herring" <robh@kernel.org> wrote:
On Fri, Jul 09, 2021 at 02:52:16PM +0800, Billy Tsai wrote:
>>> This patch adds device binding for aspeed pwm-tach device which is a
>>> multi-function device include pwm and tach function and pwm/tach device
>>> bindings which should be the child-node of pwm-tach device.
>>I'll say it again, the fan control h/w needs some common bindings for
>>describing fans and fan connections to pwm and tach. I'm not going to
>>sign off on more fan bindings just doing their own thing.
> 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.
Can you give me more suggestions about this patch?
Thanks
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2021-10-04 1:48 UTC | newest]
Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-09 6:52 [v9 0/2] Support pwm driver for aspeed ast26xx Billy Tsai
2021-07-09 6:52 ` Billy Tsai
2021-07-09 6:52 ` [v9 1/2] dt-bindings: Add bindings for aspeed pwm-tach Billy Tsai
2021-07-09 6:52 ` Billy Tsai
2021-07-13 22:14 ` Rob Herring
2021-07-13 22:14 ` Rob Herring
2021-07-14 4:02 ` Billy Tsai
2021-07-14 4:02 ` Billy Tsai
2021-10-04 1:46 ` Billy Tsai
2021-10-04 1:46 ` Billy Tsai
2021-07-09 6:52 ` [v9 2/2] pwm: Add Aspeed ast2600 PWM support Billy Tsai
2021-07-09 6:52 ` Billy Tsai
2021-07-15 15:05 ` Uwe Kleine-König
2021-07-15 15:05 ` Uwe Kleine-König
2021-07-16 1:48 ` Billy Tsai
2021-07-16 1:48 ` Billy Tsai
2021-07-16 7:09 ` Uwe Kleine-König
2021-07-16 7:09 ` Uwe Kleine-König
2021-07-16 9:22 ` Billy Tsai
2021-07-16 9:22 ` Billy Tsai
2021-07-16 10:13 ` Uwe Kleine-König
2021-07-16 10:13 ` Uwe Kleine-König
2021-07-16 10:56 ` Billy Tsai
2021-07-16 10:56 ` Billy Tsai
2021-07-21 10:52 ` Billy Tsai
2021-07-21 10:52 ` Billy Tsai
2021-07-21 12:48 ` Uwe Kleine-König
2021-07-21 12:48 ` Uwe Kleine-König
2021-07-23 4:23 ` Billy Tsai
2021-07-23 4:23 ` Billy Tsai
2021-07-23 20:12 ` Uwe Kleine-König
2021-07-23 20:12 ` Uwe Kleine-König
2021-07-26 5:14 ` Billy Tsai
2021-07-26 5:14 ` Billy Tsai
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.