[PATCH v5 0/2] pwm: intel: Add PWM driver for a new SoC

[PATCH v5 0/2] pwm: intel: Add PWM driver for a new SoC

[Rahul Tanwar]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 2478 bytes --]

Patch 1 adds dt binding document in YAML format.
Patch 2 add PWM fan controller driver for LGM SoC.

Patch series is baselined on linux 5.8-rc5.

v5:
- Address below review concerns from Uwe Kleine-König.
  * Improve comments about Limitations.
  * Use return value of regmap_update_bits if container function returns
    error code.
  * Modify .apply op to have strict checking for fixed period supported
    by PWM HW.
  * Use u64 as type when use min_t for duty_cycle.
  * Add reset_control_assert() in failure case in probe where it was missing
    earlier.
- Remove fan specific optional properties from pwm dt binding document (Rob Herring)

v4:
- Address below review concerns from Uwe Kleine-König.
  * Improve notes and limitations comments.
  * Add common prefixes for all #defines.
  * Modify/Improve logic in .apply & .get_state ops as advised.
  * Skip error messages in probe when error is -EPROBE_DEFER.
  * Add dependencies in Kconfig (OF & HAS_IOMEM) and add select REGMAP_MMIO.
  * Address other code quality related review concerns.
- Fix make dt_binding_check reported error in YAML file.

v3:
- Address below review concerns from Uwe Kleine-König.
  * Remove fan rpm calibration task from the driver.
  * Modify apply op as per the review feedback.
  * Add roundup & round down where necessary.
  * Address other misc code quality related review concerns.
  * Use devm_reset_control_get_exclusive(). (Philipp Zabel)
  * Improve dt binding document.

v2:
- Address below review concerns from Uwe Kleine-König.
  * Add notes and limitations about PWM HW.
  * Rename all functions and structure to lgm_pwm_* 
  * Readjust space aligninment in structure fields to single space.
  * Switch to using apply instead of config/enable/disable.
  * Address other code quality related concerns.
  * Rebase to 5.8-rc1.
- Address review concerns in dt binding YAML from Rob Herring.

v1:
- Initial version.


Rahul Tanwar (2):
  Add DT bindings YAML schema for PWM fan controller of LGM SoC
  Add PWM fan controller driver for LGM SoC

 .../devicetree/bindings/pwm/intel,lgm-pwm.yaml     |  40 +++
 drivers/pwm/Kconfig                                |  11 +
 drivers/pwm/Makefile                               |   1 +
 drivers/pwm/pwm-intel-lgm.c                        | 269 +++++++++++++++++++++
 4 files changed, 321 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml
 create mode 100644 drivers/pwm/pwm-intel-lgm.c

-- 
2.11.0

[PATCH v5 1/2] Add DT bindings YAML schema for PWM fan controller of LGM SoC

[Rahul Tanwar]

Intel's LGM(Lightning Mountain) SoC contains a PWM fan controller
which is only used to control the fan attached to the system. This
PWM controller does not have any other consumer other than fan.
Add DT bindings documentation for this PWM fan controller.

Signed-off-by: Rahul Tanwar <rahul.tanwar-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
---
 .../devicetree/bindings/pwm/intel,lgm-pwm.yaml     | 40 ++++++++++++++++++++++
 1 file changed, 40 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml

diff --git a/Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml b/Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml
new file mode 100644
index 000000000000..0211a0dc79ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/intel,lgm-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LGM SoC PWM fan controller
+
+maintainers:
+  - Rahul Tanwar <rahul.tanwar-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
+
+properties:
+  compatible:
+    const: intel,lgm-pwm
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+  resets:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - resets
+
+additionalProperties: false
+
+examples:
+  - |
+    pwm: pwm@e0d00000 {
+        compatible = "intel,lgm-pwm";
+        reg = <0xe0d00000 0x30>;
+        clocks = <&cgu0 126>;
+        resets = <&rcu0 0x30 21>;
+    };
-- 
2.11.0

Re: [PATCH v5 1/2] Add DT bindings YAML schema for PWM fan controller of LGM SoC

