[v2,3/3] hwmon: Add Aspeed ast2600 TACH support

  This patch add the support of Tachometer which can use to monitor the
frequency of the input. The tach supports up to 16 channels and it's part
function of multi-function device "pwm-tach controller".

Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
---
 Documentation/hwmon/tach-aspeed-ast2600.rst |  28 ++
 drivers/hwmon/Kconfig                       |   9 +
 drivers/hwmon/Makefile                      |   1 +
 drivers/hwmon/tach-aspeed-ast2600.c         | 484 ++++++++++++++++++++
 4 files changed, 522 insertions(+)
 create mode 100644 Documentation/hwmon/tach-aspeed-ast2600.rst
 create mode 100644 drivers/hwmon/tach-aspeed-ast2600.c
  

Le 01/11/2022 à 10:51, Billy Tsai a écrit :
> This patch add the support of Tachometer which can use to monitor the
> frequency of the input. The tach supports up to 16 channels and it's part
> function of multi-function device "pwm-tach controller".
> 
> Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>

Hi,
a few nits below,

[...]

> +
> +	if (ret) {
> +		/* return 0 if we didn't get an answer because of timeout*/

Missing space at the end of the comment

> +		if (ret == -ETIMEDOUT)
> +			return 0;
> +		else
> +			return ret;

[...]

> +static int aspeed_tach_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct device_node *np, *child;
> +	struct aspeed_tach_data *priv;
> +	struct device *hwmon;
> +	struct platform_device *parent_dev;
> +	int ret;
> +
> +	np = dev->parent->of_node;
> +	if (!of_device_is_compatible(np, "aspeed,ast2600-pwm-tach"))
> +		return dev_err_probe(dev, -ENODEV,
> +				     "Unsupported tach device binding\n");
> +
> +	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> +	if (!priv)
> +		return -ENOMEM;
> +	priv->dev = &pdev->dev;
> +	priv->tach_channel =
> +		devm_kzalloc(dev,
> +			     TACH_ASPEED_NR_TACHS * sizeof(*priv->tach_channel),
> +			     GFP_KERNEL);

use devm_kcalloc() instead of devm_kzalloc()?
Error handling?

> +
> +	priv->regmap = syscon_node_to_regmap(np);
> +	if (IS_ERR(priv->regmap)) {
> +		dev_err(priv->dev, "Couldn't get regmap\n");

In order to be conistent with the other error handling paths:
return dev_err_probe()?

> +		return -ENODEV;
> +	}

[...]
  

On Tue, Nov 01, 2022 at 05:51:56PM +0800, Billy Tsai wrote:
> This patch add the support of Tachometer which can use to monitor the
> frequency of the input. The tach supports up to 16 channels and it's part
> function of multi-function device "pwm-tach controller".
> 
> Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
> ---
>  Documentation/hwmon/tach-aspeed-ast2600.rst |  28 ++

Also needs to be added to Documentation/hwmon/index.rst.

>  drivers/hwmon/Kconfig                       |   9 +
>  drivers/hwmon/Makefile                      |   1 +
>  drivers/hwmon/tach-aspeed-ast2600.c         | 484 ++++++++++++++++++++
>  4 files changed, 522 insertions(+)
>  create mode 100644 Documentation/hwmon/tach-aspeed-ast2600.rst
>  create mode 100644 drivers/hwmon/tach-aspeed-ast2600.c
> 
> diff --git a/Documentation/hwmon/tach-aspeed-ast2600.rst b/Documentation/hwmon/tach-aspeed-ast2600.rst
> new file mode 100644
> index 000000000000..8967f60672dc
> --- /dev/null
> +++ b/Documentation/hwmon/tach-aspeed-ast2600.rst
> @@ -0,0 +1,28 @@
> +Kernel driver tach-aspeed-ast2600
> +==============================
> +
> +Supported chips:
> +	ASPEED AST2600
> +
> +Authors:
> +	<billy_tsai@aspeedtech.com>
> +
> +Description:
> +------------
> +This driver implements support for ASPEED AST2600 Fan Tacho controller.
> +The controller supports up to 16 tachometer inputs.
> +
> +The driver provides the following sensor accesses in sysfs:
> +=============== ======= =====================================================
> +fanX_input	ro	provide current fan rotation value in RPM as reported
> +			by the fan to the device.
> +fanX_div	rw	Fan divisor: Supported value are power of 4 (1, 4, 16
> +                        64, ... 4194304)
> +                        The larger divisor, the less rpm accuracy and the less
> +                        affected by fan signal glitch.
> +fanX_min	rw      Fan minimum RPM which can used to change the timeout
> +                        value for controller polling the result.
> +fanX_max	rw      Fan maximum RPM which can used to change the polling
> +                        period of the driver.
> +fanX_pulses	rw      Fan pulses per resolution.
> +=============== ======= ======================================================
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index fa2356398744..a84c15b73aa6 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -397,6 +397,15 @@ config SENSORS_ASPEED
>  	  This driver can also be built as a module. If so, the module
>  	  will be called aspeed_pwm_tacho.
>  
> +config SENSORS_TACH_ASPEED_AST2600
> +	tristate "ASPEED ast2600 Tachometer support"
> +	select REGMAP
> +	help
> +	  This driver provides support for Aspeed ast2600 Tachometer.
> +
> +	  To compile this driver as a module, choose M here: the module
> +	  will be called tach-aspeed-ast2600.
> +
>  config SENSORS_ATXP1
>  	tristate "Attansic ATXP1 VID controller"
>  	depends on I2C
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index d2497b2644e6..7e2d708e93b8 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -51,6 +51,7 @@ obj-$(CONFIG_SENSORS_ARM_SCMI)	+= scmi-hwmon.o
>  obj-$(CONFIG_SENSORS_ARM_SCPI)	+= scpi-hwmon.o
>  obj-$(CONFIG_SENSORS_AS370)	+= as370-hwmon.o
>  obj-$(CONFIG_SENSORS_ASC7621)	+= asc7621.o
> +obj-$(CONFIG_SENSORS_TACH_ASPEED_AST2600) += tach-aspeed-ast2600.o
>  obj-$(CONFIG_SENSORS_ASPEED)	+= aspeed-pwm-tacho.o
>  obj-$(CONFIG_SENSORS_ATXP1)	+= atxp1.o
>  obj-$(CONFIG_SENSORS_AXI_FAN_CONTROL) += axi-fan-control.o
> diff --git a/drivers/hwmon/tach-aspeed-ast2600.c b/drivers/hwmon/tach-aspeed-ast2600.c
> new file mode 100644
> index 000000000000..599ed5db17a8
> --- /dev/null
> +++ b/drivers/hwmon/tach-aspeed-ast2600.c
> @@ -0,0 +1,484 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) ASPEED Technology Inc.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/errno.h>
> +#include <linux/delay.h>
> +#include <linux/hwmon.h>
> +#include <linux/hwmon-sysfs.h>

