* [PATCH v2 0/2] Add PWM driver for Suplus SP7021 SoC @ 2022-03-04 6:20 Hammer Hsieh 2022-03-04 6:20 ` [PATCH v2 1/2] dt-bindings:pwm:Add bindings doc for Sunplus SoC PWM Driver Hammer Hsieh 2022-03-04 6:20 ` [PATCH v2 2/2] pwm:sunplus-pwm:Add " Hammer Hsieh 0 siblings, 2 replies; 11+ messages in thread From: Hammer Hsieh @ 2022-03-04 6:20 UTC (permalink / raw) To: thierry.reding, u.kleine-koenig, lee.jones, robh+dt, linux-pwm, devicetree, linux-kernel Cc: wells.lu, hammer.hsieh, Hammer Hsieh This is a patch series for PWM driver for Suplus SP7021 SoC. Sunplus SP7021 is an ARM Cortex A7 (4 cores) based SoC. It integrates many peripherals (ex: UART. I2C, SPI, SDIO, eMMC, USB, SD card and etc.) into a single chip. It is designed for industrial control. Refer to: https://sunplus-tibbo.atlassian.net/wiki/spaces/doc/overview https://tibbo.com/store/plus1.html Hammer Hsieh (2): dt-bindings:pwm:Add bindings doc for Sunplus SoC PWM Driver pwm:sunplus-pwm:Add Sunplus SoC PWM Driver .../devicetree/bindings/pwm/pwm-sunplus.yaml | 40 ++++ MAINTAINERS | 6 + drivers/pwm/Kconfig | 11 + drivers/pwm/Makefile | 1 + drivers/pwm/pwm-sunplus.c | 229 +++++++++++++++++++++ 5 files changed, 287 insertions(+) create mode 100644 Documentation/devicetree/bindings/pwm/pwm-sunplus.yaml create mode 100644 drivers/pwm/pwm-sunplus.c -- 2.7.4 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v2 1/2] dt-bindings:pwm:Add bindings doc for Sunplus SoC PWM Driver 2022-03-04 6:20 [PATCH v2 0/2] Add PWM driver for Suplus SP7021 SoC Hammer Hsieh @ 2022-03-04 6:20 ` Hammer Hsieh 2022-03-04 15:01 ` Krzysztof Kozlowski 2022-03-04 6:20 ` [PATCH v2 2/2] pwm:sunplus-pwm:Add " Hammer Hsieh 1 sibling, 1 reply; 11+ messages in thread From: Hammer Hsieh @ 2022-03-04 6:20 UTC (permalink / raw) To: thierry.reding, u.kleine-koenig, lee.jones, robh+dt, linux-pwm, devicetree, linux-kernel Cc: wells.lu, hammer.hsieh, Hammer Hsieh Add bindings doc for Sunplus SoC PWM Driver Signed-off-by: Hammer Hsieh <hammerh0314@gmail.com> --- Changes in v2: - Addressed all comments from Rob Herring. modify author's mail match Signed-off-by. - rebase kernel to 5.17 rc5 .../devicetree/bindings/pwm/pwm-sunplus.yaml | 40 ++++++++++++++++++++++ MAINTAINERS | 5 +++ 2 files changed, 45 insertions(+) create mode 100644 Documentation/devicetree/bindings/pwm/pwm-sunplus.yaml diff --git a/Documentation/devicetree/bindings/pwm/pwm-sunplus.yaml b/Documentation/devicetree/bindings/pwm/pwm-sunplus.yaml new file mode 100644 index 0000000..19fe5d5 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/pwm-sunplus.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) Sunplus Co., Ltd. 2021 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pwm/pwm-sunplus.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sunplus SoC PWM Controller + +maintainers: + - Hammer Hsieh <hammerh0314@gmail.com> + +properties: + '#pwm-cells': + const: 2 + + compatible: + items: + - const: sunplus,sp7021-pwm + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - reg + - clocks + +additionalProperties: false + +examples: + - | + pwm: pwm@9c007a00 { + #pwm-cells = <2>; + compatible = "sunplus,sp7021-pwm"; + reg = <0x9c007a00 0x80>; + clocks = <&clkc 0xa2>; + }; diff --git a/MAINTAINERS b/MAINTAINERS index 2524b75..825b714 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -18531,6 +18531,11 @@ L: netdev@vger.kernel.org S: Maintained F: drivers/net/ethernet/dlink/sundance.c +SUNPLUS PWM DRIVER +M: Hammer Hsieh <hammerh0314@gmail.com> +S: Maintained +F: Documentation/devicetree/bindings/pwm/pwm-sunplus.yaml + SUNPLUS RTC DRIVER M: Vincent Shih <vincent.sunplus@gmail.com> L: linux-rtc@vger.kernel.org -- 2.7.4 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH v2 1/2] dt-bindings:pwm:Add bindings doc for Sunplus SoC PWM Driver 2022-03-04 6:20 ` [PATCH v2 1/2] dt-bindings:pwm:Add bindings doc for Sunplus SoC PWM Driver Hammer Hsieh @ 2022-03-04 15:01 ` Krzysztof Kozlowski 2022-03-07 4:18 ` hammer hsieh 0 siblings, 1 reply; 11+ messages in thread From: Krzysztof Kozlowski @ 2022-03-04 15:01 UTC (permalink / raw) To: Hammer Hsieh, thierry.reding, u.kleine-koenig, lee.jones, robh+dt, linux-pwm, devicetree, linux-kernel Cc: wells.lu, hammer.hsieh On 04/03/2022 07:20, Hammer Hsieh wrote: > Add bindings doc for Sunplus SoC PWM Driver You miss spaces in the subject. > > Signed-off-by: Hammer Hsieh <hammerh0314@gmail.com> > --- > Changes in v2: > - Addressed all comments from Rob Herring. > modify author's mail match Signed-off-by. > - rebase kernel to 5.17 rc5 > > .../devicetree/bindings/pwm/pwm-sunplus.yaml | 40 ++++++++++++++++++++++ > MAINTAINERS | 5 +++ > 2 files changed, 45 insertions(+) > create mode 100644 Documentation/devicetree/bindings/pwm/pwm-sunplus.yaml > > diff --git a/Documentation/devicetree/bindings/pwm/pwm-sunplus.yaml b/Documentation/devicetree/bindings/pwm/pwm-sunplus.yaml > new file mode 100644 > index 0000000..19fe5d5 > --- /dev/null > +++ b/Documentation/devicetree/bindings/pwm/pwm-sunplus.yaml > @@ -0,0 +1,40 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +# Copyright (C) Sunplus Co., Ltd. 2021 > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/pwm/pwm-sunplus.yaml# Is it going to be one binding for all Sunplus SoCs? Existing and future? > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Sunplus SoC PWM Controller > + > +maintainers: > + - Hammer Hsieh <hammerh0314@gmail.com> > + allOf with pwm.yaml Then unevaluatedProperties instead of additionalProperties. > +properties: > + '#pwm-cells': > + const: 2 > + > + compatible: Commpatible goes first. Rest of properties you could order alphabetically. Similar approach in required. > + items: > + - const: sunplus,sp7021-pwm > + > + reg: > + maxItems: 1 > + > + clocks: > + maxItems: 1 > + > +required: compatible > + - reg > + - clocks > + > +additionalProperties: false > + > +examples: > + - | > + pwm: pwm@9c007a00 { > + #pwm-cells = <2>; > + compatible = "sunplus,sp7021-pwm"; compatible goes first, then reg. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2 1/2] dt-bindings:pwm:Add bindings doc for Sunplus SoC PWM Driver 2022-03-04 15:01 ` Krzysztof Kozlowski @ 2022-03-07 4:18 ` hammer hsieh 2022-03-07 7:51 ` Krzysztof Kozlowski 0 siblings, 1 reply; 11+ messages in thread From: hammer hsieh @ 2022-03-07 4:18 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: thierry.reding, Uwe Kleine-König, lee.jones, robh+dt, linux-pwm, devicetree, linux-kernel, wells.lu, hammer.hsieh Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> 於 2022年3月4日 週五 下午11:01寫道： > > On 04/03/2022 07:20, Hammer Hsieh wrote: > > Add bindings doc for Sunplus SoC PWM Driver > > You miss spaces in the subject. > ok, will modify it. > > > > Signed-off-by: Hammer Hsieh <hammerh0314@gmail.com> > > --- > > Changes in v2: > > - Addressed all comments from Rob Herring. > > modify author's mail match Signed-off-by. > > - rebase kernel to 5.17 rc5 > > > > .../devicetree/bindings/pwm/pwm-sunplus.yaml | 40 ++++++++++++++++++++++ > > MAINTAINERS | 5 +++ > > 2 files changed, 45 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/pwm/pwm-sunplus.yaml > > > > diff --git a/Documentation/devicetree/bindings/pwm/pwm-sunplus.yaml b/Documentation/devicetree/bindings/pwm/pwm-sunplus.yaml > > new file mode 100644 > > index 0000000..19fe5d5 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/pwm/pwm-sunplus.yaml > > @@ -0,0 +1,40 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +# Copyright (C) Sunplus Co., Ltd. 2021 > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/pwm/pwm-sunplus.yaml# > > Is it going to be one binding for all Sunplus SoCs? Existing and future? > yes, that was my first plan. but not all sunplus SoCs use the same IP-based, so I will change file name form 'pwm-sunplus.yaml' to 'sunplus,sp7021-pwm.yaml' in next patch. > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Sunplus SoC PWM Controller > > + > > +maintainers: > > + - Hammer Hsieh <hammerh0314@gmail.com> > > + > > allOf with pwm.yaml > Then unevaluatedProperties instead of additionalProperties. > ok , will add it. > > > +properties: > > + '#pwm-cells': > > + const: 2 > > + > > + compatible: > > Commpatible goes first. Rest of properties you could order > alphabetically. Similar approach in required. > > ok, will modify it. > > + items: > > + - const: sunplus,sp7021-pwm > > + > > + reg: > > + maxItems: 1 > > + > > + clocks: > > + maxItems: 1 > > + > > +required: > > compatible > > > + - reg > > + - clocks > > > > + > > +additionalProperties: false > > + > > +examples: > > + - | > > + pwm: pwm@9c007a00 { > > + #pwm-cells = <2>; > > + compatible = "sunplus,sp7021-pwm"; > > compatible goes first, then reg. > ok, will modify it. > > Best regards, > Krzysztof ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2 1/2] dt-bindings:pwm:Add bindings doc for Sunplus SoC PWM Driver 2022-03-07 4:18 ` hammer hsieh @ 2022-03-07 7:51 ` Krzysztof Kozlowski 0 siblings, 0 replies; 11+ messages in thread From: Krzysztof Kozlowski @ 2022-03-07 7:51 UTC (permalink / raw) To: hammer hsieh Cc: thierry.reding, Uwe Kleine-König, lee.jones, robh+dt, linux-pwm, devicetree, linux-kernel, wells.lu, hammer.hsieh On 07/03/2022 05:18, hammer hsieh wrote: > Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> 於 2022年3月4日 週五 > 下午11:01寫道： >> >> On 04/03/2022 07:20, Hammer Hsieh wrote: >>> Add bindings doc for Sunplus SoC PWM Driver >> >> You miss spaces in the subject. >> > > ok, will modify it. > >>> >>> Signed-off-by: Hammer Hsieh <hammerh0314@gmail.com> >>> --- >>> Changes in v2: >>> - Addressed all comments from Rob Herring. >>> modify author's mail match Signed-off-by. >>> - rebase kernel to 5.17 rc5 >>> >>> .../devicetree/bindings/pwm/pwm-sunplus.yaml | 40 ++++++++++++++++++++++ >>> MAINTAINERS | 5 +++ >>> 2 files changed, 45 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-sunplus.yaml >>> >>> diff --git a/Documentation/devicetree/bindings/pwm/pwm-sunplus.yaml b/Documentation/devicetree/bindings/pwm/pwm-sunplus.yaml >>> new file mode 100644 >>> index 0000000..19fe5d5 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/pwm/pwm-sunplus.yaml >>> @@ -0,0 +1,40 @@ >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>> +# Copyright (C) Sunplus Co., Ltd. 2021 >>> +%YAML 1.2 >>> +--- >>> +$id: http://devicetree.org/schemas/pwm/pwm-sunplus.yaml# >> >> Is it going to be one binding for all Sunplus SoCs? Existing and future? >> > > yes, that was my first plan. > but not all sunplus SoCs use the same IP-based, > so I will change file name form 'pwm-sunplus.yaml' to > 'sunplus,sp7021-pwm.yaml' in next patch. Yes, that might be better approach, Best regards, Krzysztof ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v2 2/2] pwm:sunplus-pwm:Add Sunplus SoC PWM Driver 2022-03-04 6:20 [PATCH v2 0/2] Add PWM driver for Suplus SP7021 SoC Hammer Hsieh 2022-03-04 6:20 ` [PATCH v2 1/2] dt-bindings:pwm:Add bindings doc for Sunplus SoC PWM Driver Hammer Hsieh @ 2022-03-04 6:20 ` Hammer Hsieh 2022-03-04 18:57 ` Uwe Kleine-König 1 sibling, 1 reply; 11+ messages in thread From: Hammer Hsieh @ 2022-03-04 6:20 UTC (permalink / raw) To: thierry.reding, u.kleine-koenig, lee.jones, robh+dt, linux-pwm, devicetree, linux-kernel Cc: wells.lu, hammer.hsieh, Hammer Hsieh [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset=y, Size: 8739 bytes --] Add Sunplus SoC PWM Driver Signed-off-by: Hammer Hsieh <hammerh0314@gmail.com> --- Changes in v2: - Addressed all comments from Uwe Kleine-König. - rebase kernel to 5.17 rc5 MAINTAINERS | 1 + drivers/pwm/Kconfig | 11 +++ drivers/pwm/Makefile | 1 + drivers/pwm/pwm-sunplus.c | 229 ++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 242 insertions(+) create mode 100644 drivers/pwm/pwm-sunplus.c diff --git a/MAINTAINERS b/MAINTAINERS index 825b714..8710c8e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -18535,6 +18535,7 @@ SUNPLUS PWM DRIVER M: Hammer Hsieh <hammerh0314@gmail.com> S: Maintained F: Documentation/devicetree/bindings/pwm/pwm-sunplus.yaml +F: drivers/pwm/pwm-sunplus.c SUNPLUS RTC DRIVER M: Vincent Shih <vincent.sunplus@gmail.com> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig index 21e3b05..54cfb50 100644 --- a/drivers/pwm/Kconfig +++ b/drivers/pwm/Kconfig @@ -572,6 +572,17 @@ config PWM_SUN4I To compile this driver as a module, choose M here: the module will be called pwm-sun4i. +config PWM_SUNPLUS + tristate "Sunplus PWM support" + depends on ARCH_SUNPLUS || COMPILE_TEST + depends on HAS_IOMEM && OF + help + Generic PWM framework driver for the PWM controller on + Sunplus SoCs. + + To compile this driver as a module, choose M here: the module + will be called pwm-sunplus. + config PWM_TEGRA tristate "NVIDIA Tegra PWM support" depends on ARCH_TEGRA || COMPILE_TEST diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile index 708840b..be58616 100644 --- a/drivers/pwm/Makefile +++ b/drivers/pwm/Makefile @@ -53,6 +53,7 @@ obj-$(CONFIG_PWM_STM32) += pwm-stm32.o obj-$(CONFIG_PWM_STM32_LP) += pwm-stm32-lp.o obj-$(CONFIG_PWM_STMPE) += pwm-stmpe.o obj-$(CONFIG_PWM_SUN4I) += pwm-sun4i.o +obj-$(CONFIG_PWM_SUNPLUS) += pwm-sunplus.o obj-$(CONFIG_PWM_TEGRA) += pwm-tegra.o obj-$(CONFIG_PWM_TIECAP) += pwm-tiecap.o obj-$(CONFIG_PWM_TIEHRPWM) += pwm-tiehrpwm.o diff --git a/drivers/pwm/pwm-sunplus.c b/drivers/pwm/pwm-sunplus.c new file mode 100644 index 0000000..170534f --- /dev/null +++ b/drivers/pwm/pwm-sunplus.c @@ -0,0 +1,229 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * PWM device driver for SUNPLUS SoCs + * + * Limitations: + * - Only supports normal polarity. + * + * Author: Hammer Hsieh <hammerh0314@gmail.com> + */ +#include <linux/clk.h> +#include <linux/io.h> +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/platform_device.h> +#include <linux/pwm.h> + +#define PWM_SUP_CONTROL0 0x000 +#define PWM_SUP_CONTROL1 0x004 +#define PWM_SUP_FREQ_BASE 0x008 +#define PWM_SUP_DUTY_BASE 0x018 +#define PWM_SUP_FREQ(ch) (PWM_SUP_FREQ_BASE + 4 * (ch)) +#define PWM_SUP_DUTY(ch) (PWM_SUP_DUTY_BASE + 4 * (ch)) +#define PWM_SUP_FREQ_MAX GENMASK(15, 0) +#define PWM_SUP_DUTY_MAX GENMASK(7, 0) + +#define PWM_SUP_NUM 4 +#define PWM_BYPASS_BIT_SHIFT 8 +#define PWM_DD_SEL_BIT_SHIFT 8 +#define PWM_SUP_FREQ_SCALER 256 + +struct sunplus_pwm { + struct pwm_chip chip; + void __iomem *base; + struct clk *clk; + u32 approx_period[PWM_SUP_NUM]; + u32 approx_duty_cycle[PWM_SUP_NUM]; +}; + +static inline struct sunplus_pwm *to_sunplus_pwm(struct pwm_chip *chip) +{ + return container_of(chip, struct sunplus_pwm, chip); +} + +static void sunplus_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm) +{ + struct sunplus_pwm *priv = to_sunplus_pwm(chip); + u32 value; + + /* disable pwm channel output */ + value = readl(priv->base + PWM_SUP_CONTROL0); + value &= ~BIT(pwm->hwpwm); + writel(value, priv->base + PWM_SUP_CONTROL0); + /* disable pwm channel clk source */ + value = readl(priv->base + PWM_SUP_CONTROL1); + value &= ~BIT(pwm->hwpwm); + writel(value, priv->base + PWM_SUP_CONTROL1); +} + +static int sunplus_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm, + const struct pwm_state *state) +{ + struct sunplus_pwm *priv = to_sunplus_pwm(chip); + u32 dd_freq, duty, value, value1; + u32 tmp, rate; + u64 max_period, period_ns, duty_ns, clk_rate; + + if (state->polarity != pwm->state.polarity) + return -EINVAL; + + if (!state->enabled) { + /* disable pwm channel output */ + value = readl(priv->base + PWM_SUP_CONTROL0); + value &= ~BIT(pwm->hwpwm); + writel(value, priv->base + PWM_SUP_CONTROL0); + /* disable pwm channel clk source */ + value = readl(priv->base + PWM_SUP_CONTROL1); + value &= ~BIT(pwm->hwpwm); + writel(value, priv->base + PWM_SUP_CONTROL1); + return 0; + } + + clk_rate = clk_get_rate(priv->clk); + rate = (u32)clk_rate / 100000; + max_period = PWM_SUP_FREQ_MAX * (PWM_SUP_FREQ_SCALER * 10000 / rate); + + if (state->period > max_period) + return -EINVAL; + + period_ns = state->period; + duty_ns = state->duty_cycle; + + priv->approx_period[pwm->hwpwm] = (u32)period_ns / 100; + priv->approx_duty_cycle[pwm->hwpwm] = (u32)duty_ns / 100; + + /* cal pwm freq and check value under range */ + dd_freq = rate * priv->approx_period[pwm->hwpwm] / (PWM_SUP_FREQ_SCALER * 100); + + if (dd_freq == 0) + return -EINVAL; + + if (dd_freq > PWM_SUP_FREQ_MAX) + dd_freq = PWM_SUP_FREQ_MAX; + + writel(dd_freq, priv->base + PWM_SUP_FREQ(pwm->hwpwm)); + + /* cal and set pwm duty */ + value = readl(priv->base + PWM_SUP_CONTROL0); + value |= BIT(pwm->hwpwm); + value1 = readl(priv->base + PWM_SUP_CONTROL1); + value1 |= BIT(pwm->hwpwm); + if (duty_ns == period_ns) { + value |= BIT(pwm->hwpwm + PWM_BYPASS_BIT_SHIFT); + duty = PWM_SUP_DUTY_MAX; + } else { + value &= ~BIT(pwm->hwpwm + PWM_BYPASS_BIT_SHIFT); + tmp = priv->approx_duty_cycle[pwm->hwpwm] * PWM_SUP_FREQ_SCALER; + tmp /= priv->approx_period[pwm->hwpwm]; + duty = (u32)tmp; + duty |= (pwm->hwpwm << PWM_DD_SEL_BIT_SHIFT); + } + writel(duty, priv->base + PWM_SUP_DUTY(pwm->hwpwm)); + writel(value1, priv->base + PWM_SUP_CONTROL1); + writel(value, priv->base + PWM_SUP_CONTROL0); + + return 0; +} + +static void sunplus_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm, + struct pwm_state *state) +{ + struct sunplus_pwm *priv = to_sunplus_pwm(chip); + u32 value, freq, duty, rate, freq_tmp, duty_tmp; + u64 tmp, clk_rate; + + value = readl(priv->base + PWM_SUP_CONTROL0); + + if (value & BIT(pwm->hwpwm)) { + clk_rate = clk_get_rate(priv->clk); + rate = (u32)clk_rate / 100000; + freq = readl(priv->base + PWM_SUP_FREQ(pwm->hwpwm)); + duty = readl(priv->base + PWM_SUP_DUTY(pwm->hwpwm)); + duty &= ~GENMASK(9, 8); + + freq_tmp = rate * priv->approx_period[pwm->hwpwm] / (PWM_SUP_FREQ_SCALER * 100); + duty_tmp = priv->approx_duty_cycle[pwm->hwpwm] * PWM_SUP_FREQ_SCALER / + priv->approx_period[pwm->hwpwm]; + + if (freq == freq_tmp && duty == duty_tmp) { + state->period = priv->approx_period[pwm->hwpwm] * 100; + state->duty_cycle = priv->approx_duty_cycle[pwm->hwpwm] * 100; + } else { + tmp = (u64)freq * PWM_SUP_FREQ_SCALER * 10000; + state->period = div64_u64(tmp, rate); + tmp = (u64)freq * (u64)duty * 10000; + state->duty_cycle = div64_u64(tmp, rate); + } + state->enabled = true; + } else { + state->enabled = false; + } + + state->polarity = PWM_POLARITY_NORMAL; +} + +static const struct pwm_ops sunplus_pwm_ops = { + .free = sunplus_pwm_free, + .apply = sunplus_pwm_apply, + .get_state = sunplus_pwm_get_state, + .owner = THIS_MODULE, +}; + +static int sunplus_pwm_probe(struct platform_device *pdev) +{ + struct device *dev = &pdev->dev; + struct sunplus_pwm *priv; + int ret; + + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL); + if (!priv) + return -ENOMEM; + + priv->base = devm_platform_ioremap_resource(pdev, 0); + if (IS_ERR(priv->base)) + return PTR_ERR(priv->base); + + priv->clk = devm_clk_get_optional(dev, NULL); + if (IS_ERR(priv->clk)) + return dev_err_probe(dev, PTR_ERR(priv->clk), + "get pwm clock failed\n"); + + ret = clk_prepare_enable(priv->clk); + if (ret) + return ret; + + ret = devm_add_action_or_reset(dev, + (void(*)(void *))clk_disable_unprepare, + priv->clk); + if (ret) + return ret; + + priv->chip.dev = dev; + priv->chip.ops = &sunplus_pwm_ops; + priv->chip.npwm = PWM_SUP_NUM; + + ret = devm_pwmchip_add(dev, &priv->chip); + if (ret < 0) + return dev_err_probe(dev, ret, "Cannot register sunplus PWM\n"); + + return 0; +} + +static const struct of_device_id sunplus_pwm_of_match[] = { + { .compatible = "sunplus,sp7021-pwm", }, + {} +}; +MODULE_DEVICE_TABLE(of, sunplus_pwm_of_match); + +static struct platform_driver sunplus_pwm_driver = { + .probe = sunplus_pwm_probe, + .driver = { + .name = "sunplus-pwm", + .of_match_table = sunplus_pwm_of_match, + }, +}; +module_platform_driver(sunplus_pwm_driver); + +MODULE_DESCRIPTION("Sunplus SoC PWM Driver"); +MODULE_AUTHOR("Hammer Hsieh <hammerh0314@gmail.com>"); +MODULE_LICENSE("GPL"); -- 2.7.4 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH v2 2/2] pwm:sunplus-pwm:Add Sunplus SoC PWM Driver 2022-03-04 6:20 ` [PATCH v2 2/2] pwm:sunplus-pwm:Add " Hammer Hsieh @ 2022-03-04 18:57 ` Uwe Kleine-König 2022-03-07 12:50 ` hammer hsieh 0 siblings, 1 reply; 11+ messages in thread From: Uwe Kleine-König @ 2022-03-04 18:57 UTC (permalink / raw) To: Hammer Hsieh Cc: thierry.reding, lee.jones, robh+dt, linux-pwm, devicetree, linux-kernel, wells.lu, hammer.hsieh [-- Attachment #1: Type: text/plain, Size: 12105 bytes --] Hello, On Fri, Mar 04, 2022 at 02:20:12PM +0800, Hammer Hsieh wrote: > Add Sunplus SoC PWM Driver > > Signed-off-by: Hammer Hsieh <hammerh0314@gmail.com> > --- > Changes in v2: > - Addressed all comments from Uwe Kleine-König. > - rebase kernel to 5.17 rc5 > > MAINTAINERS | 1 + > drivers/pwm/Kconfig | 11 +++ > drivers/pwm/Makefile | 1 + > drivers/pwm/pwm-sunplus.c | 229 ++++++++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 242 insertions(+) > create mode 100644 drivers/pwm/pwm-sunplus.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index 825b714..8710c8e 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -18535,6 +18535,7 @@ SUNPLUS PWM DRIVER > M: Hammer Hsieh <hammerh0314@gmail.com> > S: Maintained > F: Documentation/devicetree/bindings/pwm/pwm-sunplus.yaml > +F: drivers/pwm/pwm-sunplus.c > > SUNPLUS RTC DRIVER > M: Vincent Shih <vincent.sunplus@gmail.com> > diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig > index 21e3b05..54cfb50 100644 > --- a/drivers/pwm/Kconfig > +++ b/drivers/pwm/Kconfig > @@ -572,6 +572,17 @@ config PWM_SUN4I > To compile this driver as a module, choose M here: the module > will be called pwm-sun4i. > > +config PWM_SUNPLUS > + tristate "Sunplus PWM support" > + depends on ARCH_SUNPLUS || COMPILE_TEST > + depends on HAS_IOMEM && OF > + help > + Generic PWM framework driver for the PWM controller on > + Sunplus SoCs. > + > + To compile this driver as a module, choose M here: the module > + will be called pwm-sunplus. > + > config PWM_TEGRA > tristate "NVIDIA Tegra PWM support" > depends on ARCH_TEGRA || COMPILE_TEST > diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile > index 708840b..be58616 100644 > --- a/drivers/pwm/Makefile > +++ b/drivers/pwm/Makefile > @@ -53,6 +53,7 @@ obj-$(CONFIG_PWM_STM32) += pwm-stm32.o > obj-$(CONFIG_PWM_STM32_LP) += pwm-stm32-lp.o > obj-$(CONFIG_PWM_STMPE) += pwm-stmpe.o > obj-$(CONFIG_PWM_SUN4I) += pwm-sun4i.o > +obj-$(CONFIG_PWM_SUNPLUS) += pwm-sunplus.o > obj-$(CONFIG_PWM_TEGRA) += pwm-tegra.o > obj-$(CONFIG_PWM_TIECAP) += pwm-tiecap.o > obj-$(CONFIG_PWM_TIEHRPWM) += pwm-tiehrpwm.o > diff --git a/drivers/pwm/pwm-sunplus.c b/drivers/pwm/pwm-sunplus.c > new file mode 100644 > index 0000000..170534f > --- /dev/null > +++ b/drivers/pwm/pwm-sunplus.c > @@ -0,0 +1,229 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * PWM device driver for SUNPLUS SoCs Is there a public manual available for this hardware? If yes, please add a link here. > + * > + * Limitations: > + * - Only supports normal polarity. How does the HW behave when it's disabled? Usual candidates are: - It freezes at where it currently is - It outputs low - It becomes tristate Please note this in the Limitations section, too. Another thing to mention is if running periods are completed when the parameters change. > + * > + * Author: Hammer Hsieh <hammerh0314@gmail.com> > + */ > +#include <linux/clk.h> > +#include <linux/io.h> > +#include <linux/kernel.h> > +#include <linux/module.h> > +#include <linux/platform_device.h> > +#include <linux/pwm.h> > + > +#define PWM_SUP_CONTROL0 0x000 > +#define PWM_SUP_CONTROL1 0x004 > +#define PWM_SUP_FREQ_BASE 0x008 > +#define PWM_SUP_DUTY_BASE 0x018 > +#define PWM_SUP_FREQ(ch) (PWM_SUP_FREQ_BASE + 4 * (ch)) > +#define PWM_SUP_DUTY(ch) (PWM_SUP_DUTY_BASE + 4 * (ch)) I'd not give PWM_SUP_FREQ_BASE and PWM_SUP_DUTY_BASE a name here, just #define PWM_SUP_FREQ(ch) (0x008 + 4 * (ch)) ... > +#define PWM_SUP_FREQ_MAX GENMASK(15, 0) > +#define PWM_SUP_DUTY_MAX GENMASK(7, 0) > + > +#define PWM_SUP_NUM 4 > +#define PWM_BYPASS_BIT_SHIFT 8 > +#define PWM_DD_SEL_BIT_SHIFT 8 > +#define PWM_SUP_FREQ_SCALER 256 Please use a consistent prefix for the driver specific defines. > +struct sunplus_pwm { > + struct pwm_chip chip; > + void __iomem *base; > + struct clk *clk; > + u32 approx_period[PWM_SUP_NUM]; > + u32 approx_duty_cycle[PWM_SUP_NUM]; > +}; > + > +static inline struct sunplus_pwm *to_sunplus_pwm(struct pwm_chip *chip) > +{ > + return container_of(chip, struct sunplus_pwm, chip); > +} > + > +static void sunplus_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm) > +{ > + struct sunplus_pwm *priv = to_sunplus_pwm(chip); > + u32 value; > + > + /* disable pwm channel output */ > + value = readl(priv->base + PWM_SUP_CONTROL0); > + value &= ~BIT(pwm->hwpwm); > + writel(value, priv->base + PWM_SUP_CONTROL0); > + /* disable pwm channel clk source */ > + value = readl(priv->base + PWM_SUP_CONTROL1); > + value &= ~BIT(pwm->hwpwm); > + writel(value, priv->base + PWM_SUP_CONTROL1); the .free callback isn't supposed to modify the hardware. > +} > + > +static int sunplus_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm, > + const struct pwm_state *state) > +{ > + struct sunplus_pwm *priv = to_sunplus_pwm(chip); > + u32 dd_freq, duty, value, value1; As value and value1 hold register values for PWM_SUP_CONTROL0 and PWM_SUP_CONTROL1, I'd call them control0 and control1 respectively. > + u32 tmp, rate; > + u64 max_period, period_ns, duty_ns, clk_rate; > + > + if (state->polarity != pwm->state.polarity) > + return -EINVAL; > + > + if (!state->enabled) { > + /* disable pwm channel output */ > + value = readl(priv->base + PWM_SUP_CONTROL0); > + value &= ~BIT(pwm->hwpwm); I'd give this one a name. Something like: #define PWM_SUP_CONTROL_EN(ch) BIT(ch) (Pick the right name from the manual.) > + writel(value, priv->base + PWM_SUP_CONTROL0); > + /* disable pwm channel clk source */ > + value = readl(priv->base + PWM_SUP_CONTROL1); > + value &= ~BIT(pwm->hwpwm); > + writel(value, priv->base + PWM_SUP_CONTROL1); > + return 0; > + } > + > + clk_rate = clk_get_rate(priv->clk); > + rate = (u32)clk_rate / 100000; This cast doesn't change anything, does it? > + max_period = PWM_SUP_FREQ_MAX * (PWM_SUP_FREQ_SCALER * 10000 / rate); Here you have rounding issues. Consider rate = 3329. Then you get max_period = 0xffff * (2560000 / 3329) = 0xffff * 768 = 50330880. However the actual result is 50396395.31... Also dividing by the result of a division looses precision. > + > + if (state->period > max_period) > + return -EINVAL; No, you're supposed to implement the biggest period possible not bigger than the requested period. So the right thing here is: > + period_ns = state->period; period = min(state->period, max_period); > + duty_ns = state->duty_cycle; > + > + priv->approx_period[pwm->hwpwm] = (u32)period_ns / 100; > + priv->approx_duty_cycle[pwm->hwpwm] = (u32)duty_ns / 100; Tracking period_ns / 100 seems strange and vulnerable to rounding issues. > + /* cal pwm freq and check value under range */ > + dd_freq = rate * priv->approx_period[pwm->hwpwm] / (PWM_SUP_FREQ_SCALER * 100); This is all too complicated, you just need: dd_freq = mul_u64_u64_div_u64(clk_rate, period, (u64)PWM_SUP_FREQ_SCALER * NSEC_PER_SEC) > + if (dd_freq == 0) > + return -EINVAL; > + > + if (dd_freq > PWM_SUP_FREQ_MAX) > + dd_freq = PWM_SUP_FREQ_MAX; > + > + writel(dd_freq, priv->base + PWM_SUP_FREQ(pwm->hwpwm)); > + > + /* cal and set pwm duty */ > + value = readl(priv->base + PWM_SUP_CONTROL0); > + value |= BIT(pwm->hwpwm); > + value1 = readl(priv->base + PWM_SUP_CONTROL1); > + value1 |= BIT(pwm->hwpwm); > + if (duty_ns == period_ns) { > + value |= BIT(pwm->hwpwm + PWM_BYPASS_BIT_SHIFT); > + duty = PWM_SUP_DUTY_MAX; > + } else { > + value &= ~BIT(pwm->hwpwm + PWM_BYPASS_BIT_SHIFT); > + tmp = priv->approx_duty_cycle[pwm->hwpwm] * PWM_SUP_FREQ_SCALER; > + tmp /= priv->approx_period[pwm->hwpwm]; Please use the exact values available. > + duty = (u32)tmp; > + duty |= (pwm->hwpwm << PWM_DD_SEL_BIT_SHIFT); > + } > + writel(duty, priv->base + PWM_SUP_DUTY(pwm->hwpwm)); > + writel(value1, priv->base + PWM_SUP_CONTROL1); > + writel(value, priv->base + PWM_SUP_CONTROL0); What is the difference between CONTROL1 and CONTROL0? > + return 0; > +} > + > +static void sunplus_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm, > + struct pwm_state *state) > +{ > + struct sunplus_pwm *priv = to_sunplus_pwm(chip); > + u32 value, freq, duty, rate, freq_tmp, duty_tmp; > + u64 tmp, clk_rate; > + > + value = readl(priv->base + PWM_SUP_CONTROL0); > + > + if (value & BIT(pwm->hwpwm)) { > + clk_rate = clk_get_rate(priv->clk); > + rate = (u32)clk_rate / 100000; > + freq = readl(priv->base + PWM_SUP_FREQ(pwm->hwpwm)); > + duty = readl(priv->base + PWM_SUP_DUTY(pwm->hwpwm)); > + duty &= ~GENMASK(9, 8); > + > + freq_tmp = rate * priv->approx_period[pwm->hwpwm] / (PWM_SUP_FREQ_SCALER * 100); > + duty_tmp = priv->approx_duty_cycle[pwm->hwpwm] * PWM_SUP_FREQ_SCALER / > + priv->approx_period[pwm->hwpwm]; > + > + if (freq == freq_tmp && duty == duty_tmp) { > + state->period = priv->approx_period[pwm->hwpwm] * 100; > + state->duty_cycle = priv->approx_duty_cycle[pwm->hwpwm] * 100; > + } else { > + tmp = (u64)freq * PWM_SUP_FREQ_SCALER * 10000; > + state->period = div64_u64(tmp, rate); > + tmp = (u64)freq * (u64)duty * 10000; > + state->duty_cycle = div64_u64(tmp, rate); > + } > + state->enabled = true; > + } else { > + state->enabled = false; > + } > + > + state->polarity = PWM_POLARITY_NORMAL; > +} When .get_state() is first called, .apply wasn't called yet. Then priv->approx_period[pwm->hwpwm] is zero and the returned result is wrong. Please read the register values and calculate the implemented output without caching. > +static const struct pwm_ops sunplus_pwm_ops = { > + .free = sunplus_pwm_free, > + .apply = sunplus_pwm_apply, > + .get_state = sunplus_pwm_get_state, > + .owner = THIS_MODULE, > +}; > + > +static int sunplus_pwm_probe(struct platform_device *pdev) > +{ > + struct device *dev = &pdev->dev; > + struct sunplus_pwm *priv; > + int ret; > + > + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL); > + if (!priv) > + return -ENOMEM; > + > + priv->base = devm_platform_ioremap_resource(pdev, 0); > + if (IS_ERR(priv->base)) > + return PTR_ERR(priv->base); > + > + priv->clk = devm_clk_get_optional(dev, NULL); > + if (IS_ERR(priv->clk)) > + return dev_err_probe(dev, PTR_ERR(priv->clk), > + "get pwm clock failed\n"); If priv->clk is the dummy clk, clk_get_rate returns 0. This is bad as (at lease up to now) you divide by rate in .apply(). > + > + ret = clk_prepare_enable(priv->clk); > + if (ret) missing error message > + return ret; > + > + ret = devm_add_action_or_reset(dev, > + (void(*)(void *))clk_disable_unprepare, Without checking my C book I'm unsure if this is save on all platforms. I'd implement a oneline function for this. > + priv->clk); > + if (ret) missing error message > + return ret; > + > + priv->chip.dev = dev; > + priv->chip.ops = &sunplus_pwm_ops; > + priv->chip.npwm = PWM_SUP_NUM; > + > + ret = devm_pwmchip_add(dev, &priv->chip); > + if (ret < 0) > + return dev_err_probe(dev, ret, "Cannot register sunplus PWM\n"); > + > + return 0; > +} > + > +static const struct of_device_id sunplus_pwm_of_match[] = { > + { .compatible = "sunplus,sp7021-pwm", }, > + {} > +}; > +MODULE_DEVICE_TABLE(of, sunplus_pwm_of_match); > + > +static struct platform_driver sunplus_pwm_driver = { > + .probe = sunplus_pwm_probe, > + .driver = { > + .name = "sunplus-pwm", > + .of_match_table = sunplus_pwm_of_match, > + }, > +}; > +module_platform_driver(sunplus_pwm_driver); > + > +MODULE_DESCRIPTION("Sunplus SoC PWM Driver"); > +MODULE_AUTHOR("Hammer Hsieh <hammerh0314@gmail.com>"); > +MODULE_LICENSE("GPL"); > -- > 2.7.4 > > -- 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 --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2 2/2] pwm:sunplus-pwm:Add Sunplus SoC PWM Driver 2022-03-04 18:57 ` Uwe Kleine-König @ 2022-03-07 12:50 ` hammer hsieh 2022-03-07 13:10 ` Uwe Kleine-König 0 siblings, 1 reply; 11+ messages in thread From: hammer hsieh @ 2022-03-07 12:50 UTC (permalink / raw) To: Uwe Kleine-König Cc: thierry.reding, lee.jones, robh+dt, linux-pwm, devicetree, linux-kernel, wells.lu, hammer.hsieh " Uwe Kleine-König <u.kleine-koenig@pengutronix.de> 於 2022年3月5日 週六 上午2:57寫道： > > Hello, > > On Fri, Mar 04, 2022 at 02:20:12PM +0800, Hammer Hsieh wrote: > > Add Sunplus SoC PWM Driver > > > > Signed-off-by: Hammer Hsieh <hammerh0314@gmail.com> > > --- > > Changes in v2: > > - Addressed all comments from Uwe Kleine-König. > > - rebase kernel to 5.17 rc5 > > > > MAINTAINERS | 1 + > > drivers/pwm/Kconfig | 11 +++ > > drivers/pwm/Makefile | 1 + > > drivers/pwm/pwm-sunplus.c | 229 ++++++++++++++++++++++++++++++++++++++++++++++ > > 4 files changed, 242 insertions(+) > > create mode 100644 drivers/pwm/pwm-sunplus.c > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 825b714..8710c8e 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -18535,6 +18535,7 @@ SUNPLUS PWM DRIVER > > M: Hammer Hsieh <hammerh0314@gmail.com> > > S: Maintained > > F: Documentation/devicetree/bindings/pwm/pwm-sunplus.yaml > > +F: drivers/pwm/pwm-sunplus.c > > > > SUNPLUS RTC DRIVER > > M: Vincent Shih <vincent.sunplus@gmail.com> > > diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig > > index 21e3b05..54cfb50 100644 > > --- a/drivers/pwm/Kconfig > > +++ b/drivers/pwm/Kconfig > > @@ -572,6 +572,17 @@ config PWM_SUN4I > > To compile this driver as a module, choose M here: the module > > will be called pwm-sun4i. > > > > +config PWM_SUNPLUS > > + tristate "Sunplus PWM support" > > + depends on ARCH_SUNPLUS || COMPILE_TEST > > + depends on HAS_IOMEM && OF > > + help > > + Generic PWM framework driver for the PWM controller on > > + Sunplus SoCs. > > + > > + To compile this driver as a module, choose M here: the module > > + will be called pwm-sunplus. > > + > > config PWM_TEGRA > > tristate "NVIDIA Tegra PWM support" > > depends on ARCH_TEGRA || COMPILE_TEST > > diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile > > index 708840b..be58616 100644 > > --- a/drivers/pwm/Makefile > > +++ b/drivers/pwm/Makefile > > @@ -53,6 +53,7 @@ obj-$(CONFIG_PWM_STM32) += pwm-stm32.o > > obj-$(CONFIG_PWM_STM32_LP) += pwm-stm32-lp.o > > obj-$(CONFIG_PWM_STMPE) += pwm-stmpe.o > > obj-$(CONFIG_PWM_SUN4I) += pwm-sun4i.o > > +obj-$(CONFIG_PWM_SUNPLUS) += pwm-sunplus.o > > obj-$(CONFIG_PWM_TEGRA) += pwm-tegra.o > > obj-$(CONFIG_PWM_TIECAP) += pwm-tiecap.o > > obj-$(CONFIG_PWM_TIEHRPWM) += pwm-tiehrpwm.o > > diff --git a/drivers/pwm/pwm-sunplus.c b/drivers/pwm/pwm-sunplus.c > > new file mode 100644 > > index 0000000..170534f > > --- /dev/null > > +++ b/drivers/pwm/pwm-sunplus.c > > @@ -0,0 +1,229 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * PWM device driver for SUNPLUS SoCs > > Is there a public manual available for this hardware? If yes, please add > a link here. > yes, will add links as below https://sunplus-tibbo.atlassian.net/wiki/spaces/doc/overview https://sunplus.atlassian.net/wiki/spaces/doc/pages/461144198/12.+Pulse+Width+Modulation+PWM > > + * > > + * Limitations: > > + * - Only supports normal polarity. > > How does the HW behave when it's disabled? Usual candidates are: > - It freezes at where it currently is > - It outputs low > - It becomes tristate > > Please note this in the Limitations section, too. > > Another thing to mention is if running periods are completed when the > parameters change. > ok, will add note as below Limitations: - Only supports normal polarity. - It output low when PWM channel disabled. - When the parameters change, current running period will not be completed and run new settings immediately. > > + * > > + * Author: Hammer Hsieh <hammerh0314@gmail.com> > > + */ > > +#include <linux/clk.h> > > +#include <linux/io.h> > > +#include <linux/kernel.h> > > +#include <linux/module.h> > > +#include <linux/platform_device.h> > > +#include <linux/pwm.h> > > + > > +#define PWM_SUP_CONTROL0 0x000 > > +#define PWM_SUP_CONTROL1 0x004 > > +#define PWM_SUP_FREQ_BASE 0x008 > > +#define PWM_SUP_DUTY_BASE 0x018 > > +#define PWM_SUP_FREQ(ch) (PWM_SUP_FREQ_BASE + 4 * (ch)) > > +#define PWM_SUP_DUTY(ch) (PWM_SUP_DUTY_BASE + 4 * (ch)) > > I'd not give PWM_SUP_FREQ_BASE and PWM_SUP_DUTY_BASE a name here, just > > #define PWM_SUP_FREQ(ch) (0x008 + 4 * (ch)) > ... > ok, will modify it. > > +#define PWM_SUP_FREQ_MAX GENMASK(15, 0) > > +#define PWM_SUP_DUTY_MAX GENMASK(7, 0) > > + > > +#define PWM_SUP_NUM 4 > > +#define PWM_BYPASS_BIT_SHIFT 8 > > +#define PWM_DD_SEL_BIT_SHIFT 8 > > +#define PWM_SUP_FREQ_SCALER 256 > > Please use a consistent prefix for the driver specific defines. > ok, will modify it. > > +struct sunplus_pwm { > > + struct pwm_chip chip; > > + void __iomem *base; > > + struct clk *clk; > > + u32 approx_period[PWM_SUP_NUM]; > > + u32 approx_duty_cycle[PWM_SUP_NUM]; > > +}; > > + > > +static inline struct sunplus_pwm *to_sunplus_pwm(struct pwm_chip *chip) > > +{ > > + return container_of(chip, struct sunplus_pwm, chip); > > +} > > + > > +static void sunplus_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm) > > +{ > > + struct sunplus_pwm *priv = to_sunplus_pwm(chip); > > + u32 value; > > + > > + /* disable pwm channel output */ > > + value = readl(priv->base + PWM_SUP_CONTROL0); > > + value &= ~BIT(pwm->hwpwm); > > + writel(value, priv->base + PWM_SUP_CONTROL0); > > + /* disable pwm channel clk source */ > > + value = readl(priv->base + PWM_SUP_CONTROL1); > > + value &= ~BIT(pwm->hwpwm); > > + writel(value, priv->base + PWM_SUP_CONTROL1); > > the .free callback isn't supposed to modify the hardware. > But how to turn pwm channel off ? I add .free function for turn it off. In user space cd /sys/class/pwm/pwmchip0 echo 0 > export cd pwm0 echo 20000000 > period echo 1000000 > duty_cycle echo 1 > enable cd .. echo 0 > unexport ; turn off pwm will call .free function > > +} > > + > > +static int sunplus_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm, > > + const struct pwm_state *state) > > +{ > > + struct sunplus_pwm *priv = to_sunplus_pwm(chip); > > + u32 dd_freq, duty, value, value1; > > As value and value1 hold register values for PWM_SUP_CONTROL0 and > PWM_SUP_CONTROL1, I'd call them control0 and control1 respectively. > ok, will modify it. > > + u32 tmp, rate; > > + u64 max_period, period_ns, duty_ns, clk_rate; > > + > > + if (state->polarity != pwm->state.polarity) > > + return -EINVAL; > > + > > + if (!state->enabled) { > > + /* disable pwm channel output */ > > + value = readl(priv->base + PWM_SUP_CONTROL0); > > + value &= ~BIT(pwm->hwpwm); > > I'd give this one a name. Something like: > > #define PWM_SUP_CONTROL_EN(ch) BIT(ch) > > (Pick the right name from the manual.) > That means it need to implement PWM_SUP_CONTROL_EN(ch) and PWM_SUP_CONTROL_DIS(ch) ? > > + writel(value, priv->base + PWM_SUP_CONTROL0); > > + /* disable pwm channel clk source */ > > + value = readl(priv->base + PWM_SUP_CONTROL1); > > + value &= ~BIT(pwm->hwpwm); > > + writel(value, priv->base + PWM_SUP_CONTROL1); > > + return 0; > > + } > > + > > + clk_rate = clk_get_rate(priv->clk); > > + rate = (u32)clk_rate / 100000; > > This cast doesn't change anything, does it? > yes, clk_rate should be 202.5MHz, to prevent overflow use 2025 to calculate. > > + max_period = PWM_SUP_FREQ_MAX * (PWM_SUP_FREQ_SCALER * 10000 / rate); > > Here you have rounding issues. Consider rate = 3329. Then you get > max_period = 0xffff * (2560000 / 3329) = 0xffff * 768 = 50330880. > > However the actual result is 50396395.31... > > Also dividing by the result of a division looses precision. > I am not sure how to fix the rounding issue.(thinking...) > > + > > + if (state->period > max_period) > > + return -EINVAL; > > No, you're supposed to implement the biggest period possible not bigger > than the requested period. So the right thing here is: > > > + period_ns = state->period; > > period = min(state->period, max_period); > ok, will modify it. > > + duty_ns = state->duty_cycle; > > + > > + priv->approx_period[pwm->hwpwm] = (u32)period_ns / 100; > > + priv->approx_duty_cycle[pwm->hwpwm] = (u32)duty_ns / 100; > > Tracking period_ns / 100 seems strange and vulnerable to rounding > issues. > In patch v1, you suggest to enable PWM_DEBUG and make sure there is no warning. For fix ".apply is not idempotent" issue. I add approx_period / approx_duty_cycle for it. > > + /* cal pwm freq and check value under range */ > > + dd_freq = rate * priv->approx_period[pwm->hwpwm] / (PWM_SUP_FREQ_SCALER * 100); > > This is all too complicated, you just need: > ok, will modify it. > dd_freq = mul_u64_u64_div_u64(clk_rate, period, (u64)PWM_SUP_FREQ_SCALER * NSEC_PER_SEC) > > > + if (dd_freq == 0) > > + return -EINVAL; > > + > > + if (dd_freq > PWM_SUP_FREQ_MAX) > > + dd_freq = PWM_SUP_FREQ_MAX; > > + > > + writel(dd_freq, priv->base + PWM_SUP_FREQ(pwm->hwpwm)); > > + > > + /* cal and set pwm duty */ > > + value = readl(priv->base + PWM_SUP_CONTROL0); > > + value |= BIT(pwm->hwpwm); > > + value1 = readl(priv->base + PWM_SUP_CONTROL1); > > + value1 |= BIT(pwm->hwpwm); > > + if (duty_ns == period_ns) { > > + value |= BIT(pwm->hwpwm + PWM_BYPASS_BIT_SHIFT); > > + duty = PWM_SUP_DUTY_MAX; > > + } else { > > + value &= ~BIT(pwm->hwpwm + PWM_BYPASS_BIT_SHIFT); > > + tmp = priv->approx_duty_cycle[pwm->hwpwm] * PWM_SUP_FREQ_SCALER; > > + tmp /= priv->approx_period[pwm->hwpwm]; > > Please use the exact values available. > The same reason, in case of enable PWM_DEBUG. first call .apply , then it will call .get_state for verify the calculation. > > + duty = (u32)tmp; > > + duty |= (pwm->hwpwm << PWM_DD_SEL_BIT_SHIFT); > > + } > > + writel(duty, priv->base + PWM_SUP_DUTY(pwm->hwpwm)); > > + writel(value1, priv->base + PWM_SUP_CONTROL1); > > + writel(value, priv->base + PWM_SUP_CONTROL0); > > What is the difference between CONTROL1 and CONTROL0? > PWM CONTROL0 for PWM channel switch. PWM CONTROL1 for PWM clock source switch. Actually PWM supports 8 channels , but clock source only 4 sets. For easy control(now submit), I just support 4 PWM channels, and one clock source for one pwm channel. For complicated control(not now), 8 PWM channels 4 clock source , need to manage clock source / pwm channel enable or not while request/free pwm channel. > > + return 0; > > +} > > + > > +static void sunplus_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm, > > + struct pwm_state *state) > > +{ > > + struct sunplus_pwm *priv = to_sunplus_pwm(chip); > > + u32 value, freq, duty, rate, freq_tmp, duty_tmp; > > + u64 tmp, clk_rate; > > + > > + value = readl(priv->base + PWM_SUP_CONTROL0); > > + > > + if (value & BIT(pwm->hwpwm)) { > > + clk_rate = clk_get_rate(priv->clk); > > + rate = (u32)clk_rate / 100000; > > + freq = readl(priv->base + PWM_SUP_FREQ(pwm->hwpwm)); > > + duty = readl(priv->base + PWM_SUP_DUTY(pwm->hwpwm)); > > + duty &= ~GENMASK(9, 8); > > + > > + freq_tmp = rate * priv->approx_period[pwm->hwpwm] / (PWM_SUP_FREQ_SCALER * 100); > > + duty_tmp = priv->approx_duty_cycle[pwm->hwpwm] * PWM_SUP_FREQ_SCALER / > > + priv->approx_period[pwm->hwpwm]; > > + > > + if (freq == freq_tmp && duty == duty_tmp) { > > + state->period = priv->approx_period[pwm->hwpwm] * 100; > > + state->duty_cycle = priv->approx_duty_cycle[pwm->hwpwm] * 100; > > + } else { > > + tmp = (u64)freq * PWM_SUP_FREQ_SCALER * 10000; > > + state->period = div64_u64(tmp, rate); > > + tmp = (u64)freq * (u64)duty * 10000; > > + state->duty_cycle = div64_u64(tmp, rate); > > + } > > + state->enabled = true; > > + } else { > > + state->enabled = false; > > + } > > + > > + state->polarity = PWM_POLARITY_NORMAL; > > +} > > When .get_state() is first called, .apply wasn't called yet. Then > priv->approx_period[pwm->hwpwm] is zero and the returned result is > wrong. Please read the register values and calculate the implemented > output without caching. > The same reason, in case of enable PWM_DEBUG. first call .apply , then it will call .get_state for verify the calculation. In get_state, I thought about that. first called .get_state, read register value to calculate period and duty_cycle. after calling .apply , caching data approx_period / approx_duty_cycle will not zero. then get_state will use caching data to do PWM_DEBUG self verification. I will think about how to solve the PWM_DEBUG ".apply is not idempotent" issue. > > +static const struct pwm_ops sunplus_pwm_ops = { > > + .free = sunplus_pwm_free, > > + .apply = sunplus_pwm_apply, > > + .get_state = sunplus_pwm_get_state, > > + .owner = THIS_MODULE, > > +}; > > + > > +static int sunplus_pwm_probe(struct platform_device *pdev) > > +{ > > + struct device *dev = &pdev->dev; > > + struct sunplus_pwm *priv; > > + int ret; > > + > > + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL); > > + if (!priv) > > + return -ENOMEM; > > + > > + priv->base = devm_platform_ioremap_resource(pdev, 0); > > + if (IS_ERR(priv->base)) > > + return PTR_ERR(priv->base); > > + > > + priv->clk = devm_clk_get_optional(dev, NULL); > > + if (IS_ERR(priv->clk)) , > > + return dev_err_probe(dev, PTR_ERR(priv->clk), > > + "get pwm clock failed\n"); > > If priv->clk is the dummy clk, clk_get_rate returns 0. This is bad as > (at lease up to now) you divide by rate in .apply(). > I check many pwm drivers , they are called devm_clk_get_optional( ) or devm_clk_get( ). Could you tell me how to do it in a probe ? > > + > > + ret = clk_prepare_enable(priv->clk); > > + if (ret) > > missing error message > ok, will add error message. > > + return ret; > > + > > + ret = devm_add_action_or_reset(dev, > > + (void(*)(void *))clk_disable_unprepare, > > Without checking my C book I'm unsure if this is save on all platforms. > I'd implement a oneline function for this. > ok, will implement it in one line. static void sunplus_pwm_clk_release(*data) { struct clk *clk = data; clk_disable_unprepare(clk); } ret = devm_add_action_or_reset(dev, sunplus_pwm_clk_release, priv->clk); > > + priv->clk); > > + if (ret) > > missing error message > I didn't see another driver add an error message, is it necessary? > > + return ret; > > + > > + priv->chip.dev = dev; > > + priv->chip.ops = &sunplus_pwm_ops; > > + priv->chip.npwm = PWM_SUP_NUM; > > + > > + ret = devm_pwmchip_add(dev, &priv->chip); > > + if (ret < 0) > > + return dev_err_probe(dev, ret, "Cannot register sunplus PWM\n"); > > + > > + return 0; > > +} > > + > > +static const struct of_device_id sunplus_pwm_of_match[] = { > > + { .compatible = "sunplus,sp7021-pwm", }, > > + {} > > +}; > > +MODULE_DEVICE_TABLE(of, sunplus_pwm_of_match); > > + > > +static struct platform_driver sunplus_pwm_driver = { > > + .probe = sunplus_pwm_probe, > > + .driver = { > > + .name = "sunplus-pwm", > > + .of_match_table = sunplus_pwm_of_match, > > + }, > > +}; > > +module_platform_driver(sunplus_pwm_driver); > > + > > +MODULE_DESCRIPTION("Sunplus SoC PWM Driver"); > > +MODULE_AUTHOR("Hammer Hsieh <hammerh0314@gmail.com>"); > > +MODULE_LICENSE("GPL"); > > -- > > 2.7.4 > > > > > > -- > Pengutronix e.K. | Uwe Kleine-König | > Industrial Linux Solutions | https://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2 2/2] pwm:sunplus-pwm:Add Sunplus SoC PWM Driver 2022-03-07 12:50 ` hammer hsieh @ 2022-03-07 13:10 ` Uwe Kleine-König 2022-03-08 12:03 ` hammer hsieh 0 siblings, 1 reply; 11+ messages in thread From: Uwe Kleine-König @ 2022-03-07 13:10 UTC (permalink / raw) To: hammer hsieh Cc: thierry.reding, lee.jones, robh+dt, linux-pwm, devicetree, linux-kernel, wells.lu, hammer.hsieh, kernel [-- Attachment #1: Type: text/plain, Size: 11925 bytes --] Hello, On Mon, Mar 07, 2022 at 08:50:10PM +0800, hammer hsieh wrote: > Uwe Kleine-König <u.kleine-koenig@pengutronix.de> 於 2022年3月5日 週六 上午2:57寫道： > > On Fri, Mar 04, 2022 at 02:20:12PM +0800, Hammer Hsieh wrote: > > > diff --git a/drivers/pwm/pwm-sunplus.c b/drivers/pwm/pwm-sunplus.c > > > new file mode 100644 > > > index 0000000..170534f > > > --- /dev/null > > > +++ b/drivers/pwm/pwm-sunplus.c > > > @@ -0,0 +1,229 @@ > > > +// SPDX-License-Identifier: GPL-2.0 > > > +/* > > > + * PWM device driver for SUNPLUS SoCs > > > > Is there a public manual available for this hardware? If yes, please add > > a link here. > > yes, will add links as below > https://sunplus-tibbo.atlassian.net/wiki/spaces/doc/overview > https://sunplus.atlassian.net/wiki/spaces/doc/pages/461144198/12.+Pulse+Width+Modulation+PWM > > > > + * > > > + * Limitations: > > > + * - Only supports normal polarity. > > > > How does the HW behave when it's disabled? Usual candidates are: > > - It freezes at where it currently is > > - It outputs low > > - It becomes tristate > > > > Please note this in the Limitations section, too. > > > > Another thing to mention is if running periods are completed when the > > parameters change. > > > > ok, will add note as below > Limitations: > - Only supports normal polarity. > - It output low when PWM channel disabled. > - When the parameters change, current running period will not be completed > and run new settings immediately. Sounds good. Other thing that might maybe happen: in .apply() you write the register for period first and then the one for duty_cycle. Can it happen, that for a moment the output is defined by new period and old duty_cycle? That would be another thing to note. > > > +struct sunplus_pwm { > > > + struct pwm_chip chip; > > > + void __iomem *base; > > > + struct clk *clk; > > > + u32 approx_period[PWM_SUP_NUM]; > > > + u32 approx_duty_cycle[PWM_SUP_NUM]; > > > +}; > > > + > > > +static inline struct sunplus_pwm *to_sunplus_pwm(struct pwm_chip *chip) > > > +{ > > > + return container_of(chip, struct sunplus_pwm, chip); > > > +} > > > + > > > +static void sunplus_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm) > > > +{ > > > + struct sunplus_pwm *priv = to_sunplus_pwm(chip); > > > + u32 value; > > > + > > > + /* disable pwm channel output */ > > > + value = readl(priv->base + PWM_SUP_CONTROL0); > > > + value &= ~BIT(pwm->hwpwm); > > > + writel(value, priv->base + PWM_SUP_CONTROL0); > > > + /* disable pwm channel clk source */ > > > + value = readl(priv->base + PWM_SUP_CONTROL1); > > > + value &= ~BIT(pwm->hwpwm); > > > + writel(value, priv->base + PWM_SUP_CONTROL1); > > > > the .free callback isn't supposed to modify the hardware. > > But how to turn pwm channel off ? > I add .free function for turn it off. > In user space > cd /sys/class/pwm/pwmchip0 > echo 0 > export > cd pwm0 > echo 20000000 > period > echo 1000000 > duty_cycle > echo 1 > enable > cd .. > echo 0 > unexport ; turn off pwm will call .free function unexport should just keep the PWM configured as is. To turn it of, don't unexport but echo 0 > enable. > > > + u32 tmp, rate; > > > + u64 max_period, period_ns, duty_ns, clk_rate; > > > + > > > + if (state->polarity != pwm->state.polarity) > > > + return -EINVAL; > > > + > > > + if (!state->enabled) { > > > + /* disable pwm channel output */ > > > + value = readl(priv->base + PWM_SUP_CONTROL0); > > > + value &= ~BIT(pwm->hwpwm); > > > > I'd give this one a name. Something like: > > > > #define PWM_SUP_CONTROL_EN(ch) BIT(ch) > > > > (Pick the right name from the manual.) > > That means it need to implement > PWM_SUP_CONTROL_EN(ch) and PWM_SUP_CONTROL_DIS(ch) ? PWM_SUP_CONTROL_EN(ch) should be enough, PWM_SUP_CONTROL_DIS(ch) would just be 0 which doens't make much sense. > > > > + writel(value, priv->base + PWM_SUP_CONTROL0); > > > + /* disable pwm channel clk source */ > > > + value = readl(priv->base + PWM_SUP_CONTROL1); > > > + value &= ~BIT(pwm->hwpwm); > > > + writel(value, priv->base + PWM_SUP_CONTROL1); > > > + return 0; > > > + } > > > + > > > + clk_rate = clk_get_rate(priv->clk); > > > + rate = (u32)clk_rate / 100000; > > > > This cast doesn't change anything, does it? > > yes, clk_rate should be 202.5MHz, to prevent overflow use 2025 to calculate. I only talked about the cast, so rate = clk_rate / 100000; should have the same effect and is a tad nicer. > > > + max_period = PWM_SUP_FREQ_MAX * (PWM_SUP_FREQ_SCALER * 10000 / rate); > > > > Here you have rounding issues. Consider rate = 3329. Then you get > > max_period = 0xffff * (2560000 / 3329) = 0xffff * 768 = 50330880. > > > > However the actual result is 50396395.31... > > > > Also dividing by the result of a division looses precision. > > > > I am not sure how to fix the rounding issue.(thinking...) the mul_u64_u64_div_u64 I suggested should be good. > > > + if (dd_freq == 0) > > > + return -EINVAL; > > > + > > > + if (dd_freq > PWM_SUP_FREQ_MAX) > > > + dd_freq = PWM_SUP_FREQ_MAX; > > > + > > > + writel(dd_freq, priv->base + PWM_SUP_FREQ(pwm->hwpwm)); > > > + > > > + /* cal and set pwm duty */ > > > + value = readl(priv->base + PWM_SUP_CONTROL0); > > > + value |= BIT(pwm->hwpwm); > > > + value1 = readl(priv->base + PWM_SUP_CONTROL1); > > > + value1 |= BIT(pwm->hwpwm); > > > + if (duty_ns == period_ns) { > > > + value |= BIT(pwm->hwpwm + PWM_BYPASS_BIT_SHIFT); > > > + duty = PWM_SUP_DUTY_MAX; > > > + } else { > > > + value &= ~BIT(pwm->hwpwm + PWM_BYPASS_BIT_SHIFT); > > > + tmp = priv->approx_duty_cycle[pwm->hwpwm] * PWM_SUP_FREQ_SCALER; > > > + tmp /= priv->approx_period[pwm->hwpwm]; > > > > Please use the exact values available. > > The same reason, in case of enable PWM_DEBUG. > first call .apply , then it will call .get_state for verify the calculation. The overall goal is not to please PWM_DEBUG, but to use exact calculations and if you did that, PWM_DEBUG should be happy, too. > > > + duty = (u32)tmp; > > > + duty |= (pwm->hwpwm << PWM_DD_SEL_BIT_SHIFT); > > > + } > > > + writel(duty, priv->base + PWM_SUP_DUTY(pwm->hwpwm)); > > > + writel(value1, priv->base + PWM_SUP_CONTROL1); > > > + writel(value, priv->base + PWM_SUP_CONTROL0); > > > > What is the difference between CONTROL1 and CONTROL0? > > PWM CONTROL0 for PWM channel switch. > PWM CONTROL1 for PWM clock source switch. > Actually PWM supports 8 channels , but clock source only 4 sets. > For easy control(now submit), I just support 4 PWM channels, and one > clock source for one pwm channel. > For complicated control(not now), 8 PWM channels 4 clock source , need > to manage clock source / pwm channel enable or not > while request/free pwm channel. So you can use (say) clk 2 to "drive" PWM channel 6? Where is that mapping defined. Only implementing 4 channels with a 1:1 mapping is ok, but you might want to ensure the mapping is indeed 1:1. > > > + return 0; > > > +} > > > + > > > +static void sunplus_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm, > > > + struct pwm_state *state) > > > +{ > > > + struct sunplus_pwm *priv = to_sunplus_pwm(chip); > > > + u32 value, freq, duty, rate, freq_tmp, duty_tmp; > > > + u64 tmp, clk_rate; > > > + > > > + value = readl(priv->base + PWM_SUP_CONTROL0); > > > + > > > + if (value & BIT(pwm->hwpwm)) { > > > + clk_rate = clk_get_rate(priv->clk); > > > + rate = (u32)clk_rate / 100000; > > > + freq = readl(priv->base + PWM_SUP_FREQ(pwm->hwpwm)); > > > + duty = readl(priv->base + PWM_SUP_DUTY(pwm->hwpwm)); > > > + duty &= ~GENMASK(9, 8); > > > + > > > + freq_tmp = rate * priv->approx_period[pwm->hwpwm] / (PWM_SUP_FREQ_SCALER * 100); > > > + duty_tmp = priv->approx_duty_cycle[pwm->hwpwm] * PWM_SUP_FREQ_SCALER / > > > + priv->approx_period[pwm->hwpwm]; > > > + > > > + if (freq == freq_tmp && duty == duty_tmp) { > > > + state->period = priv->approx_period[pwm->hwpwm] * 100; > > > + state->duty_cycle = priv->approx_duty_cycle[pwm->hwpwm] * 100; > > > + } else { > > > + tmp = (u64)freq * PWM_SUP_FREQ_SCALER * 10000; > > > + state->period = div64_u64(tmp, rate); > > > + tmp = (u64)freq * (u64)duty * 10000; > > > + state->duty_cycle = div64_u64(tmp, rate); > > > + } > > > + state->enabled = true; > > > + } else { > > > + state->enabled = false; > > > + } > > > + > > > + state->polarity = PWM_POLARITY_NORMAL; > > > +} > > > > When .get_state() is first called, .apply wasn't called yet. Then > > priv->approx_period[pwm->hwpwm] is zero and the returned result is > > wrong. Please read the register values and calculate the implemented > > output without caching. > > The same reason, in case of enable PWM_DEBUG. > first call .apply , then it will call .get_state for verify the calculation. > > In get_state, I thought about that. > first called .get_state, read register value to calculate period and duty_cycle. > after calling .apply , caching data approx_period / approx_duty_cycle > will not zero. > then get_state will use caching data to do PWM_DEBUG self verification. > I will think about how to solve the PWM_DEBUG ".apply is not idempotent" issue. I'd say: Don't cache anything. In .get_state() just read the registers and determine .duty_cycle and .period from them, and in .apply() do the inverse. > > > + priv->clk = devm_clk_get_optional(dev, NULL); > > > + if (IS_ERR(priv->clk)) > , > > + return dev_err_probe(dev, PTR_ERR(priv->clk), > > > + "get pwm clock failed\n"); > > > > If priv->clk is the dummy clk, clk_get_rate returns 0. This is bad as > > (at lease up to now) you divide by rate in .apply(). > > > > I check many pwm drivers , they are called devm_clk_get_optional( ) or > devm_clk_get( ). > Could you tell me how to do it in a probe ? You can only sensibly use devm_clk_get_optional() if you don't rely on the rate of the clk. So the way to go here is to just use devm_clk_get(). > > > + ret = devm_add_action_or_reset(dev, > > > + (void(*)(void *))clk_disable_unprepare, > > > > Without checking my C book I'm unsure if this is save on all platforms. > > I'd implement a oneline function for this. > > ok, will implement it in one line. > static void sunplus_pwm_clk_release(*data) > { > struct clk *clk = data; > clk_disable_unprepare(clk); > } > ret = devm_add_action_or_reset(dev, sunplus_pwm_clk_release, priv->clk); > *nod* > > > + priv->clk); > > > + if (ret) > > > > missing error message > > > > I didn't see another driver add an error message, is it necessary? IMHO yes. (Though the most likely error -ENOMEM, in this case no error message should be emitted.) 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 --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2 2/2] pwm:sunplus-pwm:Add Sunplus SoC PWM Driver 2022-03-07 13:10 ` Uwe Kleine-König @ 2022-03-08 12:03 ` hammer hsieh 2022-03-08 15:44 ` Uwe Kleine-König 0 siblings, 1 reply; 11+ messages in thread From: hammer hsieh @ 2022-03-08 12:03 UTC (permalink / raw) To: Uwe Kleine-König Cc: thierry.reding, lee.jones, robh+dt, linux-pwm, devicetree, linux-kernel, wells.lu, hammer.hsieh, kernel Uwe Kleine-König <u.kleine-koenig@pengutronix.de> 於 2022年3月7日 週一 下午9:10寫道： > > Hello, > > On Mon, Mar 07, 2022 at 08:50:10PM +0800, hammer hsieh wrote: > > Uwe Kleine-König <u.kleine-koenig@pengutronix.de> 於 2022年3月5日 週六 上午2:57寫道： > > > On Fri, Mar 04, 2022 at 02:20:12PM +0800, Hammer Hsieh wrote: > > > > diff --git a/drivers/pwm/pwm-sunplus.c b/drivers/pwm/pwm-sunplus.c > > > > new file mode 100644 > > > > index 0000000..170534f > > > > --- /dev/null > > > > +++ b/drivers/pwm/pwm-sunplus.c > > > > @@ -0,0 +1,229 @@ > > > > +// SPDX-License-Identifier: GPL-2.0 > > > > +/* > > > > + * PWM device driver for SUNPLUS SoCs > > > > > > Is there a public manual available for this hardware? If yes, please add > > > a link here. > > > > yes, will add links as below > > https://sunplus-tibbo.atlassian.net/wiki/spaces/doc/overview > > https://sunplus.atlassian.net/wiki/spaces/doc/pages/461144198/12.+Pulse+Width+Modulation+PWM > > > > > > + * > > > > + * Limitations: > > > > + * - Only supports normal polarity. > > > > > > How does the HW behave when it's disabled? Usual candidates are: > > > - It freezes at where it currently is > > > - It outputs low > > > - It becomes tristate > > > > > > Please note this in the Limitations section, too. > > > > > > Another thing to mention is if running periods are completed when the > > > parameters change. > > > > > > > ok, will add note as below > > Limitations: > > - Only supports normal polarity. > > - It output low when PWM channel disabled. > > - When the parameters change, current running period will not be completed > > and run new settings immediately. > > Sounds good. > > Other thing that might maybe happen: in .apply() you write the register > for period first and then the one for duty_cycle. Can it happen, that > for a moment the output is defined by new period and old duty_cycle? > That would be another thing to note. > ok, i will add note for it. - In .apply() PWM output need to write register FREQ and DUTY. When first write FREQ done and not yet write DUTY, it has short timing gap use new FREQ and old DUTY. > > > > +struct sunplus_pwm { > > > > + struct pwm_chip chip; > > > > + void __iomem *base; > > > > + struct clk *clk; > > > > + u32 approx_period[PWM_SUP_NUM]; > > > > + u32 approx_duty_cycle[PWM_SUP_NUM]; > > > > +}; > > > > + > > > > +static inline struct sunplus_pwm *to_sunplus_pwm(struct pwm_chip *chip) > > > > +{ > > > > + return container_of(chip, struct sunplus_pwm, chip); > > > > +} > > > > + > > > > +static void sunplus_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm) > > > > +{ > > > > + struct sunplus_pwm *priv = to_sunplus_pwm(chip); > > > > + u32 value; > > > > + > > > > + /* disable pwm channel output */ > > > > + value = readl(priv->base + PWM_SUP_CONTROL0); > > > > + value &= ~BIT(pwm->hwpwm); > > > > + writel(value, priv->base + PWM_SUP_CONTROL0); > > > > + /* disable pwm channel clk source */ > > > > + value = readl(priv->base + PWM_SUP_CONTROL1); > > > > + value &= ~BIT(pwm->hwpwm); > > > > + writel(value, priv->base + PWM_SUP_CONTROL1); > > > > > > the .free callback isn't supposed to modify the hardware. > > > > But how to turn pwm channel off ? > > I add .free function for turn it off. > > In user space > > cd /sys/class/pwm/pwmchip0 > > echo 0 > export > > cd pwm0 > > echo 20000000 > period > > echo 1000000 > duty_cycle > > echo 1 > enable > > cd .. > > echo 0 > unexport ; turn off pwm will call .free function > > unexport should just keep the PWM configured as is. To turn it of, don't > unexport but echo 0 > enable. > ok, i will remove .free function. > > > > + u32 tmp, rate; > > > > + u64 max_period, period_ns, duty_ns, clk_rate; > > > > + > > > > + if (state->polarity != pwm->state.polarity) > > > > + return -EINVAL; > > > > + > > > > + if (!state->enabled) { > > > > + /* disable pwm channel output */ > > > > + value = readl(priv->base + PWM_SUP_CONTROL0); > > > > + value &= ~BIT(pwm->hwpwm); > > > > > > I'd give this one a name. Something like: > > > > > > #define PWM_SUP_CONTROL_EN(ch) BIT(ch) > > > > > > (Pick the right name from the manual.) > > > > That means it need to implement > > PWM_SUP_CONTROL_EN(ch) and PWM_SUP_CONTROL_DIS(ch) ? > > PWM_SUP_CONTROL_EN(ch) should be enough, PWM_SUP_CONTROL_DIS(ch) would > just be 0 which doens't make much sense. > ok , i will add #define PWM_SP7021_CONTROL_EN(ch) BIT(ch). value &= ~BIT(pwm->hwpwm); should be change to value &= ~PWM_SP7021_CONTROL_EN(pwm->hwpwm); > > > > > > + writel(value, priv->base + PWM_SUP_CONTROL0); > > > > + /* disable pwm channel clk source */ > > > > + value = readl(priv->base + PWM_SUP_CONTROL1); > > > > + value &= ~BIT(pwm->hwpwm); > > > > + writel(value, priv->base + PWM_SUP_CONTROL1); > > > > + return 0; > > > > + } > > > > + > > > > + clk_rate = clk_get_rate(priv->clk); > > > > + rate = (u32)clk_rate / 100000; > > > > > > This cast doesn't change anything, does it? > > > > yes, clk_rate should be 202.5MHz, to prevent overflow use 2025 to calculate. > > I only talked about the cast, so > > rate = clk_rate / 100000; > > should have the same effect and is a tad nicer. > since i use mul_u64_u64_div_u64(a,b,c) max_period = mul_u64_u64_div_u64(PWM_SP7021_FREQ_MAX, (u64)PWM_SP7021_FREQ_SCALER * NSEC_PER_SEC, clk_rate); seems not necessary for "rate = clk_rate / 100000". > > > > + max_period = PWM_SUP_FREQ_MAX * (PWM_SUP_FREQ_SCALER * 10000 / rate); > > > > > > Here you have rounding issues. Consider rate = 3329. Then you get > > > max_period = 0xffff * (2560000 / 3329) = 0xffff * 768 = 50330880. > > > > > > However the actual result is 50396395.31... > > > > > > Also dividing by the result of a division looses precision. > > > > > > > I am not sure how to fix the rounding issue.(thinking...) > > the mul_u64_u64_div_u64 I suggested should be good. > it works. dd_freq = mul_u64_u64_div_u64(clk_rate, period_ns, (u64)PWM_SP7021_FREQ_SCALER * NSEC_PER_SEC); > > > > + if (dd_freq == 0) > > > > + return -EINVAL; > > > > + > > > > + if (dd_freq > PWM_SUP_FREQ_MAX) > > > > + dd_freq = PWM_SUP_FREQ_MAX; > > > > + > > > > + writel(dd_freq, priv->base + PWM_SUP_FREQ(pwm->hwpwm)); > > > > + > > > > + /* cal and set pwm duty */ > > > > + value = readl(priv->base + PWM_SUP_CONTROL0); > > > > + value |= BIT(pwm->hwpwm); > > > > + value1 = readl(priv->base + PWM_SUP_CONTROL1); > > > > + value1 |= BIT(pwm->hwpwm); > > > > + if (duty_ns == period_ns) { > > > > + value |= BIT(pwm->hwpwm + PWM_BYPASS_BIT_SHIFT); > > > > + duty = PWM_SUP_DUTY_MAX; > > > > + } else { > > > > + value &= ~BIT(pwm->hwpwm + PWM_BYPASS_BIT_SHIFT); > > > > + tmp = priv->approx_duty_cycle[pwm->hwpwm] * PWM_SUP_FREQ_SCALER; > > > > + tmp /= priv->approx_period[pwm->hwpwm]; > > > > > > Please use the exact values available. > > > > The same reason, in case of enable PWM_DEBUG. > > first call .apply , then it will call .get_state for verify the calculation. > > The overall goal is not to please PWM_DEBUG, but to use exact > calculations and if you did that, PWM_DEBUG should be happy, too. > sure, will remove approx_xxxx code. > > > > + duty = (u32)tmp; > > > > + duty |= (pwm->hwpwm << PWM_DD_SEL_BIT_SHIFT); > > > > + } > > > > + writel(duty, priv->base + PWM_SUP_DUTY(pwm->hwpwm)); > > > > + writel(value1, priv->base + PWM_SUP_CONTROL1); > > > > + writel(value, priv->base + PWM_SUP_CONTROL0); > > > > > > What is the difference between CONTROL1 and CONTROL0? > > > > PWM CONTROL0 for PWM channel switch. > > PWM CONTROL1 for PWM clock source switch. > > Actually PWM supports 8 channels , but clock source only 4 sets. > > For easy control(now submit), I just support 4 PWM channels, and one > > clock source for one pwm channel. > > For complicated control(not now), 8 PWM channels 4 clock source , need > > to manage clock source / pwm channel enable or not > > while request/free pwm channel. > > So you can use (say) clk 2 to "drive" PWM channel 6? Where is that > mapping defined. Only implementing 4 channels with a 1:1 mapping is ok, > but you might want to ensure the mapping is indeed 1:1. > PWM CONTROL0 REG[7:0] for PWM channel on/off PWM CONTROL1 REG[3:0] for PWM clock source on/off PWM FREQ REG[15:0] freq = 1/clk_rate *256 * FREQ REG[15:0] PWM DUTY REG[7:0] for duty, REG[9:8] for clock source select. duty |= (pwm->hwpwm << PWM_DD_SEL_BIT_SHIFT); can make sure clock source 0 for pwm0 clock source 1 for pwm1 clock source 2 for pwm2 clock source 3 for pwm3 > > > > + return 0; > > > > +} > > > > + > > > > +static void sunplus_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm, > > > > + struct pwm_state *state) > > > > +{ > > > > + struct sunplus_pwm *priv = to_sunplus_pwm(chip); > > > > + u32 value, freq, duty, rate, freq_tmp, duty_tmp; > > > > + u64 tmp, clk_rate; > > > > + > > > > + value = readl(priv->base + PWM_SUP_CONTROL0); > > > > + > > > > + if (value & BIT(pwm->hwpwm)) { > > > > + clk_rate = clk_get_rate(priv->clk); > > > > + rate = (u32)clk_rate / 100000; > > > > + freq = readl(priv->base + PWM_SUP_FREQ(pwm->hwpwm)); > > > > + duty = readl(priv->base + PWM_SUP_DUTY(pwm->hwpwm)); > > > > + duty &= ~GENMASK(9, 8); > > > > + > > > > + freq_tmp = rate * priv->approx_period[pwm->hwpwm] / (PWM_SUP_FREQ_SCALER * 100); > > > > + duty_tmp = priv->approx_duty_cycle[pwm->hwpwm] * PWM_SUP_FREQ_SCALER / > > > > + priv->approx_period[pwm->hwpwm]; > > > > + > > > > + if (freq == freq_tmp && duty == duty_tmp) { > > > > + state->period = priv->approx_period[pwm->hwpwm] * 100; > > > > + state->duty_cycle = priv->approx_duty_cycle[pwm->hwpwm] * 100; > > > > + } else { > > > > + tmp = (u64)freq * PWM_SUP_FREQ_SCALER * 10000; > > > > + state->period = div64_u64(tmp, rate); > > > > + tmp = (u64)freq * (u64)duty * 10000; > > > > + state->duty_cycle = div64_u64(tmp, rate); > > > > + } > > > > + state->enabled = true; > > > > + } else { > > > > + state->enabled = false; > > > > + } > > > > + > > > > + state->polarity = PWM_POLARITY_NORMAL; > > > > +} > > > > > > When .get_state() is first called, .apply wasn't called yet. Then > > > priv->approx_period[pwm->hwpwm] is zero and the returned result is > > > wrong. Please read the register values and calculate the implemented > > > output without caching. > > > > The same reason, in case of enable PWM_DEBUG. > > first call .apply , then it will call .get_state for verify the calculation. > > > > In get_state, I thought about that. > > first called .get_state, read register value to calculate period and duty_cycle. > > after calling .apply , caching data approx_period / approx_duty_cycle > > will not zero. > > then get_state will use caching data to do PWM_DEBUG self verification. > > I will think about how to solve the PWM_DEBUG ".apply is not idempotent" issue. > > I'd say: Don't cache anything. In .get_state() just read the registers and > determine .duty_cycle and .period from them, and in .apply() do the > inverse. > got it. i will modify code like below, and it works. state->period = mul_u64_u64_div_u64((u64)freq, (u64)PWM_SP7021_FREQ_SCALER * NSEC_PER_SEC, clk_rate) + 1UL; state->duty_cycle = mul_u64_u64_div_u64((u64)freq, (u64)duty * NSEC_PER_SEC, clk_rate) + 1UL; seems like i need to plus 1 for it, or ".apply is not idempotent" will happen. > > > > + priv->clk = devm_clk_get_optional(dev, NULL); > > > > + if (IS_ERR(priv->clk)) > > , > > + return dev_err_probe(dev, PTR_ERR(priv->clk), > > > > + "get pwm clock failed\n"); > > > > > > If priv->clk is the dummy clk, clk_get_rate returns 0. This is bad as > > > (at lease up to now) you divide by rate in .apply(). > > > > > > > I check many pwm drivers , they are called devm_clk_get_optional( ) or > > devm_clk_get( ). > > Could you tell me how to do it in a probe ? > > You can only sensibly use devm_clk_get_optional() if you don't rely on > the rate of the clk. So the way to go here is to just use > devm_clk_get(). > ok, will modify it, change to devm_clk_get(). > > > > + ret = devm_add_action_or_reset(dev, > > > > + (void(*)(void *))clk_disable_unprepare, > > > > > > Without checking my C book I'm unsure if this is save on all platforms. > > > I'd implement a oneline function for this. > > > > ok, will implement it in one line. > > static void sunplus_pwm_clk_release(*data) > > { > > struct clk *clk = data; > > clk_disable_unprepare(clk); > > } > > ret = devm_add_action_or_reset(dev, sunplus_pwm_clk_release, priv->clk); > > > > *nod* > > > > > + priv->clk); > > > > + if (ret) > > > > > > missing error message > > > > > > > I didn't see another driver add an error message, is it necessary? > > IMHO yes. (Though the most likely error -ENOMEM, in this case no error > message should be emitted.) > ok, will add error message like below. if (ret < 0) { dev_err(dev, "failed to release clock: %d\n", ret); return ret; } or should i modify like if (ret < 0) { dev_err(dev, "failed to release clock: %d\n", ret); return ERR_PTR(ret); } i didn't find reference code for it, not sure which one is better? thank you. > Best regards > Uwe > > -- > Pengutronix e.K. | Uwe Kleine-König | > Industrial Linux Solutions | https://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2 2/2] pwm:sunplus-pwm:Add Sunplus SoC PWM Driver 2022-03-08 12:03 ` hammer hsieh @ 2022-03-08 15:44 ` Uwe Kleine-König 0 siblings, 0 replies; 11+ messages in thread From: Uwe Kleine-König @ 2022-03-08 15:44 UTC (permalink / raw) To: hammer hsieh Cc: linux-pwm, wells.lu, devicetree, hammer.hsieh, linux-kernel, robh+dt, thierry.reding, kernel, lee.jones [-- Attachment #1: Type: text/plain, Size: 943 bytes --] Hello, On Tue, Mar 08, 2022 at 08:03:55PM +0800, hammer hsieh wrote: > > IMHO yes. (Though the most likely error -ENOMEM, in this case no error > > message should be emitted.) > > > > ok, will add error message like below. > if (ret < 0) { > dev_err(dev, "failed to release clock: %d\n", ret); > return ret; > } > or should i modify like > if (ret < 0) { > dev_err(dev, "failed to release clock: %d\n", ret); > return ERR_PTR(ret); > } > i didn't find reference code for it, not sure which one is better? It depends if you return a pointer or an int. Also please make use of %pe instead of %d for error codes to make it easier to understand. 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 --] ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2022-03-08 15:44 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-03-04 6:20 [PATCH v2 0/2] Add PWM driver for Suplus SP7021 SoC Hammer Hsieh 2022-03-04 6:20 ` [PATCH v2 1/2] dt-bindings:pwm:Add bindings doc for Sunplus SoC PWM Driver Hammer Hsieh 2022-03-04 15:01 ` Krzysztof Kozlowski 2022-03-07 4:18 ` hammer hsieh 2022-03-07 7:51 ` Krzysztof Kozlowski 2022-03-04 6:20 ` [PATCH v2 2/2] pwm:sunplus-pwm:Add " Hammer Hsieh 2022-03-04 18:57 ` Uwe Kleine-König 2022-03-07 12:50 ` hammer hsieh 2022-03-07 13:10 ` Uwe Kleine-König 2022-03-08 12:03 ` hammer hsieh 2022-03-08 15:44 ` Uwe Kleine-König
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.