[Rob Herring]

On Thu, 23 Jul 2020 15:44:17 +0800, Rahul Tanwar wrote:
> Intel's LGM(Lightning Mountain) SoC contains a PWM fan controller
> which is only used to control the fan attached to the system. This
> PWM controller does not have any other consumer other than fan.
> Add DT bindings documentation for this PWM fan controller.
> 
> Signed-off-by: Rahul Tanwar <rahul.tanwar-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> ---
>  .../devicetree/bindings/pwm/intel,lgm-pwm.yaml     | 40 ++++++++++++++++++++++
>  1 file changed, 40 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml
> 


My bot found errors running 'make dt_binding_check' on your patch:

/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/reset/intel,rcu-gw.example.dt.yaml: pwm@e0d00000: '#pwm-cells' does not match any of the regexes: 'pinctrl-[0-9]+'
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/pwm/intel,lgm-pwm.example.dt.yaml: pwm@e0d00000: '#pwm-cells' is a required property


See https://patchwork.ozlabs.org/patch/1334579

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:

pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade

Please check and re-submit.

[PATCH v5 2/2] Add PWM fan controller driver for LGM SoC

[Rahul Tanwar]

Intel Lightning Mountain(LGM) SoC contains a PWM fan controller.
This PWM controller does not have any other consumer, it is a
dedicated PWM controller for fan attached to the system. Add
driver for this PWM fan controller.

Signed-off-by: Rahul Tanwar <rahul.tanwar-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
---
 drivers/pwm/Kconfig         |  11 ++
 drivers/pwm/Makefile        |   1 +
 drivers/pwm/pwm-intel-lgm.c | 269 ++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 281 insertions(+)
 create mode 100644 drivers/pwm/pwm-intel-lgm.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index cb8d739067d2..3486edab09c4 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -232,6 +232,17 @@ config PWM_IMX_TPM
 	  To compile this driver as a module, choose M here: the module
 	  will be called pwm-imx-tpm.
 
+config PWM_INTEL_LGM
+	tristate "Intel LGM PWM support"
+	depends on OF && HAS_IOMEM
+	depends on X86 || COMPILE_TEST
+	select REGMAP_MMIO
+	help
+	  Generic PWM fan controller driver for LGM SoC.
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called pwm-intel-lgm.
+
 config PWM_IQS620A
 	tristate "Azoteq IQS620A PWM support"
 	depends on MFD_IQS62X || COMPILE_TEST
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index a59c710e98c7..db154a6b4f51 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_PWM_IMG)		+= pwm-img.o
 obj-$(CONFIG_PWM_IMX1)		+= pwm-imx1.o
 obj-$(CONFIG_PWM_IMX27)		+= pwm-imx27.o
 obj-$(CONFIG_PWM_IMX_TPM)	+= pwm-imx-tpm.o
+obj-$(CONFIG_PWM_INTEL_LGM)	+= pwm-intel-lgm.o
 obj-$(CONFIG_PWM_IQS620A)	+= pwm-iqs620a.o
 obj-$(CONFIG_PWM_JZ4740)	+= pwm-jz4740.o
 obj-$(CONFIG_PWM_LP3943)	+= pwm-lp3943.o