Not needed. Please check if there are other unnecessary includes.

> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of_platform.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/sysfs.h>
> +#include <linux/reset.h>
> +#include <linux/regmap.h>
> +#include <linux/bitfield.h>

Please order include files in alphabetic order.

> +
> +/* The channel number of Aspeed tach controller */
> +#define TACH_ASPEED_NR_TACHS 16

#define<space>NAME<tab>value, please, and align the value.

> +/* TACH Control Register */
> +#define TACH_ASPEED_CTRL(ch) (((ch) * 0x10) + 0x08)
> +#define TACH_ASPEED_IER BIT(31)
> +#define TACH_ASPEED_INVERS_LIMIT BIT(30)
> +#define TACH_ASPEED_LOOPBACK BIT(29)
> +#define TACH_ASPEED_ENABLE BIT(28)
> +#define TACH_ASPEED_DEBOUNCE_MASK GENMASK(27, 26)
> +#define TACH_ASPEED_DEBOUNCE_BIT (26)

() around plain integers is not needed.

> +#define TACH_ASPEED_IO_EDGE_MASK GENMASK(25, 24)
> +#define TACH_ASPEED_IO_EDGE_BIT (24)
> +#define TACH_ASPEED_CLK_DIV_T_MASK GENMASK(23, 20)
> +#define TACH_ASPEED_CLK_DIV_BIT (20)
> +#define TACH_ASPEED_THRESHOLD_MASK GENMASK(19, 0)
> +/* [27:26] */
> +#define DEBOUNCE_3_CLK 0x00
> +#define DEBOUNCE_2_CLK 0x01
> +#define DEBOUNCE_1_CLK 0x02
> +#define DEBOUNCE_0_CLK 0x03
> +/* [25:24] */
> +#define F2F_EDGES 0x00
> +#define R2R_EDGES 0x01
> +#define BOTH_EDGES 0x02
> +/* [23:20] */
> +/* divisor = 4 to the nth power, n = register value */
> +#define DEFAULT_TACH_DIV 1024
> +#define DIV_TO_REG(divisor) (ilog2(divisor) >> 1)
> +
> +/* TACH Status Register */
> +#define TACH_ASPEED_STS(ch) (((ch) * 0x10) + 0x0C)
> +
> +/*PWM_TACH_STS */
> +#define TACH_ASPEED_ISR BIT(31)
> +#define TACH_ASPEED_PWM_OUT BIT(25)
> +#define TACH_ASPEED_PWM_OEN BIT(24)
> +#define TACH_ASPEED_DEB_INPUT BIT(23)
> +#define TACH_ASPEED_RAW_INPUT BIT(22)
> +#define TACH_ASPEED_VALUE_UPDATE BIT(21)
> +#define TACH_ASPEED_FULL_MEASUREMENT BIT(20)
> +#define TACH_ASPEED_VALUE_MASK GENMASK(19, 0)
> +/**********************************************************
> + * Software setting
> + *********************************************************/
> +#define DEFAULT_FAN_MIN_RPM 1000
> +#define DEFAULT_FAN_PULSE_PR 2
> +/*
> + * Add this value to avoid CPU consuming a lot of resources in waiting rpm
> + * updating. Assume the max rpm of fan is 60000, the fastest period of updating
> + * tach value will be equal to (1000000 * 2 * 60) / (2 * max_rpm) = 1000us.
> + */
> +#define DEFAULT_FAN_MAX_RPM 60000
> +
> +struct aspeed_tach_channel_params {
> +	int limited_inverse;
> +	u16 threshold;
> +	u8 tach_edge;
> +	u8 tach_debounce;
> +	u8 pulse_pr;
> +	u32 min_rpm;
> +	u32 max_rpm;
> +	u32 divisor;
> +	u32 sample_period; /* unit is us */
> +	u32 polling_period; /* unit is us */
> +};
> +
> +struct aspeed_tach_data {
> +	struct device *dev;
> +	struct regmap *regmap;
> +	struct clk *clk;
> +	struct reset_control *reset;
> +	bool tach_present[TACH_ASPEED_NR_TACHS];
> +	struct aspeed_tach_channel_params *tach_channel;
> +};
> +
> +static void aspeed_update_tach_sample_period(struct aspeed_tach_data *priv,
> +					     u8 fan_tach_ch)
> +{
> +	u32 tach_period_us;
> +	u8 pulse_pr = priv->tach_channel[fan_tach_ch].pulse_pr;
> +	u32 min_rpm = priv->tach_channel[fan_tach_ch].min_rpm;
> +
> +	/*
> +	 * min(Tach input clock) = (PulsePR * minRPM) / 60
> +	 * max(Tach input period) = 60 / (PulsePR * minRPM)
> +	 * Tach sample period > 2 * max(Tach input period) = (2*60) / (PulsePR * minRPM)
> +	 */
> +	tach_period_us = (USEC_PER_SEC * 2 * 60) / (pulse_pr * min_rpm);
> +	/* Add the margin (about 1.5) of tach sample period to avoid sample miss */
> +	tach_period_us = (tach_period_us * 1500) >> 10;
> +	dev_dbg(priv->dev, "tach%d sample period = %dus", fan_tach_ch, tach_period_us);
> +	priv->tach_channel[fan_tach_ch].sample_period = tach_period_us;
> +}
> +
> +static void aspeed_update_tach_polling_period(struct aspeed_tach_data *priv,
> +					     u8 fan_tach_ch)
> +{
> +	u32 tach_period_us;
> +	u8 pulse_pr = priv->tach_channel[fan_tach_ch].pulse_pr;
> +	u32 max_rpm = priv->tach_channel[fan_tach_ch].max_rpm;
> +
> +	tach_period_us = (USEC_PER_SEC * 2 * 60) / (pulse_pr * max_rpm);
> +	dev_dbg(priv->dev, "tach%d polling period = %dus", fan_tach_ch, tach_period_us);
> +	priv->tach_channel[fan_tach_ch].polling_period = tach_period_us;
> +}
> +
> +static void aspeed_tach_ch_enable(struct aspeed_tach_data *priv, u8 tach_ch,
> +				  bool enable)
> +{
> +	if (enable)
> +		regmap_set_bits(priv->regmap, TACH_ASPEED_CTRL(tach_ch),
> +				TACH_ASPEED_ENABLE);
> +	else
> +		regmap_clear_bits(priv->regmap, TACH_ASPEED_CTRL(tach_ch),
> +				   TACH_ASPEED_ENABLE);
> +}
> +
> +static int aspeed_get_fan_tach_ch_rpm(struct aspeed_tach_data *priv,
> +				      u8 fan_tach_ch)
> +{
> +	u32 raw_data, tach_div, val;
> +	unsigned long clk_source;
> +	u64 rpm;
> +	int ret;
> +
> +	/* Restart the Tach channel to guarantee the value is fresh */
> +	aspeed_tach_ch_enable(priv, fan_tach_ch, false);
> +	aspeed_tach_ch_enable(priv, fan_tach_ch, true);

Is that really needed ? Doesn't the controller measure values continuously ?

> +	ret = regmap_read_poll_timeout(
> +		priv->regmap, TACH_ASPEED_STS(fan_tach_ch), val,
> +		(val & TACH_ASPEED_FULL_MEASUREMENT) &&
> +			(val & TACH_ASPEED_VALUE_UPDATE),
> +		priv->tach_channel[fan_tach_ch].polling_period,
> +		priv->tach_channel[fan_tach_ch].sample_period);

Please fix multi-line alignment everywhere. Go up to 100 columns if needed.

> +
> +	if (ret) {
> +		/* return 0 if we didn't get an answer because of timeout*/
> +		if (ret == -ETIMEDOUT)
> +			return 0;
> +		else
> +			return ret;

else after return is unnecessary, and why would a timeout be be ignored ?

> +	}
> +
> +	raw_data = val & TACH_ASPEED_VALUE_MASK;
> +	/*
> +	 * We need the mode to determine if the raw_data is double (from
> +	 * counting both edges).
> +	 */
> +	if (priv->tach_channel[fan_tach_ch].tach_edge == BOTH_EDGES)
> +		raw_data <<= 1;
> +
> +	tach_div = raw_data * (priv->tach_channel[fan_tach_ch].divisor) *
> +		   (priv->tach_channel[fan_tach_ch].pulse_pr);
> +
> +	clk_source = clk_get_rate(priv->clk);
> +	dev_dbg(priv->dev, "clk %ld, raw_data %d , tach_div %d\n", clk_source,
> +		raw_data, tach_div);
> +
> +	if (tach_div == 0)
> +		return -EDOM;

If the fan is off or not connected, would that return an error ?
If so, that would be inappropriate; it should return a speed
of 0 in that case.

> +
> +	rpm = (u64)clk_source * 60;
> +	do_div(rpm, tach_div);
> +
> +	return rpm;
> +}
> +
> +static int aspeed_tach_hwmon_read(struct device *dev, enum hwmon_sensor_types type, u32 attr,
> +			int channel, long *val)
> +{
> +	struct aspeed_tach_data *priv = dev_get_drvdata(dev);
> +	u32 reg_val;
> +	int ret;
> +
> +	switch (attr) {
> +	case hwmon_fan_input:
> +		ret = aspeed_get_fan_tach_ch_rpm(priv, channel);
> +		if (ret < 0)
> +			return ret;
> +		*val = ret;
> +		break;
> +	case hwmon_fan_min:
> +		*val = priv->tach_channel[channel].min_rpm;
> +		break;
> +	case hwmon_fan_max:
> +		*val = priv->tach_channel[channel].max_rpm;
> +		break;
> +	case hwmon_fan_div:
> +		regmap_read(priv->regmap, TACH_ASPEED_CTRL(channel), &reg_val);
> +		reg_val = FIELD_GET(TACH_ASPEED_CLK_DIV_T_MASK, reg_val);
> +		*val = 1 << (reg_val << 1);

BIT() ?

> +		break;
> +	case hwmon_fan_pulses:
> +		*val = priv->tach_channel[channel].pulse_pr;
> +		break;
> +	default:
> +		return -EOPNOTSUPP;
> +	}
> +	return 0;
> +}
> +
> +static int aspeed_tach_hwmon_write(struct device *dev, enum hwmon_sensor_types type, u32 attr,
> +			 int channel, long val)
> +{
> +	struct aspeed_tach_data *priv = dev_get_drvdata(dev);
> +
> +	switch (attr) {
> +	case hwmon_fan_min:
> +		priv->tach_channel[channel].min_rpm = val;
> +		aspeed_update_tach_sample_period(priv, channel);
> +		break;
> +	case hwmon_fan_max:
> +		priv->tach_channel[channel].max_rpm = val;
> +		aspeed_update_tach_polling_period(priv, channel);
> +		break;
> +	case hwmon_fan_div:
> +		if ((is_power_of_2(val) && !(ilog2(val) % 2))) {
> +			priv->tach_channel[channel].divisor = val;
> +			regmap_write_bits(
> +				priv->regmap, TACH_ASPEED_CTRL(channel),
> +				TACH_ASPEED_CLK_DIV_T_MASK,
> +				DIV_TO_REG(priv->tach_channel[channel].divisor)
> +					<< TACH_ASPEED_CLK_DIV_BIT);
> +		} else {
> +			dev_err(dev,
> +				"fan_div value %ld not supported. Only support power of 4\n",
> +				val);
> +			return -EINVAL;
> +		}

Error case should be handled first, making else unnecessary.

> +		break;
> +	case hwmon_fan_pulses:
> +		priv->tach_channel[channel].pulse_pr = val;
> +		aspeed_update_tach_sample_period(priv, channel);
> +		break;
> +	default:
> +		return -EOPNOTSUPP;
> +	}
> +
> +	return 0;
> +}
> +
> +static umode_t aspeed_tach_dev_is_visible(const void *drvdata, enum hwmon_sensor_types type,
> +				  u32 attr, int channel)
> +{
> +	const struct aspeed_tach_data *priv = drvdata;
> +
> +	if (!priv->tach_present[channel])
> +		return 0;
> +	switch (attr) {
> +	case hwmon_fan_input:
> +		return 0444;
> +	case hwmon_fan_min:
> +	case hwmon_fan_max:
> +	case hwmon_fan_div:
> +	case hwmon_fan_pulses:
> +		return 0644;
> +	}
> +	return 0;
> +}
> +
> +static const struct hwmon_ops aspeed_tach_ops = {
> +	.is_visible = aspeed_tach_dev_is_visible,
> +	.read = aspeed_tach_hwmon_read,
> +	.write = aspeed_tach_hwmon_write,
> +};
> +
> +static const struct hwmon_channel_info *aspeed_tach_info[] = {
> +	HWMON_CHANNEL_INFO(fan,
> +			   HWMON_F_INPUT | HWMON_F_MIN | HWMON_F_MAX |
> +				   HWMON_F_DIV | HWMON_F_PULSES,
> +			   HWMON_F_INPUT | HWMON_F_MIN | HWMON_F_MAX |
> +				   HWMON_F_DIV | HWMON_F_PULSES,
> +			   HWMON_F_INPUT | HWMON_F_MIN | HWMON_F_MAX |
> +				   HWMON_F_DIV | HWMON_F_PULSES,
> +			   HWMON_F_INPUT | HWMON_F_MIN | HWMON_F_MAX |
> +				   HWMON_F_DIV | HWMON_F_PULSES,
> +			   HWMON_F_INPUT | HWMON_F_MIN | HWMON_F_MAX |
> +				   HWMON_F_DIV | HWMON_F_PULSES,
> +			   HWMON_F_INPUT | HWMON_F_MIN | HWMON_F_MAX |
> +				   HWMON_F_DIV | HWMON_F_PULSES,
> +			   HWMON_F_INPUT | HWMON_F_MIN | HWMON_F_MAX |
> +				   HWMON_F_DIV | HWMON_F_PULSES,
> +			   HWMON_F_INPUT | HWMON_F_MIN | HWMON_F_MAX |
> +				   HWMON_F_DIV | HWMON_F_PULSES,
> +			   HWMON_F_INPUT | HWMON_F_MIN | HWMON_F_MAX |
> +				   HWMON_F_DIV | HWMON_F_PULSES,
> +			   HWMON_F_INPUT | HWMON_F_MIN | HWMON_F_MAX |
> +				   HWMON_F_DIV | HWMON_F_PULSES,
> +			   HWMON_F_INPUT | HWMON_F_MIN | HWMON_F_MAX |
> +				   HWMON_F_DIV | HWMON_F_PULSES,
> +			   HWMON_F_INPUT | HWMON_F_MIN | HWMON_F_MAX |
> +				   HWMON_F_DIV | HWMON_F_PULSES,
> +			   HWMON_F_INPUT | HWMON_F_MIN | HWMON_F_MAX |
> +				   HWMON_F_DIV | HWMON_F_PULSES,
> +			   HWMON_F_INPUT | HWMON_F_MIN | HWMON_F_MAX |
> +				   HWMON_F_DIV | HWMON_F_PULSES,
> +			   HWMON_F_INPUT | HWMON_F_MIN | HWMON_F_MAX |
> +				   HWMON_F_DIV | HWMON_F_PULSES,
> +			   HWMON_F_INPUT | HWMON_F_MIN | HWMON_F_MAX |
> +				   HWMON_F_DIV | HWMON_F_PULSES),
> +	NULL
> +};
> +
> +static const struct hwmon_chip_info aspeed_tach_chip_info = {
> +	.ops = &aspeed_tach_ops,
> +	.info = aspeed_tach_info,
> +};
> +
> +static void aspeed_create_fan_tach_channel(struct aspeed_tach_data *priv,
> +					   u32 tach_ch)
> +{
> +	priv->tach_present[tach_ch] = true;
> +	priv->tach_channel[tach_ch].limited_inverse = 0;
> +	regmap_write_bits(priv->regmap, TACH_ASPEED_CTRL(tach_ch),
> +			  TACH_ASPEED_INVERS_LIMIT,
> +			  priv->tach_channel[tach_ch].limited_inverse ?
> +				  TACH_ASPEED_INVERS_LIMIT :
> +				  0);
> +
> +	priv->tach_channel[tach_ch].tach_debounce = DEBOUNCE_3_CLK;
> +	regmap_write_bits(priv->regmap, TACH_ASPEED_CTRL(tach_ch),
> +			  TACH_ASPEED_DEBOUNCE_MASK,
> +			  priv->tach_channel[tach_ch].tach_debounce
> +				  << TACH_ASPEED_DEBOUNCE_BIT);
> +
> +	priv->tach_channel[tach_ch].tach_edge = F2F_EDGES;
> +	regmap_write_bits(priv->regmap, TACH_ASPEED_CTRL(tach_ch),
> +			  TACH_ASPEED_IO_EDGE_MASK,
> +			  priv->tach_channel[tach_ch].tach_edge
> +				  << TACH_ASPEED_IO_EDGE_BIT);
> +
> +	priv->tach_channel[tach_ch].divisor = DEFAULT_TACH_DIV;
> +	regmap_write_bits(priv->regmap, TACH_ASPEED_CTRL(tach_ch),
> +			  TACH_ASPEED_CLK_DIV_T_MASK,
> +			  DIV_TO_REG(priv->tach_channel[tach_ch].divisor)
> +				  << TACH_ASPEED_CLK_DIV_BIT);
> +
> +	priv->tach_channel[tach_ch].threshold = 0;
> +	regmap_write_bits(priv->regmap, TACH_ASPEED_CTRL(tach_ch),
> +			  TACH_ASPEED_THRESHOLD_MASK,
> +			  priv->tach_channel[tach_ch].threshold);
> +
> +	priv->tach_channel[tach_ch].pulse_pr = DEFAULT_FAN_PULSE_PR;
> +	priv->tach_channel[tach_ch].min_rpm = DEFAULT_FAN_MIN_RPM;
> +	aspeed_update_tach_sample_period(priv, tach_ch);
> +
> +	priv->tach_channel[tach_ch].max_rpm = DEFAULT_FAN_MAX_RPM;
> +	aspeed_update_tach_polling_period(priv, tach_ch);
> +
> +	aspeed_tach_ch_enable(priv, tach_ch, true);
> +}
> +
> +static int aspeed_tach_create_fan(struct device *dev, struct device_node *child,
> +				  struct aspeed_tach_data *priv)
> +{
> +	u32 tach_channel;
> +	int ret;
> +
> +	ret = of_property_read_u32(child, "reg", &tach_channel);
> +	if (ret)
> +		return ret;
> +
> +	aspeed_create_fan_tach_channel(priv, tach_channel);
> +
> +	return 0;
> +}
> +
> +static void aspeed_tach_reset_assert(void *data)
> +{
> +	struct reset_control *rst = data;
> +
> +	reset_control_assert(rst);
> +}
> +
> +static int aspeed_tach_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct device_node *np, *child;
> +	struct aspeed_tach_data *priv;
> +	struct device *hwmon;
> +	struct platform_device *parent_dev;
> +	int ret;
> +
> +	np = dev->parent->of_node;
> +	if (!of_device_is_compatible(np, "aspeed,ast2600-pwm-tach"))
> +		return dev_err_probe(dev, -ENODEV,
> +				     "Unsupported tach device binding\n");
> +
> +	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> +	if (!priv)
> +		return -ENOMEM;
> +	priv->dev = &pdev->dev;
> +	priv->tach_channel =
> +		devm_kzalloc(dev,
> +			     TACH_ASPEED_NR_TACHS * sizeof(*priv->tach_channel),
> +			     GFP_KERNEL);
> +
> +	priv->regmap = syscon_node_to_regmap(np);
> +	if (IS_ERR(priv->regmap)) {
> +		dev_err(priv->dev, "Couldn't get regmap\n");
> +		return -ENODEV;

Why replace the reported error ?

> +	}
> +	parent_dev = of_find_device_by_node(np);
> +	priv->clk = devm_clk_get_enabled(&parent_dev->dev, 0);
> +	if (IS_ERR(priv->clk))
> +		return dev_err_probe(dev, PTR_ERR(priv->clk),
> +				     "Couldn't get clock\n");
> +
> +	priv->reset = devm_reset_control_get_shared(&parent_dev->dev, NULL);
> +	if (IS_ERR(priv->reset))
> +		return dev_err_probe(dev, PTR_ERR(priv->reset),
> +				     "Couldn't get reset control\n");
> +
> +	ret = reset_control_deassert(priv->reset);
> +	if (ret)
> +		return dev_err_probe(dev, ret,
> +				     "Couldn't deassert reset control\n");
> +
> +	ret = devm_add_action_or_reset(dev, aspeed_tach_reset_assert,
> +				       priv->reset);
> +	if (ret)
> +		return ret;
> +
> +	for_each_child_of_node(dev->of_node, child) {
> +		ret = aspeed_tach_create_fan(dev, child, priv);
> +		if (ret) {
> +			of_node_put(child);
> +			return ret;
> +		}
> +	}
> +
> +	hwmon = devm_hwmon_device_register_with_info(
> +		dev, "aspeed_tach", priv, &aspeed_tach_chip_info, NULL);

