From: Chanh Nguyen <chanh@amperemail.onmicrosoft.com>
To: Guenter Roeck <linux@roeck-us.net>, Conor Dooley <conor@kernel.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
Chanh Nguyen <chanh@os.amperecomputing.com>,
Jean Delvare <jdelvare@suse.com>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Justin Ledford <justinledford@google.com>,
devicetree@vger.kernel.org, linux-hwmon@vger.kernel.org,
linux-kernel@vger.kernel.org,
OpenBMC Maillist <openbmc@lists.ozlabs.org>,
Open Source Submission <patches@amperecomputing.com>,
Phong Vo <phong@os.amperecomputing.com>,
Thang Nguyen <thang@os.amperecomputing.com>,
Quan Nguyen <quan@os.amperecomputing.com>
Subject: Re: [PATCH v2 3/3] dt-bindings: hwmon: max31790: Add maxim,pwmout-pin-as-tach-input property
Date: Sat, 8 Jun 2024 15:32:04 +0700 [thread overview]
Message-ID: <94adcd6d-1e66-40d3-b9e7-ef35f79691b6@amperemail.onmicrosoft.com> (raw)
In-Reply-To: <ee94c869-54ae-42ac-ac44-34535141293a@roeck-us.net>
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
>
next prev parent reply other threads:[~2024-06-08 8:32 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-14 4:22 [PATCH v2 0/3] Update the max31790 driver Chanh Nguyen
2024-04-14 4:22 ` [PATCH v2 1/3] dt-bindings: hwmon: Add maxim max31790 bindings Chanh Nguyen
2024-04-14 6:03 ` Krzysztof Kozlowski
2024-04-16 4:38 ` Chanh Nguyen
2024-04-14 4:22 ` [PATCH v2 2/3] hwmon: (max31790): Support config PWM output becomes TACH Chanh Nguyen
2024-04-14 8:03 ` Christophe JAILLET
2024-04-16 5:27 ` Chanh Nguyen
2024-04-16 17:39 ` Christophe JAILLET
2024-04-17 2:54 ` Chanh Nguyen
2024-04-14 4:22 ` [PATCH v2 3/3] dt-bindings: hwmon: max31790: Add maxim,pwmout-pin-as-tach-input property Chanh Nguyen
2024-04-14 6:07 ` Krzysztof Kozlowski
2024-04-16 4:52 ` Chanh Nguyen
2024-04-23 8:45 ` Chanh Nguyen
2024-04-23 17:02 ` Conor Dooley
2024-04-25 10:33 ` Chanh Nguyen
2024-04-25 14:05 ` Guenter Roeck
2024-04-25 15:46 ` Krzysztof Kozlowski
2024-04-25 15:56 ` Conor Dooley
2024-05-05 10:08 ` Chanh Nguyen
2024-05-05 15:40 ` Guenter Roeck
2024-05-08 3:44 ` Chanh Nguyen
2024-05-08 16:47 ` Conor Dooley
2024-06-07 16:47 ` Chanh Nguyen
2024-06-07 23:14 ` Guenter Roeck
2024-06-08 8:32 ` Chanh Nguyen [this message]
2024-05-09 8:29 ` Krzysztof Kozlowski
2024-06-07 16:46 ` Chanh Nguyen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=94adcd6d-1e66-40d3-b9e7-ef35f79691b6@amperemail.onmicrosoft.com \
--to=chanh@amperemail.onmicrosoft.com \
--cc=chanh@os.amperecomputing.com \
--cc=conor+dt@kernel.org \
--cc=conor@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jdelvare@suse.com \
--cc=justinledford@google.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=openbmc@lists.ozlabs.org \
--cc=patches@amperecomputing.com \
--cc=phong@os.amperecomputing.com \
--cc=quan@os.amperecomputing.com \
--cc=robh+dt@kernel.org \
--cc=thang@os.amperecomputing.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®