diff --git a/drivers/pwm/pwm-intel-lgm.c b/drivers/pwm/pwm-intel-lgm.c
new file mode 100644
index 000000000000..7c6c21512d53
--- /dev/null
+++ b/drivers/pwm/pwm-intel-lgm.c
@@ -0,0 +1,269 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Intel Corporation.
+ *
+ * Limitations:
+ * - The hardware supports fixed period which is dependent on 2/3 or 4
+ *   wire fan mode.
+ * - Supports normal polarity. Does not support changing polarity.
+ * - When PWM is disabled, output of PWM will become 0(inactive). It doesn't
+ *   keep track of running period.
+ * - When duty cycle is changed, PWM output may be a mix of previous setting
+ *   and new setting for the first period. From second period, the output is
+ *   based on new setting.
+ * - It is a dedicated PWM fan controller. There are no other consumers for
+ *   this PWM controller.
+ */
+#include <linux/bitfield.h>
+#include <linux/clk.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/pwm.h>
+#include <linux/regmap.h>
+#include <linux/reset.h>
+
+#define LGM_PWM_FAN_CON0		0x0
+#define LGM_PWM_FAN_EN_EN		BIT(0)
+#define LGM_PWM_FAN_EN_DIS		0x0
+#define LGM_PWM_FAN_EN_MSK		BIT(0)
+#define LGM_PWM_FAN_MODE_2WIRE		0x0
+#define LGM_PWM_FAN_MODE_4WIRE		0x1
+#define LGM_PWM_FAN_MODE_MSK		BIT(1)
+#define LGM_PWM_FAN_DC_MSK		GENMASK(23, 16)
+
+#define LGM_PWM_FAN_CON1		0x4
+#define LGM_PWM_FAN_MAX_RPM_MSK		GENMASK(15, 0)
+
+#define LGM_PWM_MAX_RPM			(BIT(16) - 1)
+#define LGM_PWM_DEFAULT_RPM		4000
+#define LGM_PWM_MAX_DUTY_CYCLE		(BIT(8) - 1)
+
+#define LGM_PWM_DC_BITS			8
+
+#define LGM_PWM_PERIOD_2WIRE_NSECS	40000000
+#define LGM_PWM_PERIOD_4WIRE_NSECS	40000
+
+struct lgm_pwm_chip {
+	struct pwm_chip chip;
+	struct regmap *regmap;
+	struct clk *clk;
+	struct reset_control *rst;
+	u32 period;
+};
+
+static inline struct lgm_pwm_chip *to_lgm_pwm_chip(struct pwm_chip *chip)
+{
+	return container_of(chip, struct lgm_pwm_chip, chip);
+}
+
+static int lgm_pwm_enable(struct pwm_chip *chip, bool enable)
+{
+	struct lgm_pwm_chip *pc = to_lgm_pwm_chip(chip);
+	struct regmap *regmap = pc->regmap;
+
+	return regmap_update_bits(regmap, LGM_PWM_FAN_CON0, LGM_PWM_FAN_EN_MSK,
+				  enable ? LGM_PWM_FAN_EN_EN : LGM_PWM_FAN_EN_DIS);
+}
+
+static int lgm_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+			 const struct pwm_state *state)
+{
+	struct lgm_pwm_chip *pc = to_lgm_pwm_chip(chip);
+	u32 duty_cycle, val;
+	int ret;
+
+	if (!state->enabled) {
+		ret = lgm_pwm_enable(chip, 0);
+		return ret;
+	}
+
+	/*
+	 * HW only supports NORMAL polarity
+	 * HW supports fixed period which can not be changed/configured by user
+	 */
+	if (state->polarity != PWM_POLARITY_NORMAL ||
+	    state->period != pc->period)
+		return -EINVAL;
+
+	duty_cycle = min_t(u64, state->duty_cycle, state->period);
+	/* reg_value = duty_ns * LGM_PWM_MAX_DUTY_CYCLE(0xff) / period_ns */
+	val = duty_cycle * LGM_PWM_MAX_DUTY_CYCLE / state->period;
+
+	ret = regmap_update_bits(pc->regmap, LGM_PWM_FAN_CON0, LGM_PWM_FAN_DC_MSK,
+				 FIELD_PREP(LGM_PWM_FAN_DC_MSK, val));
+	if (ret)
+		return ret;
+
+	if (state->enabled)
+		ret = lgm_pwm_enable(chip, 1);
+
+	return ret;
+}
+
+static void lgm_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
+			      struct pwm_state *state)
+{
+	struct lgm_pwm_chip *pc = to_lgm_pwm_chip(chip);
+	u32 duty, val;
+
+	state->enabled = regmap_test_bits(pc->regmap, LGM_PWM_FAN_CON0,
+					  LGM_PWM_FAN_EN_EN);
+	state->polarity = PWM_POLARITY_NORMAL;
+	state->period = pc->period; /* fixed period */
+
+	regmap_read(pc->regmap, LGM_PWM_FAN_CON0, &val);
+	duty = FIELD_GET(LGM_PWM_FAN_DC_MSK, val);
+	state->duty_cycle = DIV_ROUND_UP(duty * pc->period,
+					 LGM_PWM_MAX_DUTY_CYCLE);
+}
+
+static const struct pwm_ops lgm_pwm_ops = {
+	.get_state = lgm_pwm_get_state,
+	.apply = lgm_pwm_apply,
+	.owner = THIS_MODULE,
+};
+
+static void lgm_pwm_init(struct lgm_pwm_chip *pc)
+{
+	struct device *dev = pc->chip.dev;
+	struct regmap *regmap = pc->regmap;
+	u32 max_rpm, fan_wire, con0_val, con0_mask;
+
+	if (device_property_read_u32(dev, "intel,fan-wire", &fan_wire))
+		fan_wire = 2; /* default is 2 wire mode */
+
+	con0_mask = LGM_PWM_FAN_MODE_MSK;
+
+	switch (fan_wire) {
+	case 4:
+		con0_val = FIELD_PREP(LGM_PWM_FAN_MODE_MSK, LGM_PWM_FAN_MODE_4WIRE);
+		pc->period = LGM_PWM_PERIOD_4WIRE_NSECS;
+		break;
+	default:
+		/* default is 2wire mode */
+		con0_val = FIELD_PREP(LGM_PWM_FAN_MODE_MSK, LGM_PWM_FAN_MODE_2WIRE);
+		pc->period = LGM_PWM_PERIOD_2WIRE_NSECS;
+		break;
+	}
+
+	if (device_property_read_u32(dev, "intel,max-rpm", &max_rpm))
+		max_rpm = LGM_PWM_DEFAULT_RPM;
+
+	max_rpm = min_t(u32, max_rpm, LGM_PWM_MAX_RPM);
+	if (max_rpm == 0)
+		max_rpm = LGM_PWM_DEFAULT_RPM;
+
+	regmap_update_bits(regmap, LGM_PWM_FAN_CON1, LGM_PWM_FAN_MAX_RPM_MSK, max_rpm);
+	regmap_update_bits(regmap, LGM_PWM_FAN_CON0, con0_mask, con0_val);
+}
+
+static const struct regmap_config lgm_pwm_regmap_config = {
+	.reg_bits = 32,
+	.reg_stride = 4,
+	.val_bits = 32,
+};
+
+static int lgm_pwm_probe(struct platform_device *pdev)
+{
+	struct lgm_pwm_chip *pc;
+	struct device *dev = &pdev->dev;
+	void __iomem *io_base;
+	int ret;
+
+	pc = devm_kzalloc(dev, sizeof(*pc), GFP_KERNEL);
+	if (!pc)
+		return -ENOMEM;
+
+	io_base = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(io_base))
+		return PTR_ERR(io_base);
+
+	pc->regmap = devm_regmap_init_mmio(dev, io_base, &lgm_pwm_regmap_config);
+	if (IS_ERR(pc->regmap)) {
+		ret = PTR_ERR(pc->regmap);
+		if (ret != -EPROBE_DEFER)
+			dev_err(dev, "failed to init register map: %pe\n",
+				pc->regmap);
+		return ret;
+	}
+
+	pc->clk = devm_clk_get(dev, NULL);
+	if (IS_ERR(pc->clk)) {
+		ret = PTR_ERR(pc->clk);
+		if (ret != -EPROBE_DEFER)
+			dev_err(dev, "failed to get clock: %pe\n", pc->clk);
+		return ret;
+	}
+
+	pc->rst = devm_reset_control_get_exclusive(dev, NULL);
+	if (IS_ERR(pc->rst)) {
+		ret = PTR_ERR(pc->rst);
+		if (ret != -EPROBE_DEFER)
+			dev_err(dev, "failed to get reset control: %pe\n",
+				pc->rst);
+		return ret;
+	}
+
+	ret = reset_control_deassert(pc->rst);
+	if (ret) {
+		if (ret != -EPROBE_DEFER)
+			dev_err(dev, "cannot deassert reset control: %pe\n",
+				ERR_PTR(ret));
+		return ret;
+	}
+
+	ret = clk_prepare_enable(pc->clk);
+	if (ret) {
+		dev_err(dev, "failed to enable clock\n");
+		reset_control_assert(pc->rst);
+		return ret;
+	}
+
+	pc->chip.dev = dev;
+	pc->chip.ops = &lgm_pwm_ops;
+	pc->chip.npwm = 1;
+
+	lgm_pwm_init(pc);
+
+	ret = pwmchip_add(&pc->chip);
+	if (ret < 0) {
+		dev_err(dev, "failed to add PWM chip: %pe\n", ERR_PTR(ret));
+		clk_disable_unprepare(pc->clk);
+		reset_control_assert(pc->rst);
+		return ret;
+	}
+
+	platform_set_drvdata(pdev, pc);
+	return 0;
+}
+
+static int lgm_pwm_remove(struct platform_device *pdev)
+{
+	struct lgm_pwm_chip *pc = platform_get_drvdata(pdev);
+	int ret;
+
+	ret = pwmchip_remove(&pc->chip);
+	if (ret < 0)
+		return ret;
+
+	clk_disable_unprepare(pc->clk);
+	reset_control_assert(pc->rst);
+
+	return 0;
+}
+
+static const struct of_device_id lgm_pwm_of_match[] = {
+	{ .compatible = "intel,lgm-pwm" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, lgm_pwm_of_match);
+
+static struct platform_driver lgm_pwm_driver = {
+	.driver = {
+		.name = "intel-pwm",
+		.of_match_table = lgm_pwm_of_match,
+	},
+	.probe = lgm_pwm_probe,
+	.remove = lgm_pwm_remove,
+};
+module_platform_driver(lgm_pwm_driver);
-- 
2.11.0

Re: [PATCH v5 2/2] Add PWM fan controller driver for LGM SoC

[Uwe Kleine-König]

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

Hello,

On Thu, Jul 23, 2020 at 03:44:18PM +0800, Rahul Tanwar wrote:
> +static int lgm_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> +			 const struct pwm_state *state)
> +{
> +	struct lgm_pwm_chip *pc = to_lgm_pwm_chip(chip);
> +	u32 duty_cycle, val;
> +	int ret;
> +
> +	if (!state->enabled) {
> +		ret = lgm_pwm_enable(chip, 0);
> +		return ret;
> +	}
> +
> +	/*
> +	 * HW only supports NORMAL polarity
> +	 * HW supports fixed period which can not be changed/configured by user
> +	 */
> +	if (state->polarity != PWM_POLARITY_NORMAL ||
> +	    state->period != pc->period)
> +		return -EINVAL;

At least for state->polarity you have to check before state->enabled, as
the expectation on

        .enabled = false
        .polarity = PWM_POLARITY_INVERSED

is that the output becomes constant high. Also as confirmed at the end
of v4, state->period < pc->period was the right check to do.

> +	duty_cycle = min_t(u64, state->duty_cycle, state->period);
> +	/* reg_value = duty_ns * LGM_PWM_MAX_DUTY_CYCLE(0xff) / period_ns */
> +	val = duty_cycle * LGM_PWM_MAX_DUTY_CYCLE / state->period;

The comment adds only little compared to the code line below. Please
drop it.

Dividing by state->period is wrong. I think you need pc->period here.

> +	ret = regmap_update_bits(pc->regmap, LGM_PWM_FAN_CON0, LGM_PWM_FAN_DC_MSK,
> +				 FIELD_PREP(LGM_PWM_FAN_DC_MSK, val));
> +	if (ret)
> +		return ret;
> +
> +	if (state->enabled)
> +		ret = lgm_pwm_enable(chip, 1);
> +
> +	return ret;
> +}
> +
> +static void lgm_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
> +			      struct pwm_state *state)
> +{
> +	struct lgm_pwm_chip *pc = to_lgm_pwm_chip(chip);
> +	u32 duty, val;
> +
> +	state->enabled = regmap_test_bits(pc->regmap, LGM_PWM_FAN_CON0,
> +					  LGM_PWM_FAN_EN_EN);
> +	state->polarity = PWM_POLARITY_NORMAL;
> +	state->period = pc->period; /* fixed period */
> +
> +	regmap_read(pc->regmap, LGM_PWM_FAN_CON0, &val);
> +	duty = FIELD_GET(LGM_PWM_FAN_DC_MSK, val);
> +	state->duty_cycle = DIV_ROUND_UP(duty * pc->period,
> +					 LGM_PWM_MAX_DUTY_CYCLE);
> +}
> +
> +static const struct pwm_ops lgm_pwm_ops = {
> +	.get_state = lgm_pwm_get_state,
> +	.apply = lgm_pwm_apply,
> +	.owner = THIS_MODULE,
> +};
> +
> +static void lgm_pwm_init(struct lgm_pwm_chip *pc)
> +{
> +	struct device *dev = pc->chip.dev;
> +	struct regmap *regmap = pc->regmap;
> +	u32 max_rpm, fan_wire, con0_val, con0_mask;
> +
> +	if (device_property_read_u32(dev, "intel,fan-wire", &fan_wire))
> +		fan_wire = 2; /* default is 2 wire mode */
> +
> +	con0_mask = LGM_PWM_FAN_MODE_MSK;
> +
> +	switch (fan_wire) {
> +	case 4:
> +		con0_val = FIELD_PREP(LGM_PWM_FAN_MODE_MSK, LGM_PWM_FAN_MODE_4WIRE);
> +		pc->period = LGM_PWM_PERIOD_4WIRE_NSECS;
> +		break;
> +	default:
> +		/* default is 2wire mode */
> +		con0_val = FIELD_PREP(LGM_PWM_FAN_MODE_MSK, LGM_PWM_FAN_MODE_2WIRE);
> +		pc->period = LGM_PWM_PERIOD_2WIRE_NSECS;
> +		break;
> +	}
> +
> +	if (device_property_read_u32(dev, "intel,max-rpm", &max_rpm))
> +		max_rpm = LGM_PWM_DEFAULT_RPM;

This property isn't in the binding!?

> +	max_rpm = min_t(u32, max_rpm, LGM_PWM_MAX_RPM);
> +	if (max_rpm == 0)
> +		max_rpm = LGM_PWM_DEFAULT_RPM;
> +
> +	regmap_update_bits(regmap, LGM_PWM_FAN_CON1, LGM_PWM_FAN_MAX_RPM_MSK, max_rpm);
> +	regmap_update_bits(regmap, LGM_PWM_FAN_CON0, con0_mask, con0_val);
> +}

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

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