Please watch out for multi-line alignment (checkpatch --strict); go up to 100
columns if needed.

> +	ret = PTR_ERR_OR_ZERO(hwmon);
> +	if (ret)
> +		return dev_err_probe(dev, ret,
> +				     "Failed to register hwmon device\n");
> +	return 0;
> +}
> +
> +static const struct of_device_id of_stach_match_table[] = {
> +	{
> +		.compatible = "aspeed,ast2600-tach",
> +	},
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, of_stach_match_table);
> +
> +static struct platform_driver aspeed_tach_driver = {
> +	.probe		= aspeed_tach_probe,
> +	.driver		= {
> +		.name	= "aspeed_tach",
> +		.of_match_table = of_stach_match_table,
> +	},
> +};
> +
> +module_platform_driver(aspeed_tach_driver);
> +
> +MODULE_AUTHOR("Billy Tsai <billy_tsai@aspeedtech.com>");
> +MODULE_DESCRIPTION("Aspeed ast2600 TACH device driver");
> +MODULE_LICENSE("GPL v2");
> +
> -- 
> 2.25.1
>
  

Hi Guenter,

On 2022/11/1, 9:15 PM, "Guenter Roeck" <groeck7@gmail.com on behalf of linux@roeck-us.net> wrote:

    On Tue, Nov 01, 2022 at 05:51:56PM +0800, Billy Tsai wrote:
    > > +
    > > +	/* Restart the Tach channel to guarantee the value is fresh */
    > > +	aspeed_tach_ch_enable(priv, fan_tach_ch, false);
    > > +	aspeed_tach_ch_enable(priv, fan_tach_ch, true);

    > Is that really needed ? Doesn't the controller measure values continuously ?

