linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Nikita Travkin <nikita@trvn.ru>
Cc: Krzysztof Kozlowski <krzk@kernel.org>,
	thierry.reding@gmail.com, lee.jones@linaro.org,
	robh+dt@kernel.org, sboyd@kernel.org, linus.walleij@linaro.org,
	masneyb@onstation.org, sean.anderson@seco.com,
	linux-pwm@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	~postmarketos/upstreaming@lists.sr.ht
Subject: Re: [PATCH v4 2/2] pwm: Add clock based PWM output driver
Date: Wed, 26 Jan 2022 16:35:35 +0100	[thread overview]
Message-ID: <20220126153535.jg4kidtvlfb6aplt@pengutronix.de> (raw)
In-Reply-To: <72e076e7d0612667d503cb1196abb3c7@trvn.ru>

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

On Wed, Jan 26, 2022 at 06:35:15PM +0500, Nikita Travkin wrote:
> Krzysztof Kozlowski писал(а) 26.01.2022 18:18:
> > On 26/01/2022 13:58, Nikita Travkin wrote:
> >> Some systems have clocks exposed to external devices. If the clock
> >> controller supports duty-cycle configuration, such clocks can be used as
> >> pwm outputs. In fact PWM and CLK subsystems are interfaced with in a
> >> similar way and an "opposite" driver already exists (clk-pwm). Add a
> >> driver that would enable pwm devices to be used via clk subsystem.
> >>
> >> Signed-off-by: Nikita Travkin <nikita@trvn.ru>
> >> --
> >>
> >> Changes in v2:
> >>  - Address Uwe's review comments:
> >>    - Round set clk rate up
> >>    - Add a description with limitations of the driver
> >>    - Disable and unprepare clock before removing pwmchip
> >> Changes in v3:
> >>  - Use 64bit version of div round up
> >>  - Address Uwe's review comments:
> >>    - Reword the limitations to avoid incorrect claims
> >>    - Move the clk_enabled flag assignment
> >>    - Drop unnecessary statements
> >> ---
> >>  drivers/pwm/Kconfig   |  10 +++
> >>  drivers/pwm/Makefile  |   1 +
> >>  drivers/pwm/pwm-clk.c | 139 ++++++++++++++++++++++++++++++++++++++++++
> >>  3 files changed, 150 insertions(+)
> >>  create mode 100644 drivers/pwm/pwm-clk.c
> >>
> >> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> >> index 21e3b05a5153..daa2491a4054 100644
> >> --- a/drivers/pwm/Kconfig
> >> +++ b/drivers/pwm/Kconfig
> >> @@ -140,6 +140,16 @@ config PWM_BRCMSTB
> >>  	  To compile this driver as a module, choose M Here: the module
> >>  	  will be called pwm-brcmstb.c.
> >>
> >> +config PWM_CLK
> >> +	tristate "Clock based PWM support"
> >> +	depends on HAVE_CLK || COMPILE_TEST
> >> +	help
> >> +	  Generic PWM framework driver for outputs that can be
> >> +	  muxed to clocks.
> >> +
> >> +	  To compile this driver as a module, choose M here: the module
> >> +	  will be called pwm-clk.
> >> +
> >>  config PWM_CLPS711X
> >>  	tristate "CLPS711X PWM support"
> >>  	depends on ARCH_CLPS711X || COMPILE_TEST
> >> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> >> index 708840b7fba8..4a860103c470 100644
> >> --- a/drivers/pwm/Makefile
> >> +++ b/drivers/pwm/Makefile
> >> @@ -10,6 +10,7 @@ obj-$(CONFIG_PWM_BCM_KONA)	+= pwm-bcm-kona.o
> >>  obj-$(CONFIG_PWM_BCM2835)	+= pwm-bcm2835.o
> >>  obj-$(CONFIG_PWM_BERLIN)	+= pwm-berlin.o
> >>  obj-$(CONFIG_PWM_BRCMSTB)	+= pwm-brcmstb.o
> >> +obj-$(CONFIG_PWM_CLK)		+= pwm-clk.o
> >>  obj-$(CONFIG_PWM_CLPS711X)	+= pwm-clps711x.o
> >>  obj-$(CONFIG_PWM_CRC)		+= pwm-crc.o
> >>  obj-$(CONFIG_PWM_CROS_EC)	+= pwm-cros-ec.o
> >> diff --git a/drivers/pwm/pwm-clk.c b/drivers/pwm/pwm-clk.c
> >> new file mode 100644
> >> index 000000000000..b3bfa12a0e73
> >> --- /dev/null
> >> +++ b/drivers/pwm/pwm-clk.c
> >> @@ -0,0 +1,139 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +/*
> >> + * Clock based PWM controller
> >> + *
> >> + * Copyright (c) 2021 Nikita Travkin <nikita@trvn.ru>
> >> + *
> >> + * This is an "adapter" driver that allows PWM consumers to use
> >> + * system clocks with duty cycle control as PWM outputs.
> >> + *
> >> + * Limitations:
> >> + * - Glitches are possible when new pwm state is applied.
> >> + * - Due to the fact that exact behavior depends on the underlying
> >> + *   clock driver, various limitations are possible.
> >> + * - Period depends on the clock and, in general, not guaranteed.
> >> + * - Underlying clock may not be able to give 0% or 100% duty cycle
> >> + *   (constant off or on), exact behavior will depend on the clock.
> >> + * - When the PWM is disabled, the clock will be disabled as well,
> >> + *   line state will depend on the clock.
> >> + */
> >> +
> >> +#include <linux/kernel.h>
> >> +#include <linux/math64.h>
> >> +#include <linux/err.h>
> >> +#include <linux/module.h>
> >> +#include <linux/of.h>
> >> +#include <linux/platform_device.h>
> >> +#include <linux/clk.h>
> >> +#include <linux/pwm.h>
> >> +
> >> +struct pwm_clk_chip {
> >> +	struct pwm_chip chip;
> >> +	struct clk *clk;
> >> +	bool clk_enabled;
> >> +};
> >> +
> >> +#define to_pwm_clk_chip(_chip) container_of(_chip, struct pwm_clk_chip, chip)
> >> +
> >> +static int pwm_clk_apply(struct pwm_chip *pwm_chip, struct pwm_device *pwm,
> >> +			 const struct pwm_state *state)
> >> +{
> >> +	struct pwm_clk_chip *chip = to_pwm_clk_chip(pwm_chip);
> >> +	int ret;
> >> +	u32 rate;
> >> +	u64 period = state->period;
> >> +	u64 duty_cycle = state->duty_cycle;
> >> +
> >> +	if (!state->enabled) {
> >> +		if (pwm->state.enabled) {
> >> +			clk_disable(chip->clk);
> >> +			chip->clk_enabled = false;
> >> +		}
> >> +		return 0;
> >> +	} else if (!pwm->state.enabled) {
> >> +		ret = clk_enable(chip->clk);
> >> +		if (ret)
> >> +			return ret;
> >> +		chip->clk_enabled = true;
> >> +	}
> >> +
> >> +	rate = DIV64_U64_ROUND_UP(NSEC_PER_SEC, period);
> >> +	ret = clk_set_rate(chip->clk, rate);
> >> +	if (ret)
> >> +		return ret;
> >> +
> >> +	if (state->polarity == PWM_POLARITY_INVERSED)
> >> +		duty_cycle = period - duty_cycle;
> >> +
> >> +	return clk_set_duty_cycle(chip->clk, duty_cycle, period);
> >> +}
> >> +
> >> +static const struct pwm_ops pwm_clk_ops = {
> >> +	.apply = pwm_clk_apply,
> >> +	.owner = THIS_MODULE,
> >> +};
> >> +
> >> +static int pwm_clk_probe(struct platform_device *pdev)
> >> +{
> >> +	struct pwm_clk_chip *chip;
> >> +	int ret;
> >> +
> >> +	chip = devm_kzalloc(&pdev->dev, sizeof(*chip), GFP_KERNEL);
> >> +	if (!chip)
> >> +		return -ENOMEM;
> >> +
> >> +	chip->clk = devm_clk_get(&pdev->dev, NULL);
> >> +	if (IS_ERR(chip->clk))
> >> +		return dev_err_probe(&pdev->dev, PTR_ERR(chip->clk),
> >> +				     "Failed to get clock\n");
> >> +
> >> +	chip->chip.dev = &pdev->dev;
> >> +	chip->chip.ops = &pwm_clk_ops;
> >> +	chip->chip.npwm = 1;
> >> +
> >> +	ret = clk_prepare(chip->clk);
> >> +	if (ret < 0)
> >> +		dev_err_probe(&pdev->dev, ret, "Failed to prepare clock\n");
> >> +
> >> +	ret = pwmchip_add(&chip->chip);
> >> +	if (ret < 0)
> >> +		dev_err_probe(&pdev->dev, ret, "Failed to add pwm chip\n");
> >> +
> > 
> > What is the point of probing the driver if pwmchip_add() fails? This
> > should be rather fatal error.
> > 
> > The same with clock. If preparing clock fails, there is little point in
> > enabling/disabling it later.
> > 
> 
> Uh oh... Seems like I forgot a return in both cases... For some reason
> I had an incorrect assumption in my mind that dev_err_probe is a macro
> that does the return on it's own, yet I used it correctly just a couple
> of lines earlier...

dev_err_probe returns the error code, so

	return dev_err_probe(&pdev->dev, ret, "Failed to add pwm chip\n");

is the right magic.

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 --]

      reply	other threads:[~2022-01-26 15:36 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-26 12:58 [PATCH v4 0/2] Clock based PWM output driver Nikita Travkin
2022-01-26 12:58 ` [PATCH v4 1/2] dt-bindings: pwm: Document clk based PWM controller Nikita Travkin
2022-01-26 13:14   ` Krzysztof Kozlowski
2022-01-26 13:24     ` Nikita Travkin
2022-01-26 12:58 ` [PATCH v4 2/2] pwm: Add clock based PWM output driver Nikita Travkin
2022-01-26 13:18   ` Krzysztof Kozlowski
2022-01-26 13:35     ` Nikita Travkin
2022-01-26 15:35       ` Uwe Kleine-König [this message]

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=20220126153535.jg4kidtvlfb6aplt@pengutronix.de \
    --to=u.kleine-koenig@pengutronix.de \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk@kernel.org \
    --cc=lee.jones@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=masneyb@onstation.org \
    --cc=nikita@trvn.ru \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=sean.anderson@seco.com \
    --cc=thierry.reding@gmail.com \
    --cc=~postmarketos/upstreaming@lists.sr.ht \
    /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).