Re: [PATCH v5 2/2] Add PWM fan controller driver for LGM SoC

[Tanwar, Rahul]

Hi Uwe,

On 24/7/2020 12:15 am, Uwe Kleine-König wrote:
> Hello,
>
> On Thu, Jul 23, 2020 at 03:44:18PM +0800, Rahul Tanwar wrote:
>> +static int lgm_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
>> +			 const struct pwm_state *state)
>> +{
>> +	struct lgm_pwm_chip *pc = to_lgm_pwm_chip(chip);
>> +	u32 duty_cycle, val;
>> +	int ret;
>> +
>> +	if (!state->enabled) {
>> +		ret = lgm_pwm_enable(chip, 0);
>> +		return ret;
>> +	}
>> +
>> +	/*
>> +	 * HW only supports NORMAL polarity
>> +	 * HW supports fixed period which can not be changed/configured by user
>> +	 */
>> +	if (state->polarity != PWM_POLARITY_NORMAL ||
>> +	    state->period != pc->period)
>> +		return -EINVAL;
> At least for state->polarity you have to check before state->enabled, as
> the expectation on
>
>         .enabled = false
>         .polarity = PWM_POLARITY_INVERSED
>
> is that the output becomes constant high. Also as confirmed at the end
> of v4, state->period < pc->period was the right check to do.

For below case:

.enabled = false
.polarity = PWM_POLARITY_INVERSED

Since our HW does not support inversed polarity, the output for above case
is expected to be constant low. And if we disable PWM before checking for
polarity, the output becomes constant low. The code just does that. Sorry,
i could not understand what is wrong with the code. It looks correct to me.

Given the fact that we support fixed period, if we allow
state->period < pc->period case then the duty cycle will be evaluated as
higher than the requested one because the state->period is lesser than
the actual fixed period supported by the HW. Can you please elaborate
on why you think we should allow state->period < pc->period case?

Thanks,

Regards,
Rahul

Re: [PATCH v5 2/2] Add PWM fan controller driver for LGM SoC

[Uwe Kleine-König]

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

On Mon, Jul 27, 2020 at 02:04:56PM +0800, Tanwar, Rahul wrote:
> 
> Hi Uwe,
> 
> On 24/7/2020 12:15 am, Uwe Kleine-König wrote:
> > Hello,
> >
> > On Thu, Jul 23, 2020 at 03:44:18PM +0800, Rahul Tanwar wrote:
> >> +static int lgm_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> >> +			 const struct pwm_state *state)
> >> +{
> >> +	struct lgm_pwm_chip *pc = to_lgm_pwm_chip(chip);
> >> +	u32 duty_cycle, val;
> >> +	int ret;
> >> +
> >> +	if (!state->enabled) {
> >> +		ret = lgm_pwm_enable(chip, 0);
> >> +		return ret;
> >> +	}
> >> +
> >> +	/*
> >> +	 * HW only supports NORMAL polarity
> >> +	 * HW supports fixed period which can not be changed/configured by user
> >> +	 */
> >> +	if (state->polarity != PWM_POLARITY_NORMAL ||
> >> +	    state->period != pc->period)
> >> +		return -EINVAL;
> > At least for state->polarity you have to check before state->enabled, as
> > the expectation on
> >
> >         .enabled = false
> >         .polarity = PWM_POLARITY_INVERSED
> >
> > is that the output becomes constant high. Also as confirmed at the end
> > of v4, state->period < pc->period was the right check to do.
> 
> For below case:
> 
> .enabled = false
> .polarity = PWM_POLARITY_INVERSED
> 
> Since our HW does not support inversed polarity, the output for above case
> is expected to be constant low. And if we disable PWM before checking for
> polarity, the output becomes constant low. The code just does that. Sorry,
> i could not understand what is wrong with the code. It looks correct to me.

As your hardware can only support normal polarity, the code must have:

	if (state->polarity != PWM_POLARITY_NORMAL)
		return -EINVAL;

	if (!state->enabled) {
		ret = lgm_pwm_enable(chip, 0);
		return ret;
	}

That's what I meant writing: "At least for state->polarity you have to
check before state->enabled".

> Given the fact that we support fixed period, if we allow
> state->period < pc->period case then the duty cycle will be evaluated as
> higher than the requested one because the state->period is lesser than
> the actual fixed period supported by the HW. Can you please elaborate
> on why you think we should allow state->period < pc->period case?

You should not allow it. In v4 you had:

	if (state->polarity != PWM_POLARITY_NORMAL ||
	    state->period < pc->period)
		return -EINVAL;

That's the right thing to do (even though I was unsettled at one point
and wrote it was wrong). The check in v5 with state->period !=
pc->period is wrong.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

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