Yes, the controller will measure values continuously by hardware. I will remove it. 
If the user want to get the fresh value, it should be done by the application layer
(e.g. read two times).

    > > +
    > > +	if (ret) {
    > > +		/* return 0 if we didn't get an answer because of timeout*/
    > > +		if (ret == -ETIMEDOUT)
    > > +			return 0;
    > > +		else
    > > +			return ret;

    > else after return is unnecessary, and why would a timeout be be ignored ?

When the user sets the correct fan information (i.e., min_rpm, max_rpm), the read
poll timeout will only occur if the tach pin does not get any signal (i.e. rpm=0).

    > > +	}
    > > +
    > > +	raw_data = val & TACH_ASPEED_VALUE_MASK;
    > > +	/*
    > > +	 * We need the mode to determine if the raw_data is double (from
    > > +	 * counting both edges).
    > > +	 */
    > > +	if (priv->tach_channel[fan_tach_ch].tach_edge == BOTH_EDGES)
    > > +		raw_data <<= 1;
    > > +
    > > +	tach_div = raw_data * (priv->tach_channel[fan_tach_ch].divisor) *
    > > +		   (priv->tach_channel[fan_tach_ch].pulse_pr);
    > > +
    > > +	clk_source = clk_get_rate(priv->clk);
    > > +	dev_dbg(priv->dev, "clk %ld, raw_data %d , tach_div %d\n", clk_source,
    > > +		raw_data, tach_div);
    > > +
    > > +	if (tach_div == 0)
    > > +		return -EDOM;

    > If the fan is off or not connected, would that return an error ?
    > If so, that would be inappropriate; it should return a speed
    > of 0 in that case.

