From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Aleksandr Shubin <privatesub2@gmail.com>
Cc: linux-kernel@vger.kernel.org,
Thierry Reding <thierry.reding@gmail.com>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>, Chen-Yu Tsai <wens@csie.org>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Samuel Holland <samuel@sholland.org>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Philipp Zabel <p.zabel@pengutronix.de>,
Cristian Ciocaltea <cristian.ciocaltea@collabora.com>,
Heiko Stuebner <heiko.stuebner@vrull.eu>,
Maxime Ripard <mripard@kernel.org>,
linux-pwm@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-sunxi@lists.linux.dev, linux-riscv@lists.infradead.org
Subject: Re: [PATCH v1 2/3] pwm: Add Allwinner's D1/T113-S3/R329 SoCs PWM support
Date: Fri, 16 Jun 2023 10:03:26 +0200 [thread overview]
Message-ID: <20230616080326.2vtkfeyzwx542hk7@pengutronix.de> (raw)
In-Reply-To: <20230615144423.828698-3-privatesub2@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 14322 bytes --]
Hello,
this isn't a complete review, just a first quick look. Up to you if you
follow up with a v2 fixing the things here. If you don't I will take a
deeper look at a later time.
On Thu, Jun 15, 2023 at 05:43:57PM +0300, Aleksandr Shubin wrote:
> Allwinner's D1, T113-S3 and R329 SoCs have a quite different PWM
> controllers with ones supported by pwm-sun4i driver.
>
> This patch adds a PWM controller driver for Allwinner's D1,
> T113-S3 and R329 SoCs. The main difference between these SoCs
> is the number of channels defined by the DT property.
>
> Signed-off-by: Aleksandr Shubin <privatesub2@gmail.com>
> ---
> drivers/pwm/Kconfig | 12 ++
> drivers/pwm/Makefile | 1 +
> drivers/pwm/pwm-sun20i.c | 364 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 377 insertions(+)
> create mode 100644 drivers/pwm/pwm-sun20i.c
>
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 8df861b1f4a3..b435e50fbd3e 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -594,6 +594,18 @@ config PWM_SUN4I
> To compile this driver as a module, choose M here: the module
> will be called pwm-sun4i.
>
> +config PWM_SUN20I
> + tristate "Allwinner D1/T113s/R329 PWM support"
> + depends on ARCH_SUNXI || COMPILE_TEST
> + depends on COMMON_CLK
> + help
> + Generic PWM framework driver for Allwinner D1/T113s/R329 SoCs.
> + The main difference between these SoCs is the number of
> + channels defined by the DT property.
That is a detail that better fits into a code comment in the driver. The
user choosing if they should enable PWM_SUN20I or not, don't need to
know that.
> + To compile this driver as a module, choose M here: the module
> + will be called pwm-sun20i.
> +
> config PWM_SUNPLUS
> tristate "Sunplus PWM support"
> depends on ARCH_SUNPLUS || COMPILE_TEST
> [...]
> diff --git a/drivers/pwm/pwm-sun20i.c b/drivers/pwm/pwm-sun20i.c
> new file mode 100644
> index 000000000000..100b0f3bcec0
> --- /dev/null
> +++ b/drivers/pwm/pwm-sun20i.c
> @@ -0,0 +1,364 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * PWM Controller Driver for sunxi platforms (D1, T113-S3 and R329)
> + *
> + * Copyright (c) 2023 Aleksandr Shubin <privatesub2@gmail.com>
> + */
Please add a "Limitations" section here answering the following
questions:
- Is a currently running period completed when a new pwm_state is
applied that has .enabled = true? What about .enabled = false?
- How does the PWM behave when disabled? Typical behaviours are: drives
to inactive level, just freezes or goes HIGH-Z.
Stick to the format that is used in other drivers to make this easily
grepable.
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/pwm.h>
> +#include <linux/clk.h>
> +#include <linux/reset.h>
alphabetic ordering please
> +#define PWM_CLK_CFG_REG(chan) (0x20 + (((chan) >> 1) * 0x4))
> +#define PWM_CLK_SRC 7
> +#define PWM_CLK_SRC_MASK GENMASK(8, PWM_CLK_SRC)
> +#define PWM_CLK_DIV_M 0
> +#define PWM_CLK_DIV_M_MASK GENMASK(3, PWM_CLK_DIV_M)
> +
> +#define PWM_CLK_GATE_REG 0x40
> +#define PWM_CLK_GATING(chan) BIT(chan)
> +
> +#define PWM_ENABLE_REG 0x80
> +#define PWM_EN(chan) BIT(chan)
> +
> +#define PWM_CTL_REG(chan) (0x100 + (chan) * 0x20)
> +#define PWM_ACT_STA BIT(8)
> +#define PWM_PRESCAL_K 0
> +#define PWM_PRESCAL_K_MASK GENMASK(7, PWM_PRESCAL_K)
> +
> +#define PWM_PERIOD_REG(chan) (0x104 + (chan) * 0x20)
> +#define PWM_ENTIRE_CYCLE 16
> +#define PWM_ENTIRE_CYCLE_MASK GENMASK(31, PWM_ENTIRE_CYCLE)
> +#define PWM_ACT_CYCLE 0
> +#define PWM_ACT_CYCLE_MASK GENMASK(15, PWM_ACT_CYCLE)
> +
> +#define SET_VALUE(reg_val, val, name) \
> + (reg_val = (((reg_val) & ~name##_MASK) | ((val) << (name))))
> +#define GET_VALUE(reg_val, name) \
> + (((reg_val) & ~name##_MASK) >> (name))
Please use FIELD_GET here instead. This works nice with dropping
PWM_PRESCAL_K and renaming PWM_PRESCAL_K_MASK to PWM_PRESCAL_K.
> [...]
> +static int sun20i_pwm_get_state(struct pwm_chip *chip,
> + struct pwm_device *pwm,
> + struct pwm_state *state)
> +{
> + struct sun20i_pwm_chip *sun20i_chip = to_sun20i_pwm_chip(chip);
> + u64 clk_rate, tmp;
> + u32 val;
> + u16 clk_div, act_cycle;
> + u8 prescal, div_id;
> + u8 chn = pwm->hwpwm;
> +
> + mutex_lock(&sun20i_chip->mutex);
> +
> + val = sun20i_pwm_readl(sun20i_chip, PWM_CLK_CFG_REG(pwm->hwpwm));
> + div_id = GET_VALUE(val, PWM_CLK_DIV_M);
> + if (GET_VALUE(val, PWM_CLK_SRC) == 0)
> + clk_rate = clk_get_rate(sun20i_chip->clk_hosc);
> + else
> + clk_rate = clk_get_rate(sun20i_chip->clk_bus);
> +
> + val = sun20i_pwm_readl(sun20i_chip, PWM_CTL_REG(pwm->hwpwm));
> + if (PWM_ACT_STA & val)
> + state->polarity = PWM_POLARITY_NORMAL;
> + else
> + state->polarity = PWM_POLARITY_INVERSED;
> +
> + prescal = PWM_PRESCAL_K & val;
> +
> + val = sun20i_pwm_readl(sun20i_chip, PWM_ENABLE_REG);
> + if (PWM_EN(chn) & val)
> + state->enabled = true;
> + else
> + state->enabled = false;
> +
> + val = sun20i_pwm_readl(sun20i_chip, PWM_PERIOD_REG(pwm->hwpwm));
> + act_cycle = GET_VALUE(val, PWM_ACT_CYCLE);
> + clk_div = GET_VALUE(val, PWM_ENTIRE_CYCLE);
> +
> + tmp = act_cycle * prescal * (1U << div_id) * NSEC_PER_SEC;
> + state->duty_cycle = DIV_ROUND_CLOSEST_ULL(tmp, clk_rate);
> + tmp = clk_div * prescal * (1U << div_id) * NSEC_PER_SEC;
> + state->period = DIV_ROUND_CLOSEST_ULL(tmp, clk_rate);
You have to use ROUND_UP here to make
.get_state(mypwm, &state);
.apply(mypwm, &state);
idempotent. Test your driver with PWM_DEBUG enabled. With an appropriate
test sequence this should tell you such things. Test with something
like:
for i in some_range:
pwm_apply_state(mypwm, { .enabled = true, .period = i, .duty_cycle = 0 })
for i in reversed(some_range):
pwm_apply_state(mypwm, { .enabled = true, .period = i, .duty_cycle = 0 })
for i in [0, someperiod]:
pwm_apply_state(mypwm, { .enabled = true, .period = someperiod, .duty_cycle = i })
for i in reversed([0, someperiod]):
pwm_apply_state(mypwm, { .enabled = true, .period = someperiod, .duty_cycle = i })
> + mutex_unlock(&sun20i_chip->mutex);
> +
> + return 0;
> +}
> +
> +static int sun20i_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> + const struct pwm_state *state)
> +{
> + struct pwm_state curstate;
> + int ret = 0;
> + u32 clk_gate, clk_cfg, pwm_en, ctl, period;
> + u64 bus_rate, hosc_rate, clk_div, val, clk_rate;
> + u16 prescaler, div_m;
> + bool use_bus_clk;
> + struct sun20i_pwm_chip *sun20i_chip = to_sun20i_pwm_chip(chip);
> +
> + mutex_lock(&sun20i_chip->mutex);
> + pwm_get_state(pwm, &curstate);
Don't call pwm API functions in lowlevel driver. Even less while holding
a lock. If you need the previous state, using pwm->state is fine.
> + pwm_en = sun20i_pwm_readl(sun20i_chip, PWM_ENABLE_REG);
> + if (state->polarity != curstate.polarity ||
> + state->duty_cycle != curstate.duty_cycle ||
> + state->period != curstate.period) {
> + ctl = sun20i_pwm_readl(sun20i_chip, PWM_CTL_REG(pwm->hwpwm));
> + clk_cfg = sun20i_pwm_readl(sun20i_chip, PWM_CLK_CFG_REG(pwm->hwpwm));
> + hosc_rate = clk_get_rate(sun20i_chip->clk_hosc);
> + bus_rate = clk_get_rate(sun20i_chip->clk_bus);
> +
> + if (pwm_en & PWM_EN(pwm->hwpwm ^ 1)) {
> + /* check period only */
> + if (GET_VALUE(clk_cfg, PWM_CLK_SRC) == 0)
> + clk_rate = hosc_rate;
> + else
> + clk_rate = bus_rate;
> +
> + val = state->period * clk_rate;
This might overflow.
> + do_div(val, NSEC_PER_SEC);
> +
> + div_m = GET_VALUE(clk_cfg, PWM_CLK_DIV_M);
> +
> + /* calculate and set prescaler, PWM entire cycle */
> + clk_div = val;
> + for (prescaler = 0; clk_div > 65535; prescaler++) {
> + if (prescaler >= 256) {
> + dev_err(sun20i_chip->chip.dev, "Period is too long\n");
dev_err in .apply() isn't a good idea. Please fail silently.
Also you should configure the biggest period the hardware can support
that isn't bigger than state->period. So the requested period cannot be
too long.
> + ret = -EINVAL;
> + goto unlock_mutex;
> + }
> +
> + clk_div = val;
> + do_div(clk_div, 1U << div_m);
This can be simplified to clk_div >> div_m.
> + do_div(clk_div, prescaler + 1);
> + }
I wonder if prescaler can be calculated without a loop.
> + } else {
> + /* check period and select clock source */
> + use_bus_clk = false;
> + val = state->period * hosc_rate;
> + do_div(val, NSEC_PER_SEC);
> + if (val <= 1) {
> + use_bus_clk = true;
> + val = state->period * bus_rate;
> + do_div(val, NSEC_PER_SEC);
> + if (val <= 1) {
> + dev_err(sun20i_chip->chip.dev, "Period is too small\n");
> + ret = -EINVAL;
> + goto unlock_mutex;
> + }
> + }
> +
> + if (use_bus_clk)
> + SET_VALUE(clk_cfg, 1, PWM_CLK_SRC);
> + else
> + SET_VALUE(clk_cfg, 0, PWM_CLK_SRC);
> +
> + /* calculate and set prescaler, M factor, PWM entire cycle */
> + clk_div = val;
> + for (prescaler = div_m = 0; clk_div > 65535; prescaler++) {
> + if (prescaler >= 256) {
> + prescaler = 0;
> + div_m++;
> + if (div_m >= 9) {
> + dev_err(sun20i_chip->chip.dev, "Period is too long\n");
> + ret = -EINVAL;
> + goto unlock_mutex;
> + }
> + }
> +
> + clk_div = val;
> + do_div(clk_div, 1U << div_m);
> + do_div(clk_div, prescaler + 1);
> + }
> +
> + /* set up the M factor */
> + SET_VALUE(clk_cfg, div_m, PWM_CLK_DIV_M);
> +
> + sun20i_pwm_writel(sun20i_chip, clk_cfg, PWM_CLK_CFG_REG(pwm->hwpwm));
> + }
> +
> + period = sun20i_pwm_readl(sun20i_chip, PWM_PERIOD_REG(pwm->hwpwm));
> +
> + SET_VALUE(period, clk_div, PWM_ENTIRE_CYCLE);
> + SET_VALUE(ctl, prescaler, PWM_PRESCAL_K);
Are there any fields in PWM_PERIOD_REG(pwm->hwpwm) you're not
recalculating? If not, you can skip reading the register and use
FIELD_PREP instead of SET_VALUE.
> +
> + /* set duty cycle */
> + val = state->period;
> + do_div(val, clk_div);
> + clk_div = state->duty_cycle;
> + do_div(clk_div, val);
> + if (clk_div > 65535)
> + clk_div = 65535;
> +
> + SET_VALUE(period, clk_div, PWM_ACT_CYCLE);
> + sun20i_pwm_writel(sun20i_chip, period, PWM_PERIOD_REG(pwm->hwpwm));
> +
> + if (state->polarity == PWM_POLARITY_NORMAL)
> + ctl |= PWM_ACT_STA;
> + else
> + ctl &= ~PWM_ACT_STA;
> +
> + sun20i_pwm_writel(sun20i_chip, ctl, PWM_CTL_REG(pwm->hwpwm));
> + }
> +
> + if (state->enabled != curstate.enabled) {
> + clk_gate = sun20i_pwm_readl(sun20i_chip, PWM_CLK_GATE_REG);
> +
> + if (state->enabled) {
> + clk_gate |= PWM_CLK_GATING(pwm->hwpwm);
> + pwm_en |= PWM_EN(pwm->hwpwm);
> + } else {
> + clk_gate &= ~PWM_CLK_GATING(pwm->hwpwm);
> + pwm_en &= ~PWM_EN(pwm->hwpwm);
> + }
Disabling (probably) needs to be handled earlier. Consider your PWM is
enabled with say .period = 5000 and .duty_cycle = 0. If now
pwm_apply_state(&mypwm, &(struct pwm_state){ .period = 5000, .duty_cycle = 5000, .enabled = false })
is called, the output might become active before gating becomes
effective. It's not always possible to prevent such spikes, but if it
is, please do.
> + sun20i_pwm_writel(sun20i_chip, pwm_en, PWM_ENABLE_REG);
> + sun20i_pwm_writel(sun20i_chip, clk_gate, PWM_CLK_GATE_REG);
> + }
> +
> +unlock_mutex:
> + mutex_unlock(&sun20i_chip->mutex);
> +
> + return ret;
> +}
> [...]
> +static int sun20i_pwm_probe(struct platform_device *pdev)
> +{
> + struct sun20i_pwm_chip *sun20i_chip;
> + int ret;
> +
> + sun20i_chip = devm_kzalloc(&pdev->dev, sizeof(*sun20i_chip), GFP_KERNEL);
> + if (!sun20i_chip)
> + return -ENOMEM;
> +
> + sun20i_chip->base = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(sun20i_chip->base))
> + return PTR_ERR(sun20i_chip->base);
> +
> + sun20i_chip->clk_bus = devm_clk_get(&pdev->dev, "bus");
consider using devm_clk_get_enabled()
> + if (IS_ERR(sun20i_chip->clk_bus)) {
> + dev_err(&pdev->dev, "Failed to get bus clock\n");
> + return PTR_ERR(sun20i_chip->clk_bus);
Please make this:
return dev_err_probe(&pdev->dev, PTR_ERR(sun20i_chip->clk_bus),
"Failed to get bus clock\n");
ditto for the other error paths.
> + }
> +
> + sun20i_chip->clk_hosc = devm_clk_get(&pdev->dev, "hosc");
> + if (IS_ERR(sun20i_chip->clk_hosc)) {
> + dev_err(&pdev->dev, "Failed to get hosc clock\n");
> + return PTR_ERR(sun20i_chip->clk_hosc);
> + }
> +
> + sun20i_chip->rst = devm_reset_control_get(&pdev->dev, NULL);
> + if (IS_ERR(sun20i_chip->rst)) {
> + dev_err(&pdev->dev, "Failed to get bus reset\n");
> + return PTR_ERR(sun20i_chip->rst);
> + }
> +
> + /* Deassert reset */
> + ret = reset_control_deassert(sun20i_chip->rst);
> + if (ret) {
> + dev_err(&pdev->dev, "Failed to deassert reset\n");
> + return ret;
> + }
> +
> + ret = clk_prepare_enable(sun20i_chip->clk_bus);
> + if (ret) {
> + dev_err(&pdev->dev, "Failed to ungate bus clock\n");
> + goto err_bus;
> + }
> +
> + ret = of_property_read_u32(pdev->dev.of_node,
> + "allwinner,pwm-channels",
> + &sun20i_chip->chip.npwm);
> + if (ret) {
> + dev_err(&pdev->dev, "Can't get pwm-channels\n");
> + goto err_pwm_add;
> + }
> +
> + sun20i_chip->chip.dev = &pdev->dev;
> + sun20i_chip->chip.ops = &sun20i_pwm_ops;
> +
> + mutex_init(&sun20i_chip->mutex);
If the hardware is enabled, please make sure that the needed clocks are
not disabled.
> + ret = pwmchip_add(&sun20i_chip->chip);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "Failed to add PWM chip: %d\n", ret);
> + goto err_pwm_add;
> + }
> +
> + platform_set_drvdata(pdev, sun20i_chip);
> +
> + return 0;
> +
> +err_pwm_add:
> + clk_disable_unprepare(sun20i_chip->clk_bus);
> +err_bus:
> + reset_control_assert(sun20i_chip->rst);
> + return ret;
> +}
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 --]
next prev parent reply other threads:[~2023-06-16 8:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-15 14:43 [PATCH v1 0/3] Add support for Allwinner PWM on D1/T113s/R329 SoCs Aleksandr Shubin
2023-06-15 14:43 ` [PATCH v1 1/3] dt-bindings: pwm: Add binding for Allwinner D1/T113-S3/R329 PWM controller Aleksandr Shubin
2023-06-15 16:37 ` Conor Dooley
[not found] ` <CAF4idNksCzkh0WMhvb7ecqYfJRLw33GrpT1+eL5S9ydS8Uu-BA@mail.gmail.com>
2023-06-16 18:57 ` Conor Dooley
2023-06-15 14:43 ` [PATCH v1 2/3] pwm: Add Allwinner's D1/T113-S3/R329 SoCs PWM support Aleksandr Shubin
2023-06-16 8:03 ` Uwe Kleine-König [this message]
2023-06-16 8:43 ` Александр Шубин
2023-06-15 14:43 ` [PATCH v1 3/3] riscv: dts: allwinner: d1: Add pwm node Aleksandr Shubin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230616080326.2vtkfeyzwx542hk7@pengutronix.de \
--to=u.kleine-koenig@pengutronix.de \
--cc=aou@eecs.berkeley.edu \
--cc=conor+dt@kernel.org \
--cc=cristian.ciocaltea@collabora.com \
--cc=devicetree@vger.kernel.org \
--cc=heiko.stuebner@vrull.eu \
--cc=jernej.skrabec@gmail.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-sunxi@lists.linux.dev \
--cc=mripard@kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=privatesub2@gmail.com \
--cc=robh+dt@kernel.org \
--cc=samuel@sholland.org \
--cc=thierry.reding@gmail.com \
--cc=wens@csie.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).