[PATCH v2 0/3] Update the max31790 driver

[PATCH v2 0/3] Update the max31790 driver

[Chanh Nguyen]

Add the max31790 binding document and support maxim,pwmout-pin-as-tach-input
vendor property for the max31790 device.

Changes in v2:
 - Drop "driver" in the patch 1/3 commit title                           [Krzysztof]
 - Update filename of the maxim,max31790.yaml                            [Krzysztof]
 - Add the common fan schema to $ref                                     [Krzysztof]
 - Update the node name to "fan-controller" in maxim,max31790.yaml       [Krzysztof]
 - Update the vendor property name to "maxim,pwmout-pin-as-tach-input"   [Rob]

Chanh Nguyen (3):
  dt-bindings: hwmon: Add maxim max31790 bindings
  hwmon: (max31790): Support config PWM output becomes TACH
  dt-bindings: hwmon: max31790: Add maxim,pwmout-pin-as-tach-input
    property

 .../bindings/hwmon/maxim,max31790.yaml        | 63 +++++++++++++++++++
 drivers/hwmon/max31790.c                      | 31 +++++++++
 2 files changed, 94 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml

-- 
2.17.1

[PATCH v2 1/3] dt-bindings: hwmon: Add maxim max31790 bindings

[Chanh Nguyen]

Add a device tree bindings for max31790 device.

Signed-off-by: Chanh Nguyen <chanh@os.amperecomputing.com>
---
Changes in v2:
 - Update filename of the maxim,max31790.yaml                            [Krzysztof]
 - Add the common fan schema to $ref                                     [Krzysztof]
 - Update the node name to "fan-controller" in maxim,max31790.yaml       [Krzysztof]
 - Drop "driver" in commit title                                         [Krzysztof]
---
 .../bindings/hwmon/maxim,max31790.yaml        | 52 +++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml

diff --git a/Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml b/Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml
new file mode 100644
index 000000000000..a561e5a3e9e4
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/maxim,max31790.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: The Maxim MAX31790 Fan Controller
+
+maintainers:
+  - Guenter Roeck <linux@roeck-us.net>
+
+description: >
+  The MAX31790 controls the speeds of up to six fans using six
+  independent PWM outputs. The desired fan speeds (or PWM duty cycles)
+  are written through the I2C interface.
+
+  Datasheets:
+    https://datasheets.maximintegrated.com/en/ds/MAX31790.pdf
+
+properties:
+  compatible:
+    const: maxim,max31790
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+  resets:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+
+allOf:
+  - $ref: fan-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    i2c {
+      #address-cells = <1>;
+      #size-cells = <0>;
+
+      fan-controller@20 {
+        compatible = "maxim,max31790";
+        reg = <0x20>;
+      };
+    };
-- 
2.17.1

Re: [PATCH v2 1/3] dt-bindings: hwmon: Add maxim max31790 bindings

[Krzysztof Kozlowski]

On 14/04/2024 06:22, Chanh Nguyen wrote:
> Add a device tree bindings for max31790 device.
> 

Nothing improved in commit msg, where is the rationale of split of bindings?

A nit, subject: drop second/last, redundant "bindings". The
"dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v6.7-rc8/source/Documentation/devicetree/bindings/submitting-patches.rst#L18