It will be handled by the regmap_read_poll_timeout.

Thanks

Best Regards,
Billy Tsai
  

On Wed, Nov 02, 2022 at 06:54:43AM +0000, Billy Tsai wrote:
> Hi Guenter,
> 
> On 2022/11/1, 9:15 PM, "Guenter Roeck" <groeck7@gmail.com on behalf of linux@roeck-us.net> wrote:
> 
>     On Tue, Nov 01, 2022 at 05:51:56PM +0800, Billy Tsai wrote:
>     > > +
>     > > +	/* Restart the Tach channel to guarantee the value is fresh */
>     > > +	aspeed_tach_ch_enable(priv, fan_tach_ch, false);
>     > > +	aspeed_tach_ch_enable(priv, fan_tach_ch, true);
> 
>     > Is that really needed ? Doesn't the controller measure values continuously ?
> 
> Yes, the controller will measure values continuously by hardware. I will remove it. 
> If the user want to get the fresh value, it should be done by the application layer
> (e.g. read two times).
> 
>     > > +
>     > > +	if (ret) {
>     > > +		/* return 0 if we didn't get an answer because of timeout*/
>     > > +		if (ret == -ETIMEDOUT)
>     > > +			return 0;
>     > > +		else
>     > > +			return ret;
> 
>     > else after return is unnecessary, and why would a timeout be be ignored ?
> 
> When the user sets the correct fan information (i.e., min_rpm, max_rpm), the read
> poll timeout will only occur if the tach pin does not get any signal (i.e. rpm=0).
> 

In that case it would be appropriate to return -ETIMEDOUT to the caller.

Anyway, that should really not happen. Sysfs attributes such as minimum/maximum fan
speed, the number of fan pulses per revolution, or a divider value should only exist
if the chip needs that information, for example to report a fan error/alarm if the
measured speed is out of range or if the chip actually calculates RPM and provides
the result to the driver. Those values should not be necessary (and should not be
used) to calculate some timeout.

>     > > +	}
>     > > +
>     > > +	raw_data = val & TACH_ASPEED_VALUE_MASK;
>     > > +	/*
>     > > +	 * We need the mode to determine if the raw_data is double (from
>     > > +	 * counting both edges).
>     > > +	 */
>     > > +	if (priv->tach_channel[fan_tach_ch].tach_edge == BOTH_EDGES)
>     > > +		raw_data <<= 1;
>     > > +
>     > > +	tach_div = raw_data * (priv->tach_channel[fan_tach_ch].divisor) *
>     > > +		   (priv->tach_channel[fan_tach_ch].pulse_pr);
>     > > +
>     > > +	clk_source = clk_get_rate(priv->clk);
>     > > +	dev_dbg(priv->dev, "clk %ld, raw_data %d , tach_div %d\n", clk_source,
>     > > +		raw_data, tach_div);
>     > > +
>     > > +	if (tach_div == 0)
>     > > +		return -EDOM;
> 
>     > If the fan is off or not connected, would that return an error ?
>     > If so, that would be inappropriate; it should return a speed
>     > of 0 in that case.
> 
> It will be handled by the regmap_read_poll_timeout.

