* [PATCH v8 0/3] Support pwm/tach driver for aspeed ast26xx
@ 2023-08-30 12:31 ` Billy Tsai
0 siblings, 0 replies; 26+ messages in thread
From: Billy Tsai @ 2023-08-30 12:31 UTC (permalink / raw)
To: jdelvare, linux, robh+dt, krzysztof.kozlowski+dt, joel, andrew,
corbet, thierry.reding, u.kleine-koenig, p.zabel, billy_tsai,
naresh.solanki, linux-hwmon, devicetree, linux-arm-kernel,
linux-aspeed, linux-kernel, linux-doc, linux-pwm, BMC-SW,
patrick
Unlike the old design that the register setting of the TACH should based
on the configure of the PWM. In ast26xx, the dependency between pwm and
tach controller is eliminated and becomes a separate hardware block. One
is used to provide pwm output and another is used to monitor the frequency
of the input. This driver implements them by exposing two kernel
subsystems: PWM and HWMON. The PWM subsystem can be utilized alongside
existing drivers for controlling elements such as fans (pwm-fan.c),
beepers (pwm-beeper.c) and so on. Through the HWMON subsystem, the driver
provides sysfs interfaces for fan.
Changes since v7:
Cherry-pick the fan-common.yaml and add the following properties:
- min-rpm
- div
- mode
- tach-ch
Fix the warning which is reported by the kernel test robot.
Changes since v6:
Consolidate the PWM and TACH functionalities into a unified driver.
Changes since v5:
- pwm/tach:
- Remove the utilization of common resources from the parent node.
- Change the concept to 16 PWM/TACH controllers, each with one channel,
instead of 1 PWM/TACH controller with 16 channels.
- dt-binding:
- Eliminate the usage of simple-mfd.
Changes since v4:
- pwm:
- Fix the return type of get_status function.
- tach:
- read clk source once and re-use it
- Remove the constants variables
- Allocate tach_channel as array
- Use dev->parent
- dt-binding:
- Fix the order of the patches
- Add example and description for tach child node
- Remove pwm extension property
Changes since v3:
- pwm:
- Remove unnecessary include header
- Fix warning Prefer "GPL" over "GPL v2"
- tach:
- Remove the paremeter min_rpm and max_rpm and return the tach value
directly without any polling or delay.
- Fix warning Prefer "GPL" over "GPL v2"
- dt-binding:
- Replace underscore in node names with dashes
- Split per subsystem
Changes since v2:
- pwm:
- Use devm_* api to simplify the error cleanup
- Fix the multi-line alignment problem
- tach:
- Add tach-aspeed-ast2600 to index.rst
- Fix the multi-line alignment problem
- Remove the tach enable/disable when read the rpm
- Fix some coding format issue
Changes since v1:
- tach:
- Add the document tach-aspeed-ast2600.rst
- Use devm_* api to simplify the error cleanup.
- Change hwmon register api to devm_hwmon_device_register_with_info
Billy Tsai (2):
dt-bindings: hwmon: Support Aspeed g6 PWM TACH Control
hwmon: (aspeed-g6-pwm-tacho): Support for ASPEED g6 PWM/Fan tach
Naresh Solanki (1):
dt-bindings: hwmon: fan: Add fan binding to schema
.../bindings/hwmon/aspeed,g6-pwm-tach.yaml | 67 +++
.../devicetree/bindings/hwmon/fan-common.yaml | 63 +++
Documentation/hwmon/aspeed-g6-pwm-tach.rst | 26 +
Documentation/hwmon/index.rst | 1 +
drivers/hwmon/Kconfig | 11 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/aspeed-g6-pwm-tach.c | 528 ++++++++++++++++++
7 files changed, 697 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/aspeed,g6-pwm-tach.yaml
create mode 100644 Documentation/devicetree/bindings/hwmon/fan-common.yaml
create mode 100644 Documentation/hwmon/aspeed-g6-pwm-tach.rst
create mode 100644 drivers/hwmon/aspeed-g6-pwm-tach.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] 26+ messages in thread
* [PATCH v8 0/3] Support pwm/tach driver for aspeed ast26xx
@ 2023-08-30 12:31 ` Billy Tsai
0 siblings, 0 replies; 26+ messages in thread
From: Billy Tsai @ 2023-08-30 12:31 UTC (permalink / raw)
To: jdelvare, linux, robh+dt, krzysztof.kozlowski+dt, joel, andrew,
corbet, thierry.reding, u.kleine-koenig, p.zabel, billy_tsai,
naresh.solanki, linux-hwmon, devicetree, linux-arm-kernel,
linux-aspeed, linux-kernel, linux-doc, linux-pwm, BMC-SW,
patrick
Unlike the old design that the register setting of the TACH should based
on the configure of the PWM. In ast26xx, the dependency between pwm and
tach controller is eliminated and becomes a separate hardware block. One
is used to provide pwm output and another is used to monitor the frequency
of the input. This driver implements them by exposing two kernel
subsystems: PWM and HWMON. The PWM subsystem can be utilized alongside
existing drivers for controlling elements such as fans (pwm-fan.c),
beepers (pwm-beeper.c) and so on. Through the HWMON subsystem, the driver
provides sysfs interfaces for fan.
Changes since v7:
Cherry-pick the fan-common.yaml and add the following properties:
- min-rpm
- div
- mode
- tach-ch
Fix the warning which is reported by the kernel test robot.
Changes since v6:
Consolidate the PWM and TACH functionalities into a unified driver.
Changes since v5:
- pwm/tach:
- Remove the utilization of common resources from the parent node.
- Change the concept to 16 PWM/TACH controllers, each with one channel,
instead of 1 PWM/TACH controller with 16 channels.
- dt-binding:
- Eliminate the usage of simple-mfd.
Changes since v4:
- pwm:
- Fix the return type of get_status function.
- tach:
- read clk source once and re-use it
- Remove the constants variables
- Allocate tach_channel as array
- Use dev->parent
- dt-binding:
- Fix the order of the patches
- Add example and description for tach child node
- Remove pwm extension property
Changes since v3:
- pwm:
- Remove unnecessary include header
- Fix warning Prefer "GPL" over "GPL v2"
- tach:
- Remove the paremeter min_rpm and max_rpm and return the tach value
directly without any polling or delay.
- Fix warning Prefer "GPL" over "GPL v2"
- dt-binding:
- Replace underscore in node names with dashes
- Split per subsystem
Changes since v2:
- pwm:
- Use devm_* api to simplify the error cleanup
- Fix the multi-line alignment problem
- tach:
- Add tach-aspeed-ast2600 to index.rst
- Fix the multi-line alignment problem
- Remove the tach enable/disable when read the rpm
- Fix some coding format issue
Changes since v1:
- tach:
- Add the document tach-aspeed-ast2600.rst
- Use devm_* api to simplify the error cleanup.
- Change hwmon register api to devm_hwmon_device_register_with_info
Billy Tsai (2):
dt-bindings: hwmon: Support Aspeed g6 PWM TACH Control
hwmon: (aspeed-g6-pwm-tacho): Support for ASPEED g6 PWM/Fan tach
Naresh Solanki (1):
dt-bindings: hwmon: fan: Add fan binding to schema
.../bindings/hwmon/aspeed,g6-pwm-tach.yaml | 67 +++
.../devicetree/bindings/hwmon/fan-common.yaml | 63 +++
Documentation/hwmon/aspeed-g6-pwm-tach.rst | 26 +
Documentation/hwmon/index.rst | 1 +
drivers/hwmon/Kconfig | 11 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/aspeed-g6-pwm-tach.c | 528 ++++++++++++++++++
7 files changed, 697 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/aspeed,g6-pwm-tach.yaml
create mode 100644 Documentation/devicetree/bindings/hwmon/fan-common.yaml
create mode 100644 Documentation/hwmon/aspeed-g6-pwm-tach.rst
create mode 100644 drivers/hwmon/aspeed-g6-pwm-tach.c
--
2.25.1
^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH v8 1/3] dt-bindings: hwmon: fan: Add fan binding to schema
2023-08-30 12:31 ` Billy Tsai
@ 2023-08-30 12:32 ` Billy Tsai
-1 siblings, 0 replies; 26+ messages in thread
From: Billy Tsai @ 2023-08-30 12:32 UTC (permalink / raw)
To: jdelvare, linux, robh+dt, krzysztof.kozlowski+dt, joel, andrew,
corbet, thierry.reding, u.kleine-koenig, p.zabel, billy_tsai,
naresh.solanki, linux-hwmon, devicetree, linux-arm-kernel,
linux-aspeed, linux-kernel, linux-doc, linux-pwm, BMC-SW,
patrick
From: Naresh Solanki <naresh.solanki@9elements.com>
Add common fan properties bindings to a schema.
Bindings for fan controllers can reference the common schema for the
fan
child nodes:
patternProperties:
"^fan@[0-2]":
type: object
$ref: fan-common.yaml#
Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
---
.../devicetree/bindings/hwmon/fan-common.yaml | 63 +++++++++++++++++++
1 file changed, 63 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/fan-common.yaml
diff --git a/Documentation/devicetree/bindings/hwmon/fan-common.yaml b/Documentation/devicetree/bindings/hwmon/fan-common.yaml
new file mode 100644
index 000000000000..a69b4d553e45
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/fan-common.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: GPL-2.0-or-later OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/fan-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common Fan Properties
+
+maintainers:
+ - Naresh Solanki <naresh.solanki@9elements.com>
+ - Billy Tsai <billy_tsai@aspeedtech.com>
+
+properties:
+ max-rpm:
+ description:
+ Max RPM supported by fan.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ min-rpm:
+ description:
+ Min RPM supported by fan.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ pulses-per-revolution:
+ description:
+ The number of pulse from fan sensor per revolution.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ div:
+ description:
+ Fan clock divisor
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ target-rpm:
+ description:
+ Target RPM the fan should be configured during driver probe.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ mode:
+ description:
+ Select the operational mode of the fan.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ pwms:
+ description:
+ PWM provider.
+
+ tach-ch:
+ description:
+ The tach channel used for the fan.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ label:
+ description:
+ Optional fan label
+
+ fan-supply:
+ description:
+ Power supply for fan.
+
+additionalProperties: true
+
+...
--
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] 26+ messages in thread
* [PATCH v8 1/3] dt-bindings: hwmon: fan: Add fan binding to schema
@ 2023-08-30 12:32 ` Billy Tsai
0 siblings, 0 replies; 26+ messages in thread
From: Billy Tsai @ 2023-08-30 12:32 UTC (permalink / raw)
To: jdelvare, linux, robh+dt, krzysztof.kozlowski+dt, joel, andrew,
corbet, thierry.reding, u.kleine-koenig, p.zabel, billy_tsai,
naresh.solanki, linux-hwmon, devicetree, linux-arm-kernel,
linux-aspeed, linux-kernel, linux-doc, linux-pwm, BMC-SW,
patrick
From: Naresh Solanki <naresh.solanki@9elements.com>
Add common fan properties bindings to a schema.
Bindings for fan controllers can reference the common schema for the
fan
child nodes:
patternProperties:
"^fan@[0-2]":
type: object
$ref: fan-common.yaml#
Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
---
.../devicetree/bindings/hwmon/fan-common.yaml | 63 +++++++++++++++++++
1 file changed, 63 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/fan-common.yaml
diff --git a/Documentation/devicetree/bindings/hwmon/fan-common.yaml b/Documentation/devicetree/bindings/hwmon/fan-common.yaml
new file mode 100644
index 000000000000..a69b4d553e45
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/fan-common.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: GPL-2.0-or-later OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/fan-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common Fan Properties
+
+maintainers:
+ - Naresh Solanki <naresh.solanki@9elements.com>
+ - Billy Tsai <billy_tsai@aspeedtech.com>
+
+properties:
+ max-rpm:
+ description:
+ Max RPM supported by fan.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ min-rpm:
+ description:
+ Min RPM supported by fan.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ pulses-per-revolution:
+ description:
+ The number of pulse from fan sensor per revolution.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ div:
+ description:
+ Fan clock divisor
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ target-rpm:
+ description:
+ Target RPM the fan should be configured during driver probe.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ mode:
+ description:
+ Select the operational mode of the fan.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ pwms:
+ description:
+ PWM provider.
+
+ tach-ch:
+ description:
+ The tach channel used for the fan.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ label:
+ description:
+ Optional fan label
+
+ fan-supply:
+ description:
+ Power supply for fan.
+
+additionalProperties: true
+
+...
--
2.25.1
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH v8 2/3] dt-bindings: hwmon: Support Aspeed g6 PWM TACH Control
2023-08-30 12:31 ` Billy Tsai
@ 2023-08-30 12:32 ` Billy Tsai
-1 siblings, 0 replies; 26+ messages in thread
From: Billy Tsai @ 2023-08-30 12:32 UTC (permalink / raw)
To: jdelvare, linux, robh+dt, krzysztof.kozlowski+dt, joel, andrew,
corbet, thierry.reding, u.kleine-koenig, p.zabel, billy_tsai,
naresh.solanki, linux-hwmon, devicetree, linux-arm-kernel,
linux-aspeed, linux-kernel, linux-doc, linux-pwm, BMC-SW,
patrick
Document the compatible for aspeed,ast2600-pwm-tach device, which can
support up to 16 PWM outputs and 16 fan tach input.
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
---
.../bindings/hwmon/aspeed,g6-pwm-tach.yaml | 67 +++++++++++++++++++
1 file changed, 67 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/aspeed,g6-pwm-tach.yaml
diff --git a/Documentation/devicetree/bindings/hwmon/aspeed,g6-pwm-tach.yaml b/Documentation/devicetree/bindings/hwmon/aspeed,g6-pwm-tach.yaml
new file mode 100644
index 000000000000..95bac5588c04
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/aspeed,g6-pwm-tach.yaml
@@ -0,0 +1,67 @@
+# 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,g6-pwm-tach.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ASPEED G6 PWM and Fan Tach controller device driver
+
+maintainers:
+ - Billy Tsai <billy_tsai@aspeedtech.com>
+
+description: |
+ The ASPEED PWM controller can support up to 16 PWM outputs.
+ The ASPEED Fan Tacho controller can support up to 16 fan tach input.
+
+properties:
+ compatible:
+ enum:
+ - aspeed,ast2600-pwm-tach
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ "#pwm-cells":
+ const: 3
+
+patternProperties:
+ "^fan[0-9a-f]_hwmon+$":
+ $ref: fan-common.yaml#
+ required:
+ - tach-ch
+
+required:
+ - reg
+ - clocks
+ - resets
+ - "#pwm-cells"
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/aspeed-clock.h>
+ pwm_tach: pwm-tach-controller@1e610000 {
+ compatible = "aspeed,ast2600-pwm-tach";
+ reg = <0x1e610000 0x100>;
+ clocks = <&syscon ASPEED_CLK_AHB>;
+ resets = <&syscon ASPEED_RESET_PWM>;
+ #pwm-cells = <3>;
+ fan0_hwmon {
+ tach-ch = <0x0>;
+ };
+ fan1_hwmon {
+ tach-ch = <0x1>;
+ };
+ fan2_hwmon {
+ tach-ch = <0x2>;
+ };
+ };
--
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] 26+ messages in thread
* [PATCH v8 2/3] dt-bindings: hwmon: Support Aspeed g6 PWM TACH Control
@ 2023-08-30 12:32 ` Billy Tsai
0 siblings, 0 replies; 26+ messages in thread
From: Billy Tsai @ 2023-08-30 12:32 UTC (permalink / raw)
To: jdelvare, linux, robh+dt, krzysztof.kozlowski+dt, joel, andrew,
corbet, thierry.reding, u.kleine-koenig, p.zabel, billy_tsai,
naresh.solanki, linux-hwmon, devicetree, linux-arm-kernel,
linux-aspeed, linux-kernel, linux-doc, linux-pwm, BMC-SW,
patrick
Document the compatible for aspeed,ast2600-pwm-tach device, which can
support up to 16 PWM outputs and 16 fan tach input.
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
---
.../bindings/hwmon/aspeed,g6-pwm-tach.yaml | 67 +++++++++++++++++++
1 file changed, 67 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/aspeed,g6-pwm-tach.yaml
diff --git a/Documentation/devicetree/bindings/hwmon/aspeed,g6-pwm-tach.yaml b/Documentation/devicetree/bindings/hwmon/aspeed,g6-pwm-tach.yaml
new file mode 100644
index 000000000000..95bac5588c04
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/aspeed,g6-pwm-tach.yaml
@@ -0,0 +1,67 @@
+# 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,g6-pwm-tach.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ASPEED G6 PWM and Fan Tach controller device driver
+
+maintainers:
+ - Billy Tsai <billy_tsai@aspeedtech.com>
+
+description: |
+ The ASPEED PWM controller can support up to 16 PWM outputs.
+ The ASPEED Fan Tacho controller can support up to 16 fan tach input.
+
+properties:
+ compatible:
+ enum:
+ - aspeed,ast2600-pwm-tach
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ "#pwm-cells":
+ const: 3
+
+patternProperties:
+ "^fan[0-9a-f]_hwmon+$":
+ $ref: fan-common.yaml#
+ required:
+ - tach-ch
+
+required:
+ - reg
+ - clocks
+ - resets
+ - "#pwm-cells"
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/aspeed-clock.h>
+ pwm_tach: pwm-tach-controller@1e610000 {
+ compatible = "aspeed,ast2600-pwm-tach";
+ reg = <0x1e610000 0x100>;
+ clocks = <&syscon ASPEED_CLK_AHB>;
+ resets = <&syscon ASPEED_RESET_PWM>;
+ #pwm-cells = <3>;
+ fan0_hwmon {
+ tach-ch = <0x0>;
+ };
+ fan1_hwmon {
+ tach-ch = <0x1>;
+ };
+ fan2_hwmon {
+ tach-ch = <0x2>;
+ };
+ };
--
2.25.1
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH v8 3/3] hwmon: (aspeed-g6-pwm-tacho): Support for ASPEED g6 PWM/Fan tach
2023-08-30 12:31 ` Billy Tsai
@ 2023-08-30 12:32 ` Billy Tsai
-1 siblings, 0 replies; 26+ messages in thread
From: Billy Tsai @ 2023-08-30 12:32 UTC (permalink / raw)
To: jdelvare, linux, robh+dt, krzysztof.kozlowski+dt, joel, andrew,
corbet, thierry.reding, u.kleine-koenig, p.zabel, billy_tsai,
naresh.solanki, linux-hwmon, devicetree, linux-arm-kernel,
linux-aspeed, linux-kernel, linux-doc, linux-pwm, BMC-SW,
patrick
The driver support two functions: PWM and Tachometer. The PWM feature can
handle up to 16 output ports, while the Tachometer can monitor to up to 16
input ports as well. This driver implements them by exposing two kernel
subsystems: PWM and HWMON. The PWM subsystem can be utilized alongside
existing drivers for controlling elements such as fans (pwm-fan.c),
beepers (pwm-beeper.c) and so on. Through the HWMON subsystem, the driver
provides sysfs interfaces for fan.
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
---
Documentation/hwmon/aspeed-g6-pwm-tach.rst | 26 +
Documentation/hwmon/index.rst | 1 +
drivers/hwmon/Kconfig | 11 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/aspeed-g6-pwm-tach.c | 528 +++++++++++++++++++++
5 files changed, 567 insertions(+)
create mode 100644 Documentation/hwmon/aspeed-g6-pwm-tach.rst
create mode 100644 drivers/hwmon/aspeed-g6-pwm-tach.c
diff --git a/Documentation/hwmon/aspeed-g6-pwm-tach.rst b/Documentation/hwmon/aspeed-g6-pwm-tach.rst
new file mode 100644
index 000000000000..17398fe397fe
--- /dev/null
+++ b/Documentation/hwmon/aspeed-g6-pwm-tach.rst
@@ -0,0 +1,26 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver aspeed-g6-pwm-tach
+=================================
+
+Supported chips:
+ ASPEED AST2600
+
+Authors:
+ <billy_tsai@aspeedtech.com>
+
+Description:
+------------
+This driver implements support for ASPEED AST2600 Fan Tacho controller.
+The controller supports up to 16 tachometer inputs.
+
+The driver provides the following sensor accesses in sysfs:
+
+=============== ======= ======================================================
+fanX_input ro provide current fan rotation value in RPM as reported
+ by the fan to the device.
+fanX_div rw Fan divisor: Supported value are power of 4 (1, 4, 16
+ 64, ... 4194304)
+ The larger divisor, the less rpm accuracy and the less
+ affected by fan signal glitch.
+=============== ======= ======================================================
diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index 5c1052d8c57c..614a18477e9f 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -43,6 +43,7 @@ Hardware Monitoring Kernel Drivers
aquacomputer_d5next
asb100
asc7621
+ aspeed-g6-pwm-tach
aspeed-pwm-tacho
asus_ec_sensors
asus_wmi_sensors
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 283e0adafbc1..1f82df1979db 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -411,6 +411,17 @@ config SENSORS_ASPEED
This driver can also be built as a module. If so, the module
will be called aspeed_pwm_tacho.
+config SENSORS_ASPEED_G6
+ tristate "ASPEED g6 PWM and Fan tach driver"
+ depends on ARCH_ASPEED || COMPILE_TEST
+ depends on PWM
+ help
+ This driver provides support for ASPEED G6 PWM and Fan Tach
+ controllers.
+
+ This driver can also be built as a module. If so, the module
+ will be called aspeed_pwm_tacho.
+
config SENSORS_ATXP1
tristate "Attansic ATXP1 VID controller"
depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index abefc16c1e1e..1fbb66c37a7c 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_SENSORS_ARM_SCPI) += scpi-hwmon.o
obj-$(CONFIG_SENSORS_AS370) += as370-hwmon.o
obj-$(CONFIG_SENSORS_ASC7621) += asc7621.o
obj-$(CONFIG_SENSORS_ASPEED) += aspeed-pwm-tacho.o
+obj-$(CONFIG_SENSORS_ASPEED_G6) += aspeed-g6-pwm-tach.o
obj-$(CONFIG_SENSORS_ATXP1) += atxp1.o
obj-$(CONFIG_SENSORS_AXI_FAN_CONTROL) += axi-fan-control.o
obj-$(CONFIG_SENSORS_BT1_PVT) += bt1-pvt.o
diff --git a/drivers/hwmon/aspeed-g6-pwm-tach.c b/drivers/hwmon/aspeed-g6-pwm-tach.c
new file mode 100644
index 000000000000..f7d53e8e009f
--- /dev/null
+++ b/drivers/hwmon/aspeed-g6-pwm-tach.c
@@ -0,0 +1,528 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2021 Aspeed Technology Inc.
+ *
+ * PWM/TACH controller driver for Aspeed ast2600 SoCs.
+ * This drivers doesn't support earlier version of the IP.
+ *
+ * The hardware operates in time quantities of length
+ * Q := (DIV_L + 1) << DIV_H / input-clk
+ * The length of a PWM period is (DUTY_CYCLE_PERIOD + 1) * Q.
+ * The maximal value for DUTY_CYCLE_PERIOD is used here to provide
+ * a fine grained selection for the duty cycle.
+ *
+ * This driver uses DUTY_CYCLE_RISING_POINT = 0, so from the start of a
+ * period the output is active until DUTY_CYCLE_FALLING_POINT * Q. Note
+ * that if DUTY_CYCLE_RISING_POINT = DUTY_CYCLE_FALLING_POINT the output is
+ * always active.
+ *
+ * Register usage:
+ * PIN_ENABLE: When it is unset the pwm controller will emit inactive level to the external.
+ * Use to determine whether the PWM channel is enabled or disabled
+ * CLK_ENABLE: When it is unset the pwm controller will assert the duty counter reset and
+ * emit inactive level to the PIN_ENABLE mux after that the driver can still change the pwm period
+ * and duty and the value will apply when CLK_ENABLE be set again.
+ * Use to determine whether duty_cycle bigger than 0.
+ * PWM_ASPEED_CTRL_INVERSE: When it is toggled the output value will inverse immediately.
+ * PWM_ASPEED_DUTY_CYCLE_FALLING_POINT/PWM_ASPEED_DUTY_CYCLE_RISING_POINT: When these two
+ * values are equal it means the duty cycle = 100%.
+ *
+ * The glitch may generate at:
+ * - Enabled changing when the duty_cycle bigger than 0% and less than 100%.
+ * - Polarity changing when the duty_cycle bigger than 0% and less than 100%.
+ *
+ * Limitations:
+ * - When changing both duty cycle and period, we cannot prevent in
+ * software that the output might produce a period with mixed
+ * settings.
+ * - Disabling the PWM doesn't complete the current period.
+ *
+ * Improvements:
+ * - When only changing one of duty cycle or period, our pwm controller will not
+ * generate the glitch, the configure will change at next cycle of pwm.
+ * This improvement can disable/enable through PWM_ASPEED_CTRL_DUTY_SYNC_DISABLE.
+ */
+
+#include <linux/bitfield.h>
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/errno.h>
+#include <linux/hwmon.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/math64.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/pwm.h>
+#include <linux/reset.h>
+#include <linux/sysfs.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)
+
+/* The channel number of Aspeed tach controller */
+#define TACH_ASPEED_NR_TACHS 16
+/* TACH Control Register */
+#define TACH_ASPEED_CTRL(ch) (((ch) * 0x10) + 0x08)
+#define TACH_ASPEED_IER BIT(31)
+#define TACH_ASPEED_INVERS_LIMIT BIT(30)
+#define TACH_ASPEED_LOOPBACK BIT(29)
+#define TACH_ASPEED_ENABLE BIT(28)
+#define TACH_ASPEED_DEBOUNCE_MASK GENMASK(27, 26)
+#define TACH_ASPEED_DEBOUNCE_BIT 26
+#define TACH_ASPEED_IO_EDGE_MASK GENMASK(25, 24)
+#define TACH_ASPEED_IO_EDGE_BIT 24
+#define TACH_ASPEED_CLK_DIV_T_MASK GENMASK(23, 20)
+#define TACH_ASPEED_CLK_DIV_BIT 20
+#define TACH_ASPEED_THRESHOLD_MASK GENMASK(19, 0)
+/* [27:26] */
+#define DEBOUNCE_3_CLK 0x00
+#define DEBOUNCE_2_CLK 0x01
+#define DEBOUNCE_1_CLK 0x02
+#define DEBOUNCE_0_CLK 0x03
+/* [25:24] */
+#define F2F_EDGES 0x00
+#define R2R_EDGES 0x01
+#define BOTH_EDGES 0x02
+/* [23:20] */
+/* divisor = 4 to the nth power, n = register value */
+#define DEFAULT_TACH_DIV 1024
+#define DIV_TO_REG(divisor) (ilog2(divisor) >> 1)
+
+/* TACH Status Register */
+#define TACH_ASPEED_STS(ch) (((ch) * 0x10) + 0x0C)
+
+/*PWM_TACH_STS */
+#define TACH_ASPEED_ISR BIT(31)
+#define TACH_ASPEED_PWM_OUT BIT(25)
+#define TACH_ASPEED_PWM_OEN BIT(24)
+#define TACH_ASPEED_DEB_INPUT BIT(23)
+#define TACH_ASPEED_RAW_INPUT BIT(22)
+#define TACH_ASPEED_VALUE_UPDATE BIT(21)
+#define TACH_ASPEED_FULL_MEASUREMENT BIT(20)
+#define TACH_ASPEED_VALUE_MASK GENMASK(19, 0)
+/**********************************************************
+ * Software setting
+ *********************************************************/
+#define DEFAULT_FAN_PULSE_PR 2
+
+struct aspeed_pwm_tach_data {
+ struct device *dev;
+ void __iomem *base;
+ struct clk *clk;
+ struct reset_control *reset;
+ unsigned long clk_rate;
+ struct pwm_chip chip;
+ bool tach_present[TACH_ASPEED_NR_TACHS];
+ u32 tach_divisor;
+};
+
+static inline struct aspeed_pwm_tach_data *
+aspeed_pwm_chip_to_data(struct pwm_chip *chip)
+{
+ return container_of(chip, struct aspeed_pwm_tach_data, chip);
+}
+
+static int aspeed_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
+ struct pwm_state *state)
+{
+ struct aspeed_pwm_tach_data *priv = aspeed_pwm_chip_to_data(chip);
+ u32 hwpwm = pwm->hwpwm;
+ bool polarity, pin_en, clk_en;
+ u32 duty_pt, val;
+ u64 div_h, div_l, duty_cycle_period, dividend;
+
+ val = readl(priv->base + PWM_ASPEED_CTRL(hwpwm));
+ polarity = FIELD_GET(PWM_ASPEED_CTRL_INVERSE, val);
+ pin_en = FIELD_GET(PWM_ASPEED_CTRL_PIN_ENABLE, val);
+ clk_en = FIELD_GET(PWM_ASPEED_CTRL_CLK_ENABLE, val);
+ div_h = FIELD_GET(PWM_ASPEED_CTRL_CLK_DIV_H, val);
+ div_l = FIELD_GET(PWM_ASPEED_CTRL_CLK_DIV_L, val);
+ val = readl(priv->base + PWM_ASPEED_DUTY_CYCLE(hwpwm));
+ duty_pt = FIELD_GET(PWM_ASPEED_DUTY_CYCLE_FALLING_POINT, val);
+ duty_cycle_period = FIELD_GET(PWM_ASPEED_DUTY_CYCLE_PERIOD, val);
+ /*
+ * This multiplication doesn't overflow, the upper bound is
+ * 1000000000 * 256 * 256 << 15 = 0x1dcd650000000000
+ */
+ dividend = (u64)NSEC_PER_SEC * (div_l + 1) * (duty_cycle_period + 1)
+ << div_h;
+ state->period = DIV_ROUND_UP_ULL(dividend, priv->clk_rate);
+
+ if (clk_en && duty_pt) {
+ dividend = (u64)NSEC_PER_SEC * (div_l + 1) * duty_pt
+ << div_h;
+ state->duty_cycle = DIV_ROUND_UP_ULL(dividend, priv->clk_rate);
+ } else {
+ state->duty_cycle = clk_en ? state->period : 0;
+ }
+ state->polarity = polarity ? PWM_POLARITY_INVERSED : PWM_POLARITY_NORMAL;
+ state->enabled = pin_en;
+ return 0;
+}
+
+static int aspeed_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+ const struct pwm_state *state)
+{
+ struct aspeed_pwm_tach_data *priv = aspeed_pwm_chip_to_data(chip);
+ u32 hwpwm = pwm->hwpwm, duty_pt, val;
+ u64 div_h, div_l, divisor, expect_period;
+ bool clk_en;
+
+ expect_period = div64_u64(ULLONG_MAX, (u64)priv->clk_rate);
+ expect_period = min(expect_period, state->period);
+ dev_dbg(chip->dev, "expect period: %lldns, duty_cycle: %lldns",
+ expect_period, state->duty_cycle);
+ /*
+ * Pick the smallest value for div_h so that div_l can be the biggest
+ * which results in a finer resolution near the target period value.
+ */
+ divisor = (u64)NSEC_PER_SEC * (PWM_ASPEED_FIXED_PERIOD + 1) *
+ (FIELD_MAX(PWM_ASPEED_CTRL_CLK_DIV_L) + 1);
+ div_h = order_base_2(DIV64_U64_ROUND_UP(priv->clk_rate * expect_period, divisor));
+ if (div_h > 0xf)
+ div_h = 0xf;
+
+ divisor = ((u64)NSEC_PER_SEC * (PWM_ASPEED_FIXED_PERIOD + 1)) << div_h;
+ div_l = div64_u64(priv->clk_rate * expect_period, divisor);
+
+ if (div_l == 0)
+ return -ERANGE;
+
+ div_l -= 1;
+
+ if (div_l > 255)
+ div_l = 255;
+
+ dev_dbg(chip->dev, "clk source: %ld div_h %lld, div_l : %lld\n",
+ priv->clk_rate, div_h, div_l);
+ /* duty_pt = duty_cycle * (PERIOD + 1) / period */
+ duty_pt = div64_u64(state->duty_cycle * priv->clk_rate,
+ (u64)NSEC_PER_SEC * (div_l + 1) << div_h);
+ dev_dbg(chip->dev, "duty_cycle = %lld, duty_pt = %d\n",
+ state->duty_cycle, duty_pt);
+
+ /*
+ * Fixed DUTY_CYCLE_PERIOD to its max value to get a
+ * fine-grained resolution for duty_cycle at the expense of a
+ * coarser period resolution.
+ */
+ val = readl(priv->base + PWM_ASPEED_DUTY_CYCLE(hwpwm));
+ val &= ~PWM_ASPEED_DUTY_CYCLE_PERIOD;
+ val |= FIELD_PREP(PWM_ASPEED_DUTY_CYCLE_PERIOD,
+ PWM_ASPEED_FIXED_PERIOD);
+ writel(val, priv->base + PWM_ASPEED_DUTY_CYCLE(hwpwm));
+
+ if (duty_pt == 0) {
+ /* emit inactive level and assert the duty counter reset */
+ clk_en = 0;
+ } else {
+ clk_en = 1;
+ if (duty_pt >= (PWM_ASPEED_FIXED_PERIOD + 1))
+ duty_pt = 0;
+ val = readl(priv->base + PWM_ASPEED_DUTY_CYCLE(hwpwm));
+ val &= ~(PWM_ASPEED_DUTY_CYCLE_RISING_POINT |
+ PWM_ASPEED_DUTY_CYCLE_FALLING_POINT);
+ val |= FIELD_PREP(PWM_ASPEED_DUTY_CYCLE_FALLING_POINT, duty_pt);
+ writel(val, priv->base + PWM_ASPEED_DUTY_CYCLE(hwpwm));
+ }
+
+ val = readl(priv->base + PWM_ASPEED_CTRL(hwpwm));
+ val &= ~(PWM_ASPEED_CTRL_CLK_DIV_H | PWM_ASPEED_CTRL_CLK_DIV_L |
+ PWM_ASPEED_CTRL_PIN_ENABLE | PWM_ASPEED_CTRL_CLK_ENABLE |
+ PWM_ASPEED_CTRL_INVERSE);
+ val |= FIELD_PREP(PWM_ASPEED_CTRL_CLK_DIV_H, div_h) |
+ FIELD_PREP(PWM_ASPEED_CTRL_CLK_DIV_L, div_l) |
+ FIELD_PREP(PWM_ASPEED_CTRL_PIN_ENABLE, state->enabled) |
+ FIELD_PREP(PWM_ASPEED_CTRL_CLK_ENABLE, clk_en) |
+ FIELD_PREP(PWM_ASPEED_CTRL_INVERSE, state->polarity);
+ writel(val, priv->base + PWM_ASPEED_CTRL(hwpwm));
+
+ return 0;
+}
+
+static const struct pwm_ops aspeed_pwm_ops = {
+ .apply = aspeed_pwm_apply,
+ .get_state = aspeed_pwm_get_state,
+ .owner = THIS_MODULE,
+};
+
+static void aspeed_tach_ch_enable(struct aspeed_pwm_tach_data *priv, u8 tach_ch,
+ bool enable)
+{
+ if (enable)
+ writel(readl(priv->base + TACH_ASPEED_CTRL(tach_ch)) |
+ TACH_ASPEED_ENABLE,
+ priv->base + TACH_ASPEED_CTRL(tach_ch));
+ else
+ writel(readl(priv->base + TACH_ASPEED_CTRL(tach_ch)) &
+ ~TACH_ASPEED_ENABLE,
+ priv->base + TACH_ASPEED_CTRL(tach_ch));
+}
+
+static int aspeed_tach_val_to_rpm(struct aspeed_pwm_tach_data *priv, u32 tach_val)
+{
+ u64 rpm;
+ u32 tach_div;
+
+ tach_div = tach_val * priv->tach_divisor * DEFAULT_FAN_PULSE_PR;
+
+ dev_dbg(priv->dev, "clk %ld, tach_val %d , tach_div %d\n",
+ priv->clk_rate, tach_val, tach_div);
+
+ rpm = (u64)priv->clk_rate * 60;
+ do_div(rpm, tach_div);
+
+ return (int)rpm;
+}
+
+static int aspeed_get_fan_tach_ch_rpm(struct aspeed_pwm_tach_data *priv,
+ u8 fan_tach_ch)
+{
+ u32 val;
+
+ val = readl(priv->base + TACH_ASPEED_STS(fan_tach_ch));
+
+ if (!(val & TACH_ASPEED_FULL_MEASUREMENT))
+ return 0;
+ val = FIELD_GET(TACH_ASPEED_VALUE_MASK, val);
+ return aspeed_tach_val_to_rpm(priv, val);
+}
+
+static int aspeed_tach_hwmon_read(struct device *dev,
+ enum hwmon_sensor_types type, u32 attr,
+ int channel, long *val)
+{
+ struct aspeed_pwm_tach_data *priv = dev_get_drvdata(dev);
+ u32 reg_val;
+
+ switch (attr) {
+ case hwmon_fan_input:
+ *val = aspeed_get_fan_tach_ch_rpm(priv, channel);
+ break;
+ case hwmon_fan_div:
+ reg_val = readl(priv->base + TACH_ASPEED_CTRL(channel));
+ reg_val = FIELD_GET(TACH_ASPEED_CLK_DIV_T_MASK, reg_val);
+ *val = BIT(reg_val << 1);
+ break;
+ default:
+ return -EOPNOTSUPP;
+ }
+ return 0;
+}
+
+static int aspeed_tach_hwmon_write(struct device *dev,
+ enum hwmon_sensor_types type, u32 attr,
+ int channel, long val)
+{
+ struct aspeed_pwm_tach_data *priv = dev_get_drvdata(dev);
+ u32 reg_val;
+
+ switch (attr) {
+ case hwmon_fan_div:
+ if (!is_power_of_2(val) || (ilog2(val) % 2) ||
+ DIV_TO_REG(val) > 0xb)
+ return -EINVAL;
+ priv->tach_divisor = val;
+ reg_val = readl(priv->base + TACH_ASPEED_CTRL(channel));
+ reg_val &= ~TACH_ASPEED_CLK_DIV_T_MASK;
+ reg_val |= FIELD_GET(TACH_ASPEED_CLK_DIV_T_MASK,
+ DIV_TO_REG(priv->tach_divisor));
+ writel(reg_val, priv->base + TACH_ASPEED_CTRL(channel));
+ break;
+ default:
+ return -EOPNOTSUPP;
+ }
+
+ return 0;
+}
+
+static umode_t aspeed_tach_dev_is_visible(const void *drvdata,
+ enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+ const struct aspeed_pwm_tach_data *priv = drvdata;
+
+ if (!priv->tach_present[channel])
+ return 0;
+ switch (attr) {
+ case hwmon_fan_input:
+ return 0444;
+ case hwmon_fan_div:
+ return 0644;
+ }
+ return 0;
+}
+
+static const struct hwmon_ops aspeed_tach_ops = {
+ .is_visible = aspeed_tach_dev_is_visible,
+ .read = aspeed_tach_hwmon_read,
+ .write = aspeed_tach_hwmon_write,
+};
+
+static const struct hwmon_channel_info *aspeed_tach_info[] = {
+ HWMON_CHANNEL_INFO(fan, HWMON_F_INPUT | HWMON_F_DIV, HWMON_F_INPUT | HWMON_F_DIV,
+ HWMON_F_INPUT | HWMON_F_DIV, HWMON_F_INPUT | HWMON_F_DIV,
+ HWMON_F_INPUT | HWMON_F_DIV, HWMON_F_INPUT | HWMON_F_DIV,
+ HWMON_F_INPUT | HWMON_F_DIV, HWMON_F_INPUT | HWMON_F_DIV,
+ HWMON_F_INPUT | HWMON_F_DIV, HWMON_F_INPUT | HWMON_F_DIV,
+ HWMON_F_INPUT | HWMON_F_DIV, HWMON_F_INPUT | HWMON_F_DIV,
+ HWMON_F_INPUT | HWMON_F_DIV, HWMON_F_INPUT | HWMON_F_DIV,
+ HWMON_F_INPUT | HWMON_F_DIV, HWMON_F_INPUT | HWMON_F_DIV),
+ NULL
+};
+
+static const struct hwmon_chip_info aspeed_tach_chip_info = {
+ .ops = &aspeed_tach_ops,
+ .info = aspeed_tach_info,
+};
+
+static void aspeed_present_fan_tach(struct aspeed_pwm_tach_data *priv, u32 tach_ch)
+{
+ u32 val;
+
+ priv->tach_present[tach_ch] = true;
+ priv->tach_divisor = DEFAULT_TACH_DIV;
+
+ val = readl(priv->base + TACH_ASPEED_CTRL(tach_ch));
+ val &= ~(TACH_ASPEED_INVERS_LIMIT | TACH_ASPEED_DEBOUNCE_MASK |
+ TACH_ASPEED_IO_EDGE_MASK | TACH_ASPEED_CLK_DIV_T_MASK |
+ TACH_ASPEED_THRESHOLD_MASK);
+ val |= (DEBOUNCE_3_CLK << TACH_ASPEED_DEBOUNCE_BIT) | F2F_EDGES |
+ FIELD_GET(TACH_ASPEED_CLK_DIV_T_MASK,
+ DIV_TO_REG(priv->tach_divisor));
+ writel(val, priv->base + TACH_ASPEED_CTRL(tach_ch));
+
+ aspeed_tach_ch_enable(priv, tach_ch, true);
+}
+
+static int aspeed_tach_create_fan(struct device *dev, struct device_node *child,
+ struct aspeed_pwm_tach_data *priv)
+{
+ int ret;
+ u32 tach_ch;
+
+ ret = of_property_read_u32(child, "tach-ch", &tach_ch);
+ if (ret)
+ return ret;
+
+ aspeed_present_fan_tach(priv, tach_ch);
+
+ return 0;
+}
+
+static int aspeed_pwm_tach_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev, *hwmon;
+ int ret;
+ struct device_node *child;
+ struct aspeed_pwm_tach_data *priv;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+ priv->dev = dev;
+ priv->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(priv->base))
+ return PTR_ERR(priv->base);
+
+ priv->clk = devm_clk_get_enabled(dev, NULL);
+ if (IS_ERR(priv->clk))
+ return dev_err_probe(dev, PTR_ERR(priv->clk),
+ "Couldn't get clock\n");
+ priv->clk_rate = clk_get_rate(priv->clk);
+ priv->reset = devm_reset_control_get_exclusive(dev, NULL);
+ if (IS_ERR(priv->reset))
+ return dev_err_probe(dev, PTR_ERR(priv->reset),
+ "Couldn't get reset control\n");
+
+ ret = reset_control_deassert(priv->reset);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "Couldn't deassert reset control\n");
+
+ priv->chip.dev = dev;
+ priv->chip.ops = &aspeed_pwm_ops;
+ priv->chip.npwm = PWM_ASPEED_NR_PWMS;
+
+ ret = devm_pwmchip_add(dev, &priv->chip);
+ if (ret < 0) {
+ reset_control_assert(priv->reset);
+ return dev_err_probe(dev, ret, "Failed to add PWM chip\n");
+ }
+
+ for_each_child_of_node(dev->of_node, child) {
+ ret = aspeed_tach_create_fan(dev, child, priv);
+ if (ret < 0) {
+ of_node_put(child);
+ dev_warn(dev, "Failed to create fan %d", ret);
+ return 0;
+ }
+ }
+
+ hwmon = devm_hwmon_device_register_with_info(dev, "aspeed_tach", priv,
+ &aspeed_tach_chip_info, NULL);
+ ret = PTR_ERR_OR_ZERO(hwmon);
+ if (ret) {
+ reset_control_assert(priv->reset);
+ return dev_err_probe(dev, ret,
+ "Failed to register hwmon device\n");
+ }
+
+ return 0;
+}
+
+static int aspeed_pwm_tach_remove(struct platform_device *pdev)
+{
+ struct aspeed_pwm_tach_data *priv = platform_get_drvdata(pdev);
+
+ reset_control_assert(priv->reset);
+
+ return 0;
+}
+
+static const struct of_device_id aspeed_pwm_tach_match[] = {
+ {
+ .compatible = "aspeed,ast2600-pwm-tach",
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, aspeed_pwm_tach_match);
+
+static struct platform_driver aspeed_pwm_tach_driver = {
+ .probe = aspeed_pwm_tach_probe,
+ .remove = aspeed_pwm_tach_remove,
+ .driver = {
+ .name = "aspeed-g6-pwm-tach",
+ .of_match_table = aspeed_pwm_tach_match,
+ },
+};
+
+module_platform_driver(aspeed_pwm_tach_driver);
+
+MODULE_AUTHOR("Billy Tsai <billy_tsai@aspeedtech.com>");
+MODULE_DESCRIPTION("Aspeed ast2600 PWM and Fan Tach device driver");
+MODULE_LICENSE("GPL");
--
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] 26+ messages in thread
* [PATCH v8 3/3] hwmon: (aspeed-g6-pwm-tacho): Support for ASPEED g6 PWM/Fan tach
@ 2023-08-30 12:32 ` Billy Tsai
0 siblings, 0 replies; 26+ messages in thread
From: Billy Tsai @ 2023-08-30 12:32 UTC (permalink / raw)
To: jdelvare, linux, robh+dt, krzysztof.kozlowski+dt, joel, andrew,
corbet, thierry.reding, u.kleine-koenig, p.zabel, billy_tsai,
naresh.solanki, linux-hwmon, devicetree, linux-arm-kernel,
linux-aspeed, linux-kernel, linux-doc, linux-pwm, BMC-SW,
patrick
The driver support two functions: PWM and Tachometer. The PWM feature can
handle up to 16 output ports, while the Tachometer can monitor to up to 16
input ports as well. This driver implements them by exposing two kernel
subsystems: PWM and HWMON. The PWM subsystem can be utilized alongside
existing drivers for controlling elements such as fans (pwm-fan.c),
beepers (pwm-beeper.c) and so on. Through the HWMON subsystem, the driver
provides sysfs interfaces for fan.
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
---
Documentation/hwmon/aspeed-g6-pwm-tach.rst | 26 +
Documentation/hwmon/index.rst | 1 +
drivers/hwmon/Kconfig | 11 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/aspeed-g6-pwm-tach.c | 528 +++++++++++++++++++++
5 files changed, 567 insertions(+)
create mode 100644 Documentation/hwmon/aspeed-g6-pwm-tach.rst
create mode 100644 drivers/hwmon/aspeed-g6-pwm-tach.c
diff --git a/Documentation/hwmon/aspeed-g6-pwm-tach.rst b/Documentation/hwmon/aspeed-g6-pwm-tach.rst
new file mode 100644
index 000000000000..17398fe397fe
--- /dev/null
+++ b/Documentation/hwmon/aspeed-g6-pwm-tach.rst
@@ -0,0 +1,26 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver aspeed-g6-pwm-tach
+=================================
+
+Supported chips:
+ ASPEED AST2600
+
+Authors:
+ <billy_tsai@aspeedtech.com>
+
+Description:
+------------
+This driver implements support for ASPEED AST2600 Fan Tacho controller.
+The controller supports up to 16 tachometer inputs.
+
+The driver provides the following sensor accesses in sysfs:
+
+=============== ======= ======================================================
+fanX_input ro provide current fan rotation value in RPM as reported
+ by the fan to the device.
+fanX_div rw Fan divisor: Supported value are power of 4 (1, 4, 16
+ 64, ... 4194304)
+ The larger divisor, the less rpm accuracy and the less
+ affected by fan signal glitch.
+=============== ======= ======================================================
diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index 5c1052d8c57c..614a18477e9f 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -43,6 +43,7 @@ Hardware Monitoring Kernel Drivers
aquacomputer_d5next
asb100
asc7621
+ aspeed-g6-pwm-tach
aspeed-pwm-tacho
asus_ec_sensors
asus_wmi_sensors
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 283e0adafbc1..1f82df1979db 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -411,6 +411,17 @@ config SENSORS_ASPEED
This driver can also be built as a module. If so, the module
will be called aspeed_pwm_tacho.
+config SENSORS_ASPEED_G6
+ tristate "ASPEED g6 PWM and Fan tach driver"
+ depends on ARCH_ASPEED || COMPILE_TEST
+ depends on PWM
+ help
+ This driver provides support for ASPEED G6 PWM and Fan Tach
+ controllers.
+
+ This driver can also be built as a module. If so, the module
+ will be called aspeed_pwm_tacho.
+
config SENSORS_ATXP1
tristate "Attansic ATXP1 VID controller"
depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index abefc16c1e1e..1fbb66c37a7c 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_SENSORS_ARM_SCPI) += scpi-hwmon.o
obj-$(CONFIG_SENSORS_AS370) += as370-hwmon.o
obj-$(CONFIG_SENSORS_ASC7621) += asc7621.o
obj-$(CONFIG_SENSORS_ASPEED) += aspeed-pwm-tacho.o
+obj-$(CONFIG_SENSORS_ASPEED_G6) += aspeed-g6-pwm-tach.o
obj-$(CONFIG_SENSORS_ATXP1) += atxp1.o
obj-$(CONFIG_SENSORS_AXI_FAN_CONTROL) += axi-fan-control.o
obj-$(CONFIG_SENSORS_BT1_PVT) += bt1-pvt.o
diff --git a/drivers/hwmon/aspeed-g6-pwm-tach.c b/drivers/hwmon/aspeed-g6-pwm-tach.c
new file mode 100644
index 000000000000..f7d53e8e009f
--- /dev/null
+++ b/drivers/hwmon/aspeed-g6-pwm-tach.c
@@ -0,0 +1,528 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2021 Aspeed Technology Inc.
+ *
+ * PWM/TACH controller driver for Aspeed ast2600 SoCs.
+ * This drivers doesn't support earlier version of the IP.
+ *
+ * The hardware operates in time quantities of length
+ * Q := (DIV_L + 1) << DIV_H / input-clk
+ * The length of a PWM period is (DUTY_CYCLE_PERIOD + 1) * Q.
+ * The maximal value for DUTY_CYCLE_PERIOD is used here to provide
+ * a fine grained selection for the duty cycle.
+ *
+ * This driver uses DUTY_CYCLE_RISING_POINT = 0, so from the start of a
+ * period the output is active until DUTY_CYCLE_FALLING_POINT * Q. Note
+ * that if DUTY_CYCLE_RISING_POINT = DUTY_CYCLE_FALLING_POINT the output is
+ * always active.
+ *
+ * Register usage:
+ * PIN_ENABLE: When it is unset the pwm controller will emit inactive level to the external.
+ * Use to determine whether the PWM channel is enabled or disabled
+ * CLK_ENABLE: When it is unset the pwm controller will assert the duty counter reset and
+ * emit inactive level to the PIN_ENABLE mux after that the driver can still change the pwm period
+ * and duty and the value will apply when CLK_ENABLE be set again.
+ * Use to determine whether duty_cycle bigger than 0.
+ * PWM_ASPEED_CTRL_INVERSE: When it is toggled the output value will inverse immediately.
+ * PWM_ASPEED_DUTY_CYCLE_FALLING_POINT/PWM_ASPEED_DUTY_CYCLE_RISING_POINT: When these two
+ * values are equal it means the duty cycle = 100%.
+ *
+ * The glitch may generate at:
+ * - Enabled changing when the duty_cycle bigger than 0% and less than 100%.
+ * - Polarity changing when the duty_cycle bigger than 0% and less than 100%.
+ *
+ * Limitations:
+ * - When changing both duty cycle and period, we cannot prevent in
+ * software that the output might produce a period with mixed
+ * settings.
+ * - Disabling the PWM doesn't complete the current period.
+ *
+ * Improvements:
+ * - When only changing one of duty cycle or period, our pwm controller will not
+ * generate the glitch, the configure will change at next cycle of pwm.
+ * This improvement can disable/enable through PWM_ASPEED_CTRL_DUTY_SYNC_DISABLE.
+ */
+
+#include <linux/bitfield.h>
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/errno.h>
+#include <linux/hwmon.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/math64.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/pwm.h>
+#include <linux/reset.h>
+#include <linux/sysfs.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)
+
+/* The channel number of Aspeed tach controller */
+#define TACH_ASPEED_NR_TACHS 16
+/* TACH Control Register */
+#define TACH_ASPEED_CTRL(ch) (((ch) * 0x10) + 0x08)
+#define TACH_ASPEED_IER BIT(31)
+#define TACH_ASPEED_INVERS_LIMIT BIT(30)
+#define TACH_ASPEED_LOOPBACK BIT(29)
+#define TACH_ASPEED_ENABLE BIT(28)
+#define TACH_ASPEED_DEBOUNCE_MASK GENMASK(27, 26)
+#define TACH_ASPEED_DEBOUNCE_BIT 26
+#define TACH_ASPEED_IO_EDGE_MASK GENMASK(25, 24)
+#define TACH_ASPEED_IO_EDGE_BIT 24
+#define TACH_ASPEED_CLK_DIV_T_MASK GENMASK(23, 20)
+#define TACH_ASPEED_CLK_DIV_BIT 20
+#define TACH_ASPEED_THRESHOLD_MASK GENMASK(19, 0)
+/* [27:26] */
+#define DEBOUNCE_3_CLK 0x00
+#define DEBOUNCE_2_CLK 0x01
+#define DEBOUNCE_1_CLK 0x02
+#define DEBOUNCE_0_CLK 0x03
+/* [25:24] */
+#define F2F_EDGES 0x00
+#define R2R_EDGES 0x01
+#define BOTH_EDGES 0x02
+/* [23:20] */
+/* divisor = 4 to the nth power, n = register value */
+#define DEFAULT_TACH_DIV 1024
+#define DIV_TO_REG(divisor) (ilog2(divisor) >> 1)
+
+/* TACH Status Register */
+#define TACH_ASPEED_STS(ch) (((ch) * 0x10) + 0x0C)
+
+/*PWM_TACH_STS */
+#define TACH_ASPEED_ISR BIT(31)
+#define TACH_ASPEED_PWM_OUT BIT(25)
+#define TACH_ASPEED_PWM_OEN BIT(24)
+#define TACH_ASPEED_DEB_INPUT BIT(23)
+#define TACH_ASPEED_RAW_INPUT BIT(22)
+#define TACH_ASPEED_VALUE_UPDATE BIT(21)
+#define TACH_ASPEED_FULL_MEASUREMENT BIT(20)
+#define TACH_ASPEED_VALUE_MASK GENMASK(19, 0)
+/**********************************************************
+ * Software setting
+ *********************************************************/
+#define DEFAULT_FAN_PULSE_PR 2
+
+struct aspeed_pwm_tach_data {
+ struct device *dev;
+ void __iomem *base;
+ struct clk *clk;
+ struct reset_control *reset;
+ unsigned long clk_rate;
+ struct pwm_chip chip;
+ bool tach_present[TACH_ASPEED_NR_TACHS];
+ u32 tach_divisor;
+};
+
+static inline struct aspeed_pwm_tach_data *
+aspeed_pwm_chip_to_data(struct pwm_chip *chip)
+{
+ return container_of(chip, struct aspeed_pwm_tach_data, chip);
+}
+
+static int aspeed_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
+ struct pwm_state *state)
+{
+ struct aspeed_pwm_tach_data *priv = aspeed_pwm_chip_to_data(chip);
+ u32 hwpwm = pwm->hwpwm;
+ bool polarity, pin_en, clk_en;
+ u32 duty_pt, val;
+ u64 div_h, div_l, duty_cycle_period, dividend;
+
+ val = readl(priv->base + PWM_ASPEED_CTRL(hwpwm));
+ polarity = FIELD_GET(PWM_ASPEED_CTRL_INVERSE, val);
+ pin_en = FIELD_GET(PWM_ASPEED_CTRL_PIN_ENABLE, val);
+ clk_en = FIELD_GET(PWM_ASPEED_CTRL_CLK_ENABLE, val);
+ div_h = FIELD_GET(PWM_ASPEED_CTRL_CLK_DIV_H, val);
+ div_l = FIELD_GET(PWM_ASPEED_CTRL_CLK_DIV_L, val);
+ val = readl(priv->base + PWM_ASPEED_DUTY_CYCLE(hwpwm));
+ duty_pt = FIELD_GET(PWM_ASPEED_DUTY_CYCLE_FALLING_POINT, val);
+ duty_cycle_period = FIELD_GET(PWM_ASPEED_DUTY_CYCLE_PERIOD, val);
+ /*
+ * This multiplication doesn't overflow, the upper bound is
+ * 1000000000 * 256 * 256 << 15 = 0x1dcd650000000000
+ */
+ dividend = (u64)NSEC_PER_SEC * (div_l + 1) * (duty_cycle_period + 1)
+ << div_h;
+ state->period = DIV_ROUND_UP_ULL(dividend, priv->clk_rate);
+
+ if (clk_en && duty_pt) {
+ dividend = (u64)NSEC_PER_SEC * (div_l + 1) * duty_pt
+ << div_h;
+ state->duty_cycle = DIV_ROUND_UP_ULL(dividend, priv->clk_rate);
+ } else {
+ state->duty_cycle = clk_en ? state->period : 0;
+ }
+ state->polarity = polarity ? PWM_POLARITY_INVERSED : PWM_POLARITY_NORMAL;
+ state->enabled = pin_en;
+ return 0;
+}
+
+static int aspeed_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+ const struct pwm_state *state)
+{
+ struct aspeed_pwm_tach_data *priv = aspeed_pwm_chip_to_data(chip);
+ u32 hwpwm = pwm->hwpwm, duty_pt, val;
+ u64 div_h, div_l, divisor, expect_period;
+ bool clk_en;
+
+ expect_period = div64_u64(ULLONG_MAX, (u64)priv->clk_rate);
+ expect_period = min(expect_period, state->period);
+ dev_dbg(chip->dev, "expect period: %lldns, duty_cycle: %lldns",
+ expect_period, state->duty_cycle);
+ /*
+ * Pick the smallest value for div_h so that div_l can be the biggest
+ * which results in a finer resolution near the target period value.
+ */
+ divisor = (u64)NSEC_PER_SEC * (PWM_ASPEED_FIXED_PERIOD + 1) *
+ (FIELD_MAX(PWM_ASPEED_CTRL_CLK_DIV_L) + 1);
+ div_h = order_base_2(DIV64_U64_ROUND_UP(priv->clk_rate * expect_period, divisor));
+ if (div_h > 0xf)
+ div_h = 0xf;
+
+ divisor = ((u64)NSEC_PER_SEC * (PWM_ASPEED_FIXED_PERIOD + 1)) << div_h;
+ div_l = div64_u64(priv->clk_rate * expect_period, divisor);
+
+ if (div_l == 0)
+ return -ERANGE;
+
+ div_l -= 1;
+
+ if (div_l > 255)
+ div_l = 255;
+
+ dev_dbg(chip->dev, "clk source: %ld div_h %lld, div_l : %lld\n",
+ priv->clk_rate, div_h, div_l);
+ /* duty_pt = duty_cycle * (PERIOD + 1) / period */
+ duty_pt = div64_u64(state->duty_cycle * priv->clk_rate,
+ (u64)NSEC_PER_SEC * (div_l + 1) << div_h);
+ dev_dbg(chip->dev, "duty_cycle = %lld, duty_pt = %d\n",
+ state->duty_cycle, duty_pt);
+
+ /*
+ * Fixed DUTY_CYCLE_PERIOD to its max value to get a
+ * fine-grained resolution for duty_cycle at the expense of a
+ * coarser period resolution.
+ */
+ val = readl(priv->base + PWM_ASPEED_DUTY_CYCLE(hwpwm));
+ val &= ~PWM_ASPEED_DUTY_CYCLE_PERIOD;
+ val |= FIELD_PREP(PWM_ASPEED_DUTY_CYCLE_PERIOD,
+ PWM_ASPEED_FIXED_PERIOD);
+ writel(val, priv->base + PWM_ASPEED_DUTY_CYCLE(hwpwm));
+
+ if (duty_pt == 0) {
+ /* emit inactive level and assert the duty counter reset */
+ clk_en = 0;
+ } else {
+ clk_en = 1;
+ if (duty_pt >= (PWM_ASPEED_FIXED_PERIOD + 1))
+ duty_pt = 0;
+ val = readl(priv->base + PWM_ASPEED_DUTY_CYCLE(hwpwm));
+ val &= ~(PWM_ASPEED_DUTY_CYCLE_RISING_POINT |
+ PWM_ASPEED_DUTY_CYCLE_FALLING_POINT);
+ val |= FIELD_PREP(PWM_ASPEED_DUTY_CYCLE_FALLING_POINT, duty_pt);
+ writel(val, priv->base + PWM_ASPEED_DUTY_CYCLE(hwpwm));
+ }
+
+ val = readl(priv->base + PWM_ASPEED_CTRL(hwpwm));
+ val &= ~(PWM_ASPEED_CTRL_CLK_DIV_H | PWM_ASPEED_CTRL_CLK_DIV_L |
+ PWM_ASPEED_CTRL_PIN_ENABLE | PWM_ASPEED_CTRL_CLK_ENABLE |
+ PWM_ASPEED_CTRL_INVERSE);
+ val |= FIELD_PREP(PWM_ASPEED_CTRL_CLK_DIV_H, div_h) |
+ FIELD_PREP(PWM_ASPEED_CTRL_CLK_DIV_L, div_l) |
+ FIELD_PREP(PWM_ASPEED_CTRL_PIN_ENABLE, state->enabled) |
+ FIELD_PREP(PWM_ASPEED_CTRL_CLK_ENABLE, clk_en) |
+ FIELD_PREP(PWM_ASPEED_CTRL_INVERSE, state->polarity);
+ writel(val, priv->base + PWM_ASPEED_CTRL(hwpwm));
+
+ return 0;
+}
+
+static const struct pwm_ops aspeed_pwm_ops = {
+ .apply = aspeed_pwm_apply,
+ .get_state = aspeed_pwm_get_state,
+ .owner = THIS_MODULE,
+};
+
+static void aspeed_tach_ch_enable(struct aspeed_pwm_tach_data *priv, u8 tach_ch,
+ bool enable)
+{
+ if (enable)
+ writel(readl(priv->base + TACH_ASPEED_CTRL(tach_ch)) |
+ TACH_ASPEED_ENABLE,
+ priv->base + TACH_ASPEED_CTRL(tach_ch));
+ else
+ writel(readl(priv->base + TACH_ASPEED_CTRL(tach_ch)) &
+ ~TACH_ASPEED_ENABLE,
+ priv->base + TACH_ASPEED_CTRL(tach_ch));
+}
+
+static int aspeed_tach_val_to_rpm(struct aspeed_pwm_tach_data *priv, u32 tach_val)
+{
+ u64 rpm;
+ u32 tach_div;
+
+ tach_div = tach_val * priv->tach_divisor * DEFAULT_FAN_PULSE_PR;
+
+ dev_dbg(priv->dev, "clk %ld, tach_val %d , tach_div %d\n",
+ priv->clk_rate, tach_val, tach_div);
+
+ rpm = (u64)priv->clk_rate * 60;
+ do_div(rpm, tach_div);
+
+ return (int)rpm;
+}
+
+static int aspeed_get_fan_tach_ch_rpm(struct aspeed_pwm_tach_data *priv,
+ u8 fan_tach_ch)
+{
+ u32 val;
+
+ val = readl(priv->base + TACH_ASPEED_STS(fan_tach_ch));
+
+ if (!(val & TACH_ASPEED_FULL_MEASUREMENT))
+ return 0;
+ val = FIELD_GET(TACH_ASPEED_VALUE_MASK, val);
+ return aspeed_tach_val_to_rpm(priv, val);
+}
+
+static int aspeed_tach_hwmon_read(struct device *dev,
+ enum hwmon_sensor_types type, u32 attr,
+ int channel, long *val)
+{
+ struct aspeed_pwm_tach_data *priv = dev_get_drvdata(dev);
+ u32 reg_val;
+
+ switch (attr) {
+ case hwmon_fan_input:
+ *val = aspeed_get_fan_tach_ch_rpm(priv, channel);
+ break;
+ case hwmon_fan_div:
+ reg_val = readl(priv->base + TACH_ASPEED_CTRL(channel));
+ reg_val = FIELD_GET(TACH_ASPEED_CLK_DIV_T_MASK, reg_val);
+ *val = BIT(reg_val << 1);
+ break;
+ default:
+ return -EOPNOTSUPP;
+ }
+ return 0;
+}
+
+static int aspeed_tach_hwmon_write(struct device *dev,
+ enum hwmon_sensor_types type, u32 attr,
+ int channel, long val)
+{
+ struct aspeed_pwm_tach_data *priv = dev_get_drvdata(dev);
+ u32 reg_val;
+
+ switch (attr) {
+ case hwmon_fan_div:
+ if (!is_power_of_2(val) || (ilog2(val) % 2) ||
+ DIV_TO_REG(val) > 0xb)
+ return -EINVAL;
+ priv->tach_divisor = val;
+ reg_val = readl(priv->base + TACH_ASPEED_CTRL(channel));
+ reg_val &= ~TACH_ASPEED_CLK_DIV_T_MASK;
+ reg_val |= FIELD_GET(TACH_ASPEED_CLK_DIV_T_MASK,
+ DIV_TO_REG(priv->tach_divisor));
+ writel(reg_val, priv->base + TACH_ASPEED_CTRL(channel));
+ break;
+ default:
+ return -EOPNOTSUPP;
+ }
+
+ return 0;
+}
+
+static umode_t aspeed_tach_dev_is_visible(const void *drvdata,
+ enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+ const struct aspeed_pwm_tach_data *priv = drvdata;
+
+ if (!priv->tach_present[channel])
+ return 0;
+ switch (attr) {
+ case hwmon_fan_input:
+ return 0444;
+ case hwmon_fan_div:
+ return 0644;
+ }
+ return 0;
+}
+
+static const struct hwmon_ops aspeed_tach_ops = {
+ .is_visible = aspeed_tach_dev_is_visible,
+ .read = aspeed_tach_hwmon_read,
+ .write = aspeed_tach_hwmon_write,
+};
+
+static const struct hwmon_channel_info *aspeed_tach_info[] = {
+ HWMON_CHANNEL_INFO(fan, HWMON_F_INPUT | HWMON_F_DIV, HWMON_F_INPUT | HWMON_F_DIV,
+ HWMON_F_INPUT | HWMON_F_DIV, HWMON_F_INPUT | HWMON_F_DIV,
+ HWMON_F_INPUT | HWMON_F_DIV, HWMON_F_INPUT | HWMON_F_DIV,
+ HWMON_F_INPUT | HWMON_F_DIV, HWMON_F_INPUT | HWMON_F_DIV,
+ HWMON_F_INPUT | HWMON_F_DIV, HWMON_F_INPUT | HWMON_F_DIV,
+ HWMON_F_INPUT | HWMON_F_DIV, HWMON_F_INPUT | HWMON_F_DIV,
+ HWMON_F_INPUT | HWMON_F_DIV, HWMON_F_INPUT | HWMON_F_DIV,
+ HWMON_F_INPUT | HWMON_F_DIV, HWMON_F_INPUT | HWMON_F_DIV),
+ NULL
+};
+
+static const struct hwmon_chip_info aspeed_tach_chip_info = {
+ .ops = &aspeed_tach_ops,
+ .info = aspeed_tach_info,
+};
+
+static void aspeed_present_fan_tach(struct aspeed_pwm_tach_data *priv, u32 tach_ch)
+{
+ u32 val;
+
+ priv->tach_present[tach_ch] = true;
+ priv->tach_divisor = DEFAULT_TACH_DIV;
+
+ val = readl(priv->base + TACH_ASPEED_CTRL(tach_ch));
+ val &= ~(TACH_ASPEED_INVERS_LIMIT | TACH_ASPEED_DEBOUNCE_MASK |
+ TACH_ASPEED_IO_EDGE_MASK | TACH_ASPEED_CLK_DIV_T_MASK |
+ TACH_ASPEED_THRESHOLD_MASK);
+ val |= (DEBOUNCE_3_CLK << TACH_ASPEED_DEBOUNCE_BIT) | F2F_EDGES |
+ FIELD_GET(TACH_ASPEED_CLK_DIV_T_MASK,
+ DIV_TO_REG(priv->tach_divisor));
+ writel(val, priv->base + TACH_ASPEED_CTRL(tach_ch));
+
+ aspeed_tach_ch_enable(priv, tach_ch, true);
+}
+
+static int aspeed_tach_create_fan(struct device *dev, struct device_node *child,
+ struct aspeed_pwm_tach_data *priv)
+{
+ int ret;
+ u32 tach_ch;
+
+ ret = of_property_read_u32(child, "tach-ch", &tach_ch);
+ if (ret)
+ return ret;
+
+ aspeed_present_fan_tach(priv, tach_ch);
+
+ return 0;
+}
+
+static int aspeed_pwm_tach_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev, *hwmon;
+ int ret;
+ struct device_node *child;
+ struct aspeed_pwm_tach_data *priv;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+ priv->dev = dev;
+ priv->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(priv->base))
+ return PTR_ERR(priv->base);
+
+ priv->clk = devm_clk_get_enabled(dev, NULL);
+ if (IS_ERR(priv->clk))
+ return dev_err_probe(dev, PTR_ERR(priv->clk),
+ "Couldn't get clock\n");
+ priv->clk_rate = clk_get_rate(priv->clk);
+ priv->reset = devm_reset_control_get_exclusive(dev, NULL);
+ if (IS_ERR(priv->reset))
+ return dev_err_probe(dev, PTR_ERR(priv->reset),
+ "Couldn't get reset control\n");
+
+ ret = reset_control_deassert(priv->reset);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "Couldn't deassert reset control\n");
+
+ priv->chip.dev = dev;
+ priv->chip.ops = &aspeed_pwm_ops;
+ priv->chip.npwm = PWM_ASPEED_NR_PWMS;
+
+ ret = devm_pwmchip_add(dev, &priv->chip);
+ if (ret < 0) {
+ reset_control_assert(priv->reset);
+ return dev_err_probe(dev, ret, "Failed to add PWM chip\n");
+ }
+
+ for_each_child_of_node(dev->of_node, child) {
+ ret = aspeed_tach_create_fan(dev, child, priv);
+ if (ret < 0) {
+ of_node_put(child);
+ dev_warn(dev, "Failed to create fan %d", ret);
+ return 0;
+ }
+ }
+
+ hwmon = devm_hwmon_device_register_with_info(dev, "aspeed_tach", priv,
+ &aspeed_tach_chip_info, NULL);
+ ret = PTR_ERR_OR_ZERO(hwmon);
+ if (ret) {
+ reset_control_assert(priv->reset);
+ return dev_err_probe(dev, ret,
+ "Failed to register hwmon device\n");
+ }
+
+ return 0;
+}
+
+static int aspeed_pwm_tach_remove(struct platform_device *pdev)
+{
+ struct aspeed_pwm_tach_data *priv = platform_get_drvdata(pdev);
+
+ reset_control_assert(priv->reset);
+
+ return 0;
+}
+
+static const struct of_device_id aspeed_pwm_tach_match[] = {
+ {
+ .compatible = "aspeed,ast2600-pwm-tach",
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, aspeed_pwm_tach_match);
+
+static struct platform_driver aspeed_pwm_tach_driver = {
+ .probe = aspeed_pwm_tach_probe,
+ .remove = aspeed_pwm_tach_remove,
+ .driver = {
+ .name = "aspeed-g6-pwm-tach",
+ .of_match_table = aspeed_pwm_tach_match,
+ },
+};
+
+module_platform_driver(aspeed_pwm_tach_driver);
+
+MODULE_AUTHOR("Billy Tsai <billy_tsai@aspeedtech.com>");
+MODULE_DESCRIPTION("Aspeed ast2600 PWM and Fan Tach device driver");
+MODULE_LICENSE("GPL");
--
2.25.1
^ permalink raw reply related [flat|nested] 26+ messages in thread
* Re: [PATCH v8 3/3] hwmon: (aspeed-g6-pwm-tacho): Support for ASPEED g6 PWM/Fan tach
2023-08-30 12:32 ` Billy Tsai
@ 2023-09-01 4:54 ` Potin Lai
-1 siblings, 0 replies; 26+ messages in thread
From: Potin Lai @ 2023-09-01 4:54 UTC (permalink / raw)
To: Billy Tsai
Cc: jdelvare, linux, robh+dt, krzysztof.kozlowski+dt, joel, andrew,
corbet, thierry.reding, u.kleine-koenig, p.zabel, naresh.solanki,
linux-hwmon, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, linux-doc, linux-pwm, BMC-SW, patrick
On 8/30/23 20:32, Billy Tsai wrote:
> +static int aspeed_tach_hwmon_write(struct device *dev,
> + enum hwmon_sensor_types type, u32 attr,
> + int channel, long val)
> +{
> + struct aspeed_pwm_tach_data *priv = dev_get_drvdata(dev);
> + u32 reg_val;
> +
> + switch (attr) {
> + case hwmon_fan_div:
> + if (!is_power_of_2(val) || (ilog2(val) % 2) ||
> + DIV_TO_REG(val) > 0xb)
> + return -EINVAL;
> + priv->tach_divisor = val;
> + reg_val = readl(priv->base + TACH_ASPEED_CTRL(channel));
> + reg_val &= ~TACH_ASPEED_CLK_DIV_T_MASK;
> + reg_val |= FIELD_GET(TACH_ASPEED_CLK_DIV_T_MASK,
> + DIV_TO_REG(priv->tach_divisor));
Hi Billy,
I notice the fanX_div is always shows 1 after I set 1024.
I think FIELD_GET() needs to replaced with FIELD_PREP().
> + writel(reg_val, priv->base + TACH_ASPEED_CTRL(channel));
> + break;
> + default:
> + return -EOPNOTSUPP;
> + }
> +
> + return 0;
> +}
> +static void aspeed_present_fan_tach(struct aspeed_pwm_tach_data *priv, u32 tach_ch)
> +{
> + u32 val;
> +
> + priv->tach_present[tach_ch] = true;
> + priv->tach_divisor = DEFAULT_TACH_DIV;
> +
> + val = readl(priv->base + TACH_ASPEED_CTRL(tach_ch));
> + val &= ~(TACH_ASPEED_INVERS_LIMIT | TACH_ASPEED_DEBOUNCE_MASK |
> + TACH_ASPEED_IO_EDGE_MASK | TACH_ASPEED_CLK_DIV_T_MASK |
> + TACH_ASPEED_THRESHOLD_MASK);
> + val |= (DEBOUNCE_3_CLK << TACH_ASPEED_DEBOUNCE_BIT) | F2F_EDGES |
> + FIELD_GET(TACH_ASPEED_CLK_DIV_T_MASK,
> + DIV_TO_REG(priv->tach_divisor));
And here as well.
> + writel(val, priv->base + TACH_ASPEED_CTRL(tach_ch));
> +
> + aspeed_tach_ch_enable(priv, tach_ch, true);
> +}
> +
>
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v8 3/3] hwmon: (aspeed-g6-pwm-tacho): Support for ASPEED g6 PWM/Fan tach
@ 2023-09-01 4:54 ` Potin Lai
0 siblings, 0 replies; 26+ messages in thread
From: Potin Lai @ 2023-09-01 4:54 UTC (permalink / raw)
To: Billy Tsai
Cc: jdelvare, linux, robh+dt, krzysztof.kozlowski+dt, joel, andrew,
corbet, thierry.reding, u.kleine-koenig, p.zabel, naresh.solanki,
linux-hwmon, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, linux-doc, linux-pwm, BMC-SW, patrick
On 8/30/23 20:32, Billy Tsai wrote:
> +static int aspeed_tach_hwmon_write(struct device *dev,
> + enum hwmon_sensor_types type, u32 attr,
> + int channel, long val)
> +{
> + struct aspeed_pwm_tach_data *priv = dev_get_drvdata(dev);
> + u32 reg_val;
> +
> + switch (attr) {
> + case hwmon_fan_div:
> + if (!is_power_of_2(val) || (ilog2(val) % 2) ||
> + DIV_TO_REG(val) > 0xb)
> + return -EINVAL;
> + priv->tach_divisor = val;
> + reg_val = readl(priv->base + TACH_ASPEED_CTRL(channel));
> + reg_val &= ~TACH_ASPEED_CLK_DIV_T_MASK;
> + reg_val |= FIELD_GET(TACH_ASPEED_CLK_DIV_T_MASK,
> + DIV_TO_REG(priv->tach_divisor));
Hi Billy,
I notice the fanX_div is always shows 1 after I set 1024.
I think FIELD_GET() needs to replaced with FIELD_PREP().
> + writel(reg_val, priv->base + TACH_ASPEED_CTRL(channel));
> + break;
> + default:
> + return -EOPNOTSUPP;
> + }
> +
> + return 0;
> +}
> +static void aspeed_present_fan_tach(struct aspeed_pwm_tach_data *priv, u32 tach_ch)
> +{
> + u32 val;
> +
> + priv->tach_present[tach_ch] = true;
> + priv->tach_divisor = DEFAULT_TACH_DIV;
> +
> + val = readl(priv->base + TACH_ASPEED_CTRL(tach_ch));
> + val &= ~(TACH_ASPEED_INVERS_LIMIT | TACH_ASPEED_DEBOUNCE_MASK |
> + TACH_ASPEED_IO_EDGE_MASK | TACH_ASPEED_CLK_DIV_T_MASK |
> + TACH_ASPEED_THRESHOLD_MASK);
> + val |= (DEBOUNCE_3_CLK << TACH_ASPEED_DEBOUNCE_BIT) | F2F_EDGES |
> + FIELD_GET(TACH_ASPEED_CLK_DIV_T_MASK,
> + DIV_TO_REG(priv->tach_divisor));
And here as well.
> + writel(val, priv->base + TACH_ASPEED_CTRL(tach_ch));
> +
> + aspeed_tach_ch_enable(priv, tach_ch, true);
> +}
> +
>
_______________________________________________
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] 26+ messages in thread
* Re: [PATCH v8 3/3] hwmon: (aspeed-g6-pwm-tacho): Support for ASPEED g6 PWM/Fan tach
2023-09-01 4:54 ` Potin Lai
@ 2023-09-01 5:10 ` Billy Tsai
-1 siblings, 0 replies; 26+ messages in thread
From: Billy Tsai @ 2023-09-01 5:10 UTC (permalink / raw)
To: Potin Lai
Cc: jdelvare, linux, robh+dt, krzysztof.kozlowski+dt, joel, andrew,
corbet, thierry.reding, u.kleine-koenig, p.zabel, naresh.solanki,
linux-hwmon, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, linux-doc, linux-pwm, BMC-SW, patrick
On 8/30/23 20:32, Billy Tsai wrote:
>> +static int aspeed_tach_hwmon_write(struct device *dev,
>> + enum hwmon_sensor_types type, u32 attr,
>> + int channel, long val)
>> +{
>> + struct aspeed_pwm_tach_data *priv = dev_get_drvdata(dev);
>> + u32 reg_val;
>> +
>> + switch (attr) {
>> + case hwmon_fan_div:
>> + if (!is_power_of_2(val) || (ilog2(val) % 2) ||
>> + DIV_TO_REG(val) > 0xb)
>> + return -EINVAL;
>> + priv->tach_divisor = val;
>> + reg_val = readl(priv->base + TACH_ASPEED_CTRL(channel));
>> + reg_val &= ~TACH_ASPEED_CLK_DIV_T_MASK;
>> + reg_val |= FIELD_GET(TACH_ASPEED_CLK_DIV_T_MASK,
>> + DIV_TO_REG(priv->tach_divisor));
> Hi Billy,
> I notice the fanX_div is always shows 1 after I set 1024.
> I think FIELD_GET() needs to replaced with FIELD_PREP().
>> + writel(reg_val, priv->base + TACH_ASPEED_CTRL(channel));
>> + break;
>> + default:
>> + return -EOPNOTSUPP;
>> + }
>> +
>> + return 0;
>> +}
>> +static void aspeed_present_fan_tach(struct aspeed_pwm_tach_data *priv, u32 tach_ch)
>> +{
>> + u32 val;
>> +
>> + priv->tach_present[tach_ch] = true;
>> + priv->tach_divisor = DEFAULT_TACH_DIV;
>> +
>> + val = readl(priv->base + TACH_ASPEED_CTRL(tach_ch));
>> + val &= ~(TACH_ASPEED_INVERS_LIMIT | TACH_ASPEED_DEBOUNCE_MASK |
>> + TACH_ASPEED_IO_EDGE_MASK | TACH_ASPEED_CLK_DIV_T_MASK |
>> + TACH_ASPEED_THRESHOLD_MASK);
>> + val |= (DEBOUNCE_3_CLK << TACH_ASPEED_DEBOUNCE_BIT) | F2F_EDGES |
>> + FIELD_GET(TACH_ASPEED_CLK_DIV_T_MASK,
>> + DIV_TO_REG(priv->tach_divisor));
> And here as well.
>> + writel(val, priv->base + TACH_ASPEED_CTRL(tach_ch));
>> +
>> + aspeed_tach_ch_enable(priv, tach_ch, true);
>> +}
>> +
>>
Hi Potin,
I will fix it in next verison of the patch.
Thanks for reviewing.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v8 3/3] hwmon: (aspeed-g6-pwm-tacho): Support for ASPEED g6 PWM/Fan tach
@ 2023-09-01 5:10 ` Billy Tsai
0 siblings, 0 replies; 26+ messages in thread
From: Billy Tsai @ 2023-09-01 5:10 UTC (permalink / raw)
To: Potin Lai
Cc: jdelvare, linux, robh+dt, krzysztof.kozlowski+dt, joel, andrew,
corbet, thierry.reding, u.kleine-koenig, p.zabel, naresh.solanki,
linux-hwmon, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, linux-doc, linux-pwm, BMC-SW, patrick
On 8/30/23 20:32, Billy Tsai wrote:
>> +static int aspeed_tach_hwmon_write(struct device *dev,
>> + enum hwmon_sensor_types type, u32 attr,
>> + int channel, long val)
>> +{
>> + struct aspeed_pwm_tach_data *priv = dev_get_drvdata(dev);
>> + u32 reg_val;
>> +
>> + switch (attr) {
>> + case hwmon_fan_div:
>> + if (!is_power_of_2(val) || (ilog2(val) % 2) ||
>> + DIV_TO_REG(val) > 0xb)
>> + return -EINVAL;
>> + priv->tach_divisor = val;
>> + reg_val = readl(priv->base + TACH_ASPEED_CTRL(channel));
>> + reg_val &= ~TACH_ASPEED_CLK_DIV_T_MASK;
>> + reg_val |= FIELD_GET(TACH_ASPEED_CLK_DIV_T_MASK,
>> + DIV_TO_REG(priv->tach_divisor));
> Hi Billy,
> I notice the fanX_div is always shows 1 after I set 1024.
> I think FIELD_GET() needs to replaced with FIELD_PREP().
>> + writel(reg_val, priv->base + TACH_ASPEED_CTRL(channel));
>> + break;
>> + default:
>> + return -EOPNOTSUPP;
>> + }
>> +
>> + return 0;
>> +}
>> +static void aspeed_present_fan_tach(struct aspeed_pwm_tach_data *priv, u32 tach_ch)
>> +{
>> + u32 val;
>> +
>> + priv->tach_present[tach_ch] = true;
>> + priv->tach_divisor = DEFAULT_TACH_DIV;
>> +
>> + val = readl(priv->base + TACH_ASPEED_CTRL(tach_ch));
>> + val &= ~(TACH_ASPEED_INVERS_LIMIT | TACH_ASPEED_DEBOUNCE_MASK |
>> + TACH_ASPEED_IO_EDGE_MASK | TACH_ASPEED_CLK_DIV_T_MASK |
>> + TACH_ASPEED_THRESHOLD_MASK);
>> + val |= (DEBOUNCE_3_CLK << TACH_ASPEED_DEBOUNCE_BIT) | F2F_EDGES |
>> + FIELD_GET(TACH_ASPEED_CLK_DIV_T_MASK,
>> + DIV_TO_REG(priv->tach_divisor));
> And here as well.
>> + writel(val, priv->base + TACH_ASPEED_CTRL(tach_ch));
>> +
>> + aspeed_tach_ch_enable(priv, tach_ch, true);
>> +}
>> +
>>
Hi Potin,
I will fix it in next verison of the patch.
Thanks for reviewing.
_______________________________________________
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] 26+ messages in thread
* Re: [PATCH v8 1/3] dt-bindings: hwmon: fan: Add fan binding to schema
2023-08-30 12:32 ` Billy Tsai
@ 2023-09-05 17:00 ` Rob Herring
-1 siblings, 0 replies; 26+ messages in thread
From: Rob Herring @ 2023-09-05 17:00 UTC (permalink / raw)
To: Billy Tsai
Cc: jdelvare, linux, krzysztof.kozlowski+dt, joel, andrew, corbet,
thierry.reding, u.kleine-koenig, p.zabel, naresh.solanki,
linux-hwmon, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, linux-doc, linux-pwm, BMC-SW, patrick
On Wed, Aug 30, 2023 at 08:32:00PM +0800, Billy Tsai wrote:
> From: Naresh Solanki <naresh.solanki@9elements.com>
>
> Add common fan properties bindings to a schema.
>
> Bindings for fan controllers can reference the common schema for the
> fan
>
> child nodes:
>
> patternProperties:
> "^fan@[0-2]":
> type: object
> $ref: fan-common.yaml#
unevaluatedProperties: false
>
> Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>
> Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
> ---
> .../devicetree/bindings/hwmon/fan-common.yaml | 63 +++++++++++++++++++
> 1 file changed, 63 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/fan-common.yaml
>
> diff --git a/Documentation/devicetree/bindings/hwmon/fan-common.yaml b/Documentation/devicetree/bindings/hwmon/fan-common.yaml
> new file mode 100644
> index 000000000000..a69b4d553e45
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/fan-common.yaml
> @@ -0,0 +1,63 @@
> +# SPDX-License-Identifier: GPL-2.0-or-later OR BSD-2-Clause
Drop 'or-later'. It's GPL2 only.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/hwmon/fan-common.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Common Fan Properties
> +
> +maintainers:
> + - Naresh Solanki <naresh.solanki@9elements.com>
> + - Billy Tsai <billy_tsai@aspeedtech.com>
> +
> +properties:
> + max-rpm:
> + description:
> + Max RPM supported by fan.
> + $ref: /schemas/types.yaml#/definitions/uint32
Physics will limit this to something much less than 2^32. Add some
constraints. 10000?
> +
> + min-rpm:
> + description:
> + Min RPM supported by fan.
> + $ref: /schemas/types.yaml#/definitions/uint32
ditto
> +
> + pulses-per-revolution:
> + description:
> + The number of pulse from fan sensor per revolution.
> + $ref: /schemas/types.yaml#/definitions/uint32
Needs constraints. I assume this is never more than 4 (or 2 even)?
> + div:
Too generic of a name.
> + description:
> + Fan clock divisor
But what is a fan clock?
> + $ref: /schemas/types.yaml#/definitions/uint32
> +
> + target-rpm:
> + description:
> + Target RPM the fan should be configured during driver probe.
What driver? By the time the OS driver runs, a bunch of other boot
software has already run on modern systems. So this value would likely
be used much earlier. The point is that when exactly is outside the
scope of DT. This is "what RPM do I use in case of no other information
(e.g. temperature)".
> + $ref: /schemas/types.yaml#/definitions/uint32
> +
> + mode:
Too generic.
> + description:
> + Select the operational mode of the fan.
What are modes? Spin and don't spin?
> + $ref: /schemas/types.yaml#/definitions/uint32
> +
> + pwms:
> + description:
> + PWM provider.
maxItems: 1
I don't think there are fans with more than 1 PWM input?
> +
> + tach-ch:
> + description:
> + The tach channel used for the fan.
> + $ref: /schemas/types.yaml#/definitions/uint32
The existing ASpeed version of this property allows more than 1 entry. I
don't understand how a fan would have 2 tach signals, but if so, the
generic property should allow for that.
Perhaps 'reg' should be defined in here with some text saying 'reg'
corresponds to the fan controller specific id which may be the PWM+TACH
channel, PWM channel (deprecated), or TACH channel. I think there are
examples of all 3 of these cases.
> +
> + label:
> + description:
> + Optional fan label
> +
> + fan-supply:
> + description:
> + Power supply for fan.
> +
> +additionalProperties: true
> +
> +...
> --
> 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] 26+ messages in thread
* Re: [PATCH v8 1/3] dt-bindings: hwmon: fan: Add fan binding to schema
@ 2023-09-05 17:00 ` Rob Herring
0 siblings, 0 replies; 26+ messages in thread
From: Rob Herring @ 2023-09-05 17:00 UTC (permalink / raw)
To: Billy Tsai
Cc: jdelvare, linux, krzysztof.kozlowski+dt, joel, andrew, corbet,
thierry.reding, u.kleine-koenig, p.zabel, naresh.solanki,
linux-hwmon, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, linux-doc, linux-pwm, BMC-SW, patrick
On Wed, Aug 30, 2023 at 08:32:00PM +0800, Billy Tsai wrote:
> From: Naresh Solanki <naresh.solanki@9elements.com>
>
> Add common fan properties bindings to a schema.
>
> Bindings for fan controllers can reference the common schema for the
> fan
>
> child nodes:
>
> patternProperties:
> "^fan@[0-2]":
> type: object
> $ref: fan-common.yaml#
unevaluatedProperties: false
>
> Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>
> Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
> ---
> .../devicetree/bindings/hwmon/fan-common.yaml | 63 +++++++++++++++++++
> 1 file changed, 63 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/fan-common.yaml
>
> diff --git a/Documentation/devicetree/bindings/hwmon/fan-common.yaml b/Documentation/devicetree/bindings/hwmon/fan-common.yaml
> new file mode 100644
> index 000000000000..a69b4d553e45
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/fan-common.yaml
> @@ -0,0 +1,63 @@
> +# SPDX-License-Identifier: GPL-2.0-or-later OR BSD-2-Clause
Drop 'or-later'. It's GPL2 only.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/hwmon/fan-common.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Common Fan Properties
> +
> +maintainers:
> + - Naresh Solanki <naresh.solanki@9elements.com>
> + - Billy Tsai <billy_tsai@aspeedtech.com>
> +
> +properties:
> + max-rpm:
> + description:
> + Max RPM supported by fan.
> + $ref: /schemas/types.yaml#/definitions/uint32
Physics will limit this to something much less than 2^32. Add some
constraints. 10000?
> +
> + min-rpm:
> + description:
> + Min RPM supported by fan.
> + $ref: /schemas/types.yaml#/definitions/uint32
ditto
> +
> + pulses-per-revolution:
> + description:
> + The number of pulse from fan sensor per revolution.
> + $ref: /schemas/types.yaml#/definitions/uint32
Needs constraints. I assume this is never more than 4 (or 2 even)?
> + div:
Too generic of a name.
> + description:
> + Fan clock divisor
But what is a fan clock?
> + $ref: /schemas/types.yaml#/definitions/uint32
> +
> + target-rpm:
> + description:
> + Target RPM the fan should be configured during driver probe.
What driver? By the time the OS driver runs, a bunch of other boot
software has already run on modern systems. So this value would likely
be used much earlier. The point is that when exactly is outside the
scope of DT. This is "what RPM do I use in case of no other information
(e.g. temperature)".
> + $ref: /schemas/types.yaml#/definitions/uint32
> +
> + mode:
Too generic.
> + description:
> + Select the operational mode of the fan.
What are modes? Spin and don't spin?
> + $ref: /schemas/types.yaml#/definitions/uint32
> +
> + pwms:
> + description:
> + PWM provider.
maxItems: 1
I don't think there are fans with more than 1 PWM input?
> +
> + tach-ch:
> + description:
> + The tach channel used for the fan.
> + $ref: /schemas/types.yaml#/definitions/uint32
The existing ASpeed version of this property allows more than 1 entry. I
don't understand how a fan would have 2 tach signals, but if so, the
generic property should allow for that.
Perhaps 'reg' should be defined in here with some text saying 'reg'
corresponds to the fan controller specific id which may be the PWM+TACH
channel, PWM channel (deprecated), or TACH channel. I think there are
examples of all 3 of these cases.
> +
> + label:
> + description:
> + Optional fan label
> +
> + fan-supply:
> + description:
> + Power supply for fan.
> +
> +additionalProperties: true
> +
> +...
> --
> 2.25.1
>
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v8 2/3] dt-bindings: hwmon: Support Aspeed g6 PWM TACH Control
2023-08-30 12:32 ` Billy Tsai
@ 2023-09-05 17:07 ` Rob Herring
-1 siblings, 0 replies; 26+ messages in thread
From: Rob Herring @ 2023-09-05 17:07 UTC (permalink / raw)
To: Billy Tsai
Cc: jdelvare, linux, krzysztof.kozlowski+dt, joel, andrew, corbet,
thierry.reding, u.kleine-koenig, p.zabel, naresh.solanki,
linux-hwmon, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, linux-doc, linux-pwm, BMC-SW, patrick
On Wed, Aug 30, 2023 at 08:32:01PM +0800, Billy Tsai wrote:
> Document the compatible for aspeed,ast2600-pwm-tach device, which can
> support up to 16 PWM outputs and 16 fan tach input.
>
> Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
> ---
> .../bindings/hwmon/aspeed,g6-pwm-tach.yaml | 67 +++++++++++++++++++
> 1 file changed, 67 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/aspeed,g6-pwm-tach.yaml
>
> diff --git a/Documentation/devicetree/bindings/hwmon/aspeed,g6-pwm-tach.yaml b/Documentation/devicetree/bindings/hwmon/aspeed,g6-pwm-tach.yaml
> new file mode 100644
> index 000000000000..95bac5588c04
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/aspeed,g6-pwm-tach.yaml
> @@ -0,0 +1,67 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (C) 2021 Aspeed, Inc.
A few years out of date.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/hwmon/aspeed,g6-pwm-tach.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ASPEED G6 PWM and Fan Tach controller device driver
> +
> +maintainers:
> + - Billy Tsai <billy_tsai@aspeedtech.com>
> +
> +description: |
> + The ASPEED PWM controller can support up to 16 PWM outputs.
> + The ASPEED Fan Tacho controller can support up to 16 fan tach input.
Are PWM and tach channels independent? Would be useful to know here.
> +
> +properties:
> + compatible:
> + enum:
> + - aspeed,ast2600-pwm-tach
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> + resets:
> + maxItems: 1
> +
> + "#pwm-cells":
> + const: 3
> +
> +patternProperties:
> + "^fan[0-9a-f]_hwmon+$":
Drop 'hwmon'. Standard practice for naming without 'reg' is
'^fan-[0-9]+$'.
> + $ref: fan-common.yaml#
unevaluatedProperties: false
> + required:
> + - tach-ch
> +
> +required:
> + - reg
> + - clocks
> + - resets
> + - "#pwm-cells"
> + - compatible
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/aspeed-clock.h>
> + pwm_tach: pwm-tach-controller@1e610000 {
> + compatible = "aspeed,ast2600-pwm-tach";
> + reg = <0x1e610000 0x100>;
> + clocks = <&syscon ASPEED_CLK_AHB>;
> + resets = <&syscon ASPEED_RESET_PWM>;
> + #pwm-cells = <3>;
Blank line.
> + fan0_hwmon {
> + tach-ch = <0x0>;
Don't you need 'pwms'?
> + };
Blank line.
> + fan1_hwmon {
> + tach-ch = <0x1>;
> + };
> + fan2_hwmon {
> + tach-ch = <0x2>;
> + };
> + };
> --
> 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] 26+ messages in thread
* Re: [PATCH v8 2/3] dt-bindings: hwmon: Support Aspeed g6 PWM TACH Control
@ 2023-09-05 17:07 ` Rob Herring
0 siblings, 0 replies; 26+ messages in thread
From: Rob Herring @ 2023-09-05 17:07 UTC (permalink / raw)
To: Billy Tsai
Cc: jdelvare, linux, krzysztof.kozlowski+dt, joel, andrew, corbet,
thierry.reding, u.kleine-koenig, p.zabel, naresh.solanki,
linux-hwmon, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, linux-doc, linux-pwm, BMC-SW, patrick
On Wed, Aug 30, 2023 at 08:32:01PM +0800, Billy Tsai wrote:
> Document the compatible for aspeed,ast2600-pwm-tach device, which can
> support up to 16 PWM outputs and 16 fan tach input.
>
> Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
> ---
> .../bindings/hwmon/aspeed,g6-pwm-tach.yaml | 67 +++++++++++++++++++
> 1 file changed, 67 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/aspeed,g6-pwm-tach.yaml
>
> diff --git a/Documentation/devicetree/bindings/hwmon/aspeed,g6-pwm-tach.yaml b/Documentation/devicetree/bindings/hwmon/aspeed,g6-pwm-tach.yaml
> new file mode 100644
> index 000000000000..95bac5588c04
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/aspeed,g6-pwm-tach.yaml
> @@ -0,0 +1,67 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (C) 2021 Aspeed, Inc.
A few years out of date.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/hwmon/aspeed,g6-pwm-tach.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ASPEED G6 PWM and Fan Tach controller device driver
> +
> +maintainers:
> + - Billy Tsai <billy_tsai@aspeedtech.com>
> +
> +description: |
> + The ASPEED PWM controller can support up to 16 PWM outputs.
> + The ASPEED Fan Tacho controller can support up to 16 fan tach input.
Are PWM and tach channels independent? Would be useful to know here.
> +
> +properties:
> + compatible:
> + enum:
> + - aspeed,ast2600-pwm-tach
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> + resets:
> + maxItems: 1
> +
> + "#pwm-cells":
> + const: 3
> +
> +patternProperties:
> + "^fan[0-9a-f]_hwmon+$":
Drop 'hwmon'. Standard practice for naming without 'reg' is
'^fan-[0-9]+$'.
> + $ref: fan-common.yaml#
unevaluatedProperties: false
> + required:
> + - tach-ch
> +
> +required:
> + - reg
> + - clocks
> + - resets
> + - "#pwm-cells"
> + - compatible
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/aspeed-clock.h>
> + pwm_tach: pwm-tach-controller@1e610000 {
> + compatible = "aspeed,ast2600-pwm-tach";
> + reg = <0x1e610000 0x100>;
> + clocks = <&syscon ASPEED_CLK_AHB>;
> + resets = <&syscon ASPEED_RESET_PWM>;
> + #pwm-cells = <3>;
Blank line.
> + fan0_hwmon {
> + tach-ch = <0x0>;
Don't you need 'pwms'?
> + };
Blank line.
> + fan1_hwmon {
> + tach-ch = <0x1>;
> + };
> + fan2_hwmon {
> + tach-ch = <0x2>;
> + };
> + };
> --
> 2.25.1
>
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v8 1/3] dt-bindings: hwmon: fan: Add fan binding to schema
2023-09-05 17:00 ` Rob Herring
@ 2023-09-07 7:17 ` Billy Tsai
-1 siblings, 0 replies; 26+ messages in thread
From: Billy Tsai @ 2023-09-07 7:17 UTC (permalink / raw)
To: Rob Herring
Cc: jdelvare, linux, krzysztof.kozlowski+dt, joel, andrew, corbet,
thierry.reding, u.kleine-koenig, p.zabel, naresh.solanki,
linux-hwmon, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, linux-doc, linux-pwm, BMC-SW, patrick
On Wed, Aug 30, 2023 at 08:32:00PM +0800, Billy Tsai wrote:
>> From: Naresh Solanki <naresh.solanki@9elements.com>
>>
>> Add common fan properties bindings to a schema.
>>
>> Bindings for fan controllers can reference the common schema for the
>> fan
>>
>> child nodes:
>>
>> patternProperties:
>> "^fan@[0-2]":
>> type: object
>> $ref: fan-common.yaml#
> unevaluatedProperties: false
OK, I will add this.
>>
>> Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>
>> Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
>> ---
>> .../devicetree/bindings/hwmon/fan-common.yaml | 63 +++++++++++++++++++
>> 1 file changed, 63 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/hwmon/fan-common.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/hwmon/fan-common.yaml b/Documentation/devicetree/bindings/>hwmon/fan-common.yaml
>> new file mode 100644
>> index 000000000000..a69b4d553e45
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/hwmon/fan-common.yaml
>> @@ -0,0 +1,63 @@
>> +# SPDX-License-Identifier: GPL-2.0-or-later OR BSD-2-Clause
> Drop 'or-later'. It's GPL2 only.
OK, I will fix it.
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/hwmon/fan-common.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Common Fan Properties
>> +
>> +maintainers:
>> + - Naresh Solanki <naresh.solanki@9elements.com>
>> + - Billy Tsai <billy_tsai@aspeedtech.com>
>> +
>> +properties:
>> + max-rpm:
>> + description:
>> + Max RPM supported by fan.
>> + $ref: /schemas/types.yaml#/definitions/uint32
> Physics will limit this to something much less than 2^32. Add some
> constraints. 10000?
>> +
>> + min-rpm:
>> + description:
>> + Min RPM supported by fan.
>> + $ref: /schemas/types.yaml#/definitions/uint32
> ditto
>> +
>> + pulses-per-revolution:
>> + description:
>> + The number of pulse from fan sensor per revolution.
>> + $ref: /schemas/types.yaml#/definitions/uint32
>Needs constraints. I assume this is never more than 4 (or 2 even)?
Do you think we should add the contraint in the common binding?
In my option, the limit of the max/min rpm should be declared by
the binding if necessary, because the usage of each fan monitor is
based on the connection of the tach pin.
>> + div:
> Too generic of a name.
>> + description:
>> + Fan clock divisor
> But what is a fan clock?
This is the divisor for the tachometer sampling clock, which determines the sensitivity of the tach pin.
So, if the name of the property changes to 'tach-div,' is it acceptable to you?
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> +
>> + target-rpm:
>> + description:
>> + Target RPM the fan should be configured during driver probe.
> What driver? By the time the OS driver runs, a bunch of other boot
> software has already run on modern systems. So this value would likely
> be used much earlier. The point is that when exactly is outside the
> scope of DT. This is "what RPM do I use in case of no other information
> (e.g. temperature)".
So, the description should be changed to 'The default desired fan speed in RPM,'
and we shouldn't mention the timing of the property's operation in the DT, is that correct?
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> +
>> + mode:
> Too generic.
>> + description:
>> + Select the operational mode of the fan.
> What are modes? Spin and don't spin?
The mode is used to indicate the driving mode of the fan (DC, PWM and so on).
So, if the name of the property changes to 'fan-driving-mode,' is it acceptable to you?
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> +
>> + pwms:
>> + description:
>> + PWM provider.
> maxItems: 1
> I don't think there are fans with more than 1 PWM input?
Ok, I will add the constraint for the pwm input.
>> +
>> + tach-ch:
>> + description:
>> + The tach channel used for the fan.
>> + $ref: /schemas/types.yaml#/definitions/uint32
> The existing ASpeed version of this property allows more than 1 entry. I
> don't understand how a fan would have 2 tach signals, but if so, the
> generic property should allow for that.
Ok, I will modify it to the uint32-array
> Perhaps 'reg' should be defined in here with some text saying 'reg'
> corresponds to the fan controller specific id which may be the PWM+TACH
> channel, PWM channel (deprecated), or TACH channel. I think there are
> examples of all 3 of these cases.
I don't think it's necessary for the 'reg' because the case you mentioned is
already covered by the property 'tach-ch' and the 'pwms'.
> +
> + label:
> + description:
> + Optional fan label
> +
> + fan-supply:
> + description:
> + Power supply for fan.
> +
> +additionalProperties: true
> +
> +...
> --
> 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] 26+ messages in thread
* Re: [PATCH v8 1/3] dt-bindings: hwmon: fan: Add fan binding to schema
@ 2023-09-07 7:17 ` Billy Tsai
0 siblings, 0 replies; 26+ messages in thread
From: Billy Tsai @ 2023-09-07 7:17 UTC (permalink / raw)
To: Rob Herring
Cc: jdelvare, linux, krzysztof.kozlowski+dt, joel, andrew, corbet,
thierry.reding, u.kleine-koenig, p.zabel, naresh.solanki,
linux-hwmon, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, linux-doc, linux-pwm, BMC-SW, patrick
On Wed, Aug 30, 2023 at 08:32:00PM +0800, Billy Tsai wrote:
>> From: Naresh Solanki <naresh.solanki@9elements.com>
>>
>> Add common fan properties bindings to a schema.
>>
>> Bindings for fan controllers can reference the common schema for the
>> fan
>>
>> child nodes:
>>
>> patternProperties:
>> "^fan@[0-2]":
>> type: object
>> $ref: fan-common.yaml#
> unevaluatedProperties: false
OK, I will add this.
>>
>> Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>
>> Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
>> ---
>> .../devicetree/bindings/hwmon/fan-common.yaml | 63 +++++++++++++++++++
>> 1 file changed, 63 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/hwmon/fan-common.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/hwmon/fan-common.yaml b/Documentation/devicetree/bindings/>hwmon/fan-common.yaml
>> new file mode 100644
>> index 000000000000..a69b4d553e45
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/hwmon/fan-common.yaml
>> @@ -0,0 +1,63 @@
>> +# SPDX-License-Identifier: GPL-2.0-or-later OR BSD-2-Clause
> Drop 'or-later'. It's GPL2 only.
OK, I will fix it.
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/hwmon/fan-common.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Common Fan Properties
>> +
>> +maintainers:
>> + - Naresh Solanki <naresh.solanki@9elements.com>
>> + - Billy Tsai <billy_tsai@aspeedtech.com>
>> +
>> +properties:
>> + max-rpm:
>> + description:
>> + Max RPM supported by fan.
>> + $ref: /schemas/types.yaml#/definitions/uint32
> Physics will limit this to something much less than 2^32. Add some
> constraints. 10000?
>> +
>> + min-rpm:
>> + description:
>> + Min RPM supported by fan.
>> + $ref: /schemas/types.yaml#/definitions/uint32
> ditto
>> +
>> + pulses-per-revolution:
>> + description:
>> + The number of pulse from fan sensor per revolution.
>> + $ref: /schemas/types.yaml#/definitions/uint32
>Needs constraints. I assume this is never more than 4 (or 2 even)?
Do you think we should add the contraint in the common binding?
In my option, the limit of the max/min rpm should be declared by
the binding if necessary, because the usage of each fan monitor is
based on the connection of the tach pin.
>> + div:
> Too generic of a name.
>> + description:
>> + Fan clock divisor
> But what is a fan clock?
This is the divisor for the tachometer sampling clock, which determines the sensitivity of the tach pin.
So, if the name of the property changes to 'tach-div,' is it acceptable to you?
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> +
>> + target-rpm:
>> + description:
>> + Target RPM the fan should be configured during driver probe.
> What driver? By the time the OS driver runs, a bunch of other boot
> software has already run on modern systems. So this value would likely
> be used much earlier. The point is that when exactly is outside the
> scope of DT. This is "what RPM do I use in case of no other information
> (e.g. temperature)".
So, the description should be changed to 'The default desired fan speed in RPM,'
and we shouldn't mention the timing of the property's operation in the DT, is that correct?
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> +
>> + mode:
> Too generic.
>> + description:
>> + Select the operational mode of the fan.
> What are modes? Spin and don't spin?
The mode is used to indicate the driving mode of the fan (DC, PWM and so on).
So, if the name of the property changes to 'fan-driving-mode,' is it acceptable to you?
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> +
>> + pwms:
>> + description:
>> + PWM provider.
> maxItems: 1
> I don't think there are fans with more than 1 PWM input?
Ok, I will add the constraint for the pwm input.
>> +
>> + tach-ch:
>> + description:
>> + The tach channel used for the fan.
>> + $ref: /schemas/types.yaml#/definitions/uint32
> The existing ASpeed version of this property allows more than 1 entry. I
> don't understand how a fan would have 2 tach signals, but if so, the
> generic property should allow for that.
Ok, I will modify it to the uint32-array
> Perhaps 'reg' should be defined in here with some text saying 'reg'
> corresponds to the fan controller specific id which may be the PWM+TACH
> channel, PWM channel (deprecated), or TACH channel. I think there are
> examples of all 3 of these cases.
I don't think it's necessary for the 'reg' because the case you mentioned is
already covered by the property 'tach-ch' and the 'pwms'.
> +
> + label:
> + description:
> + Optional fan label
> +
> + fan-supply:
> + description:
> + Power supply for fan.
> +
> +additionalProperties: true
> +
> +...
> --
> 2.25.1
>
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v8 2/3] dt-bindings: hwmon: Support Aspeed g6 PWM TACH Control
2023-09-05 17:07 ` Rob Herring
@ 2023-09-07 7:24 ` Billy Tsai
-1 siblings, 0 replies; 26+ messages in thread
From: Billy Tsai @ 2023-09-07 7:24 UTC (permalink / raw)
To: Rob Herring
Cc: jdelvare, linux, krzysztof.kozlowski+dt, joel, andrew, corbet,
thierry.reding, u.kleine-koenig, p.zabel, naresh.solanki,
linux-hwmon, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, linux-doc, linux-pwm, BMC-SW, patrick
>> +
>> +examples:
>> + - |
>> + #include <dt-bindings/clock/aspeed-clock.h>
>> + pwm_tach: pwm-tach-controller@1e610000 {
>> + compatible = "aspeed,ast2600-pwm-tach";
>> + reg = <0x1e610000 0x100>;
>> + clocks = <&syscon ASPEED_CLK_AHB>;
>> + resets = <&syscon ASPEED_RESET_PWM>;
>> + #pwm-cells = <3>;
> Blank line.
>> + fan0_hwmon {
>> + tach-ch = <0x0>;
> Don't you need 'pwms'?
Yes, I only want to create the fan monitor without fan control.
> + };
_______________________________________________
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] 26+ messages in thread
* Re: [PATCH v8 2/3] dt-bindings: hwmon: Support Aspeed g6 PWM TACH Control
@ 2023-09-07 7:24 ` Billy Tsai
0 siblings, 0 replies; 26+ messages in thread
From: Billy Tsai @ 2023-09-07 7:24 UTC (permalink / raw)
To: Rob Herring
Cc: jdelvare, linux, krzysztof.kozlowski+dt, joel, andrew, corbet,
thierry.reding, u.kleine-koenig, p.zabel, naresh.solanki,
linux-hwmon, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, linux-doc, linux-pwm, BMC-SW, patrick
>> +
>> +examples:
>> + - |
>> + #include <dt-bindings/clock/aspeed-clock.h>
>> + pwm_tach: pwm-tach-controller@1e610000 {
>> + compatible = "aspeed,ast2600-pwm-tach";
>> + reg = <0x1e610000 0x100>;
>> + clocks = <&syscon ASPEED_CLK_AHB>;
>> + resets = <&syscon ASPEED_RESET_PWM>;
>> + #pwm-cells = <3>;
> Blank line.
>> + fan0_hwmon {
>> + tach-ch = <0x0>;
> Don't you need 'pwms'?
Yes, I only want to create the fan monitor without fan control.
> + };
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v8 1/3] dt-bindings: hwmon: fan: Add fan binding to schema
2023-09-07 7:17 ` Billy Tsai
@ 2023-09-07 19:43 ` Rob Herring
-1 siblings, 0 replies; 26+ messages in thread
From: Rob Herring @ 2023-09-07 19:43 UTC (permalink / raw)
To: Billy Tsai
Cc: jdelvare, linux, krzysztof.kozlowski+dt, joel, andrew, corbet,
thierry.reding, u.kleine-koenig, p.zabel, naresh.solanki,
linux-hwmon, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, linux-doc, linux-pwm, BMC-SW, patrick
On Thu, Sep 07, 2023 at 07:17:55AM +0000, Billy Tsai wrote:
> On Wed, Aug 30, 2023 at 08:32:00PM +0800, Billy Tsai wrote:
> >> From: Naresh Solanki <naresh.solanki@9elements.com>
> >>
> >> Add common fan properties bindings to a schema.
> >>
> >> Bindings for fan controllers can reference the common schema for the
> >> fan
> >> +properties:
> >> + max-rpm:
> >> + description:
> >> + Max RPM supported by fan.
> >> + $ref: /schemas/types.yaml#/definitions/uint32
>
> > Physics will limit this to something much less than 2^32. Add some
> > constraints. 10000?
>
>
> >> +
> >> + min-rpm:
> >> + description:
> >> + Min RPM supported by fan.
> >> + $ref: /schemas/types.yaml#/definitions/uint32
>
> > ditto
>
> >> +
> >> + pulses-per-revolution:
> >> + description:
> >> + The number of pulse from fan sensor per revolution.
> >> + $ref: /schemas/types.yaml#/definitions/uint32
>
> >Needs constraints. I assume this is never more than 4 (or 2 even)?
>
> Do you think we should add the contraint in the common binding?
> In my option, the limit of the max/min rpm should be declared by
> the binding if necessary, because the usage of each fan monitor is
> based on the connection of the tach pin.
Yes, I think we should have default limits.
Unless we go as far as a schema for every specific fan model, then there
is actually no way we can have specific limits unless the fan
controllers have some limits.
The most I see in tree for pulses-per-revolution is 2. There's no value
in more. So set the max to 4 and then if anyone needs more they can bump
the value.
Or maybe there's some electrical/mechanical design reason fans are 1 or
2 pulses and we'll never see anything else? This document[1] seems to
indicate that is indeed the case. (First hit googling "fan tach signal
pulses")
>
>
> >> + div:
>
> > Too generic of a name.
>
> >> + description:
> >> + Fan clock divisor
>
> > But what is a fan clock?
>
> This is the divisor for the tachometer sampling clock, which determines the sensitivity of the tach pin.
> So, if the name of the property changes to 'tach-div,' is it acceptable to you?
That sounds like a property of the controller, not the fan, so it
belongs in the controller binding. Is this really a common thing?
> >> + $ref: /schemas/types.yaml#/definitions/uint32
> >> +
> >> + target-rpm:
> >> + description:
> >> + Target RPM the fan should be configured during driver probe.
>
> > What driver? By the time the OS driver runs, a bunch of other boot
> > software has already run on modern systems. So this value would likely
> > be used much earlier. The point is that when exactly is outside the
> > scope of DT. This is "what RPM do I use in case of no other information
> > (e.g. temperature)".
>
> So, the description should be changed to 'The default desired fan speed in RPM,'
> and we shouldn't mention the timing of the property's operation in the DT, is that correct?
Correct.
>
> >> + $ref: /schemas/types.yaml#/definitions/uint32
> >> +
> >> + mode:
>
> > Too generic.
>
> >> + description:
> >> + Select the operational mode of the fan.
>
> > What are modes? Spin and don't spin?
>
> The mode is used to indicate the driving mode of the fan (DC, PWM and so on).
> So, if the name of the property changes to 'fan-driving-mode,' is it acceptable to you?
I tend to think that should be implied from the parent node and/or other
properties. PWM if "pwms" property is present. DC if the supply is
variable. We could also use compatible strings in the fan nodes if
there's a need.
That reminds me, both of these modes probably need a table of
voltage/duty-cycle to RPMs. I imagine it's not always a linear response.
Naresh also privately sent me (don't do that) an updated common binding
which we discussed the need for this. I expect him to comment further
with details.
> >> + $ref: /schemas/types.yaml#/definitions/uint32
> >> +
> >> + pwms:
> >> + description:
> >> + PWM provider.
>
> > maxItems: 1
>
> > I don't think there are fans with more than 1 PWM input?
>
> Ok, I will add the constraint for the pwm input.
>
> >> +
> >> + tach-ch:
> >> + description:
> >> + The tach channel used for the fan.
> >> + $ref: /schemas/types.yaml#/definitions/uint32
>
> > The existing ASpeed version of this property allows more than 1 entry. I
> > don't understand how a fan would have 2 tach signals, but if so, the
> > generic property should allow for that.
>
> Ok, I will modify it to the uint32-array
Perhaps uint8-array to align with existing versions of the property.
>
> > Perhaps 'reg' should be defined in here with some text saying 'reg'
> > corresponds to the fan controller specific id which may be the PWM+TACH
> > channel, PWM channel (deprecated), or TACH channel. I think there are
> > examples of all 3 of these cases.
>
> I don't think it's necessary for the 'reg' because the case you mentioned is
> already covered by the property 'tach-ch' and the 'pwms'.
Yes, but when we have N child nodes of the same thing, we usually have
"reg" and its value corresponds to how the parent identifies each child.
We already have a mixture using PWM or tach channel. Yes, this can all
just be in the fan controllers binding, but putting it here would just
document the options.
Rob
[1] http://www.comairrotron.com/methods-monitoring-fan-performance
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v8 1/3] dt-bindings: hwmon: fan: Add fan binding to schema
@ 2023-09-07 19:43 ` Rob Herring
0 siblings, 0 replies; 26+ messages in thread
From: Rob Herring @ 2023-09-07 19:43 UTC (permalink / raw)
To: Billy Tsai
Cc: jdelvare, linux, krzysztof.kozlowski+dt, joel, andrew, corbet,
thierry.reding, u.kleine-koenig, p.zabel, naresh.solanki,
linux-hwmon, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, linux-doc, linux-pwm, BMC-SW, patrick
On Thu, Sep 07, 2023 at 07:17:55AM +0000, Billy Tsai wrote:
> On Wed, Aug 30, 2023 at 08:32:00PM +0800, Billy Tsai wrote:
> >> From: Naresh Solanki <naresh.solanki@9elements.com>
> >>
> >> Add common fan properties bindings to a schema.
> >>
> >> Bindings for fan controllers can reference the common schema for the
> >> fan
> >> +properties:
> >> + max-rpm:
> >> + description:
> >> + Max RPM supported by fan.
> >> + $ref: /schemas/types.yaml#/definitions/uint32
>
> > Physics will limit this to something much less than 2^32. Add some
> > constraints. 10000?
>
>
> >> +
> >> + min-rpm:
> >> + description:
> >> + Min RPM supported by fan.
> >> + $ref: /schemas/types.yaml#/definitions/uint32
>
> > ditto
>
> >> +
> >> + pulses-per-revolution:
> >> + description:
> >> + The number of pulse from fan sensor per revolution.
> >> + $ref: /schemas/types.yaml#/definitions/uint32
>
> >Needs constraints. I assume this is never more than 4 (or 2 even)?
>
> Do you think we should add the contraint in the common binding?
> In my option, the limit of the max/min rpm should be declared by
> the binding if necessary, because the usage of each fan monitor is
> based on the connection of the tach pin.
Yes, I think we should have default limits.
Unless we go as far as a schema for every specific fan model, then there
is actually no way we can have specific limits unless the fan
controllers have some limits.
The most I see in tree for pulses-per-revolution is 2. There's no value
in more. So set the max to 4 and then if anyone needs more they can bump
the value.
Or maybe there's some electrical/mechanical design reason fans are 1 or
2 pulses and we'll never see anything else? This document[1] seems to
indicate that is indeed the case. (First hit googling "fan tach signal
pulses")
>
>
> >> + div:
>
> > Too generic of a name.
>
> >> + description:
> >> + Fan clock divisor
>
> > But what is a fan clock?
>
> This is the divisor for the tachometer sampling clock, which determines the sensitivity of the tach pin.
> So, if the name of the property changes to 'tach-div,' is it acceptable to you?
That sounds like a property of the controller, not the fan, so it
belongs in the controller binding. Is this really a common thing?
> >> + $ref: /schemas/types.yaml#/definitions/uint32
> >> +
> >> + target-rpm:
> >> + description:
> >> + Target RPM the fan should be configured during driver probe.
>
> > What driver? By the time the OS driver runs, a bunch of other boot
> > software has already run on modern systems. So this value would likely
> > be used much earlier. The point is that when exactly is outside the
> > scope of DT. This is "what RPM do I use in case of no other information
> > (e.g. temperature)".
>
> So, the description should be changed to 'The default desired fan speed in RPM,'
> and we shouldn't mention the timing of the property's operation in the DT, is that correct?
Correct.
>
> >> + $ref: /schemas/types.yaml#/definitions/uint32
> >> +
> >> + mode:
>
> > Too generic.
>
> >> + description:
> >> + Select the operational mode of the fan.
>
> > What are modes? Spin and don't spin?
>
> The mode is used to indicate the driving mode of the fan (DC, PWM and so on).
> So, if the name of the property changes to 'fan-driving-mode,' is it acceptable to you?
I tend to think that should be implied from the parent node and/or other
properties. PWM if "pwms" property is present. DC if the supply is
variable. We could also use compatible strings in the fan nodes if
there's a need.
That reminds me, both of these modes probably need a table of
voltage/duty-cycle to RPMs. I imagine it's not always a linear response.
Naresh also privately sent me (don't do that) an updated common binding
which we discussed the need for this. I expect him to comment further
with details.
> >> + $ref: /schemas/types.yaml#/definitions/uint32
> >> +
> >> + pwms:
> >> + description:
> >> + PWM provider.
>
> > maxItems: 1
>
> > I don't think there are fans with more than 1 PWM input?
>
> Ok, I will add the constraint for the pwm input.
>
> >> +
> >> + tach-ch:
> >> + description:
> >> + The tach channel used for the fan.
> >> + $ref: /schemas/types.yaml#/definitions/uint32
>
> > The existing ASpeed version of this property allows more than 1 entry. I
> > don't understand how a fan would have 2 tach signals, but if so, the
> > generic property should allow for that.
>
> Ok, I will modify it to the uint32-array
Perhaps uint8-array to align with existing versions of the property.
>
> > Perhaps 'reg' should be defined in here with some text saying 'reg'
> > corresponds to the fan controller specific id which may be the PWM+TACH
> > channel, PWM channel (deprecated), or TACH channel. I think there are
> > examples of all 3 of these cases.
>
> I don't think it's necessary for the 'reg' because the case you mentioned is
> already covered by the property 'tach-ch' and the 'pwms'.
Yes, but when we have N child nodes of the same thing, we usually have
"reg" and its value corresponds to how the parent identifies each child.
We already have a mixture using PWM or tach channel. Yes, this can all
just be in the fan controllers binding, but putting it here would just
document the options.
Rob
[1] http://www.comairrotron.com/methods-monitoring-fan-performance
_______________________________________________
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] 26+ messages in thread
* Re: [PATCH v8 1/3] dt-bindings: hwmon: fan: Add fan binding to schema
2023-09-07 19:43 ` Rob Herring
@ 2023-09-08 8:49 ` Billy Tsai
-1 siblings, 0 replies; 26+ messages in thread
From: Billy Tsai @ 2023-09-08 8:49 UTC (permalink / raw)
To: Rob Herring
Cc: jdelvare, linux, krzysztof.kozlowski+dt, joel, andrew, corbet,
thierry.reding, u.kleine-koenig, p.zabel, naresh.solanki,
linux-hwmon, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, linux-doc, linux-pwm, BMC-SW, patrick
On Thu, Sep 07, 2023 at 07:17:55AM +0000, Billy Tsai wrote:
> > On Wed, Aug 30, 2023 at 08:32:00PM +0800, Billy Tsai wrote:
> > >> From: Naresh Solanki <naresh.solanki@9elements.com>
> > >>
> > >> Add common fan properties bindings to a schema.
> > >>
> > >> Bindings for fan controllers can reference the common schema for the
> > >> fan
> > >> +properties:
> > >> + max-rpm:
> > >> + description:
> > >> + Max RPM supported by fan.
> > >> + $ref: /schemas/types.yaml#/definitions/uint32
> >
> > > Physics will limit this to something much less than 2^32. Add some
> > > constraints. 10000?
> >
> >
> > >> +
> > >> + min-rpm:
> > >> + description:
> > >> + Min RPM supported by fan.
> > >> + $ref: /schemas/types.yaml#/definitions/uint32
> >
> > > ditto
> >
> > >> +
> > >> + pulses-per-revolution:
> > >> + description:
> > >> + The number of pulse from fan sensor per revolution.
> > >> + $ref: /schemas/types.yaml#/definitions/uint32
> >
> > >Needs constraints. I assume this is never more than 4 (or 2 even)?
> >
> > Do you think we should add the contraint in the common binding?
> > In my option, the limit of the max/min rpm should be declared by
> > the binding if necessary, because the usage of each fan monitor is
> > based on the connection of the tach pin.
> Yes, I think we should have default limits.
> Unless we go as far as a schema for every specific fan model, then there
> is actually no way we can have specific limits unless the fan
> controllers have some limits.
> The most I see in tree for pulses-per-revolution is 2. There's no value
> in more. So set the max to 4 and then if anyone needs more they can bump
> the value.
> Or maybe there's some electrical/mechanical design reason fans are 1 or
> 2 pulses and we'll never see anything else? This document[1] seems to
> indicate that is indeed the case. (First hit googling "fan tach signal
> pulses")
OK, I will add the maximum value for the max-rpm, min-rpm and pulses-per-revolution.
> >
> >
> > >> + div:
> >
> > > Too generic of a name.
> >
> > >> + description:
> > >> + Fan clock divisor
> >
> > > But what is a fan clock?
> >
> > This is the divisor for the tachometer sampling clock, which determines the sensitivity of the tach pin.
> > So, if the name of the property changes to 'tach-div,' is it acceptable to you?
> That sounds like a property of the controller, not the fan, so it
> belongs in the controller binding. Is this really a common thing?
Yes, I believe this is a common feature for fans. You can refer to the Documentation/hwmon/sysfs-interface.rst,
where the fan divisor is defined for users, determining the fan's sensitivity.
> > >> + $ref: /schemas/types.yaml#/definitions/uint32
> > >> +
> > >> + target-rpm:
> > >> + description:
> > >> + Target RPM the fan should be configured during driver probe.
> >
> > > What driver? By the time the OS driver runs, a bunch of other boot
> > > software has already run on modern systems. So this value would likely
> > > be used much earlier. The point is that when exactly is outside the
> > > scope of DT. This is "what RPM do I use in case of no other information
> > > (e.g. temperature)".
> >
> > So, the description should be changed to 'The default desired fan speed in RPM,'
> > and we shouldn't mention the timing of the property's operation in the DT, is that correct?
> Correct.
> >
> > >> + $ref: /schemas/types.yaml#/definitions/uint32
> > >> +
> > >> + mode:
> >
> > > Too generic.
> >
> > >> + description:
> > >> + Select the operational mode of the fan.
> >
> > > What are modes? Spin and don't spin?
> >
> > The mode is used to indicate the driving mode of the fan (DC, PWM and so on).
> > So, if the name of the property changes to 'fan-driving-mode,' is it acceptable to you?
> I tend to think that should be implied from the parent node and/or other
> properties. PWM if "pwms" property is present. DC if the supply is
> variable. We could also use compatible strings in the fan nodes if
> there's a need.
So, it looks that this property isn't necessary for the fan. And it should be determined by the
present of the driving source. is that correct?
> That reminds me, both of these modes probably need a table of
> voltage/duty-cycle to RPMs. I imagine it's not always a linear response.
> Naresh also privately sent me (don't do that) an updated common binding
> which we discussed the need for this. I expect him to comment further
> with details.
For this purpose, we should add the speed-map like the usage of the gpio-fan, right?
https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/hwmon/gpio-fan.txt
> > >> + $ref: /schemas/types.yaml#/definitions/uint32
> > >> +
> > >> + pwms:
> > >> + description:
> > >> + PWM provider.
> >
> > > maxItems: 1
> >
> > > I don't think there are fans with more than 1 PWM input?
> >
> > Ok, I will add the constraint for the pwm input.
> >
> > >> +
> > >> + tach-ch:
> > >> + description:
> > >> + The tach channel used for the fan.
> > >> + $ref: /schemas/types.yaml#/definitions/uint32
> >
> > > The existing ASpeed version of this property allows more than 1 entry. I
> > > don't understand how a fan would have 2 tach signals, but if so, the
> > > generic property should allow for that.
> >
> > Ok, I will modify it to the uint32-array
> Perhaps uint8-array to align with existing versions of the property.
Ok, I will modify it to the uint8-array.
> >
> > > Perhaps 'reg' should be defined in here with some text saying 'reg'
> > > corresponds to the fan controller specific id which may be the PWM+TACH
> > > channel, PWM channel (deprecated), or TACH channel. I think there are
> > > examples of all 3 of these cases.
> >
> > I don't think it's necessary for the 'reg' because the case you mentioned is
> > already covered by the property 'tach-ch' and the 'pwms'.
> Yes, but when we have N child nodes of the same thing, we usually have
> "reg" and its value corresponds to how the parent identifies each child.
> We already have a mixture using PWM or tach channel. Yes, this can all
> just be in the fan controllers binding, but putting it here would just
> document the options.
Ok, I will add reg property for the option.
> Rob
> [1] http://www.comairrotron.com/methods-monitoring-fan-performance
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v8 1/3] dt-bindings: hwmon: fan: Add fan binding to schema
@ 2023-09-08 8:49 ` Billy Tsai
0 siblings, 0 replies; 26+ messages in thread
From: Billy Tsai @ 2023-09-08 8:49 UTC (permalink / raw)
To: Rob Herring
Cc: jdelvare, linux, krzysztof.kozlowski+dt, joel, andrew, corbet,
thierry.reding, u.kleine-koenig, p.zabel, naresh.solanki,
linux-hwmon, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, linux-doc, linux-pwm, BMC-SW, patrick
On Thu, Sep 07, 2023 at 07:17:55AM +0000, Billy Tsai wrote:
> > On Wed, Aug 30, 2023 at 08:32:00PM +0800, Billy Tsai wrote:
> > >> From: Naresh Solanki <naresh.solanki@9elements.com>
> > >>
> > >> Add common fan properties bindings to a schema.
> > >>
> > >> Bindings for fan controllers can reference the common schema for the
> > >> fan
> > >> +properties:
> > >> + max-rpm:
> > >> + description:
> > >> + Max RPM supported by fan.
> > >> + $ref: /schemas/types.yaml#/definitions/uint32
> >
> > > Physics will limit this to something much less than 2^32. Add some
> > > constraints. 10000?
> >
> >
> > >> +
> > >> + min-rpm:
> > >> + description:
> > >> + Min RPM supported by fan.
> > >> + $ref: /schemas/types.yaml#/definitions/uint32
> >
> > > ditto
> >
> > >> +
> > >> + pulses-per-revolution:
> > >> + description:
> > >> + The number of pulse from fan sensor per revolution.
> > >> + $ref: /schemas/types.yaml#/definitions/uint32
> >
> > >Needs constraints. I assume this is never more than 4 (or 2 even)?
> >
> > Do you think we should add the contraint in the common binding?
> > In my option, the limit of the max/min rpm should be declared by
> > the binding if necessary, because the usage of each fan monitor is
> > based on the connection of the tach pin.
> Yes, I think we should have default limits.
> Unless we go as far as a schema for every specific fan model, then there
> is actually no way we can have specific limits unless the fan
> controllers have some limits.
> The most I see in tree for pulses-per-revolution is 2. There's no value
> in more. So set the max to 4 and then if anyone needs more they can bump
> the value.
> Or maybe there's some electrical/mechanical design reason fans are 1 or
> 2 pulses and we'll never see anything else? This document[1] seems to
> indicate that is indeed the case. (First hit googling "fan tach signal
> pulses")
OK, I will add the maximum value for the max-rpm, min-rpm and pulses-per-revolution.
> >
> >
> > >> + div:
> >
> > > Too generic of a name.
> >
> > >> + description:
> > >> + Fan clock divisor
> >
> > > But what is a fan clock?
> >
> > This is the divisor for the tachometer sampling clock, which determines the sensitivity of the tach pin.
> > So, if the name of the property changes to 'tach-div,' is it acceptable to you?
> That sounds like a property of the controller, not the fan, so it
> belongs in the controller binding. Is this really a common thing?
Yes, I believe this is a common feature for fans. You can refer to the Documentation/hwmon/sysfs-interface.rst,
where the fan divisor is defined for users, determining the fan's sensitivity.
> > >> + $ref: /schemas/types.yaml#/definitions/uint32
> > >> +
> > >> + target-rpm:
> > >> + description:
> > >> + Target RPM the fan should be configured during driver probe.
> >
> > > What driver? By the time the OS driver runs, a bunch of other boot
> > > software has already run on modern systems. So this value would likely
> > > be used much earlier. The point is that when exactly is outside the
> > > scope of DT. This is "what RPM do I use in case of no other information
> > > (e.g. temperature)".
> >
> > So, the description should be changed to 'The default desired fan speed in RPM,'
> > and we shouldn't mention the timing of the property's operation in the DT, is that correct?
> Correct.
> >
> > >> + $ref: /schemas/types.yaml#/definitions/uint32
> > >> +
> > >> + mode:
> >
> > > Too generic.
> >
> > >> + description:
> > >> + Select the operational mode of the fan.
> >
> > > What are modes? Spin and don't spin?
> >
> > The mode is used to indicate the driving mode of the fan (DC, PWM and so on).
> > So, if the name of the property changes to 'fan-driving-mode,' is it acceptable to you?
> I tend to think that should be implied from the parent node and/or other
> properties. PWM if "pwms" property is present. DC if the supply is
> variable. We could also use compatible strings in the fan nodes if
> there's a need.
So, it looks that this property isn't necessary for the fan. And it should be determined by the
present of the driving source. is that correct?
> That reminds me, both of these modes probably need a table of
> voltage/duty-cycle to RPMs. I imagine it's not always a linear response.
> Naresh also privately sent me (don't do that) an updated common binding
> which we discussed the need for this. I expect him to comment further
> with details.
For this purpose, we should add the speed-map like the usage of the gpio-fan, right?
https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/hwmon/gpio-fan.txt
> > >> + $ref: /schemas/types.yaml#/definitions/uint32
> > >> +
> > >> + pwms:
> > >> + description:
> > >> + PWM provider.
> >
> > > maxItems: 1
> >
> > > I don't think there are fans with more than 1 PWM input?
> >
> > Ok, I will add the constraint for the pwm input.
> >
> > >> +
> > >> + tach-ch:
> > >> + description:
> > >> + The tach channel used for the fan.
> > >> + $ref: /schemas/types.yaml#/definitions/uint32
> >
> > > The existing ASpeed version of this property allows more than 1 entry. I
> > > don't understand how a fan would have 2 tach signals, but if so, the
> > > generic property should allow for that.
> >
> > Ok, I will modify it to the uint32-array
> Perhaps uint8-array to align with existing versions of the property.
Ok, I will modify it to the uint8-array.
> >
> > > Perhaps 'reg' should be defined in here with some text saying 'reg'
> > > corresponds to the fan controller specific id which may be the PWM+TACH
> > > channel, PWM channel (deprecated), or TACH channel. I think there are
> > > examples of all 3 of these cases.
> >
> > I don't think it's necessary for the 'reg' because the case you mentioned is
> > already covered by the property 'tach-ch' and the 'pwms'.
> Yes, but when we have N child nodes of the same thing, we usually have
> "reg" and its value corresponds to how the parent identifies each child.
> We already have a mixture using PWM or tach channel. Yes, this can all
> just be in the fan controllers binding, but putting it here would just
> document the options.
Ok, I will add reg property for the option.
> Rob
> [1] http://www.comairrotron.com/methods-monitoring-fan-performance
_______________________________________________
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] 26+ messages in thread
* Re: [PATCH v8 1/3] dt-bindings: hwmon: fan: Add fan binding to schema
2023-09-08 8:49 ` Billy Tsai
@ 2023-09-12 15:11 ` Rob Herring
-1 siblings, 0 replies; 26+ messages in thread
From: Rob Herring @ 2023-09-12 15:11 UTC (permalink / raw)
To: Billy Tsai
Cc: jdelvare, linux, krzysztof.kozlowski+dt, joel, andrew, corbet,
thierry.reding, u.kleine-koenig, p.zabel, naresh.solanki,
linux-hwmon, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, linux-doc, linux-pwm, BMC-SW, patrick
On Fri, Sep 08, 2023 at 08:49:25AM +0000, Billy Tsai wrote:
> On Thu, Sep 07, 2023 at 07:17:55AM +0000, Billy Tsai wrote:
> > > On Wed, Aug 30, 2023 at 08:32:00PM +0800, Billy Tsai wrote:
> > > >> From: Naresh Solanki <naresh.solanki@9elements.com>
> > > >>
> > > >> Add common fan properties bindings to a schema.
> > > >>
> > > >> Bindings for fan controllers can reference the common schema for the
> > > >> fan
>
>
> > > >> +properties:
> > > >> + max-rpm:
> > > >> + description:
> > > >> + Max RPM supported by fan.
> > > >> + $ref: /schemas/types.yaml#/definitions/uint32
> > >
> > > > Physics will limit this to something much less than 2^32. Add some
> > > > constraints. 10000?
> > >
> > >
> > > >> +
> > > >> + min-rpm:
> > > >> + description:
> > > >> + Min RPM supported by fan.
> > > >> + $ref: /schemas/types.yaml#/definitions/uint32
> > >
> > > > ditto
> > >
> > > >> +
> > > >> + pulses-per-revolution:
> > > >> + description:
> > > >> + The number of pulse from fan sensor per revolution.
> > > >> + $ref: /schemas/types.yaml#/definitions/uint32
> > >
> > > >Needs constraints. I assume this is never more than 4 (or 2 even)?
> > >
> > > Do you think we should add the contraint in the common binding?
> > > In my option, the limit of the max/min rpm should be declared by
> > > the binding if necessary, because the usage of each fan monitor is
> > > based on the connection of the tach pin.
>
> > Yes, I think we should have default limits.
>
> > Unless we go as far as a schema for every specific fan model, then there
> > is actually no way we can have specific limits unless the fan
> > controllers have some limits.
>
> > The most I see in tree for pulses-per-revolution is 2. There's no value
> > in more. So set the max to 4 and then if anyone needs more they can bump
> > the value.
>
> > Or maybe there's some electrical/mechanical design reason fans are 1 or
> > 2 pulses and we'll never see anything else? This document[1] seems to
> > indicate that is indeed the case. (First hit googling "fan tach signal
> > pulses")
>
> OK, I will add the maximum value for the max-rpm, min-rpm and pulses-per-revolution.
>
> > >
> > >
> > > >> + div:
> > >
> > > > Too generic of a name.
> > >
> > > >> + description:
> > > >> + Fan clock divisor
> > >
> > > > But what is a fan clock?
> > >
> > > This is the divisor for the tachometer sampling clock, which determines the sensitivity of the tach pin.
> > > So, if the name of the property changes to 'tach-div,' is it acceptable to you?
>
> > That sounds like a property of the controller, not the fan, so it
> > belongs in the controller binding. Is this really a common thing?
>
> Yes, I believe this is a common feature for fans. You can refer to the Documentation/hwmon/sysfs-interface.rst,
> where the fan divisor is defined for users, determining the fan's sensitivity.
It's a feature of the controller, but I guess since it may be a per
fan or tach channel setting having it in the fan node is fine.
'tach-div' is fine.
>
> > > >> + $ref: /schemas/types.yaml#/definitions/uint32
> > > >> +
> > > >> + target-rpm:
> > > >> + description:
> > > >> + Target RPM the fan should be configured during driver probe.
> > >
> > > > What driver? By the time the OS driver runs, a bunch of other boot
> > > > software has already run on modern systems. So this value would likely
> > > > be used much earlier. The point is that when exactly is outside the
> > > > scope of DT. This is "what RPM do I use in case of no other information
> > > > (e.g. temperature)".
> > >
> > > So, the description should be changed to 'The default desired fan speed in RPM,'
> > > and we shouldn't mention the timing of the property's operation in the DT, is that correct?
>
> > Correct.
>
> > >
> > > >> + $ref: /schemas/types.yaml#/definitions/uint32
> > > >> +
> > > >> + mode:
> > >
> > > > Too generic.
> > >
> > > >> + description:
> > > >> + Select the operational mode of the fan.
> > >
> > > > What are modes? Spin and don't spin?
> > >
> > > The mode is used to indicate the driving mode of the fan (DC, PWM and so on).
> > > So, if the name of the property changes to 'fan-driving-mode,' is it acceptable to you?
>
> > I tend to think that should be implied from the parent node and/or other
> > properties. PWM if "pwms" property is present. DC if the supply is
> > variable. We could also use compatible strings in the fan nodes if
> > there's a need.
>
> So, it looks that this property isn't necessary for the fan. And it should be determined by the
> present of the driving source. is that correct?
Looking back, I see Guenter asked for something like this. So I guess it
is fine to keep if he still thinks we need it. I think it could also be
implied a bit more clearly if we do 'cooling-levels' as below. The fan
controller should know what modes it can do. Duty cycle vs. voltage in
uV is pretty easy to distinguish.
>
> > That reminds me, both of these modes probably need a table of
> > voltage/duty-cycle to RPMs. I imagine it's not always a linear response.
> > Naresh also privately sent me (don't do that) an updated common binding
> > which we discussed the need for this. I expect him to comment further
> > with details.
>
> For this purpose, we should add the speed-map like the usage of the gpio-fan, right?
> https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/hwmon/gpio-fan.txt
That should be fine. I guess it comes down to whether we want one
property or 3 depending on whether the control is voltage, duty-cycle,
GPIO pins state, etc. Unfortunately, it's "gpio-fan,speed-map", not
"speed-map", so we can't use that as-is. There's also "cooling-levels"
which can accomplish the same thing. We don't know RPMs with that, but
do we need to? Maybe, as it seems some drivers want to set speed in RPMs
from userspace. Could also do something like this:
cooling-levels = < 33 66 100>;
rpm-levels = <500 1000 1500>;
"rpm-levels" would replace the min-rpm/max-rpm properties.
Also, looking at gpio-fan.txt, it looks like you should add
"#cooling-cells" as well.
Rob
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v8 1/3] dt-bindings: hwmon: fan: Add fan binding to schema
@ 2023-09-12 15:11 ` Rob Herring
0 siblings, 0 replies; 26+ messages in thread
From: Rob Herring @ 2023-09-12 15:11 UTC (permalink / raw)
To: Billy Tsai
Cc: jdelvare, linux, krzysztof.kozlowski+dt, joel, andrew, corbet,
thierry.reding, u.kleine-koenig, p.zabel, naresh.solanki,
linux-hwmon, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, linux-doc, linux-pwm, BMC-SW, patrick
On Fri, Sep 08, 2023 at 08:49:25AM +0000, Billy Tsai wrote:
> On Thu, Sep 07, 2023 at 07:17:55AM +0000, Billy Tsai wrote:
> > > On Wed, Aug 30, 2023 at 08:32:00PM +0800, Billy Tsai wrote:
> > > >> From: Naresh Solanki <naresh.solanki@9elements.com>
> > > >>
> > > >> Add common fan properties bindings to a schema.
> > > >>
> > > >> Bindings for fan controllers can reference the common schema for the
> > > >> fan
>
>
> > > >> +properties:
> > > >> + max-rpm:
> > > >> + description:
> > > >> + Max RPM supported by fan.
> > > >> + $ref: /schemas/types.yaml#/definitions/uint32
> > >
> > > > Physics will limit this to something much less than 2^32. Add some
> > > > constraints. 10000?
> > >
> > >
> > > >> +
> > > >> + min-rpm:
> > > >> + description:
> > > >> + Min RPM supported by fan.
> > > >> + $ref: /schemas/types.yaml#/definitions/uint32
> > >
> > > > ditto
> > >
> > > >> +
> > > >> + pulses-per-revolution:
> > > >> + description:
> > > >> + The number of pulse from fan sensor per revolution.
> > > >> + $ref: /schemas/types.yaml#/definitions/uint32
> > >
> > > >Needs constraints. I assume this is never more than 4 (or 2 even)?
> > >
> > > Do you think we should add the contraint in the common binding?
> > > In my option, the limit of the max/min rpm should be declared by
> > > the binding if necessary, because the usage of each fan monitor is
> > > based on the connection of the tach pin.
>
> > Yes, I think we should have default limits.
>
> > Unless we go as far as a schema for every specific fan model, then there
> > is actually no way we can have specific limits unless the fan
> > controllers have some limits.
>
> > The most I see in tree for pulses-per-revolution is 2. There's no value
> > in more. So set the max to 4 and then if anyone needs more they can bump
> > the value.
>
> > Or maybe there's some electrical/mechanical design reason fans are 1 or
> > 2 pulses and we'll never see anything else? This document[1] seems to
> > indicate that is indeed the case. (First hit googling "fan tach signal
> > pulses")
>
> OK, I will add the maximum value for the max-rpm, min-rpm and pulses-per-revolution.
>
> > >
> > >
> > > >> + div:
> > >
> > > > Too generic of a name.
> > >
> > > >> + description:
> > > >> + Fan clock divisor
> > >
> > > > But what is a fan clock?
> > >
> > > This is the divisor for the tachometer sampling clock, which determines the sensitivity of the tach pin.
> > > So, if the name of the property changes to 'tach-div,' is it acceptable to you?
>
> > That sounds like a property of the controller, not the fan, so it
> > belongs in the controller binding. Is this really a common thing?
>
> Yes, I believe this is a common feature for fans. You can refer to the Documentation/hwmon/sysfs-interface.rst,
> where the fan divisor is defined for users, determining the fan's sensitivity.
It's a feature of the controller, but I guess since it may be a per
fan or tach channel setting having it in the fan node is fine.
'tach-div' is fine.
>
> > > >> + $ref: /schemas/types.yaml#/definitions/uint32
> > > >> +
> > > >> + target-rpm:
> > > >> + description:
> > > >> + Target RPM the fan should be configured during driver probe.
> > >
> > > > What driver? By the time the OS driver runs, a bunch of other boot
> > > > software has already run on modern systems. So this value would likely
> > > > be used much earlier. The point is that when exactly is outside the
> > > > scope of DT. This is "what RPM do I use in case of no other information
> > > > (e.g. temperature)".
> > >
> > > So, the description should be changed to 'The default desired fan speed in RPM,'
> > > and we shouldn't mention the timing of the property's operation in the DT, is that correct?
>
> > Correct.
>
> > >
> > > >> + $ref: /schemas/types.yaml#/definitions/uint32
> > > >> +
> > > >> + mode:
> > >
> > > > Too generic.
> > >
> > > >> + description:
> > > >> + Select the operational mode of the fan.
> > >
> > > > What are modes? Spin and don't spin?
> > >
> > > The mode is used to indicate the driving mode of the fan (DC, PWM and so on).
> > > So, if the name of the property changes to 'fan-driving-mode,' is it acceptable to you?
>
> > I tend to think that should be implied from the parent node and/or other
> > properties. PWM if "pwms" property is present. DC if the supply is
> > variable. We could also use compatible strings in the fan nodes if
> > there's a need.
>
> So, it looks that this property isn't necessary for the fan. And it should be determined by the
> present of the driving source. is that correct?
Looking back, I see Guenter asked for something like this. So I guess it
is fine to keep if he still thinks we need it. I think it could also be
implied a bit more clearly if we do 'cooling-levels' as below. The fan
controller should know what modes it can do. Duty cycle vs. voltage in
uV is pretty easy to distinguish.
>
> > That reminds me, both of these modes probably need a table of
> > voltage/duty-cycle to RPMs. I imagine it's not always a linear response.
> > Naresh also privately sent me (don't do that) an updated common binding
> > which we discussed the need for this. I expect him to comment further
> > with details.
>
> For this purpose, we should add the speed-map like the usage of the gpio-fan, right?
> https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/hwmon/gpio-fan.txt
That should be fine. I guess it comes down to whether we want one
property or 3 depending on whether the control is voltage, duty-cycle,
GPIO pins state, etc. Unfortunately, it's "gpio-fan,speed-map", not
"speed-map", so we can't use that as-is. There's also "cooling-levels"
which can accomplish the same thing. We don't know RPMs with that, but
do we need to? Maybe, as it seems some drivers want to set speed in RPMs
from userspace. Could also do something like this:
cooling-levels = < 33 66 100>;
rpm-levels = <500 1000 1500>;
"rpm-levels" would replace the min-rpm/max-rpm properties.
Also, looking at gpio-fan.txt, it looks like you should add
"#cooling-cells" as well.
Rob
_______________________________________________
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] 26+ messages in thread
end of thread, other threads:[~2023-09-12 15:12 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-08-30 12:31 [PATCH v8 0/3] Support pwm/tach driver for aspeed ast26xx Billy Tsai
2023-08-30 12:31 ` Billy Tsai
2023-08-30 12:32 ` [PATCH v8 1/3] dt-bindings: hwmon: fan: Add fan binding to schema Billy Tsai
2023-08-30 12:32 ` Billy Tsai
2023-09-05 17:00 ` Rob Herring
2023-09-05 17:00 ` Rob Herring
2023-09-07 7:17 ` Billy Tsai
2023-09-07 7:17 ` Billy Tsai
2023-09-07 19:43 ` Rob Herring
2023-09-07 19:43 ` Rob Herring
2023-09-08 8:49 ` Billy Tsai
2023-09-08 8:49 ` Billy Tsai
2023-09-12 15:11 ` Rob Herring
2023-09-12 15:11 ` Rob Herring
2023-08-30 12:32 ` [PATCH v8 2/3] dt-bindings: hwmon: Support Aspeed g6 PWM TACH Control Billy Tsai
2023-08-30 12:32 ` Billy Tsai
2023-09-05 17:07 ` Rob Herring
2023-09-05 17:07 ` Rob Herring
2023-09-07 7:24 ` Billy Tsai
2023-09-07 7:24 ` Billy Tsai
2023-08-30 12:32 ` [PATCH v8 3/3] hwmon: (aspeed-g6-pwm-tacho): Support for ASPEED g6 PWM/Fan tach Billy Tsai
2023-08-30 12:32 ` Billy Tsai
2023-09-01 4:54 ` Potin Lai
2023-09-01 4:54 ` Potin Lai
2023-09-01 5:10 ` Billy Tsai
2023-09-01 5:10 ` 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.