| Message ID | 20211213150335.51888-3-nikita@trvn.ru |
|---|---|
| State | Changes Requested |
| Delegated to: | Uwe Kleine-König |
| Headers | show |
| Series | Clock based PWM output driver | expand |
Hi Nikita,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on thierry-reding-pwm/for-next]
[also build test ERROR on v5.16-rc5 next-20211213]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Nikita-Travkin/Clock-based-PWM-output-driver/20211213-230628
base: https://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git for-next
config: riscv-randconfig-c024-20211214 (https://download.01.org/0day-ci/archive/20211215/202112150018.zRKkwUhX-lkp@intel.com/config)
compiler: riscv32-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/454624747f4637529777274ae1b5ab7af33fd130
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Nikita-Travkin/Clock-based-PWM-output-driver/20211213-230628
git checkout 454624747f4637529777274ae1b5ab7af33fd130
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=riscv SHELL=/bin/bash
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
riscv32-linux-ld: drivers/pwm/pwm-clk.o: in function `.L18':
>> pwm-clk.c:(.text+0x86): undefined reference to `__udivdi3'
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
Hi Nikita,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on thierry-reding-pwm/for-next]
[also build test ERROR on v5.16-rc5 next-20211213]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Nikita-Travkin/Clock-based-PWM-output-driver/20211213-230628
base: https://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git for-next
config: microblaze-randconfig-r003-20211214 (https://download.01.org/0day-ci/archive/20211215/202112150357.lrG18diq-lkp@intel.com/config)
compiler: microblaze-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/454624747f4637529777274ae1b5ab7af33fd130
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Nikita-Travkin/Clock-based-PWM-output-driver/20211213-230628
git checkout 454624747f4637529777274ae1b5ab7af33fd130
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=microblaze SHELL=/bin/bash
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>, old ones prefixed by <<):
>> ERROR: modpost: "__udivdi3" [drivers/pwm/pwm-clk.ko] undefined!
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
Hello, On Mon, Dec 13, 2021 at 08:03:35PM +0500, 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 > --- > drivers/pwm/Kconfig | 10 +++ > drivers/pwm/Makefile | 1 + > drivers/pwm/pwm-clk.c | 143 ++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 154 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..55fd320b9c19 > --- /dev/null > +++ b/drivers/pwm/pwm-clk.c > @@ -0,0 +1,143 @@ > +// 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: > + * - There is no way to atomically set both clock rate and > + * duty-cycle so glitches are possible when new pwm state > + * is applied. > + * - Period depends on the underlying clock driver and, > + * in general, not guaranteed. > + * - Underlying clock may not be able to give 100% > + * duty cycle (constant on) and only set the closest > + * possible duty cycle. (e.g. 99.9%) What about 0%? - Periods are not completed on changes in general. - Behaviour on disable depends on the underlaying clk, don't assume it to provide the inactive level. > + */ > + > +#include <linux/clk.h> > +#include <linux/err.h> > +#include <linux/kernel.h> > +#include <linux/module.h> > +#include <linux/of.h> > +#include <linux/platform_device.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); > + chip->clk_enabled = true; > + if (ret) > + return ret; if clk_enable() failed better don't set chip->clk_enabled = true; > + } > + > + rate = DIV_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; > + > + ret = clk_set_duty_cycle(chip->clk, duty_cycle, period); > + if (ret) > + return ret; > + > + return ret; This can be simplified to 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.of_xlate = of_pwm_xlate_with_flags; > + chip->chip.of_pwm_n_cells = 2; I'd just skip those two assignments. These are the default, anyhow. (Assuming you have #pwm-cells = <2> in the device tree.) > + 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"); > + > + platform_set_drvdata(pdev, chip); > + return 0; > +} Best regards Uwe
Hi, Uwe Kleine-König писал(а) 17.01.2022 20:58: > Hello, > > On Mon, Dec 13, 2021 at 08:03:35PM +0500, 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 >> --- >> drivers/pwm/Kconfig | 10 +++ >> drivers/pwm/Makefile | 1 + >> drivers/pwm/pwm-clk.c | 143 ++++++++++++++++++++++++++++++++++++++++++ >> 3 files changed, 154 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..55fd320b9c19 >> --- /dev/null >> +++ b/drivers/pwm/pwm-clk.c >> @@ -0,0 +1,143 @@ >> +// 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: >> + * - There is no way to atomically set both clock rate and >> + * duty-cycle so glitches are possible when new pwm state >> + * is applied. >> + * - Period depends on the underlying clock driver and, >> + * in general, not guaranteed. >> + * - Underlying clock may not be able to give 100% >> + * duty cycle (constant on) and only set the closest >> + * possible duty cycle. (e.g. 99.9%) > > What about 0%? You're right, this is also a problematic case that I should've mentioned here. In fact I *did* have problems with zero written into the duty cycle register of my clock. I decided that it should be solved by the hardware driver so I sent a patch with a zero check there. (As otherwise there might be a clock that would properly support 0% and 100% cycles so making the write like this impossible is not a job of this driver I think) > > - Periods are not completed on changes in general. I suppose I should reword the limitation, dropping the reference to impossible atomic operations and just state that glitches are inevitable. > - Behaviour on disable depends on the underlaying clk, don't assume it > to provide the inactive level. > Hm, now thinking of it, I'm not sure if the clock line was set to logic 0 or was left floating (which is what I assume you mean by the undefined behavior here) on the clock I was debugging this on with an oscilloscope. (nor am I sure if I even can make such a conclusion by looking at that...) Do you think that this should be just documented in the limitations? Like: - Underlying clock may not be able to give 0% or 100% duty cycle (constant off or on) and only set the closest possible duty cycle. (e.g. 0.1% or 99.9%) - When the PWM is disabled, the clock will be disabled as well. User should take care of properly pulling the line down in case the disabled clock leaves it floating. (I guess here I'm making an assumption that there is no clock that will be set to logic 1 upon being disabled without the way to change that behavior...) >> + */ >> + >> +#include <linux/clk.h> >> +#include <linux/err.h> >> +#include <linux/kernel.h> >> +#include <linux/module.h> >> +#include <linux/of.h> >> +#include <linux/platform_device.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); >> + chip->clk_enabled = true; >> + if (ret) >> + return ret; > > if clk_enable() failed better don't set chip->clk_enabled = true; > Will move it after the check. >> + } >> + >> + rate = DIV_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; >> + >> + ret = clk_set_duty_cycle(chip->clk, duty_cycle, period); >> + if (ret) >> + return ret; >> + >> + return ret; > > This can be simplified to > > return clk_set_duty_cycle(chip->clk, duty_cycle, period); > Will do. >> +} >> + >> +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.of_xlate = of_pwm_xlate_with_flags; >> + chip->chip.of_pwm_n_cells = 2; > > I'd just skip those two assignments. These are the default, anyhow. > (Assuming you have #pwm-cells = <2> in the device tree.) > Right, now I see that the core sets those and I force the #pwm-cells = <2> via the dt bindings. Will drop. Thanks for the comments! I will send a v3 with the changes slightly later Nikita >> + 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"); >> + >> + platform_set_drvdata(pdev, chip); >> + return 0; >> +} > > Best regards > Uwe
On Mon, Jan 17, 2022 at 11:04:31PM +0500, Nikita Travkin wrote: > Hi, > > Uwe Kleine-König писал(а) 17.01.2022 20:58: > > Hello, > > > > On Mon, Dec 13, 2021 at 08:03:35PM +0500, 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 > >> --- > >> drivers/pwm/Kconfig | 10 +++ > >> drivers/pwm/Makefile | 1 + > >> drivers/pwm/pwm-clk.c | 143 ++++++++++++++++++++++++++++++++++++++++++ > >> 3 files changed, 154 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..55fd320b9c19 > >> --- /dev/null > >> +++ b/drivers/pwm/pwm-clk.c > >> @@ -0,0 +1,143 @@ > >> +// 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: > >> + * - There is no way to atomically set both clock rate and > >> + * duty-cycle so glitches are possible when new pwm state > >> + * is applied. > >> + * - Period depends on the underlying clock driver and, > >> + * in general, not guaranteed. > >> + * - Underlying clock may not be able to give 100% > >> + * duty cycle (constant on) and only set the closest > >> + * possible duty cycle. (e.g. 99.9%) > > > > What about 0%? > > You're right, this is also a problematic case that I should've > mentioned here. In fact I *did* have problems with zero written > into the duty cycle register of my clock. I decided that it > should be solved by the hardware driver so I sent a patch > with a zero check there. (As otherwise there might be a clock > that would properly support 0% and 100% cycles so making the > write like this impossible is not a job of this driver I think) > > > > > - Periods are not completed on changes in general. > > I suppose I should reword the limitation, dropping > the reference to impossible atomic operations and > just state that glitches are inevitable. > > > - Behaviour on disable depends on the underlaying clk, don't assume it > > to provide the inactive level. > > > > Hm, now thinking of it, I'm not sure if the clock line > was set to logic 0 or was left floating (which is what I assume > you mean by the undefined behavior here) on the clock I was > debugging this on with an oscilloscope. (nor am I sure > if I even can make such a conclusion by looking at that...) > > Do you think that this should be just documented in the > limitations? Like: > > - Underlying clock may not be able to give 0% or 100% > duty cycle (constant off or on) and only set the > closest possible duty cycle. (e.g. 0.1% or 99.9%) I would not bet on this. Maybe in such a case clk_set_duty_cycle might also fail. The clk API isn't (TTBOMK) well-defined enough to make promises like that. > - When the PWM is disabled, the clock will be disabled > as well. User should take care of properly pulling > the line down in case the disabled clock leaves it > floating. This isn't universally true. I'd expect that just freezing (i.e. driving either high or low depending on the state when the clk was stopped) is a very usual behaviour. So a pull isn't always a good idea. I would just keep that unspecified. Best regards Uwe
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..55fd320b9c19 --- /dev/null +++ b/drivers/pwm/pwm-clk.c @@ -0,0 +1,143 @@ +// 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: + * - There is no way to atomically set both clock rate and + * duty-cycle so glitches are possible when new pwm state + * is applied. + * - Period depends on the underlying clock driver and, + * in general, not guaranteed. + * - Underlying clock may not be able to give 100% + * duty cycle (constant on) and only set the closest + * possible duty cycle. (e.g. 99.9%) + */ + +#include <linux/clk.h> +#include <linux/err.h> +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/of.h> +#include <linux/platform_device.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); + chip->clk_enabled = true; + if (ret) + return ret; + } + + rate = DIV_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; + + ret = clk_set_duty_cycle(chip->clk, duty_cycle, period); + if (ret) + return ret; + + return ret; +} + +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.of_xlate = of_pwm_xlate_with_flags; + chip->chip.of_pwm_n_cells = 2; + 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"); + + platform_set_drvdata(pdev, chip); + return 0; +} + +static int pwm_clk_remove(struct platform_device *pdev) +{ + struct pwm_clk_chip *chip = platform_get_drvdata(pdev); + + pwmchip_remove(&chip->chip); + + if (chip->clk_enabled) + clk_disable(chip->clk); + + clk_unprepare(chip->clk); + + return 0; +} + +static const struct of_device_id pwm_clk_dt_ids[] = { + { .compatible = "clk-pwm", }, + { /* sentinel */ } +}; +MODULE_DEVICE_TABLE(of, pwm_clk_dt_ids); + +static struct platform_driver pwm_clk_driver = { + .driver = { + .name = "pwm-clk", + .of_match_table = pwm_clk_dt_ids, + }, + .probe = pwm_clk_probe, + .remove = pwm_clk_remove, +}; +module_platform_driver(pwm_clk_driver); + +MODULE_ALIAS("platform:pwm-clk"); +MODULE_AUTHOR("Nikita Travkin <nikita@trvn.ru>"); +MODULE_DESCRIPTION("Clock based PWM driver"); +MODULE_LICENSE("GPL");
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 --- drivers/pwm/Kconfig | 10 +++ drivers/pwm/Makefile | 1 + drivers/pwm/pwm-clk.c | 143 ++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 154 insertions(+) create mode 100644 drivers/pwm/pwm-clk.c