This would only happen if raw_data is 0, or if any of
priv->tach_channel[fan_tach_ch].divisor or priv->tach_channel[fan_tach_ch].pulse_pr
are 0. The latter should never happen, leaving raw_data. If that is 0, I would assume
that there was no fan pulse. That would indicate that the fan isn't running (or maybe
that no fan is connected). Either case that would not warrant returning -EDOM.
If the fan isn't running (no pulse was reported), the reported fan speed should be 0.
If that is an error, the fanX_alarm (or, if available, fanX_min_alarm) should report 1.
Reading the fan speed should never return an error to the caller unless there was
an actual error when reading the value from the hardware.

Thanks,
Guenter
  

On 2022/11/3, 1:01 AM, "Guenter Roeck" <groeck7@gmail.com on behalf of linux@roeck-us.net> wrote:

    On Wed, Nov 02, 2022 at 06:54:43AM +0000, Billy Tsai wrote:
    >   > Hi Guenter,
    >   > 
    >   > On 2022/11/1, 9:15 PM, "Guenter Roeck" <groeck7@gmail.com on behalf of linux@roeck-us.net> wrote:
    >   > 
    >   >     On Tue, Nov 01, 2022 at 05:51:56PM +0800, Billy Tsai wrote:
    >   >     > > +
    >   >     > > +	/* Restart the Tach channel to guarantee the value is fresh */
    >   >     > > +	aspeed_tach_ch_enable(priv, fan_tach_ch, false);
    >   >     > > +	aspeed_tach_ch_enable(priv, fan_tach_ch, true);
    >   > 
    >   >     > Is that really needed ? Doesn't the controller measure values continuously ?
    >   > 
    >   > Yes, the controller will measure values continuously by hardware. I will remove it. 
    >   > If the user want to get the fresh value, it should be done by the application layer
    >   > (e.g. read two times).
    >   > 
    >   >     > > +
    >   >     > > +	if (ret) {
    >   >     > > +		/* return 0 if we didn't get an answer because of timeout*/
    >   >     > > +		if (ret == -ETIMEDOUT)
    >   >     > > +			return 0;
    >   >     > > +		else
    >   >     > > +			return ret;
    >   > 
    >   >     > else after return is unnecessary, and why would a timeout be be ignored ?
    >   > 
    >   > When the user sets the correct fan information (i.e., min_rpm, max_rpm), the read
    >   > poll timeout will only occur if the tach pin does not get any signal (i.e. rpm=0).
    >   > 

    >   In that case it would be appropriate to return -ETIMEDOUT to the caller.

    >   Anyway, that should really not happen. Sysfs attributes such as minimum/maximum fan
    >   speed, the number of fan pulses per revolution, or a divider value should only exist
    >   if the chip needs that information, for example to report a fan error/alarm if the
    >   measured speed is out of range or if the chip actually calculates RPM and provides
    >   the result to the driver. Those values should not be necessary (and should not be
    >   used) to calculate some timeout.

Can't I use a min/max RPM to let the driver know a reasonable timeout/polling period when
the driver is trying to get RPM?
Beacause that our tach controller have the falg to indicates the hardware detected the change
in the input signal. I need the proper timout to rule out slow RPMs.

Thanks

Best Regards,
Billy Tsai
  

On Thu, Nov 03, 2022 at 03:52:59AM +0000, Billy Tsai wrote:
> 
> Can't I use a min/max RPM to let the driver know a reasonable timeout/polling period when
> the driver is trying to get RPM?
> Beacause that our tach controller have the falg to indicates the hardware detected the change
> in the input signal. I need the proper timout to rule out slow RPMs.
> 

If the chip measures the fan speed continuously, why would that ever be a
problem, and why wait in the first place instead of just taking the most
recent result ?

Pretty much every other driver is doing that, so I really don't understand
why that would not work here.

Guenter
  

On 2022/11/3, 12:30 PM, "Guenter Roeck" <groeck7@gmail.com on behalf of linux@roeck-us.net> wrote:

    On Thu, Nov 03, 2022 at 03:52:59AM +0000, Billy Tsai wrote:
    > > 
    > > Can't I use a min/max RPM to let the driver know a reasonable timeout/polling period when
    > > the driver is trying to get RPM?
    > > Beacause that our tach controller have the falg to indicates the hardware detected the change
    > > in the input signal. I need the proper timout to rule out slow RPMs.

    > If the chip measures the fan speed continuously, why would that ever be a
    > problem, and why wait in the first place instead of just taking the most
    > recent result ?

    > Pretty much every other driver is doing that, so I really don't understand
    > why that would not work here.

When the fan speed drop from a very fast RPM to a very slow RPM. Especially when it is close to stopping.
The most recent result will be no meaningful value. The slower RPM needs more time to sample it. E.g., If
we want to measure the fan with 600 RPM, the controller needs at least 100ms. During this time period, we
will always get the wrong value. So, our tach controller have the flag to avoid this problem:
TACH_ASPEED_VALUE_UPDATE: tach value updated since last read
This flag will be set when the controller detected the change of the signal and clear by read it.
In order to use this flag, the controller needs the proper timeout based on minimum RPM to avoid waiting forever.

Best Regards,
Billy Tsai
  

On Thu, Nov 03, 2022 at 05:40:44AM +0000, Billy Tsai wrote:
> On 2022/11/3, 12:30 PM, "Guenter Roeck" <groeck7@gmail.com on behalf of linux@roeck-us.net> wrote:
> 
>     On Thu, Nov 03, 2022 at 03:52:59AM +0000, Billy Tsai wrote:
>     > > 
>     > > Can't I use a min/max RPM to let the driver know a reasonable timeout/polling period when
>     > > the driver is trying to get RPM?
>     > > Beacause that our tach controller have the falg to indicates the hardware detected the change
>     > > in the input signal. I need the proper timout to rule out slow RPMs.
> 
>     > If the chip measures the fan speed continuously, why would that ever be a
>     > problem, and why wait in the first place instead of just taking the most
>     > recent result ?
> 
>     > Pretty much every other driver is doing that, so I really don't understand
>     > why that would not work here.
> 
> When the fan speed drop from a very fast RPM to a very slow RPM. Especially when it is close to stopping.
> The most recent result will be no meaningful value. The slower RPM needs more time to sample it. E.g., If
> we want to measure the fan with 600 RPM, the controller needs at least 100ms. During this time period, we
> will always get the wrong value. So, our tach controller have the flag to avoid this problem:
> TACH_ASPEED_VALUE_UPDATE: tach value updated since last read
> This flag will be set when the controller detected the change of the signal and clear by read it.
> In order to use this flag, the controller needs the proper timeout based on minimum RPM to avoid waiting forever.
> 

I am not going to accept this patch as-is. If userspace wants to have
values accurate down to ms, this kind of approach is just wrong. Users
will have to live with the fact that measurements may be a bit (in the 
< 1 second range) out of date. Many older drivers even implement code
which avoids reading registers again for a second or longer. Older
temperature sensors may take several seconds to provide new readings.
That is not a reason to block userspace until a new value is available.
I do not see that as a problem. In my opinion it is much more of a
problem if the driver returns a completely bad value such as 0 or even
an error code because its software parameters did not match reality and
the driver didn't wait long enough for a new value. That would be _much_
worse than providing a value which is a few 100 ms out of date, and your
code is vulnerable to that problem.

Besides, for a fan to reduce its speed that quickly, it has to be manually
stopped. Normally fans take several seconds to stop if power is taken away
completely. Your code is adding a lot of complexity (and unnecessary
attributes) for no good reason.

Guenter
  

On 2022/11/3, 10:31 PM, "Guenter Roeck" <groeck7@gmail.com on behalf of linux@roeck-us.net> wrote:

    On Thu, Nov 03, 2022 at 05:40:44AM +0000, Billy Tsai wrote:
    > > On 2022/11/3, 12:30 PM, "Guenter Roeck" <groeck7@gmail.com on behalf of linux@roeck-us.net> wrote:
    > > 
    > >     On Thu, Nov 03, 2022 at 03:52:59AM +0000, Billy Tsai wrote:
    > >     > > 
    > >     > > Can't I use a min/max RPM to let the driver know a reasonable timeout/polling period when
    > >     > > the driver is trying to get RPM?
    > >     > > Beacause that our tach controller have the falg to indicates the hardware detected the change
    > >     > > in the input signal. I need the proper timout to rule out slow RPMs.
    > > 
    > >     > If the chip measures the fan speed continuously, why would that ever be a
    > >     > problem, and why wait in the first place instead of just taking the most
    > >     > recent result ?
    > > 
    > >     > Pretty much every other driver is doing that, so I really don't understand
    > >     > why that would not work here.
    > > 
    > > When the fan speed drop from a very fast RPM to a very slow RPM. Especially when it is close to stopping.
    > > The most recent result will be no meaningful value. The slower RPM needs more time to sample it. E.g., If
    > > we want to measure the fan with 600 RPM, the controller needs at least 100ms. During this time period, we
    > > will always get the wrong value. So, our tach controller have the flag to avoid this problem:
    > > TACH_ASPEED_VALUE_UPDATE: tach value updated since last read
    > > This flag will be set when the controller detected the change of the signal and clear by read it.
    > > In order to use this flag, the controller needs the proper timeout based on minimum RPM to avoid waiting forever.
    > > 

    > I am not going to accept this patch as-is. If userspace wants to have
    > values accurate down to ms, this kind of approach is just wrong. Users
    > will have to live with the fact that measurements may be a bit (in the 
    > < 1 second range) out of date. Many older drivers even implement code
    > which avoids reading registers again for a second or longer. Older
    > temperature sensors may take several seconds to provide new readings.
    > That is not a reason to block userspace until a new value is available.
    > I do not see that as a problem. In my opinion it is much more of a
    > problem if the driver returns a completely bad value such as 0 or even
    > an error code because its software parameters did not match reality and
    > the driver didn't wait long enough for a new value. That would be _much_
    > worse than providing a value which is a few 100 ms out of date, and your
    > code is vulnerable to that problem.

    > Besides, for a fan to reduce its speed that quickly, it has to be manually
    > stopped. Normally fans take several seconds to stop if power is taken away
    > completely. Your code is adding a lot of complexity (and unnecessary
    > attributes) for no good reason.

Thanks for your detailed explanations.
I will remove the min and max RPMs and return the tach value directly without any polling or delay.

Best Regards,
Billy Tsai