Re: [PATCH v5 2/2] Add PWM fan controller driver for LGM SoC

[Tanwar, Rahul]

Hi Uwe,

On 27/7/2020 3:01 pm, Uwe Kleine-König wrote:
> On Mon, Jul 27, 2020 at 02:04:56PM +0800, Tanwar, Rahul wrote:
>> Hi Uwe,
>>
>> On 24/7/2020 12:15 am, Uwe Kleine-König wrote:
>>> Hello,
>>>
>>> On Thu, Jul 23, 2020 at 03:44:18PM +0800, Rahul Tanwar wrote:
>>>> +static int lgm_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
>>>> +			 const struct pwm_state *state)
>>>> +{
>>>> +	struct lgm_pwm_chip *pc = to_lgm_pwm_chip(chip);
>>>> +	u32 duty_cycle, val;
>>>> +	int ret;
>>>> +
>>>> +	if (!state->enabled) {
>>>> +		ret = lgm_pwm_enable(chip, 0);
>>>> +		return ret;
>>>> +	}
>>>> +
>>>> +	/*
>>>> +	 * HW only supports NORMAL polarity
>>>> +	 * HW supports fixed period which can not be changed/configured by user
>>>> +	 */
>>>> +	if (state->polarity != PWM_POLARITY_NORMAL ||
>>>> +	    state->period != pc->period)
>>>> +		return -EINVAL;
>>> At least for state->polarity you have to check before state->enabled, as
>>> the expectation on
>>>
>>>         .enabled = false
>>>         .polarity = PWM_POLARITY_INVERSED
>>>
>>> is that the output becomes constant high. Also as confirmed at the end
>>> of v4, state->period < pc->period was the right check to do.
>> For below case:
>>
>> .enabled = false
>> .polarity = PWM_POLARITY_INVERSED
>>
>> Since our HW does not support inversed polarity, the output for above case
>> is expected to be constant low. And if we disable PWM before checking for
>> polarity, the output becomes constant low. The code just does that. Sorry,
>> i could not understand what is wrong with the code. It looks correct to me.
> As your hardware can only support normal polarity, the code must have:
>
> 	if (state->polarity != PWM_POLARITY_NORMAL)
> 		return -EINVAL;
>
> 	if (!state->enabled) {
> 		ret = lgm_pwm_enable(chip, 0);
> 		return ret;
> 	}
>
> That's what I meant writing: "At least for state->polarity you have to
> check before state->enabled".

Ok, i understand your point now.

>> Given the fact that we support fixed period, if we allow
>> state->period < pc->period case then the duty cycle will be evaluated as
>> higher than the requested one because the state->period is lesser than
>> the actual fixed period supported by the HW. Can you please elaborate
>> on why you think we should allow state->period < pc->period case?
> You should not allow it. In v4 you had:
>
> 	if (state->polarity != PWM_POLARITY_NORMAL ||
> 	    state->period < pc->period)
> 		return -EINVAL;
>
> That's the right thing to do (even though I was unsettled at one point
> and wrote it was wrong). The check in v5 with state->period !=
> pc->period is wrong.
>