> Signed-off-by: Chanh Nguyen <chanh@os.amperecomputing.com>
> ---
> Changes in v2:
>  - Update filename of the maxim,max31790.yaml                            [Krzysztof]
>  - Add the common fan schema to $ref                                     [Krzysztof]
>  - Update the node name to "fan-controller" in maxim,max31790.yaml       [Krzysztof]
>  - Drop "driver" in commit title                                         [Krzysztof]
> ---
>  .../bindings/hwmon/maxim,max31790.yaml        | 52 +++++++++++++++++++
>  1 file changed, 52 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml
> 
> diff --git a/Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml b/Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml
> new file mode 100644
> index 000000000000..a561e5a3e9e4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml
> @@ -0,0 +1,52 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/hwmon/maxim,max31790.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: The Maxim MAX31790 Fan Controller
> +
> +maintainers:
> +  - Guenter Roeck <linux@roeck-us.net>
> +
> +description: >
> +  The MAX31790 controls the speeds of up to six fans using six
> +  independent PWM outputs. The desired fan speeds (or PWM duty cycles)
> +  are written through the I2C interface.
> +
> +  Datasheets:
> +    https://datasheets.maximintegrated.com/en/ds/MAX31790.pdf
> +
> +properties:
> +  compatible:
> +    const: maxim,max31790
> +
> +  reg:
> +    maxItems: 1
> +
> +  clocks:
> +    maxItems: 1
> +
> +  resets:
> +    maxItems: 1
> +
> +required:
> +  - compatible
> +  - reg
> +
> +allOf:
> +  - $ref: fan-common.yaml#
> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +    i2c {
> +      #address-cells = <1>;
> +      #size-cells = <0>;
> +
> +      fan-controller@20 {
> +        compatible = "maxim,max31790";
> +        reg = <0x20>;

Make the example complete - add all properties, like clocks, resets and
any others which are applicable.

Best regards,
Krzysztof

Re: [PATCH v2 1/3] dt-bindings: hwmon: Add maxim max31790 bindings

[Chanh Nguyen]

On 14/04/2024 13:03, Krzysztof Kozlowski wrote:
> On 14/04/2024 06:22, Chanh Nguyen wrote:
>> Add a device tree bindings for max31790 device.
>>
> 
> Nothing improved in commit msg, where is the rationale of split of bindings?
> 

Yes Krzysztof, I will use "tach-ch" property from the fan-common.yaml to 
solve my case. So I will not need a split of bindings.

Finally, my patch series will only be two patches. They are 
"dt-bindings: hwmon: Add maxim max31790" and "hwmon: (max31790): Support 
config PWM output becomes TACH".

I'm going to update that in the patch v3 series.

> A nit, subject: drop second/last, redundant "bindings". The
> "dt-bindings" prefix is already stating that these are bindings.
> See also:
> https://elixir.bootlin.com/linux/v6.7-rc8/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
> 

Thank Krzysztof, I'll drop "bindings" in commit msg.

>> Signed-off-by: Chanh Nguyen <chanh@os.amperecomputing.com>
>> ---
>> Changes in v2:
>>   - Update filename of the maxim,max31790.yaml                            [Krzysztof]
>>   - Add the common fan schema to $ref                                     [Krzysztof]
>>   - Update the node name to "fan-controller" in maxim,max31790.yaml       [Krzysztof]
>>   - Drop "driver" in commit title                                         [Krzysztof]
>> ---
>>   .../bindings/hwmon/maxim,max31790.yaml        | 52 +++++++++++++++++++
>>   1 file changed, 52 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml b/Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml
>> new file mode 100644
>> index 000000000000..a561e5a3e9e4
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml
>> @@ -0,0 +1,52 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/hwmon/maxim,max31790.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: The Maxim MAX31790 Fan Controller
>> +
>> +maintainers:
>> +  - Guenter Roeck <linux@roeck-us.net>
>> +
>> +description: >
>> +  The MAX31790 controls the speeds of up to six fans using six
>> +  independent PWM outputs. The desired fan speeds (or PWM duty cycles)
>> +  are written through the I2C interface.
>> +
>> +  Datasheets:
>> +    https://datasheets.maximintegrated.com/en/ds/MAX31790.pdf
>> +
>> +properties:
>> +  compatible:
>> +    const: maxim,max31790
>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +  clocks:
>> +    maxItems: 1
>> +
>> +  resets:
>> +    maxItems: 1
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +
>> +allOf:
>> +  - $ref: fan-common.yaml#
>> +
>> +unevaluatedProperties: false
>> +
>> +examples:
>> +  - |
>> +    i2c {
>> +      #address-cells = <1>;
>> +      #size-cells = <0>;
>> +
>> +      fan-controller@20 {
>> +        compatible = "maxim,max31790";
>> +        reg = <0x20>;
> 
> Make the example complete - add all properties, like clocks, resets and
> any others which are applicable.
> 

Ok Krzysztof, I'll update that in the patch v3

> Best regards,
> Krzysztof
> 

[PATCH v2 2/3] hwmon: (max31790): Support config PWM output becomes TACH

[Chanh Nguyen]

PWMOUT pins on MAX31790 can be configured as a tachometer input pin by
setting bit[0] in the Configuration Register. When the bit[0] of a channel
is set, the PWMOUT pin becomes the tach input pin for the channel plus six.

This commit allows the kernel to set those pins when necessary if the
maxim,pwmout-pin-as-tach-input DT property exists.

Signed-off-by: Chanh Nguyen <chanh@os.amperecomputing.com>
---
Changes in v2:
 - Update the vendor property name to "maxim,pwmout-pin-as-tach-input"   [Rob]
---
 drivers/hwmon/max31790.c | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/drivers/hwmon/max31790.c b/drivers/hwmon/max31790.c
index 3dc95196b229..ac0a8099acf6 100644
--- a/drivers/hwmon/max31790.c
+++ b/drivers/hwmon/max31790.c
@@ -12,6 +12,7 @@
 #include <linux/init.h>
 #include <linux/jiffies.h>
 #include <linux/module.h>
+#include <linux/property.h>
 #include <linux/slab.h>
 
 /* MAX31790 registers */
@@ -506,9 +507,12 @@ static int max31790_probe(struct i2c_client *client)
 {
 	struct i2c_adapter *adapter = client->adapter;
 	struct device *dev = &client->dev;
+	u8 pwmout_to_tach[NR_CHANNEL];
 	struct max31790_data *data;
 	struct device *hwmon_dev;
 	int err;
+	u8 tmp;
+	int i;
 
 	if (!i2c_check_functionality(adapter,
 			I2C_FUNC_SMBUS_BYTE_DATA | I2C_FUNC_SMBUS_WORD_DATA))
@@ -528,6 +532,33 @@ static int max31790_probe(struct i2c_client *client)
 	if (err)
 		return err;
 
+	if (device_property_present(dev, "maxim,pwmout-pin-as-tach-input")) {
+		err = device_property_read_u8_array(dev, "maxim,pwmout-pin-as-tach-input",
+						    pwmout_to_tach, NR_CHANNEL);
+		if (err) {
+			/* The maxim,pwmout-pin-as-tach-input is an array of six values */
+			dev_warn(dev, "The maxim,pwmout-pin-as-tach-input property exist but malform");
+		} else {
+			for (i = 0; i < NR_CHANNEL; i++) {
+				tmp = data->fan_config[i];
+				if (pwmout_to_tach[i])
+					data->fan_config[i] |= MAX31790_FAN_CFG_TACH_INPUT;
+				else
+					data->fan_config[i] &= ~(MAX31790_FAN_CFG_TACH_INPUT);
+
+				if (tmp != data->fan_config[i]) {
+					err = i2c_smbus_write_byte_data(client,
+									MAX31790_REG_FAN_CONFIG(i),
+									data->fan_config[i]);
+					if (err < 0)
+						dev_warn(dev,
+							 "Fail to apply fan configuration at channel %d",
+							 i);
+				}
+			}
+		}
+	}
+
 	hwmon_dev = devm_hwmon_device_register_with_info(dev, client->name,
 							 data,
 							 &max31790_chip_info,
-- 
2.17.1

Re: [PATCH v2 2/3] hwmon: (max31790): Support config PWM output becomes TACH

[Christophe JAILLET]

Le 14/04/2024 à 06:22, Chanh Nguyen a écrit :
> PWMOUT pins on MAX31790 can be configured as a tachometer input pin by
> setting bit[0] in the Configuration Register. When the bit[0] of a channel
> is set, the PWMOUT pin becomes the tach input pin for the channel plus six.
> 
> This commit allows the kernel to set those pins when necessary if the
> maxim,pwmout-pin-as-tach-input DT property exists.
> 
> Signed-off-by: Chanh Nguyen <chanh@os.amperecomputing.com>
> ---
> Changes in v2:
>   - Update the vendor property name to "maxim,pwmout-pin-as-tach-input"   [Rob]

...

> @@ -528,6 +532,33 @@ static int max31790_probe(struct i2c_client *client)
>   	if (err)
>   		return err;
>   
> +	if (device_property_present(dev, "maxim,pwmout-pin-as-tach-input")) {
> +		err = device_property_read_u8_array(dev, "maxim,pwmout-pin-as-tach-input",
> +						    pwmout_to_tach, NR_CHANNEL);
> +		if (err) {
> +			/* The maxim,pwmout-pin-as-tach-input is an array of six values */
> +			dev_warn(dev, "The maxim,pwmout-pin-as-tach-input property exist but malform");

Nit: exists
Nit: malformed or "is malformed"

CJ

Re: [PATCH v2 2/3] hwmon: (max31790): Support config PWM output becomes TACH

[Chanh Nguyen]

On 14/04/2024 15:03, Christophe JAILLET wrote:
> Le 14/04/2024 à 06:22, Chanh Nguyen a écrit :
>> PWMOUT pins on MAX31790 can be configured as a tachometer input pin by
>> setting bit[0] in the Configuration Register. When the bit[0] of a 
>> channel
>> is set, the PWMOUT pin becomes the tach input pin for the channel plus 
>> six.
>>
>> This commit allows the kernel to set those pins when necessary if the
>> maxim,pwmout-pin-as-tach-input DT property exists.
>>
>> Signed-off-by: Chanh Nguyen <chanh@os.amperecomputing.com>
>> ---
>> Changes in v2:
>>   - Update the vendor property name to 
>> "maxim,pwmout-pin-as-tach-input"   [Rob]
> 
> ...

Hi CJ, what does it mean?
> 
>> @@ -528,6 +532,33 @@ static int max31790_probe(struct i2c_client *client)
>>       if (err)
>>           return err;
>> +    if (device_property_present(dev, 
>> "maxim,pwmout-pin-as-tach-input")) {
>> +        err = device_property_read_u8_array(dev, 
>> "maxim,pwmout-pin-as-tach-input",
>> +                            pwmout_to_tach, NR_CHANNEL);
>> +        if (err) {
>> +            /* The maxim,pwmout-pin-as-tach-input is an array of six 
>> values */
>> +            dev_warn(dev, "The maxim,pwmout-pin-as-tach-input 
>> property exist but malform");
> 
> Nit: exists
> Nit: malformed or "is malformed"
> 

Thank CJ,

I'll update that in the patch v3

> CJ

Re: [PATCH v2 2/3] hwmon: (max31790): Support config PWM output becomes TACH

[Christophe JAILLET]

Le 16/04/2024 à 07:27, Chanh Nguyen a écrit :
> 
> 
> On 14/04/2024 15:03, Christophe JAILLET wrote:
>> Le 14/04/2024 à 06:22, Chanh Nguyen a écrit :
>>> PWMOUT pins on MAX31790 can be configured as a tachometer input pin by
>>> setting bit[0] in the Configuration Register. When the bit[0] of a 
>>> channel
>>> is set, the PWMOUT pin becomes the tach input pin for the channel 
>>> plus six.
>>>
>>> This commit allows the kernel to set those pins when necessary if the
>>> maxim,pwmout-pin-as-tach-input DT property exists.
>>>
>>> Signed-off-by: Chanh Nguyen <chanh@os.amperecomputing.com>
>>> ---
>>> Changes in v2:
>>>   - Update the vendor property name to 
>>> "maxim,pwmout-pin-as-tach-input"   [Rob]
>>
>> ...
> 
> Hi CJ, what does it mean?

Hi,
just a shortcut of my name : Christophe Jaillet.

CJ

>>
>>> @@ -528,6 +532,33 @@ static int max31790_probe(struct i2c_client 
>>> *client)
>>>       if (err)
>>>           return err;
>>> +    if (device_property_present(dev, 
>>> "maxim,pwmout-pin-as-tach-input")) {
>>> +        err = device_property_read_u8_array(dev, 
>>> "maxim,pwmout-pin-as-tach-input",
>>> +                            pwmout_to_tach, NR_CHANNEL);
>>> +        if (err) {
>>> +            /* The maxim,pwmout-pin-as-tach-input is an array of six 
>>> values */
>>> +            dev_warn(dev, "The maxim,pwmout-pin-as-tach-input 
>>> property exist but malform");
>>
>> Nit: exists
>> Nit: malformed or "is malformed"
>>
> 
> Thank CJ,
> 
> I'll update that in the patch v3
> 
>> CJ
> 
> 

Re: [PATCH v2 2/3] hwmon: (max31790): Support config PWM output becomes TACH

[Chanh Nguyen]

On 17/04/2024 00:39, Christophe JAILLET wrote:
> Le 16/04/2024 à 07:27, Chanh Nguyen a écrit :
>>
>>
>> On 14/04/2024 15:03, Christophe JAILLET wrote:
>>> Le 14/04/2024 à 06:22, Chanh Nguyen a écrit :
>>>> PWMOUT pins on MAX31790 can be configured as a tachometer input pin by
>>>> setting bit[0] in the Configuration Register. When the bit[0] of a 
>>>> channel
>>>> is set, the PWMOUT pin becomes the tach input pin for the channel 
>>>> plus six.
>>>>
>>>> This commit allows the kernel to set those pins when necessary if the
>>>> maxim,pwmout-pin-as-tach-input DT property exists.
>>>>
>>>> Signed-off-by: Chanh Nguyen <chanh@os.amperecomputing.com>
>>>> ---
>>>> Changes in v2:
>>>>   - Update the vendor property name to 
>>>> "maxim,pwmout-pin-as-tach-input"   [Rob]
>>>
>>> ...
>>
>> Hi CJ, what does it mean?
> 
> Hi,
> just a shortcut of my name : Christophe Jaillet.
> 

Thank CJ! It's a pleasure to see your comments. I'm happy to meet your 
review in the next patches.

Best Regards,
Chanh Ng

> CJ
> 
>>>
>>>> @@ -528,6 +532,33 @@ static int max31790_probe(struct i2c_client 
>>>> *client)
>>>>       if (err)
>>>>           return err;
>>>> +    if (device_property_present(dev, 
>>>> "maxim,pwmout-pin-as-tach-input")) {
>>>> +        err = device_property_read_u8_array(dev, 
>>>> "maxim,pwmout-pin-as-tach-input",
>>>> +                            pwmout_to_tach, NR_CHANNEL);
>>>> +        if (err) {
>>>> +            /* The maxim,pwmout-pin-as-tach-input is an array of 
>>>> six values */
>>>> +            dev_warn(dev, "The maxim,pwmout-pin-as-tach-input 
>>>> property exist but malform");
>>>
>>> Nit: exists
>>> Nit: malformed or "is malformed"
>>>
>>
>> Thank CJ,
>>
>> I'll update that in the patch v3
>>
>>> CJ
>>
>>
> 

[PATCH v2 3/3] dt-bindings: hwmon: max31790: Add maxim,pwmout-pin-as-tach-input property

[Chanh Nguyen]

The max31790 supports six pins, which are dedicated PWM outputs. Any of the
six PWM outputs can also be configured to serve as tachometer inputs,
allowing for up to 12 tachometer fans to be monitored.

Add a new vendor-specific property, 'maxim,pwmout-pin-as-tach-input',
to allow PWMOUT to become a TACH input.

An array of six integers responds to six PWM channels for configuring
the PWM to TACH mode. When set to 0, the associated PWMOUT produces
a PWM waveform for control of fan speed. When set to 1, PWMOUT becomes
a TACH input.

Signed-off-by: Chanh Nguyen <chanh@os.amperecomputing.com>
---
Changes in v2:
 - Update the vendor property name to "maxim,pwmout-pin-as-tach-input"   [Rob]
 - Update commit message                                                 [Krzysztof]
---
 .../devicetree/bindings/hwmon/maxim,max31790.yaml     | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml b/Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml
index a561e5a3e9e4..2d4f50bc7c41 100644
--- a/Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml
+++ b/Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml
@@ -30,6 +30,16 @@ properties:
   resets:
     maxItems: 1
 
+  maxim,pwmout-pin-as-tach-input:
+    description: |
+      An array of six integers responds to six PWM channels for
+      configuring the pwm to tach mode.
+      When set to 0, the associated PWMOUT produces a PWM waveform for
+      control of fan speed. When set to 1, PWMOUT becomes a TACH input
+    $ref: /schemas/types.yaml#/definitions/uint8-array
+    maxItems: 6
+    minItems: 6
+
 required:
   - compatible
   - reg
@@ -48,5 +58,6 @@ examples:
       fan-controller@20 {
         compatible = "maxim,max31790";
         reg = <0x20>;
+        maxim,pwmout-pin-as-tach-input = /bits/ 8 <0 0 0 0 1 1>;
       };
     };
-- 
2.17.1

Re: [PATCH v2 3/3] dt-bindings: hwmon: max31790: Add maxim,pwmout-pin-as-tach-input property

[Krzysztof Kozlowski]

On 14/04/2024 06:22, Chanh Nguyen wrote:
> The max31790 supports six pins, which are dedicated PWM outputs. Any of the
> six PWM outputs can also be configured to serve as tachometer inputs,
> allowing for up to 12 tachometer fans to be monitored.
> 
> Add a new vendor-specific property, 'maxim,pwmout-pin-as-tach-input',
> to allow PWMOUT to become a TACH input.
> 
> An array of six integers responds to six PWM channels for configuring
> the PWM to TACH mode. When set to 0, the associated PWMOUT produces
> a PWM waveform for control of fan speed. When set to 1, PWMOUT becomes
> a TACH input.
> 
> Signed-off-by: Chanh Nguyen <chanh@os.amperecomputing.com>
> ---
> Changes in v2:
>  - Update the vendor property name to "maxim,pwmout-pin-as-tach-input"   [Rob]
>  - Update commit message                                                 [Krzysztof]

Please put binding before its user.

> ---
>  .../devicetree/bindings/hwmon/maxim,max31790.yaml     | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml b/Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml
> index a561e5a3e9e4..2d4f50bc7c41 100644
> --- a/Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml
> +++ b/Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml
> @@ -30,6 +30,16 @@ properties:
>    resets:
>      maxItems: 1
>  
> +  maxim,pwmout-pin-as-tach-input:
> +    description: |
> +      An array of six integers responds to six PWM channels for
> +      configuring the pwm to tach mode.
> +      When set to 0, the associated PWMOUT produces a PWM waveform for
> +      control of fan speed. When set to 1, PWMOUT becomes a TACH input
> +    $ref: /schemas/types.yaml#/definitions/uint8-array
> +    maxItems: 6
> +    minItems: 6

tach-ch solves your case. You define which inputs should be used for tach.

Best regards,
Krzysztof

Re: [PATCH v2 3/3] dt-bindings: hwmon: max31790: Add maxim,pwmout-pin-as-tach-input property

[Chanh Nguyen]

On 14/04/2024 13:07, Krzysztof Kozlowski wrote:
> On 14/04/2024 06:22, Chanh Nguyen wrote:
>> The max31790 supports six pins, which are dedicated PWM outputs. Any of the
>> six PWM outputs can also be configured to serve as tachometer inputs,
>> allowing for up to 12 tachometer fans to be monitored.
>>
>> Add a new vendor-specific property, 'maxim,pwmout-pin-as-tach-input',
>> to allow PWMOUT to become a TACH input.
>>
>> An array of six integers responds to six PWM channels for configuring
>> the PWM to TACH mode. When set to 0, the associated PWMOUT produces
>> a PWM waveform for control of fan speed. When set to 1, PWMOUT becomes
>> a TACH input.
>>
>> Signed-off-by: Chanh Nguyen <chanh@os.amperecomputing.com>
>> ---
>> Changes in v2:
>>   - Update the vendor property name to "maxim,pwmout-pin-as-tach-input"   [Rob]
>>   - Update commit message                                                 [Krzysztof]
> 
> Please put binding before its user.
> 

Hi Krzysztof, I'll drop this [Path 3/3] in the patch series v3.

My patch series will only be two patches. They are "dt-bindings: hwmon: 
Add maxim max31790" and "hwmon: (max31790): Support config PWM output 
becomes TACH"

>> ---
>>   .../devicetree/bindings/hwmon/maxim,max31790.yaml     | 11 +++++++++++
>>   1 file changed, 11 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml b/Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml
>> index a561e5a3e9e4..2d4f50bc7c41 100644
>> --- a/Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml
>> +++ b/Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml
>> @@ -30,6 +30,16 @@ properties:
>>     resets:
>>       maxItems: 1
>>   
>> +  maxim,pwmout-pin-as-tach-input:
>> +    description: |
>> +      An array of six integers responds to six PWM channels for
>> +      configuring the pwm to tach mode.
>> +      When set to 0, the associated PWMOUT produces a PWM waveform for
>> +      control of fan speed. When set to 1, PWMOUT becomes a TACH input
>> +    $ref: /schemas/types.yaml#/definitions/uint8-array
>> +    maxItems: 6
>> +    minItems: 6
> 
> tach-ch solves your case. You define which inputs should be used for tach.
> 

Agree Krzysztof. I'll use the tach-ch property from the fan-common.yaml 
to solve my case. So I will not need to define a new vendor property as 
"maxim,pwmout-pin-as-tach-input". I'll drop this [Path 3/3] in the patch 
series v3.


> Best regards,
> Krzysztof
> 

Re: [PATCH v2 3/3] dt-bindings: hwmon: max31790: Add maxim,pwmout-pin-as-tach-input property

[Chanh Nguyen]

On 16/04/2024 11:52, Chanh Nguyen wrote:
> 
> 
> On 14/04/2024 13:07, Krzysztof Kozlowski wrote:
>> On 14/04/2024 06:22, Chanh Nguyen wrote:
>>> The max31790 supports six pins, which are dedicated PWM outputs. Any 
>>> of the
>>> six PWM outputs can also be configured to serve as tachometer inputs,
>>> allowing for up to 12 tachometer fans to be monitored.
>>>
>>> Add a new vendor-specific property, 'maxim,pwmout-pin-as-tach-input',
>>> to allow PWMOUT to become a TACH input.
>>>
>>> An array of six integers responds to six PWM channels for configuring
>>> the PWM to TACH mode. When set to 0, the associated PWMOUT produces
>>> a PWM waveform for control of fan speed. When set to 1, PWMOUT becomes
>>> a TACH input.
>>>
>>> Signed-off-by: Chanh Nguyen <chanh@os.amperecomputing.com>
>>> ---
>>> Changes in v2:
>>>   - Update the vendor property name to 
>>> "maxim,pwmout-pin-as-tach-input"   [Rob]
>>>   - Update commit 
>>> message                                                 [Krzysztof]
>>
>> Please put binding before its user.
>>
> 
> Hi Krzysztof, I'll drop this [Path 3/3] in the patch series v3.
> 
> My patch series will only be two patches. They are "dt-bindings: hwmon: 
> Add maxim max31790" and "hwmon: (max31790): Support config PWM output 
> becomes TACH"
> 
>>> ---
>>>   .../devicetree/bindings/hwmon/maxim,max31790.yaml     | 11 +++++++++++
>>>   1 file changed, 11 insertions(+)
>>>
>>> diff --git 
>>> a/Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml 
>>> b/Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml
>>> index a561e5a3e9e4..2d4f50bc7c41 100644
>>> --- a/Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml
>>> +++ b/Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml
>>> @@ -30,6 +30,16 @@ properties:
>>>     resets:
>>>       maxItems: 1
>>> +  maxim,pwmout-pin-as-tach-input:
>>> +    description: |
>>> +      An array of six integers responds to six PWM channels for
>>> +      configuring the pwm to tach mode.
>>> +      When set to 0, the associated PWMOUT produces a PWM waveform for
>>> +      control of fan speed. When set to 1, PWMOUT becomes a TACH input
>>> +    $ref: /schemas/types.yaml#/definitions/uint8-array
>>> +    maxItems: 6
>>> +    minItems: 6
>>
>> tach-ch solves your case. You define which inputs should be used for 
>> tach.
>>
> 
> Agree Krzysztof. I'll use the tach-ch property from the fan-common.yaml 
> to solve my case. So I will not need to define a new vendor property as 
> "maxim,pwmout-pin-as-tach-input". I'll drop this [Path 3/3] in the patch 
> series v3.
> 
> 
>> Best regards,
>> Krzysztof
>>


Hi Krzysztof,

I checked in the
Documentation/devicetree/bindings/hwmon/fan-common.yaml. I found the
tach-ch property, but it seems define the tach channel used for fan.

      tach-ch:
      	description:
        		The tach channel used for the fan.
      	$ref: /schemas/types.yaml#/definitions/uint8-array


In my purpose, I would like to configure the pwm output pins to become 
tachometer input pins by setting bit[0] in the Configuration Register.


I think a vendor property is suitable for this purpose. It is only 
available on specific MAX31790 fan controllers and not on other fan 
controller devices. So I think we can't use the "tach-ch" in 
fan-common.yaml.

I discussed it in the thread
https://lore.kernel.org/lkml/ce8b2b49-b194-42f7-8f83-fcbf7b460970@amperemail.onmicrosoft.com/ 
, but I have not yet received Rob's response.

Please share your comment with me. I hope that will help us make a final 
decision.

Thank Krzysztof very much!

Re: [PATCH v2 3/3] dt-bindings: hwmon: max31790: Add maxim,pwmout-pin-as-tach-input property

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 3871 bytes --]

On Tue, Apr 23, 2024 at 03:45:12PM +0700, Chanh Nguyen wrote:
> 
> 
> On 16/04/2024 11:52, Chanh Nguyen wrote:
> > 
> > 
> > On 14/04/2024 13:07, Krzysztof Kozlowski wrote:
> > > On 14/04/2024 06:22, Chanh Nguyen wrote:
> > > > The max31790 supports six pins, which are dedicated PWM outputs.
> > > > Any of the
> > > > six PWM outputs can also be configured to serve as tachometer inputs,
> > > > allowing for up to 12 tachometer fans to be monitored.
> > > > 
> > > > Add a new vendor-specific property, 'maxim,pwmout-pin-as-tach-input',
> > > > to allow PWMOUT to become a TACH input.
> > > > 
> > > > An array of six integers responds to six PWM channels for configuring
> > > > the PWM to TACH mode. When set to 0, the associated PWMOUT produces
> > > > a PWM waveform for control of fan speed. When set to 1, PWMOUT becomes
> > > > a TACH input.
> > > > 
> > > > Signed-off-by: Chanh Nguyen <chanh@os.amperecomputing.com>
> > > > ---
> > > > Changes in v2:
> > > >   - Update the vendor property name to
> > > > "maxim,pwmout-pin-as-tach-input"   [Rob]
> > > >   - Update commit
> > > > message                                                
> > > > [Krzysztof]
> > > 
> > > Please put binding before its user.
> > > 
> > 
> > Hi Krzysztof, I'll drop this [Path 3/3] in the patch series v3.
> > 
> > My patch series will only be two patches. They are "dt-bindings: hwmon:
> > Add maxim max31790" and "hwmon: (max31790): Support config PWM output
> > becomes TACH"
> > 
> > > > ---
> > > >   .../devicetree/bindings/hwmon/maxim,max31790.yaml     | 11 +++++++++++
> > > >   1 file changed, 11 insertions(+)
> > > > 
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml
> > > > b/Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml
> > > > index a561e5a3e9e4..2d4f50bc7c41 100644
> > > > --- a/Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml
> > > > +++ b/Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml
> > > > @@ -30,6 +30,16 @@ properties:
> > > >     resets:
> > > >       maxItems: 1
> > > > +  maxim,pwmout-pin-as-tach-input:
> > > > +    description: |
> > > > +      An array of six integers responds to six PWM channels for
> > > > +      configuring the pwm to tach mode.
> > > > +      When set to 0, the associated PWMOUT produces a PWM waveform for
> > > > +      control of fan speed. When set to 1, PWMOUT becomes a TACH input
> > > > +    $ref: /schemas/types.yaml#/definitions/uint8-array
> > > > +    maxItems: 6
> > > > +    minItems: 6
> > > 
> > > tach-ch solves your case. You define which inputs should be used for
> > > tach.
> > > 
> > 
> > Agree Krzysztof. I'll use the tach-ch property from the fan-common.yaml
> > to solve my case. So I will not need to define a new vendor property as
> > "maxim,pwmout-pin-as-tach-input". I'll drop this [Path 3/3] in the patch
> > series v3.
> > 
> > 
> > > Best regards,
> > > Krzysztof
> > > 
> 
> 
> Hi Krzysztof,
> 
> I checked in the
> Documentation/devicetree/bindings/hwmon/fan-common.yaml. I found the
> tach-ch property, but it seems define the tach channel used for fan.
> 
>      tach-ch:
>      	description:
>        		The tach channel used for the fan.
>      	$ref: /schemas/types.yaml#/definitions/uint8-array
> 
> 
> In my purpose, I would like to configure the pwm output pins to become
> tachometer input pins by setting bit[0] in the Configuration Register.
> 
> 
> I think a vendor property is suitable for this purpose. It is only available
> on specific MAX31790 fan controllers and not on other fan controller
> devices. So I think we can't use the "tach-ch" in fan-common.yaml.

Can you explain why you think that only MAX31790 fan controllers are
capable of an arbitrary mapping of PWM outputs to TACH inputs?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2 3/3] dt-bindings: hwmon: max31790: Add maxim,pwmout-pin-as-tach-input property

[Chanh Nguyen]

On 24/04/2024 00:02, Conor Dooley wrote:
> [EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please be mindful of safe email handling and proprietary information protection practices.]
> 

Sorry Conor, there may be confusion here. I mean the mapping of the PWM 
output to the TACH input, which is on the MAX31790, and it is not sure a 
common feature on all fan controllers.

I would like to open a discussion about whether we should use the 
tach-ch property on the fan-common.yaml

I'm looking forward to hearing comments from everyone. For me, both 
tach-ch and vendor property are good.

Thank you, Conor!

Re: [PATCH v2 3/3] dt-bindings: hwmon: max31790: Add maxim,pwmout-pin-as-tach-input property

[Guenter Roeck]

On 4/25/24 03:33, Chanh Nguyen wrote:
> 
> 
> On 24/04/2024 00:02, Conor Dooley wrote:
>> [EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please be mindful of safe email handling and proprietary information protection practices.]
>>
> 

The quote doesn't make much sense.

> Sorry Conor, there may be confusion here. I mean the mapping of the PWM output to the TACH input, which is on the MAX31790, and it is not sure a common feature on all fan controllers.
> 

I think the term "mapping" is a bit confusing here.

tach-ch, as I understand it, is supposed to associate a tachometer input
with a pwm output, meaning the fan speed measured with the tachometer input
is expected to change if the pwm output changes.

On MAX31790, it is possible to configure a pwm output pin as tachometer input pin.
That is something completely different. Also, the association is fixed.
If the first pwm channel is used as tachometer channel, it would show up as 7th
tachometer channel. If the 6th pwm channel is configured to be used as tachometer
input, it would show up as 12th tachometer channel.

Overall, the total number of channels on MAX31790 is always 12. 6 of them
are always tachometer inputs, the others can be configured to either be a
pwm output or a tachometer input.

pwm outputs on MAX31790 are always tied to the matching tachometer inputs
(pwm1 <--> tach1 etc) and can not be reconfigured, meaning tach-ch for
channel X would always be X.

> I would like to open a discussion about whether we should use the tach-ch property on the fan-common.yaml
> 
> I'm looking forward to hearing comments from everyone. For me, both tach-ch and vendor property are good.
> 

I am not even sure how to define tach-ch to mean "use the pwm output pin
associated with this tachometer input channel not as pwm output
but as tachometer input". That would be a boolean, not a number.

Guenter

Re: [PATCH v2 3/3] dt-bindings: hwmon: max31790: Add maxim,pwmout-pin-as-tach-input property

[Krzysztof Kozlowski]

On 25/04/2024 16:05, Guenter Roeck wrote:
> On 4/25/24 03:33, Chanh Nguyen wrote:
>>
>>
>> On 24/04/2024 00:02, Conor Dooley wrote:
>>> [EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please be mindful of safe email handling and proprietary information protection practices.]
>>>
>>
> 
> The quote doesn't make much sense.
> 
>> Sorry Conor, there may be confusion here. I mean the mapping of the PWM output to the TACH input, which is on the MAX31790, and it is not sure a common feature on all fan controllers.
>>
> 
> I think the term "mapping" is a bit confusing here.
> 
> tach-ch, as I understand it, is supposed to associate a tachometer input
> with a pwm output, meaning the fan speed measured with the tachometer input
> is expected to change if the pwm output changes.
> 
> On MAX31790, it is possible to configure a pwm output pin as tachometer input pin.
> That is something completely different. Also, the association is fixed.
> If the first pwm channel is used as tachometer channel, it would show up as 7th
> tachometer channel. If the 6th pwm channel is configured to be used as tachometer
> input, it would show up as 12th tachometer channel.
> 
> Overall, the total number of channels on MAX31790 is always 12. 6 of them
> are always tachometer inputs, the others can be configured to either be a
> pwm output or a tachometer input.
> 
> pwm outputs on MAX31790 are always tied to the matching tachometer inputs
> (pwm1 <--> tach1 etc) and can not be reconfigured, meaning tach-ch for
> channel X would always be X.
> 
>> I would like to open a discussion about whether we should use the tach-ch property on the fan-common.yaml
>>
>> I'm looking forward to hearing comments from everyone. For me, both tach-ch and vendor property are good.
>>
> 
> I am not even sure how to define tach-ch to mean "use the pwm output pin
> associated with this tachometer input channel not as pwm output
> but as tachometer input". That would be a boolean, not a number.

Thanks for explanation. So this is basically pin controller function
choice - kind of output or input, although not in terms of GPIO.

Shouldn't we have then fan children which will be consumers of PWMs?
Having a consumer makes pin PWM output. Then tach-ch says which pins are
tachometer for given fan? Just like aspeed,g6-pwm-tach.yaml has?

Best regards,
Krzysztof

Re: [PATCH v2 3/3] dt-bindings: hwmon: max31790: Add maxim,pwmout-pin-as-tach-input property

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 3655 bytes --]

On Thu, Apr 25, 2024 at 05:46:02PM +0200, Krzysztof Kozlowski wrote:
> On 25/04/2024 16:05, Guenter Roeck wrote:
> > On 4/25/24 03:33, Chanh Nguyen wrote:
> >>
> >>
> >> On 24/04/2024 00:02, Conor Dooley wrote:
> >>> [EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please be mindful of safe email handling and proprietary information protection practices.]
> >>>
> >>
> > 
> > The quote doesn't make much sense.

The reply is to me questioning part of their earlier reply:
	> I think a vendor property is suitable for this purpose. It is only available
	> on specific MAX31790 fan controllers and not on other fan controller
	> devices. So I think we can't use the "tach-ch" in fan-common.yaml.

	Can you explain why you think that only MAX31790 fan controllers are
	capable of an arbitrary mapping of PWM outputs to TACH inputs?

> > 
> >> Sorry Conor, there may be confusion here. I mean the mapping of the PWM output to the TACH input, which is on the MAX31790, and it is not sure a common feature on all fan controllers.
> >>
> > 
> > I think the term "mapping" is a bit confusing here.
> > 
> > tach-ch, as I understand it, is supposed to associate a tachometer input
> > with a pwm output, meaning the fan speed measured with the tachometer input
> > is expected to change if the pwm output changes.
> > 
> > On MAX31790, it is possible to configure a pwm output pin as tachometer input pin.
> > That is something completely different. Also, the association is fixed.
> > If the first pwm channel is used as tachometer channel, it would show up as 7th
> > tachometer channel. If the 6th pwm channel is configured to be used as tachometer
> > input, it would show up as 12th tachometer channel.
> > 
> > Overall, the total number of channels on MAX31790 is always 12. 6 of them
> > are always tachometer inputs, the others can be configured to either be a
> > pwm output or a tachometer input.
> >

> > pwm outputs on MAX31790 are always tied to the matching tachometer inputs
> > (pwm1 <--> tach1 etc) and can not be reconfigured, meaning tach-ch for
> > channel X would always be X.

Are they? Granted, I probably didn't read this as well as you did, but
figure 3, 4 5 & 6 seem to show mappings that are not 1:1, with PWMOUT1
controlling several fans, each of which report back via a different tach
channel. I think the fan controller binding accounts for this though:
the child nodes would reference the same PWM provider but have different
tach-ch values.

> > 
> >> I would like to open a discussion about whether we should use the tach-ch property on the fan-common.yaml
> >>
> >> I'm looking forward to hearing comments from everyone. For me, both tach-ch and vendor property are good.
> >>
> > 
> > I am not even sure how to define tach-ch to mean "use the pwm output pin
> > associated with this tachometer input channel not as pwm output
> > but as tachometer input". That would be a boolean, not a number.
> 
> Thanks for explanation. So this is basically pin controller function
> choice - kind of output or input, although not in terms of GPIO.
> 

> Shouldn't we have then fan children which will be consumers of PWMs?

In this case, the max31790 has the PWM hardware, so it would be the
provider...

> Having a consumer makes pin PWM output. Then tach-ch says which pins are
> tachometer for given fan? Just like aspeed,g6-pwm-tach.yaml has?

...and it seems to me like there should be several fan child nodes as in
the aspeed binding you mention here that are the consumers. The binding
as written seems to only support a single fan.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2 3/3] dt-bindings: hwmon: max31790: Add maxim,pwmout-pin-as-tach-input property

[Chanh Nguyen]

On 25/04/2024 21:05, Guenter Roeck wrote:
> On 4/25/24 03:33, Chanh Nguyen wrote:
>>
>>
>> On 24/04/2024 00:02, Conor Dooley wrote:
>>> [EXTERNAL EMAIL NOTICE: This email originated from an external 
>>> sender. Please be mindful of safe email handling and proprietary 
>>> information protection practices.]
>>>
>>
> 
> The quote doesn't make much sense.
> 
>> Sorry Conor, there may be confusion here. I mean the mapping of the 
>> PWM output to the TACH input, which is on the MAX31790, and it is not 
>> sure a common feature on all fan controllers.
>>
> 
> I think the term "mapping" is a bit confusing here.
> 
> tach-ch, as I understand it, is supposed to associate a tachometer input
> with a pwm output, meaning the fan speed measured with the tachometer input
> is expected to change if the pwm output changes.
> 
> On MAX31790, it is possible to configure a pwm output pin as tachometer 
> input pin.
> That is something completely different. Also, the association is fixed.
> If the first pwm channel is used as tachometer channel, it would show up 
> as 7th
> tachometer channel. If the 6th pwm channel is configured to be used as 
> tachometer
> input, it would show up as 12th tachometer channel.
> 
> Overall, the total number of channels on MAX31790 is always 12. 6 of them
> are always tachometer inputs, the others can be configured to either be a
> pwm output or a tachometer input.

Thank you, Guenter, for your explanation. That is also my understanding 
of the MAX31790 feature.

So, I think we should introduce a vendor property to configure the pwm 
output pins to become tachometer input pins. We shouldn't use the 
tach-ch property. Because they are completely different, I think.

What's your idea ? Please help share me, Guenter


> 
> pwm outputs on MAX31790 are always tied to the matching tachometer inputs
> (pwm1 <--> tach1 etc) and can not be reconfigured, meaning tach-ch for
> channel X would always be X.
> 
>> I would like to open a discussion about whether we should use the 
>> tach-ch property on the fan-common.yaml
>>
>> I'm looking forward to hearing comments from everyone. For me, both 
>> tach-ch and vendor property are good.
>>
> 
> I am not even sure how to define tach-ch to mean "use the pwm output pin
> associated with this tachometer input channel not as pwm output
> but as tachometer input". That would be a boolean, not a number.
> 

Thank Guenter,

I reviewed again the "tach-ch" property, which is used in the 
https://elixir.bootlin.com/linux/v6.9-rc6/source/Documentation/devicetree/bindings/hwmon/aspeed,g6-pwm-tach.yaml#L68 
and 
https://elixir.bootlin.com/linux/v6.9-rc6/source/drivers/hwmon/aspeed-g6-pwm-tach.c#L434 


That is something completely different from my purpose.

> Guenter
> 

Re: [PATCH v2 3/3] dt-bindings: hwmon: max31790: Add maxim,pwmout-pin-as-tach-input property

[Guenter Roeck]

On 5/5/24 03:08, Chanh Nguyen wrote:
> 
> 
> On 25/04/2024 21:05, Guenter Roeck wrote:
>> On 4/25/24 03:33, Chanh Nguyen wrote:
>>>
>>>
>>> On 24/04/2024 00:02, Conor Dooley wrote:
>>>> [EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please be mindful of safe email handling and proprietary information protection practices.]
>>>>
>>>
>>
>> The quote doesn't make much sense.
>>
>>> Sorry Conor, there may be confusion here. I mean the mapping of the PWM output to the TACH input, which is on the MAX31790, and it is not sure a common feature on all fan controllers.
>>>
>>
>> I think the term "mapping" is a bit confusing here.
>>
>> tach-ch, as I understand it, is supposed to associate a tachometer input
>> with a pwm output, meaning the fan speed measured with the tachometer input
>> is expected to change if the pwm output changes.
>>
>> On MAX31790, it is possible to configure a pwm output pin as tachometer input pin.
>> That is something completely different. Also, the association is fixed.
>> If the first pwm channel is used as tachometer channel, it would show up as 7th
>> tachometer channel. If the 6th pwm channel is configured to be used as tachometer
>> input, it would show up as 12th tachometer channel.
>>
>> Overall, the total number of channels on MAX31790 is always 12. 6 of them
>> are always tachometer inputs, the others can be configured to either be a
>> pwm output or a tachometer input.
> 
> Thank you, Guenter, for your explanation. That is also my understanding of the MAX31790 feature.
> 
> So, I think we should introduce a vendor property to configure the pwm output pins to become tachometer input pins. We shouldn't use the tach-ch property. Because they are completely different, I think.
> 
> What's your idea ? Please help share me, Guenter
> 
> 
>>
>> pwm outputs on MAX31790 are always tied to the matching tachometer inputs
>> (pwm1 <--> tach1 etc) and can not be reconfigured, meaning tach-ch for
>> channel X would always be X.
>>
>>> I would like to open a discussion about whether we should use the tach-ch property on the fan-common.yaml
>>>
>>> I'm looking forward to hearing comments from everyone. For me, both tach-ch and vendor property are good.
>>>
>>
>> I am not even sure how to define tach-ch to mean "use the pwm output pin
>> associated with this tachometer input channel not as pwm output
>> but as tachometer input". That would be a boolean, not a number.
>>
> 
> Thank Guenter,
> 
> I reviewed again the "tach-ch" property, which is used in the https://elixir.bootlin.com/linux/v6.9-rc6/source/Documentation/devicetree/bindings/hwmon/aspeed,g6-pwm-tach.yaml#L68 and https://elixir.bootlin.com/linux/v6.9-rc6/source/drivers/hwmon/aspeed-g6-pwm-tach.c#L434
> 
> That is something completely different from my purpose.
> 

Based on its definition, tach-ch is associated with fans, and it looks
like the .yaml file groups multiple sets of fans into a single
fan node.

In the simple case that would be
	tach-ch = <1>
...
	tach-ch = <12>

or, if all fans are controlled by a single pwm
	tach-ch = <1 2 3 4 5 6 8 9 10 11 12>

The existence of tachometer channel 7..12 implies that pwm channel (tachometer
channel - 6) is used as tachometer channel. That should be sufficient to program
the chip for that channel. All you'd have to do is to ensure that pwm channel
"X" is not listed as tachometer channel "X + 6", and program pwm channel "X - 6"
for tachometer channels 7..12 as tachometer channels.

Hope this helps,
Guenter

Re: [PATCH v2 3/3] dt-bindings: hwmon: max31790: Add maxim,pwmout-pin-as-tach-input property

[Chanh Nguyen]

On 05/05/2024 22:40, Guenter Roeck wrote:
> On 5/5/24 03:08, Chanh Nguyen wrote:
>>
>>
>> On 25/04/2024 21:05, Guenter Roeck wrote:
>>> On 4/25/24 03:33, Chanh Nguyen wrote:
>>>>
>>>>
>>>> On 24/04/2024 00:02, Conor Dooley wrote:
>>>>> [EXTERNAL EMAIL NOTICE: This email originated from an external 
>>>>> sender. Please be mindful of safe email handling and proprietary 
>>>>> information protection practices.]
>>>>>
>>>>
>>>
>>> The quote doesn't make much sense.
>>>
>>>> Sorry Conor, there may be confusion here. I mean the mapping of the 
>>>> PWM output to the TACH input, which is on the MAX31790, and it is 
>>>> not sure a common feature on all fan controllers.
>>>>
>>>
>>> I think the term "mapping" is a bit confusing here.
>>>
>>> tach-ch, as I understand it, is supposed to associate a tachometer input
>>> with a pwm output, meaning the fan speed measured with the tachometer 
>>> input
>>> is expected to change if the pwm output changes.
>>>
>>> On MAX31790, it is possible to configure a pwm output pin as 
>>> tachometer input pin.
>>> That is something completely different. Also, the association is fixed.
>>> If the first pwm channel is used as tachometer channel, it would show 
>>> up as 7th
>>> tachometer channel. If the 6th pwm channel is configured to be used 
>>> as tachometer
>>> input, it would show up as 12th tachometer channel.
>>>
>>> Overall, the total number of channels on MAX31790 is always 12. 6 of 
>>> them
>>> are always tachometer inputs, the others can be configured to either 
>>> be a
>>> pwm output or a tachometer input.
>>
>> Thank you, Guenter, for your explanation. That is also my 
>> understanding of the MAX31790 feature.
>>
>> So, I think we should introduce a vendor property to configure the pwm 
>> output pins to become tachometer input pins. We shouldn't use the 
>> tach-ch property. Because they are completely different, I think.
>>
>> What's your idea ? Please help share me, Guenter
>>
>>
>>>
>>> pwm outputs on MAX31790 are always tied to the matching tachometer 
>>> inputs
>>> (pwm1 <--> tach1 etc) and can not be reconfigured, meaning tach-ch for
>>> channel X would always be X.
>>>
>>>> I would like to open a discussion about whether we should use the 
>>>> tach-ch property on the fan-common.yaml
>>>>
>>>> I'm looking forward to hearing comments from everyone. For me, both 
>>>> tach-ch and vendor property are good.
>>>>
>>>
>>> I am not even sure how to define tach-ch to mean "use the pwm output pin
>>> associated with this tachometer input channel not as pwm output
>>> but as tachometer input". That would be a boolean, not a number.
>>>
>>
>> Thank Guenter,
>>
>> I reviewed again the "tach-ch" property, which is used in the 
>> https://elixir.bootlin.com/linux/v6.9-rc6/source/Documentation/devicetree/bindings/hwmon/aspeed,g6-pwm-tach.yaml#L68 and https://elixir.bootlin.com/linux/v6.9-rc6/source/drivers/hwmon/aspeed-g6-pwm-tach.c#L434
>>
>> That is something completely different from my purpose.
>>
> 
> Based on its definition, tach-ch is associated with fans, and it looks
> like the .yaml file groups multiple sets of fans into a single
> fan node.
> 
> In the simple case that would be
>      tach-ch = <1>
> ...
>      tach-ch = <12>
> 
> or, if all fans are controlled by a single pwm
>      tach-ch = <1 2 3 4 5 6 8 9 10 11 12>
> 
> The existence of tachometer channel 7..12 implies that pwm channel 
> (tachometer
> channel - 6) is used as tachometer channel. That should be sufficient to 
> program
> the chip for that channel. All you'd have to do is to ensure that pwm 
> channel
> "X" is not listed as tachometer channel "X + 6", and program pwm channel 
> "X - 6"
> for tachometer channels 7..12 as tachometer channels.
> 

Hi Guenter,

I applied the patch [2/3] in my patch series 
(https://lore.kernel.org/lkml/20240414042246.8681-3-chanh@os.amperecomputing.com/)

My device tree is configured as below, I would like to configure PWMOUT 
pins 5 and 6 to become the tachometer input pins.

        fan-controller@20 {
          compatible = "maxim,max31790";
          reg = <0x20>;
          maxim,pwmout-pin-as-tach-input = /bits/ 8 <0 0 0 0 1 1>;
        };

The sysfs is generated by the max31790 driver are shown below. We can 
see the PWM5 and PWM6 are not visible, and the fan11 and fan12 are 
visible. And all FAN devices are on my system, which worked as expected.

root@my-platform:/sys/class/hwmon/hwmon14# ls
device       fan12_input  fan1_target  fan2_target  fan3_target 
fan4_target  fan6_enable  of_node      pwm2         pwm4
fan11_fault  fan1_enable  fan2_enable  fan3_enable  fan4_enable 
fan5_enable  fan6_fault   power        pwm2_enable  pwm4_enable
fan11_input  fan1_fault   fan2_fault   fan3_fault   fan4_fault 
fan5_fault   fan6_input   pwm1         pwm3         subsystem
fan12_fault  fan1_input   fan2_input   fan3_input   fan4_input 
fan5_input   name         pwm1_enable  pwm3_enable  uevent

Please share your comments!

> Hope this helps,
> Guenter
> 

Re: [PATCH v2 3/3] dt-bindings: hwmon: max31790: Add maxim,pwmout-pin-as-tach-input property

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 4884 bytes --]

On Wed, May 08, 2024 at 10:44:34AM +0700, Chanh Nguyen wrote:
> On 05/05/2024 22:40, Guenter Roeck wrote:
> > On 5/5/24 03:08, Chanh Nguyen wrote:
> > > On 25/04/2024 21:05, Guenter Roeck wrote:
> > > > On 4/25/24 03:33, Chanh Nguyen wrote:
> > > > 
> > > > pwm outputs on MAX31790 are always tied to the matching
> > > > tachometer inputs
> > > > (pwm1 <--> tach1 etc) and can not be reconfigured, meaning tach-ch for
> > > > channel X would always be X.
> > > > 
> > > > > I would like to open a discussion about whether we should
> > > > > use the tach-ch property on the fan-common.yaml
> > > > > 
> > > > > I'm looking forward to hearing comments from everyone. For
> > > > > me, both tach-ch and vendor property are good.
> > > > > 
> > > > 
> > > > I am not even sure how to define tach-ch to mean "use the pwm output pin
> > > > associated with this tachometer input channel not as pwm output
> > > > but as tachometer input". That would be a boolean, not a number.
> > > > 
> > > 
> > > Thank Guenter,
> > > 
> > > I reviewed again the "tach-ch" property, which is used in the https://elixir.bootlin.com/linux/v6.9-rc6/source/Documentation/devicetree/bindings/hwmon/aspeed,g6-pwm-tach.yaml#L68
> > > and https://elixir.bootlin.com/linux/v6.9-rc6/source/drivers/hwmon/aspeed-g6-pwm-tach.c#L434
> > > 
> > > That is something completely different from my purpose.
> > > 
> > 
> > Based on its definition, tach-ch is associated with fans, and it looks
> > like the .yaml file groups multiple sets of fans into a single
> > fan node.
> > 
> > In the simple case that would be
> >      tach-ch = <1>
> > ...
> >      tach-ch = <12>
> > 
> > or, if all fans are controlled by a single pwm
> >      tach-ch = <1 2 3 4 5 6 8 9 10 11 12>
> > 
> > The existence of tachometer channel 7..12 implies that pwm channel
> > (tachometer
> > channel - 6) is used as tachometer channel. That should be sufficient to
> > program
> > the chip for that channel. All you'd have to do is to ensure that pwm
> > channel
> > "X" is not listed as tachometer channel "X + 6", and program pwm channel
> > "X - 6"
> > for tachometer channels 7..12 as tachometer channels.
> > 
> 
> Hi Guenter,
> 
> I applied the patch [2/3] in my patch series (https://lore.kernel.org/lkml/20240414042246.8681-3-chanh@os.amperecomputing.com/)
> 
> My device tree is configured as below, I would like to configure PWMOUT pins
> 5 and 6 to become the tachometer input pins.
> 
>        fan-controller@20 {
>          compatible = "maxim,max31790";
>          reg = <0x20>;
>          maxim,pwmout-pin-as-tach-input = /bits/ 8 <0 0 0 0 1 1>;
>        };

Why are you still operating off a binding that looks like this? I
thought that both I and Krzysztof told you to go and take a look at how
the aspeed,g6-pwm-tach.yaml binding looped and do something similar
here. You'd end up with something like:

        fan-controller@20 {
          compatible = "maxim,max31790";
          reg = <0x20>;

          fan-0 {
            pwms = <&pwm-provider ...>;
            tach-ch = 6;
        };

          fan-1 {
            pwms = <&pwm-provider ...>;
            tach-ch = 7;
        };
};

You can, as tach-ch or pwms do not need to be unique, set multiple
channels up as using the same tachs and/or pwms.
In the case of this particular fan controller, I think that the max31790
is actually the pwm provider so you'd modify it something like:

        pwm-provider: fan-controller@20 {
          compatible = "maxim,max31790";
          reg = <0x20>;
	  #pwm-cells = <N>;

          fan-0 {
            pwms = <&pwm-provider ...>;
            tach-ch = <6>;
        };

          fan-1 {
            pwms = <&pwm-provider ...>;
            tach-ch = <7>;
        };
};

I just wrote this in my mail client's editor, so it may not be not
valid, but it is how the fan bindings expect you to represent this kind
of scenario.

Cheers,
Conor.

> 
> The sysfs is generated by the max31790 driver are shown below. We can see
> the PWM5 and PWM6 are not visible, and the fan11 and fan12 are visible. And
> all FAN devices are on my system, which worked as expected.
> 
> root@my-platform:/sys/class/hwmon/hwmon14# ls
> device       fan12_input  fan1_target  fan2_target  fan3_target fan4_target
> fan6_enable  of_node      pwm2         pwm4
> fan11_fault  fan1_enable  fan2_enable  fan3_enable  fan4_enable fan5_enable
> fan6_fault   power        pwm2_enable  pwm4_enable
> fan11_input  fan1_fault   fan2_fault   fan3_fault   fan4_fault fan5_fault
> fan6_input   pwm1         pwm3         subsystem
> fan12_fault  fan1_input   fan2_input   fan3_input   fan4_input fan5_input
> name         pwm1_enable  pwm3_enable  uevent
> 
> Please share your comments!
> 
> > Hope this helps,
> > Guenter
> > 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2 3/3] dt-bindings: hwmon: max31790: Add maxim,pwmout-pin-as-tach-input property

[Chanh Nguyen]

On 08/05/2024 23:47, Conor Dooley wrote:
> On Wed, May 08, 2024 at 10:44:34AM +0700, Chanh Nguyen wrote:
>> On 05/05/2024 22:40, Guenter Roeck wrote:
>>> On 5/5/24 03:08, Chanh Nguyen wrote:
>>>> On 25/04/2024 21:05, Guenter Roeck wrote:
>>>>> On 4/25/24 03:33, Chanh Nguyen wrote:
>>>>>
>>>>> pwm outputs on MAX31790 are always tied to the matching
>>>>> tachometer inputs
>>>>> (pwm1 <--> tach1 etc) and can not be reconfigured, meaning tach-ch for
>>>>> channel X would always be X.
>>>>>
>>>>>> I would like to open a discussion about whether we should
>>>>>> use the tach-ch property on the fan-common.yaml
>>>>>>
>>>>>> I'm looking forward to hearing comments from everyone. For
>>>>>> me, both tach-ch and vendor property are good.
>>>>>>
>>>>>
>>>>> I am not even sure how to define tach-ch to mean "use the pwm output pin
>>>>> associated with this tachometer input channel not as pwm output
>>>>> but as tachometer input". That would be a boolean, not a number.
>>>>>
>>>>
>>>> Thank Guenter,
>>>>
>>>> I reviewed again the "tach-ch" property, which is used in the https://elixir.bootlin.com/linux/v6.9-rc6/source/Documentation/devicetree/bindings/hwmon/aspeed,g6-pwm-tach.yaml#L68
>>>> and https://elixir.bootlin.com/linux/v6.9-rc6/source/drivers/hwmon/aspeed-g6-pwm-tach.c#L434
>>>>
>>>> That is something completely different from my purpose.
>>>>
>>>
>>> Based on its definition, tach-ch is associated with fans, and it looks
>>> like the .yaml file groups multiple sets of fans into a single
>>> fan node.
>>>
>>> In the simple case that would be
>>>       tach-ch = <1>
>>> ...
>>>       tach-ch = <12>
>>>
>>> or, if all fans are controlled by a single pwm
>>>       tach-ch = <1 2 3 4 5 6 8 9 10 11 12>
>>>
>>> The existence of tachometer channel 7..12 implies that pwm channel
>>> (tachometer
>>> channel - 6) is used as tachometer channel. That should be sufficient to
>>> program
>>> the chip for that channel. All you'd have to do is to ensure that pwm
>>> channel
>>> "X" is not listed as tachometer channel "X + 6", and program pwm channel
>>> "X - 6"
>>> for tachometer channels 7..12 as tachometer channels.
>>>
>>
>> Hi Guenter,
>>
>> I applied the patch [2/3] in my patch series (https://lore.kernel.org/lkml/20240414042246.8681-3-chanh@os.amperecomputing.com/)
>>
>> My device tree is configured as below, I would like to configure PWMOUT pins
>> 5 and 6 to become the tachometer input pins.
>>
>>         fan-controller@20 {
>>           compatible = "maxim,max31790";
>>           reg = <0x20>;
>>           maxim,pwmout-pin-as-tach-input = /bits/ 8 <0 0 0 0 1 1>;
>>         };
> 
> Why are you still operating off a binding that looks like this? I
> thought that both I and Krzysztof told you to go and take a look at how
> the aspeed,g6-pwm-tach.yaml binding looped and do something similar
> here. You'd end up with something like:
> 
>          fan-controller@20 {
>            compatible = "maxim,max31790";
>            reg = <0x20>;
> 
>            fan-0 {
>              pwms = <&pwm-provider ...>;
>              tach-ch = 6;
>          };
> 
>            fan-1 {
>              pwms = <&pwm-provider ...>;
>              tach-ch = 7;
>          };
> };
> 
> You can, as tach-ch or pwms do not need to be unique, set multiple
> channels up as using the same tachs and/or pwms.
> In the case of this particular fan controller, I think that the max31790
> is actually the pwm provider so you'd modify it something like:
> 
>          pwm-provider: fan-controller@20 {
>            compatible = "maxim,max31790";
>            reg = <0x20>;
> 	  #pwm-cells = <N>;
> 
>            fan-0 {
>              pwms = <&pwm-provider ...>;
>              tach-ch = <6>;
>          };
> 
>            fan-1 {
>              pwms = <&pwm-provider ...>;
>              tach-ch = <7>;
>          };
> };
> 
> I just wrote this in my mail client's editor, so it may not be not
> valid, but it is how the fan bindings expect you to represent this kind
> of scenario.
> 

My apologies for the late reply.

Thank you, Conor, for your recommendation!

I spend more time checking the aspeed,g6-pwm-tach.yaml . Finally, I'll 
support the child nodes by having different tach-ch values. My system is 
designed similar to Figure 6 (8 Tach Monitors, 4PMWs).

I'm going to push the patch series v3 soon.

This is a brief binding.
....
properties:
   compatible:
     const: maxim,max31790

   reg:
     maxItems: 1

   clocks:
     maxItems: 1

   resets:
     maxItems: 1

patternProperties:
   "^fan-[0-9]+$":
     $ref: fan-common.yaml#
     unevaluatedProperties: false

required:
   - compatible
   - reg

additionalProperties: false

examples:
   - |
     i2c {
       #address-cells = <1>;
       #size-cells = <0>;

       pwm_provider: fan-controller@20 {
         compatible = "maxim,max31790";
         reg = <0x20>;
         clocks = <&sys_clk>;
         resets = <&reset 0>;

         fan-0 {
           pwms = <&pwm_provider 1>;
           tach-ch = <1 2>;
         };

         fan-1 {
           pwms = <&pwm_provider 2>;
           tach-ch = <7 8>;
         };
       };
     };


As your example, I saw the #pwm-cells = <N> . Please let me know, what's 
the purpose of this property?

Thanks!

Chanh Ng


> Cheers,
> Conor.
> 
>>
>> The sysfs is generated by the max31790 driver are shown below. We can see
>> the PWM5 and PWM6 are not visible, and the fan11 and fan12 are visible. And
>> all FAN devices are on my system, which worked as expected.
>>
>> root@my-platform:/sys/class/hwmon/hwmon14# ls
>> device       fan12_input  fan1_target  fan2_target  fan3_target fan4_target
>> fan6_enable  of_node      pwm2         pwm4
>> fan11_fault  fan1_enable  fan2_enable  fan3_enable  fan4_enable fan5_enable
>> fan6_fault   power        pwm2_enable  pwm4_enable
>> fan11_input  fan1_fault   fan2_fault   fan3_fault   fan4_fault fan5_fault
>> fan6_input   pwm1         pwm3         subsystem
>> fan12_fault  fan1_input   fan2_input   fan3_input   fan4_input fan5_input
>> name         pwm1_enable  pwm3_enable  uevent
>>
>> Please share your comments!
>>
>>> Hope this helps,
>>> Guenter
>>>

Re: [PATCH v2 3/3] dt-bindings: hwmon: max31790: Add maxim,pwmout-pin-as-tach-input property

[Guenter Roeck]

On 6/7/24 09:47, Chanh Nguyen wrote:
> 
> 
> On 08/05/2024 23:47, Conor Dooley wrote:
>> On Wed, May 08, 2024 at 10:44:34AM +0700, Chanh Nguyen wrote:
>>> On 05/05/2024 22:40, Guenter Roeck wrote:
>>>> On 5/5/24 03:08, Chanh Nguyen wrote:
>>>>> On 25/04/2024 21:05, Guenter Roeck wrote:
>>>>>> On 4/25/24 03:33, Chanh Nguyen wrote:
>>>>>>
>>>>>> pwm outputs on MAX31790 are always tied to the matching
>>>>>> tachometer inputs
>>>>>> (pwm1 <--> tach1 etc) and can not be reconfigured, meaning tach-ch for
>>>>>> channel X would always be X.
>>>>>>
>>>>>>> I would like to open a discussion about whether we should
>>>>>>> use the tach-ch property on the fan-common.yaml
>>>>>>>
>>>>>>> I'm looking forward to hearing comments from everyone. For
>>>>>>> me, both tach-ch and vendor property are good.
>>>>>>>
>>>>>>
>>>>>> I am not even sure how to define tach-ch to mean "use the pwm output pin
>>>>>> associated with this tachometer input channel not as pwm output
>>>>>> but as tachometer input". That would be a boolean, not a number.
>>>>>>
>>>>>
>>>>> Thank Guenter,
>>>>>
>>>>> I reviewed again the "tach-ch" property, which is used in the https://elixir.bootlin.com/linux/v6.9-rc6/source/Documentation/devicetree/bindings/hwmon/aspeed,g6-pwm-tach.yaml#L68
>>>>> and https://elixir.bootlin.com/linux/v6.9-rc6/source/drivers/hwmon/aspeed-g6-pwm-tach.c#L434
>>>>>
>>>>> That is something completely different from my purpose.
>>>>>
>>>>
>>>> Based on its definition, tach-ch is associated with fans, and it looks
>>>> like the .yaml file groups multiple sets of fans into a single
>>>> fan node.
>>>>
>>>> In the simple case that would be
>>>>       tach-ch = <1>
>>>> ...
>>>>       tach-ch = <12>
>>>>
>>>> or, if all fans are controlled by a single pwm
>>>>       tach-ch = <1 2 3 4 5 6 8 9 10 11 12>
>>>>
>>>> The existence of tachometer channel 7..12 implies that pwm channel
>>>> (tachometer
>>>> channel - 6) is used as tachometer channel. That should be sufficient to
>>>> program
>>>> the chip for that channel. All you'd have to do is to ensure that pwm
>>>> channel
>>>> "X" is not listed as tachometer channel "X + 6", and program pwm channel
>>>> "X - 6"
>>>> for tachometer channels 7..12 as tachometer channels.
>>>>
>>>
>>> Hi Guenter,
>>>
>>> I applied the patch [2/3] in my patch series (https://lore.kernel.org/lkml/20240414042246.8681-3-chanh@os.amperecomputing.com/)
>>>
>>> My device tree is configured as below, I would like to configure PWMOUT pins
>>> 5 and 6 to become the tachometer input pins.
>>>
>>>         fan-controller@20 {
>>>           compatible = "maxim,max31790";
>>>           reg = <0x20>;
>>>           maxim,pwmout-pin-as-tach-input = /bits/ 8 <0 0 0 0 1 1>;
>>>         };
>>
>> Why are you still operating off a binding that looks like this? I
>> thought that both I and Krzysztof told you to go and take a look at how
>> the aspeed,g6-pwm-tach.yaml binding looped and do something similar
>> here. You'd end up with something like:
>>
>>          fan-controller@20 {
>>            compatible = "maxim,max31790";
>>            reg = <0x20>;
>>
>>            fan-0 {
>>              pwms = <&pwm-provider ...>;
>>              tach-ch = 6;
>>          };
>>
>>            fan-1 {
>>              pwms = <&pwm-provider ...>;
>>              tach-ch = 7;
>>          };
>> };
>>
>> You can, as tach-ch or pwms do not need to be unique, set multiple
>> channels up as using the same tachs and/or pwms.
>> In the case of this particular fan controller, I think that the max31790
>> is actually the pwm provider so you'd modify it something like:
>>
>>          pwm-provider: fan-controller@20 {
>>            compatible = "maxim,max31790";
>>            reg = <0x20>;
>>       #pwm-cells = <N>;
>>
>>            fan-0 {
>>              pwms = <&pwm-provider ...>;
>>              tach-ch = <6>;
>>          };
>>
>>            fan-1 {
>>              pwms = <&pwm-provider ...>;
>>              tach-ch = <7>;
>>          };
>> };
>>
>> I just wrote this in my mail client's editor, so it may not be not
>> valid, but it is how the fan bindings expect you to represent this kind
>> of scenario.
>>
> 
> My apologies for the late reply.
> 
> Thank you, Conor, for your recommendation!
> 
> I spend more time checking the aspeed,g6-pwm-tach.yaml . Finally, I'll support the child nodes by having different tach-ch values. My system is designed similar to Figure 6 (8 Tach Monitors, 4PMWs).
> 
> I'm going to push the patch series v3 soon.
> 
> This is a brief binding.
> ....
> properties:
>    compatible:
>      const: maxim,max31790
> 
>    reg:
>      maxItems: 1
> 
>    clocks:
>      maxItems: 1
> 
>    resets:
>      maxItems: 1
> 
> patternProperties:
>    "^fan-[0-9]+$":
>      $ref: fan-common.yaml#
>      unevaluatedProperties: false
> 
> required:
>    - compatible
>    - reg
> 
> additionalProperties: false
> 
> examples:
>    - |
>      i2c {
>        #address-cells = <1>;
>        #size-cells = <0>;
> 
>        pwm_provider: fan-controller@20 {
>          compatible = "maxim,max31790";
>          reg = <0x20>;
>          clocks = <&sys_clk>;
>          resets = <&reset 0>;
> 
>          fan-0 {
>            pwms = <&pwm_provider 1>;
>            tach-ch = <1 2>;
>          };
> 
>          fan-1 {
>            pwms = <&pwm_provider 2>;
>            tach-ch = <7 8>;
>          };
>        };
>      };
> 
> 
> As your example, I saw the #pwm-cells = <N> . Please let me know, what's the purpose of this property?
> 

It is the number of fields in "pwms" after the provider reference.
In your case it would be 1 (the index). If the pwm has additional
configuration parameters such as the frequency or polarity there
would be additional entries.

Guenter

Re: [PATCH v2 3/3] dt-bindings: hwmon: max31790: Add maxim,pwmout-pin-as-tach-input property

[Chanh Nguyen]

On 08/06/2024 06:14, Guenter Roeck wrote:
> On 6/7/24 09:47, Chanh Nguyen wrote:
>>
>>
>> On 08/05/2024 23:47, Conor Dooley wrote:
>>> On Wed, May 08, 2024 at 10:44:34AM +0700, Chanh Nguyen wrote:
>>>> On 05/05/2024 22:40, Guenter Roeck wrote:
>>>>> On 5/5/24 03:08, Chanh Nguyen wrote:
>>>>>> On 25/04/2024 21:05, Guenter Roeck wrote:
>>>>>>> On 4/25/24 03:33, Chanh Nguyen wrote:
>>>>>>>
>>>>>>> pwm outputs on MAX31790 are always tied to the matching
>>>>>>> tachometer inputs
>>>>>>> (pwm1 <--> tach1 etc) and can not be reconfigured, meaning 
>>>>>>> tach-ch for
>>>>>>> channel X would always be X.
>>>>>>>
>>>>>>>> I would like to open a discussion about whether we should
>>>>>>>> use the tach-ch property on the fan-common.yaml
>>>>>>>>
>>>>>>>> I'm looking forward to hearing comments from everyone. For
>>>>>>>> me, both tach-ch and vendor property are good.
>>>>>>>>
>>>>>>>
>>>>>>> I am not even sure how to define tach-ch to mean "use the pwm 
>>>>>>> output pin
>>>>>>> associated with this tachometer input channel not as pwm output
>>>>>>> but as tachometer input". That would be a boolean, not a number.
>>>>>>>
>>>>>>
>>>>>> Thank Guenter,
>>>>>>
>>>>>> I reviewed again the "tach-ch" property, which is used in the 
>>>>>> https://elixir.bootlin.com/linux/v6.9-rc6/source/Documentation/devicetree/bindings/hwmon/aspeed,g6-pwm-tach.yaml#L68
>>>>>> and 
>>>>>> https://elixir.bootlin.com/linux/v6.9-rc6/source/drivers/hwmon/aspeed-g6-pwm-tach.c#L434
>>>>>>
>>>>>> That is something completely different from my purpose.
>>>>>>
>>>>>
>>>>> Based on its definition, tach-ch is associated with fans, and it looks
>>>>> like the .yaml file groups multiple sets of fans into a single
>>>>> fan node.
>>>>>
>>>>> In the simple case that would be
>>>>>       tach-ch = <1>
>>>>> ...
>>>>>       tach-ch = <12>
>>>>>
>>>>> or, if all fans are controlled by a single pwm
>>>>>       tach-ch = <1 2 3 4 5 6 8 9 10 11 12>
>>>>>
>>>>> The existence of tachometer channel 7..12 implies that pwm channel
>>>>> (tachometer
>>>>> channel - 6) is used as tachometer channel. That should be 
>>>>> sufficient to
>>>>> program
>>>>> the chip for that channel. All you'd have to do is to ensure that pwm
>>>>> channel
>>>>> "X" is not listed as tachometer channel "X + 6", and program pwm 
>>>>> channel
>>>>> "X - 6"
>>>>> for tachometer channels 7..12 as tachometer channels.
>>>>>
>>>>
>>>> Hi Guenter,
>>>>
>>>> I applied the patch [2/3] in my patch series 
>>>> (https://lore.kernel.org/lkml/20240414042246.8681-3-chanh@os.amperecomputing.com/)
>>>>
>>>> My device tree is configured as below, I would like to configure 
>>>> PWMOUT pins
>>>> 5 and 6 to become the tachometer input pins.
>>>>
>>>>         fan-controller@20 {
>>>>           compatible = "maxim,max31790";
>>>>           reg = <0x20>;
>>>>           maxim,pwmout-pin-as-tach-input = /bits/ 8 <0 0 0 0 1 1>;
>>>>         };
>>>
>>> Why are you still operating off a binding that looks like this? I
>>> thought that both I and Krzysztof told you to go and take a look at how
>>> the aspeed,g6-pwm-tach.yaml binding looped and do something similar
>>> here. You'd end up with something like:
>>>
>>>          fan-controller@20 {
>>>            compatible = "maxim,max31790";
>>>            reg = <0x20>;
>>>
>>>            fan-0 {
>>>              pwms = <&pwm-provider ...>;
>>>              tach-ch = 6;
>>>          };
>>>
>>>            fan-1 {
>>>              pwms = <&pwm-provider ...>;
>>>              tach-ch = 7;
>>>          };
>>> };
>>>
>>> You can, as tach-ch or pwms do not need to be unique, set multiple
>>> channels up as using the same tachs and/or pwms.
>>> In the case of this particular fan controller, I think that the max31790
>>> is actually the pwm provider so you'd modify it something like:
>>>
>>>          pwm-provider: fan-controller@20 {
>>>            compatible = "maxim,max31790";
>>>            reg = <0x20>;
>>>       #pwm-cells = <N>;
>>>
>>>            fan-0 {
>>>              pwms = <&pwm-provider ...>;
>>>              tach-ch = <6>;
>>>          };
>>>
>>>            fan-1 {
>>>              pwms = <&pwm-provider ...>;
>>>              tach-ch = <7>;
>>>          };
>>> };
>>>
>>> I just wrote this in my mail client's editor, so it may not be not
>>> valid, but it is how the fan bindings expect you to represent this kind
>>> of scenario.
>>>
>>
>> My apologies for the late reply.
>>
>> Thank you, Conor, for your recommendation!
>>
>> I spend more time checking the aspeed,g6-pwm-tach.yaml . Finally, I'll 
>> support the child nodes by having different tach-ch values. My system 
>> is designed similar to Figure 6 (8 Tach Monitors, 4PMWs).
>>
>> I'm going to push the patch series v3 soon.
>>
>> This is a brief binding.
>> ....
>> properties:
>>    compatible:
>>      const: maxim,max31790
>>
>>    reg:
>>      maxItems: 1
>>
>>    clocks:
>>      maxItems: 1
>>
>>    resets:
>>      maxItems: 1
>>
>> patternProperties:
>>    "^fan-[0-9]+$":
>>      $ref: fan-common.yaml#
>>      unevaluatedProperties: false
>>
>> required:
>>    - compatible
>>    - reg
>>
>> additionalProperties: false
>>
>> examples:
>>    - |
>>      i2c {
>>        #address-cells = <1>;
>>        #size-cells = <0>;
>>
>>        pwm_provider: fan-controller@20 {
>>          compatible = "maxim,max31790";
>>          reg = <0x20>;
>>          clocks = <&sys_clk>;
>>          resets = <&reset 0>;
>>
>>          fan-0 {
>>            pwms = <&pwm_provider 1>;
>>            tach-ch = <1 2>;
>>          };
>>
>>          fan-1 {
>>            pwms = <&pwm_provider 2>;
>>            tach-ch = <7 8>;
>>          };
>>        };
>>      };
>>
>>
>> As your example, I saw the #pwm-cells = <N> . Please let me know, 
>> what's the purpose of this property?
>>
> 
> It is the number of fields in "pwms" after the provider reference.
> In your case it would be 1 (the index). If the pwm has additional
> configuration parameters such as the frequency or polarity there
> would be additional entries.
> 

Thank Guenter very much!

Please help review my binding. I'm looking forward to hearing any of 
your comments.

I'll update all comments on patch series v3 and push for review soon.

The patch series includes two commits:

[PATH 1/2] dt-bindings: hwmon: Add maxim max31790
[PATH 2/2] hwmon: (max31790): Support config PWM becomes TACH by tach-ch


Thanks,
Chanh Ng


> Guenter
> 

Re: [PATCH v2 3/3] dt-bindings: hwmon: max31790: Add maxim,pwmout-pin-as-tach-input property

[Krzysztof Kozlowski]

On 08/05/2024 05:44, Chanh Nguyen wrote:
>>>>>
>>>>
>>>> I am not even sure how to define tach-ch to mean "use the pwm output pin
>>>> associated with this tachometer input channel not as pwm output
>>>> but as tachometer input". That would be a boolean, not a number.
>>>>
>>>
>>> Thank Guenter,
>>>
>>> I reviewed again the "tach-ch" property, which is used in the 
>>> https://elixir.bootlin.com/linux/v6.9-rc6/source/Documentation/devicetree/bindings/hwmon/aspeed,g6-pwm-tach.yaml#L68 and https://elixir.bootlin.com/linux/v6.9-rc6/source/drivers/hwmon/aspeed-g6-pwm-tach.c#L434
>>>
>>> That is something completely different from my purpose.
>>>
>>
>> Based on its definition, tach-ch is associated with fans, and it looks
>> like the .yaml file groups multiple sets of fans into a single
>> fan node.
>>
>> In the simple case that would be
>>      tach-ch = <1>
>> ...
>>      tach-ch = <12>
>>
>> or, if all fans are controlled by a single pwm
>>      tach-ch = <1 2 3 4 5 6 8 9 10 11 12>
>>
>> The existence of tachometer channel 7..12 implies that pwm channel 
>> (tachometer
>> channel - 6) is used as tachometer channel. That should be sufficient to 
>> program
>> the chip for that channel. All you'd have to do is to ensure that pwm 
>> channel
>> "X" is not listed as tachometer channel "X + 6", and program pwm channel 
>> "X - 6"
>> for tachometer channels 7..12 as tachometer channels.
>>
> 
> Hi Guenter,
> 
> I applied the patch [2/3] in my patch series 
> (https://lore.kernel.org/lkml/20240414042246.8681-3-chanh@os.amperecomputing.com/)
> 
> My device tree is configured as below, I would like to configure PWMOUT 
> pins 5 and 6 to become the tachometer input pins.
> 

And what is wrong in described common tach-ch property? I think we
explained it three times and you did not provide any arguments, what's
missing. Instead you say "I want something like this in DTS" which is
not an argument and does not help discussion.

Best regards,
Krzysztof

Re: [PATCH v2 3/3] dt-bindings: hwmon: max31790: Add maxim,pwmout-pin-as-tach-input property

[Chanh Nguyen]

On 09/05/2024 15:29, Krzysztof Kozlowski wrote:
> On 08/05/2024 05:44, Chanh Nguyen wrote:
>>>>>>
>>>>>
>>>>> I am not even sure how to define tach-ch to mean "use the pwm output pin
>>>>> associated with this tachometer input channel not as pwm output
>>>>> but as tachometer input". That would be a boolean, not a number.
>>>>>
>>>>
>>>> Thank Guenter,
>>>>
>>>> I reviewed again the "tach-ch" property, which is used in the
>>>> https://elixir.bootlin.com/linux/v6.9-rc6/source/Documentation/devicetree/bindings/hwmon/aspeed,g6-pwm-tach.yaml#L68 and https://elixir.bootlin.com/linux/v6.9-rc6/source/drivers/hwmon/aspeed-g6-pwm-tach.c#L434
>>>>
>>>> That is something completely different from my purpose.
>>>>
>>>
>>> Based on its definition, tach-ch is associated with fans, and it looks
>>> like the .yaml file groups multiple sets of fans into a single
>>> fan node.
>>>
>>> In the simple case that would be
>>>       tach-ch = <1>
>>> ...
>>>       tach-ch = <12>
>>>
>>> or, if all fans are controlled by a single pwm
>>>       tach-ch = <1 2 3 4 5 6 8 9 10 11 12>
>>>
>>> The existence of tachometer channel 7..12 implies that pwm channel
>>> (tachometer
>>> channel - 6) is used as tachometer channel. That should be sufficient to
>>> program
>>> the chip for that channel. All you'd have to do is to ensure that pwm
>>> channel
>>> "X" is not listed as tachometer channel "X + 6", and program pwm channel
>>> "X - 6"
>>> for tachometer channels 7..12 as tachometer channels.
>>>
>>
>> Hi Guenter,
>>
>> I applied the patch [2/3] in my patch series
>> (https://lore.kernel.org/lkml/20240414042246.8681-3-chanh@os.amperecomputing.com/)
>>
>> My device tree is configured as below, I would like to configure PWMOUT
>> pins 5 and 6 to become the tachometer input pins.
>>
> 
> And what is wrong in described common tach-ch property? I think we
> explained it three times and you did not provide any arguments, what's
> missing. Instead you say "I want something like this in DTS" which is
> not an argument and does not help discussion.
> 

Hi Krzysztof,

Apologies for any inconvenience caused by the delayed response.

I'll to support the child nodes by having different tach-ch values. I 
suggest the child nodes and the "tach-ch" is optional, it will not be 
added to "required:". Do you have any comments? Please help me share!

This is a brief binding
...
properties:
   compatible:
     const: maxim,max31790

   reg:
     maxItems: 1

   clocks:
     maxItems: 1

   resets:
     maxItems: 1

patternProperties:
   "^fan-[0-9]+$":
     $ref: fan-common.yaml#
     unevaluatedProperties: false

required:
   - compatible
   - reg

additionalProperties: false

examples:
   - |
     i2c {
       #address-cells = <1>;
       #size-cells = <0>;

       pwm_provider: fan-controller@20 {
         compatible = "maxim,max31790";
         reg = <0x20>;
         clocks = <&sys_clk>;
         resets = <&reset 0>;

         fan-0 {
           pwms = <&pwm_provider 1>;
           tach-ch = <1 2>;
         };

         fan-1 {
           pwms = <&pwm_provider 2>;
           tach-ch = <7 8>;
         };
       };
     };


If it's OK, I'm going to push the patch series v3 soon.

Thanks,
Chanh Ng

> Best regards,
> Krzysztof
>