PWM fans are controlled solely by the duty cycle of the PWM signal, they
do not care about the exact timing. Thus set usage_power to true to
allow less flexible hardware to work as a PWM source for fan control.
Signed-off-by: Lorenz Brun <[email protected]>
---
drivers/hwmon/pwm-fan.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index 83a347ca35da..aa746c2bde39 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -507,6 +507,14 @@ static int pwm_fan_probe(struct platform_device *pdev)
pwm_init_state(ctx->pwm, &ctx->pwm_state);
+ /*
+ * PWM fans are controlled solely by the duty cycle of the PWM signal,
+ * they do not care about the exact timing. Thus set usage_power to true
+ * to allow less flexible hardware to work as a PWM source for fan
+ * control.
+ */
+ ctx->pwm_state.usage_power = true;
+
/*
* set_pwm assumes that MAX_PWM * (period - 1) fits into an unsigned
* long. Check this here to prevent the fan running at a too low
--
2.39.2
On Thu, Mar 09, 2023 at 02:10:08AM +0100, Lorenz Brun wrote:
> PWM fans are controlled solely by the duty cycle of the PWM signal, they
> do not care about the exact timing. Thus set usage_power to true to
> allow less flexible hardware to work as a PWM source for fan control.
>
This doesn't seem to be used anywhere else. I do not understand the
rationale, and I do not understand the practical impact of this change.
This needs to be confirmed by someone who understands what the flag is
supposed to be used for, its impact, and if it is indeed appropriate
in this context.
Also, since in practice there is no such "less flexible hardware"
in the upstream kernel, please describe the use case in more detail.
The only pwm driver that supports usage_power is pwm-pca9685,
and that driver uses the flag for EMI reasons, not because it is
"less flexible hardware". I am not inclined to accept such a change
without specific use case or need.
Thanks,
Guenter
> Signed-off-by: Lorenz Brun <[email protected]>
> ---
> drivers/hwmon/pwm-fan.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
> index 83a347ca35da..aa746c2bde39 100644
> --- a/drivers/hwmon/pwm-fan.c
> +++ b/drivers/hwmon/pwm-fan.c
> @@ -507,6 +507,14 @@ static int pwm_fan_probe(struct platform_device *pdev)
>
> pwm_init_state(ctx->pwm, &ctx->pwm_state);
>
> + /*
> + * PWM fans are controlled solely by the duty cycle of the PWM signal,
> + * they do not care about the exact timing. Thus set usage_power to true
> + * to allow less flexible hardware to work as a PWM source for fan
> + * control.
> + */
> + ctx->pwm_state.usage_power = true;
> +
> /*
> * set_pwm assumes that MAX_PWM * (period - 1) fits into an unsigned
> * long. Check this here to prevent the fan running at a too low
Am Mi, 15. M?r 2023 um 19:26:26 -07:00:00 schrieb Guenter Roeck
<[email protected]>:
> This doesn't seem to be used anywhere else. I do not understand the
> rationale, and I do not understand the practical impact of this
> change.
> This needs to be confirmed by someone who understands what the flag is
> supposed to be used for, its impact, and if it is indeed appropriate
> in this context.
>
> Also, since in practice there is no such "less flexible hardware"
> in the upstream kernel, please describe the use case in more detail.
> The only pwm driver that supports usage_power is pwm-pca9685,
> and that driver uses the flag for EMI reasons, not because it is
> "less flexible hardware". I am not inclined to accept such a change
> without specific use case or need.
The reason for this is that I have a PWM-driven fan on a Mediatek
MT7986a whose PWM signal is inverted by a MOSFET.
The PWM peripheral of the MT7986a however doesn't support inverted
output, at least not in a strict sense (i.e. if inverted mathematically
it is out of phase). The maintainer of the PWM subsystem recommended
that I only mathematically invert if usage_power is set as this means
that phase doesn't matter.
See
https://lore.kernel.org/linux-pwm/[email protected]/
for the PWM-side patch.
Regards,
Lorenz
On Thu, Mar 09, 2023 at 02:10:08AM +0100, Lorenz Brun wrote:
> PWM fans are controlled solely by the duty cycle of the PWM signal, they
> do not care about the exact timing. Thus set usage_power to true to
> allow less flexible hardware to work as a PWM source for fan control.
>
> Signed-off-by: Lorenz Brun <[email protected]>
Applied to hwmon-next.
Thanks,
Guenter
> ---
> drivers/hwmon/pwm-fan.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
> index 83a347ca35da..aa746c2bde39 100644
> --- a/drivers/hwmon/pwm-fan.c
> +++ b/drivers/hwmon/pwm-fan.c
> @@ -507,6 +507,14 @@ static int pwm_fan_probe(struct platform_device *pdev)
>
> pwm_init_state(ctx->pwm, &ctx->pwm_state);
>
> + /*
> + * PWM fans are controlled solely by the duty cycle of the PWM signal,
> + * they do not care about the exact timing. Thus set usage_power to true
> + * to allow less flexible hardware to work as a PWM source for fan
> + * control.
> + */
> + ctx->pwm_state.usage_power = true;
> +
> /*
> * set_pwm assumes that MAX_PWM * (period - 1) fits into an unsigned
> * long. Check this here to prevent the fan running at a too low