Does that mean we should allow state->period >= pc->period cases?
If the state->period is greater than HW supported pc->period and
if we allow it then the duty cycle will again be evaluated to be
incorrect/higher than requested duty cycle. Am i missing something
else? Thanks.

Regards,
Rahul

Re: [PATCH v5 2/2] Add PWM fan controller driver for LGM SoC

[Uwe Kleine-König]

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

Hello,

On Mon, Jul 27, 2020 at 03:30:16PM +0800, Tanwar, Rahul wrote:
> On 27/7/2020 3:01 pm, Uwe Kleine-König wrote:
> > In v4 you had:
> >
> > 	if (state->polarity != PWM_POLARITY_NORMAL ||
> > 	    state->period < pc->period)
> > 		return -EINVAL;
> >
> > That's the right thing to do (even though I was unsettled at one point
> > and wrote it was wrong). The check in v5 with state->period !=
> > pc->period is wrong.
> 
> Does that mean we should allow state->period >= pc->period cases?

Yes, the driver is supposed to implement the longest period not longer
than the requested one. This implies everything >= pc->period is fine.

> If the state->period is greater than HW supported pc->period and
> if we allow it then the duty cycle will again be evaluated to be
> incorrect/higher than requested duty cycle. Am i missing something
> else? Thanks.

Yes, similar as with period you're supposed to implement the longest
duty cycle your hardware supports and that is not longer than the
requested duty cycle.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

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