| Message ID | 1515766983-15151-1-git-send-email-claudiu.beznea@microchip.com |
|---|---|
| Headers | show |
| Series | extend PWM framework to support PWM modes | expand |
Hi, On Fri, Jan 12, 2018 at 04:22:48PM +0200, Claudiu Beznea wrote: > Remove of_pwm_simple_xlate() and of_pwm_xlate_with_flags() functions > and add of_pwm_xlate() which is used in all cases no mather if the OF > bindings are with PWM flags or not. This should not affect the old > behavior since the xlate will be based on #pwm-cells property of the > PWM controller. Based on #pwm-cells property the xlate will consider > the flags or not. This will permit the addition of other inputs to OF > xlate by just adding proper code at the end of of_pwm_xlate() and a new > input to enum pwm_args_xlate_options. With this changes there will be > no need to fill of_xlate and of_pwm_n_cells of struct pwm_chip from > the drivers probe methods. References in drives to references to of_xlate > and of_pwm_n_cells were removed. Drivers which used private of_xlate > functions switched to the generic of_pwm_xlate() function which fits > for it but with little changes in device trees (these drivers translated > differently the "pwms" bindings; the "pwms" bindings now are generic to > all drivers and all drivers should provide them in the format described > in pwm documentation). > > Cc: Thierry Reding <thierry.reding@gmail.com> > Cc: Mike Dunn <mikedunn@newsguy.com> > Cc: Brian Norris <briannorris@chromium.org> > Cc: Alexander Shiyan <shc_work@mail.ru> > Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> > --- > > This patch (and the next 7) could be applied independetly by this series, if > any, but I choosed to have it here since it makes easy the PWM modes parsing. > If you feel it could be independently of this series I could send a new version. > > Also, Thierry, Mike, Brian, Shiyan, please take an extra look over pwm-pxa.c, > pwm-cros-ec.c and pwm-clps711x.c since these were moved to use the generic > pwms (minimum 2 pwm-cells). > > drivers/pwm/core.c | 56 +++++++++++------------------------------- > drivers/pwm/pwm-atmel-hlcdc.c | 2 -- > drivers/pwm/pwm-atmel-tcb.c | 2 -- > drivers/pwm/pwm-atmel.c | 6 ----- > drivers/pwm/pwm-bcm-iproc.c | 2 -- > drivers/pwm/pwm-bcm-kona.c | 2 -- > drivers/pwm/pwm-bcm2835.c | 2 -- > drivers/pwm/pwm-berlin.c | 2 -- > drivers/pwm/pwm-clps711x.c | 11 --------- > drivers/pwm/pwm-cros-ec.c | 20 --------------- For pwm-cros-ec.c: Nacked-by: Brian Norris <briannorris@chromium.org> This is a fiat change of the documented binding, which breaks the RK3399 Kevin board. That's not how we do device tree. You can extend the binding if you want, so you can represent the period in the device tree if you'd like (though the value won't mean anything; it can't be changed by the kernel), but don't break existing device trees. > drivers/pwm/pwm-fsl-ftm.c | 2 -- > drivers/pwm/pwm-hibvt.c | 2 -- > drivers/pwm/pwm-imx.c | 8 ------ > drivers/pwm/pwm-lpc18xx-sct.c | 2 -- > drivers/pwm/pwm-meson.c | 2 -- > drivers/pwm/pwm-omap-dmtimer.c | 2 -- > drivers/pwm/pwm-pxa.c | 19 -------------- > drivers/pwm/pwm-renesas-tpu.c | 2 -- > drivers/pwm/pwm-rockchip.c | 5 ---- > drivers/pwm/pwm-samsung.c | 3 --- > drivers/pwm/pwm-sun4i.c | 2 -- > drivers/pwm/pwm-tiecap.c | 2 -- > drivers/pwm/pwm-tiehrpwm.c | 2 -- > drivers/pwm/pwm-vt8500.c | 2 -- > drivers/pwm/pwm-zx.c | 2 -- > include/linux/pwm.h | 23 ++++++++++------- > 26 files changed, 29 insertions(+), 156 deletions(-) > ... > diff --git a/drivers/pwm/pwm-cros-ec.c b/drivers/pwm/pwm-cros-ec.c > index 9c13694eaa24..692298693768 100644 > --- a/drivers/pwm/pwm-cros-ec.c > +++ b/drivers/pwm/pwm-cros-ec.c > @@ -133,24 +133,6 @@ static void cros_ec_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm, > state->duty_cycle = ret; > } > > -static struct pwm_device * > -cros_ec_pwm_xlate(struct pwm_chip *pc, const struct of_phandle_args *args) > -{ > - struct pwm_device *pwm; > - > - if (args->args[0] >= pc->npwm) > - return ERR_PTR(-EINVAL); > - > - pwm = pwm_request_from_chip(pc, args->args[0], NULL); > - if (IS_ERR(pwm)) > - return pwm; > - > - /* The EC won't let us change the period */ > - pwm->args.period = EC_PWM_MAX_DUTY; > - > - return pwm; > -} > - > static const struct pwm_ops cros_ec_pwm_ops = { > .get_state = cros_ec_pwm_get_state, > .apply = cros_ec_pwm_apply, > @@ -207,8 +189,6 @@ static int cros_ec_pwm_probe(struct platform_device *pdev) > /* PWM chip */ > chip->dev = dev; > chip->ops = &cros_ec_pwm_ops; > - chip->of_xlate = cros_ec_pwm_xlate; > - chip->of_pwm_n_cells = 1; > chip->base = -1; > ret = cros_ec_num_pwms(ec); > if (ret < 0) { ... Brian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 15.01.2018 10:41, Claudiu Beznea wrote: > Hi Boris, s/Boris/Brian > > Thanks for your review. See below my answers. > > On 12.01.2018 20:35, Brian Norris wrote: >> Hi, >> >> On Fri, Jan 12, 2018 at 04:22:48PM +0200, Claudiu Beznea wrote: >>> Remove of_pwm_simple_xlate() and of_pwm_xlate_with_flags() functions >>> and add of_pwm_xlate() which is used in all cases no mather if the OF >>> bindings are with PWM flags or not. This should not affect the old >>> behavior since the xlate will be based on #pwm-cells property of the >>> PWM controller. Based on #pwm-cells property the xlate will consider >>> the flags or not. This will permit the addition of other inputs to OF >>> xlate by just adding proper code at the end of of_pwm_xlate() and a new >>> input to enum pwm_args_xlate_options. With this changes there will be >>> no need to fill of_xlate and of_pwm_n_cells of struct pwm_chip from >>> the drivers probe methods. References in drives to references to of_xlate >>> and of_pwm_n_cells were removed. Drivers which used private of_xlate >>> functions switched to the generic of_pwm_xlate() function which fits >>> for it but with little changes in device trees (these drivers translated >>> differently the "pwms" bindings; the "pwms" bindings now are generic to >>> all drivers and all drivers should provide them in the format described >>> in pwm documentation). >>> >>> Cc: Thierry Reding <thierry.reding@gmail.com> >>> Cc: Mike Dunn <mikedunn@newsguy.com> >>> Cc: Brian Norris <briannorris@chromium.org> >>> Cc: Alexander Shiyan <shc_work@mail.ru> >>> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> >>> --- >>> >>> This patch (and the next 7) could be applied independetly by this series, if >>> any, but I choosed to have it here since it makes easy the PWM modes parsing. >>> If you feel it could be independently of this series I could send a new version. >>> >>> Also, Thierry, Mike, Brian, Shiyan, please take an extra look over pwm-pxa.c, >>> pwm-cros-ec.c and pwm-clps711x.c since these were moved to use the generic >>> pwms (minimum 2 pwm-cells). >>> >>> drivers/pwm/core.c | 56 +++++++++++------------------------------- >>> drivers/pwm/pwm-atmel-hlcdc.c | 2 -- >>> drivers/pwm/pwm-atmel-tcb.c | 2 -- >>> drivers/pwm/pwm-atmel.c | 6 ----- >>> drivers/pwm/pwm-bcm-iproc.c | 2 -- >>> drivers/pwm/pwm-bcm-kona.c | 2 -- >>> drivers/pwm/pwm-bcm2835.c | 2 -- >>> drivers/pwm/pwm-berlin.c | 2 -- >>> drivers/pwm/pwm-clps711x.c | 11 --------- >>> drivers/pwm/pwm-cros-ec.c | 20 --------------- >> >> For pwm-cros-ec.c: >> >> Nacked-by: Brian Norris <briannorris@chromium.org> >> >> This is a fiat change of the documented binding, which breaks the RK3399 >> Kevin board. That's not how we do device tree. >> >> You can extend the binding if you want, so you can represent the period >> in the device tree if you'd like (though the value won't mean anything; >> it can't be changed by the kernel), but don't break existing device >> trees. > > That wasn't the idea, I wasn't intended to break something. The idea was > to have a generic device tree parsing function since all the drivers, > except pwm-pxa.c, pwm-cros-ec.c and pwm-clps711x.c, uses the same function > to parse DT bindings. And I think, these 3 drivers could use this way of > parsing, which is not something new, is what all the current PWM drivers > uses (except pwm-pxa.c, pwm-cros-ec.c and pwm-clps711x.c). It is true > I have no RK3399 board to run any tests. > > pwm-cross-ec.c it is true that it's period cannot be changed. It is fixed, as > I saw in the driver, at EC_PWM_MAX_DUTY=0xffff. The driver itself won't apply > any PWM state if the period is different from EC_PWM_MAX_DUTY. > For this driver, the PWM bindings were changed (I did a grep by "google,cros-ec-pwm" > and located only: > arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts > arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi > files) and changed the bindings in this series, as follows, patch 7 from this series: > diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts > index 0384e3121f18..0c790ec387eb 100644 > --- a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts > +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts > @@ -77,7 +77,7 @@ > > backlight: backlight { > compatible = "pwm-backlight"; > - pwms = <&cros_ec_pwm 1>; > + pwms = <&cros_ec_pwm 1 65535>; > brightness-levels = <0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 > 17 18 19 20 21 22 23 24 25 26 27 28 29 30 > 31 32 33 34 35 36 37 38 39 40 41 42 43 44 > diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi > index 5772c52fbfd3..aa377f9ae6ad 100644 > --- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi > +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi > @@ -853,7 +853,7 @@ ap_i2c_audio: &i2c8 { > > cros_ec_pwm: ec-pwm { > compatible = "google,cros-ec-pwm"; > - #pwm-cells = <1>; > + #pwm-cells = <2>; > }; > }; > }; > > The code that was removed requests a PWM, the one that was set in the bindings, and > then set pwm->args.period: > -static struct pwm_device * > -cros_ec_pwm_xlate(struct pwm_chip *pc, const struct of_phandle_args *args) > -{ > - struct pwm_device *pwm; > - > - if (args->args[0] >= pc->npwm) > - return ERR_PTR(-EINVAL); > - > - pwm = pwm_request_from_chip(pc, args->args[0], NULL); > - if (IS_ERR(pwm)) > - return pwm; > - > - /* The EC won't let us change the period */ > - pwm->args.period = EC_PWM_MAX_DUTY; > - > - return pwm; > -} > > The old flow is as follows: > of_pwm_get() -> cros_ec_pwm_xlate() { request chip and set constant period } > > The new flow uses of_pwm_xlate(): > of_pwm_get() -> of_pwm_xlate() -> { parse PWM args: channel number, period, flags + > request PWM chip + set pwm->args; } > > This path is only used at DT parsing. > > In case of PWM channel requested by PWM backlight driver it looks good to me > with the changes in rk3399-gru-kevin.dts (please correct me if I'm wrong). > > Since this driver accepts only EC_PWM_MAX_DUTY period maybe the documentation should > be updated regarding this value? > > Please, let me know what you think! > > Thanks, > Claudiu >> >>> drivers/pwm/pwm-fsl-ftm.c | 2 -- >>> drivers/pwm/pwm-hibvt.c | 2 -- >>> drivers/pwm/pwm-imx.c | 8 ------ >>> drivers/pwm/pwm-lpc18xx-sct.c | 2 -- >>> drivers/pwm/pwm-meson.c | 2 -- >>> drivers/pwm/pwm-omap-dmtimer.c | 2 -- >>> drivers/pwm/pwm-pxa.c | 19 -------------- >>> drivers/pwm/pwm-renesas-tpu.c | 2 -- >>> drivers/pwm/pwm-rockchip.c | 5 ---- >>> drivers/pwm/pwm-samsung.c | 3 --- >>> drivers/pwm/pwm-sun4i.c | 2 -- >>> drivers/pwm/pwm-tiecap.c | 2 -- >>> drivers/pwm/pwm-tiehrpwm.c | 2 -- >>> drivers/pwm/pwm-vt8500.c | 2 -- >>> drivers/pwm/pwm-zx.c | 2 -- >>> include/linux/pwm.h | 23 ++++++++++------- >>> 26 files changed, 29 insertions(+), 156 deletions(-) >>> >> ... >> >>> diff --git a/drivers/pwm/pwm-cros-ec.c b/drivers/pwm/pwm-cros-ec.c >>> index 9c13694eaa24..692298693768 100644 >>> --- a/drivers/pwm/pwm-cros-ec.c >>> +++ b/drivers/pwm/pwm-cros-ec.c >>> @@ -133,24 +133,6 @@ static void cros_ec_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm, >>> state->duty_cycle = ret; >>> } >>> >>> -static struct pwm_device * >>> -cros_ec_pwm_xlate(struct pwm_chip *pc, const struct of_phandle_args *args) >>> -{ >>> - struct pwm_device *pwm; >>> - >>> - if (args->args[0] >= pc->npwm) >>> - return ERR_PTR(-EINVAL); >>> - >>> - pwm = pwm_request_from_chip(pc, args->args[0], NULL); >>> - if (IS_ERR(pwm)) >>> - return pwm; >>> - >>> - /* The EC won't let us change the period */ >>> - pwm->args.period = EC_PWM_MAX_DUTY; >>> - >>> - return pwm; >>> -} >>> - >>> static const struct pwm_ops cros_ec_pwm_ops = { >>> .get_state = cros_ec_pwm_get_state, >>> .apply = cros_ec_pwm_apply, >>> @@ -207,8 +189,6 @@ static int cros_ec_pwm_probe(struct platform_device *pdev) >>> /* PWM chip */ >>> chip->dev = dev; >>> chip->ops = &cros_ec_pwm_ops; >>> - chip->of_xlate = cros_ec_pwm_xlate; >>> - chip->of_pwm_n_cells = 1; >>> chip->base = -1; >>> ret = cros_ec_num_pwms(ec); >>> if (ret < 0) { >> >> ... >> >> Brian >> > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jan 15, 2018 at 10:41 AM, Claudiu Beznea <Claudiu.Beznea@microchip.com> wrote: > For this driver, the PWM bindings were changed (I did a grep by "google,cros-ec-pwm" > and located only: > arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts > arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi > files) and changed the bindings in this series, as follows, patch 7 from this series: > diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts > index 0384e3121f18..0c790ec387eb 100644 > --- a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts > +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts > @@ -77,7 +77,7 @@ > > backlight: backlight { > compatible = "pwm-backlight"; > - pwms = <&cros_ec_pwm 1>; > + pwms = <&cros_ec_pwm 1 65535>; This shows an breakage for user. The old PWM device tree sources or binaries should work independently on what changes you did to kernel.
On 15.01.2018 22:27, Andy Shevchenko wrote: > On Mon, Jan 15, 2018 at 10:41 AM, Claudiu Beznea > <Claudiu.Beznea@microchip.com> wrote: > >> For this driver, the PWM bindings were changed (I did a grep by "google,cros-ec-pwm" >> and located only: >> arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts >> arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi >> files) and changed the bindings in this series, as follows, patch 7 from this series: >> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts >> index 0384e3121f18..0c790ec387eb 100644 >> --- a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts >> +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts >> @@ -77,7 +77,7 @@ >> >> backlight: backlight { >> compatible = "pwm-backlight"; >> - pwms = <&cros_ec_pwm 1>; >> + pwms = <&cros_ec_pwm 1 65535>; > > This shows an breakage for user. As long as pwm-cells=2 the OF hooks will read PWM channel and PWM period (e.g. in this case, PWM channel=1, PWM period=65532) I don't see a breakage here. Please explain me further. The old PWM device tree sources or > binaries should work independently on what changes you did to kernel. Please explain me further. From this I understand, as a general rule, that the device tree binaries from, e.g. 3 years ago, should be compatible with, e.g. the current version of kernel? Thanks, Claudiu > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/01/2018 15:22, Claudiu Beznea wrote: > Remove of_pwm_simple_xlate() and of_pwm_xlate_with_flags() functions > and add of_pwm_xlate() which is used in all cases no mather if the OF > bindings are with PWM flags or not. This should not affect the old > behavior since the xlate will be based on #pwm-cells property of the > PWM controller. Based on #pwm-cells property the xlate will consider > the flags or not. This will permit the addition of other inputs to OF > xlate by just adding proper code at the end of of_pwm_xlate() and a new > input to enum pwm_args_xlate_options. With this changes there will be > no need to fill of_xlate and of_pwm_n_cells of struct pwm_chip from > the drivers probe methods. References in drives to references to of_xlate > and of_pwm_n_cells were removed. Drivers which used private of_xlate > functions switched to the generic of_pwm_xlate() function which fits > for it but with little changes in device trees (these drivers translated > differently the "pwms" bindings; the "pwms" bindings now are generic to > all drivers and all drivers should provide them in the format described > in pwm documentation). > > Cc: Thierry Reding <thierry.reding@gmail.com> > Cc: Mike Dunn <mikedunn@newsguy.com> > Cc: Brian Norris <briannorris@chromium.org> > Cc: Alexander Shiyan <shc_work@mail.ru> > Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> > --- > > This patch (and the next 7) could be applied independetly by this series, if > any, but I choosed to have it here since it makes easy the PWM modes parsing. > If you feel it could be independently of this series I could send a new version. > > Also, Thierry, Mike, Brian, Shiyan, please take an extra look over pwm-pxa.c, > pwm-cros-ec.c and pwm-clps711x.c since these were moved to use the generic > pwms (minimum 2 pwm-cells). > > drivers/pwm/core.c | 56 +++++++++++------------------------------- > drivers/pwm/pwm-atmel-hlcdc.c | 2 -- > drivers/pwm/pwm-atmel-tcb.c | 2 -- > drivers/pwm/pwm-atmel.c | 6 ----- > drivers/pwm/pwm-bcm-iproc.c | 2 -- > drivers/pwm/pwm-bcm-kona.c | 2 -- > drivers/pwm/pwm-bcm2835.c | 2 -- > drivers/pwm/pwm-berlin.c | 2 -- > drivers/pwm/pwm-clps711x.c | 11 --------- > drivers/pwm/pwm-cros-ec.c | 20 --------------- > drivers/pwm/pwm-fsl-ftm.c | 2 -- > drivers/pwm/pwm-hibvt.c | 2 -- > drivers/pwm/pwm-imx.c | 8 ------ > drivers/pwm/pwm-lpc18xx-sct.c | 2 -- > drivers/pwm/pwm-meson.c | 2 -- > drivers/pwm/pwm-omap-dmtimer.c | 2 -- > drivers/pwm/pwm-pxa.c | 19 -------------- > drivers/pwm/pwm-renesas-tpu.c | 2 -- > drivers/pwm/pwm-rockchip.c | 5 ---- > drivers/pwm/pwm-samsung.c | 3 --- > drivers/pwm/pwm-sun4i.c | 2 -- > drivers/pwm/pwm-tiecap.c | 2 -- > drivers/pwm/pwm-tiehrpwm.c | 2 -- > drivers/pwm/pwm-vt8500.c | 2 -- > drivers/pwm/pwm-zx.c | 2 -- > include/linux/pwm.h | 23 ++++++++++------- > 26 files changed, 29 insertions(+), 156 deletions(-) > [...] > diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c > index 0767deba8e62..6702fcc203ce 100644 > --- a/drivers/pwm/pwm-meson.c > +++ b/drivers/pwm/pwm-meson.c > @@ -535,8 +535,6 @@ static int meson_pwm_probe(struct platform_device *pdev) > meson->chip.ops = &meson_pwm_ops; > meson->chip.base = -1; > meson->chip.npwm = 2; > - meson->chip.of_xlate = of_pwm_xlate_with_flags; > - meson->chip.of_pwm_n_cells = 3; > > meson->data = of_device_get_match_data(&pdev->dev); > meson->inverter_mask = BIT(meson->chip.npwm) - 1; > diff --git a/drivers/pwm/pwm-omap-dmtimer.c b/drivers/pwm/pwm-omap-dmtimer.c > index 5ad42f33e70c..6bd32ae6dd3e 100644 > --- a/drivers/pwm/pwm-omap-dmtimer.c > +++ b/drivers/pwm/pwm-omap-dmtimer.c > @@ -317,8 +317,6 @@ static int pwm_omap_dmtimer_probe(struct platform_device *pdev) > omap->chip.ops = &pwm_omap_dmtimer_ops; > omap->chip.base = -1; > omap->chip.npwm = 1; > - omap->chip.of_xlate = of_pwm_xlate_with_flags; > - omap->chip.of_pwm_n_cells = 3; > > mutex_init(&omap->mutex); > [...] Hi Claudiu, Please avoid changing the device tree plumbing, this of_xlate fields are needed since some platforms will need to have their own translate functions. Moving a to single mandatory xlate function is going backward, a possible move would be to default to of_pwm_xlate_with_flags and 3 cells if of_xlate is NULL, or use the platforms xlate if provided. Moving to a single xlate function is unrelated to your needs and can break some platforms. Neil -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 16.01.2018 11:07, Neil Armstrong wrote: > On 12/01/2018 15:22, Claudiu Beznea wrote: >> Remove of_pwm_simple_xlate() and of_pwm_xlate_with_flags() functions >> and add of_pwm_xlate() which is used in all cases no mather if the OF >> bindings are with PWM flags or not. This should not affect the old >> behavior since the xlate will be based on #pwm-cells property of the >> PWM controller. Based on #pwm-cells property the xlate will consider >> the flags or not. This will permit the addition of other inputs to OF >> xlate by just adding proper code at the end of of_pwm_xlate() and a new >> input to enum pwm_args_xlate_options. With this changes there will be >> no need to fill of_xlate and of_pwm_n_cells of struct pwm_chip from >> the drivers probe methods. References in drives to references to of_xlate >> and of_pwm_n_cells were removed. Drivers which used private of_xlate >> functions switched to the generic of_pwm_xlate() function which fits >> for it but with little changes in device trees (these drivers translated >> differently the "pwms" bindings; the "pwms" bindings now are generic to >> all drivers and all drivers should provide them in the format described >> in pwm documentation). >> >> Cc: Thierry Reding <thierry.reding@gmail.com> >> Cc: Mike Dunn <mikedunn@newsguy.com> >> Cc: Brian Norris <briannorris@chromium.org> >> Cc: Alexander Shiyan <shc_work@mail.ru> >> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> >> --- >> >> This patch (and the next 7) could be applied independetly by this series, if >> any, but I choosed to have it here since it makes easy the PWM modes parsing. >> If you feel it could be independently of this series I could send a new version. >> >> Also, Thierry, Mike, Brian, Shiyan, please take an extra look over pwm-pxa.c, >> pwm-cros-ec.c and pwm-clps711x.c since these were moved to use the generic >> pwms (minimum 2 pwm-cells). >> >> drivers/pwm/core.c | 56 +++++++++++------------------------------- >> drivers/pwm/pwm-atmel-hlcdc.c | 2 -- >> drivers/pwm/pwm-atmel-tcb.c | 2 -- >> drivers/pwm/pwm-atmel.c | 6 ----- >> drivers/pwm/pwm-bcm-iproc.c | 2 -- >> drivers/pwm/pwm-bcm-kona.c | 2 -- >> drivers/pwm/pwm-bcm2835.c | 2 -- >> drivers/pwm/pwm-berlin.c | 2 -- >> drivers/pwm/pwm-clps711x.c | 11 --------- >> drivers/pwm/pwm-cros-ec.c | 20 --------------- >> drivers/pwm/pwm-fsl-ftm.c | 2 -- >> drivers/pwm/pwm-hibvt.c | 2 -- >> drivers/pwm/pwm-imx.c | 8 ------ >> drivers/pwm/pwm-lpc18xx-sct.c | 2 -- >> drivers/pwm/pwm-meson.c | 2 -- >> drivers/pwm/pwm-omap-dmtimer.c | 2 -- >> drivers/pwm/pwm-pxa.c | 19 -------------- >> drivers/pwm/pwm-renesas-tpu.c | 2 -- >> drivers/pwm/pwm-rockchip.c | 5 ---- >> drivers/pwm/pwm-samsung.c | 3 --- >> drivers/pwm/pwm-sun4i.c | 2 -- >> drivers/pwm/pwm-tiecap.c | 2 -- >> drivers/pwm/pwm-tiehrpwm.c | 2 -- >> drivers/pwm/pwm-vt8500.c | 2 -- >> drivers/pwm/pwm-zx.c | 2 -- >> include/linux/pwm.h | 23 ++++++++++------- >> 26 files changed, 29 insertions(+), 156 deletions(-) >> > > [...] >> diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c >> index 0767deba8e62..6702fcc203ce 100644 >> --- a/drivers/pwm/pwm-meson.c >> +++ b/drivers/pwm/pwm-meson.c >> @@ -535,8 +535,6 @@ static int meson_pwm_probe(struct platform_device *pdev) >> meson->chip.ops = &meson_pwm_ops; >> meson->chip.base = -1; >> meson->chip.npwm = 2; >> - meson->chip.of_xlate = of_pwm_xlate_with_flags; >> - meson->chip.of_pwm_n_cells = 3; >> >> meson->data = of_device_get_match_data(&pdev->dev); >> meson->inverter_mask = BIT(meson->chip.npwm) - 1; >> diff --git a/drivers/pwm/pwm-omap-dmtimer.c b/drivers/pwm/pwm-omap-dmtimer.c >> index 5ad42f33e70c..6bd32ae6dd3e 100644 >> --- a/drivers/pwm/pwm-omap-dmtimer.c >> +++ b/drivers/pwm/pwm-omap-dmtimer.c >> @@ -317,8 +317,6 @@ static int pwm_omap_dmtimer_probe(struct platform_device *pdev) >> omap->chip.ops = &pwm_omap_dmtimer_ops; >> omap->chip.base = -1; >> omap->chip.npwm = 1; >> - omap->chip.of_xlate = of_pwm_xlate_with_flags; >> - omap->chip.of_pwm_n_cells = 3; >> >> mutex_init(&omap->mutex); >> > [...] > > Hi Claudiu, > > Please avoid changing the device tree plumbing, this of_xlate fields are needed since > some platforms will need to have their own translate functions. > > Moving a to single mandatory xlate function is going backward, a possible move > would be to default to of_pwm_xlate_with_flags and 3 cells if of_xlate is NULL, > or use the platforms xlate if provided. > > Moving to a single xlate function is unrelated to your needs and can break some platforms. Hi Neil, Thank you for your feedback. Looking over the drivers I saw that only 3 drivers are using private of_xlate functions, the rest of them uses of_pwm_xlate_with_flags and of_pwm_simple_xlate function combined with pwm-cells binding and of_pwm_n_cells (which I think is redundant with pwm-cells). I though that switching to a common of_xlate to xlate everything based on pwm-cells binding value would be better and remove redundant code. But if this is a downward direction I agree to drop the changes related to of_xlate. Thanks, Claudiu > > Neil > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jan 16, 2018 at 10:24:59AM +0200, Claudiu Beznea wrote: > Please explain me further. From this I understand, as a general rule, > that the device tree binaries from, e.g. 3 years ago, should be > compatible with, e.g. the current version of kernel? Yes. https://www.kernel.org/doc/Documentation/devicetree/bindings/ABI.txt -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 18.01.2018 01:14, Brian Norris wrote: > On Tue, Jan 16, 2018 at 10:24:59AM +0200, Claudiu Beznea wrote: >> Please explain me further. From this I understand, as a general rule, >> that the device tree binaries from, e.g. 3 years ago, should be >> compatible with, e.g. the current version of kernel? > > Yes. > > https://www.kernel.org/doc/Documentation/devicetree/bindings/ABI.txt > I agree, I found that after some research. Thanks, Claudiu -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi all, Please give feedback on these patches which extends the PWM framework in order to support multiple PWM modes of operations. This series is a rework of [1]. The current patch series add the following PWM modes: - PWM mode normal - PWM mode complementary - PWM mode push-pull Normal mode - for PWM chips with one output per PWM channel; output waveforms looks like this: __ __ __ __ PWM __| |__| |__| |__| |__ <--T--> Complementary mode - for PWM chips with more than one output per PWM channel; output waveforms for a PWM controller with 2 outputs per PWM channel may looks line this: __ __ __ __ PWMH1 __| |__| |__| |__| |__ __ __ __ __ __ PWML1 |__| |__| |__| |__| <--T--> Where T is the signal period. Push-pull mode - for PWM chips with mode than one output per PWM channel; output waveform for a PWM controller with 2 outputs per PWM channel, in push-pull mode, with normal polarity looks like this: __ __ PWMH __| |________| |________ __ __ PWML ________| |________| |__ <--T--> If polarity is inversed: __ ________ ________ PWMH |__| |__| ________ ________ __ PWML |__| |__| <--T--> Where T is the signal period. Every PWM device from a PWM chip could be configured in the modes registered by PWM chip. For this, the PWM chip structure contains a field called caps which keeps the PWM modes. At probe time the PWM chip registers the supported modes and PWM devices could switch to the modes registered by PWM chips. For the moment, in my opinion, it is not neccessary to add a new hook in pwm_ops to go through the driver to check the capabilities of a single PWM device (as was proposed in [1]). I choosed to consider that a PWM controller with 2 outputs to also be capable to work in normal mode, since the outputs could be connected independently to other devices. If the drivers doesn't register any PWM capabilities the default capabilities will be used (currently, these includes PWM mode normal). These PWM mode could be configured via sysfs, or pwm_set_mode() + pwm_apply_state() (for driver clients), or via DT. In sysfs, user could check the PWM controller capabilities by reading modes file of PWM chip: root@sama5d2-xplained:/sys/class/pwm/pwmchip0# ls -l total 0 lrwxrwxrwx 1 root root 0 Oct 7 03:18 device -> ../../../f802c000.pwm --w------- 1 root root 4096 Oct 7 03:18 export -r--r--r-- 1 root root 4096 Oct 7 03:18 modes -r--r--r-- 1 root root 4096 Oct 7 03:18 npwm drwxr-xr-x 2 root root 0 Oct 7 03:18 power lrwxrwxrwx 1 root root 0 Oct 7 03:18 subsystem -> ../../../../../../../class/pwm -rw-r--r-- 1 root root 4096 Oct 7 01:20 uevent --w------- 1 root root 4096 Oct 7 03:18 unexport root@sama5d2-xplained:/sys/class/pwm/pwmchip0# cat modes normal complementary push-pull And the current capability of the PWM device could be checked as follows: root@sama5d2-xplained:/sys/class/pwm/pwmchip0/pwm1# ls -l -r--r--r-- 1 root root 4096 Feb 9 10:54 capture -rw-r--r-- 1 root root 4096 Feb 9 10:54 duty_cycle -rw-r--r-- 1 root root 4096 Feb 9 10:54 enable -rw-r--r-- 1 root root 4096 Feb 9 10:54 mode -rw-r--r-- 1 root root 4096 Feb 9 10:54 period -rw-r--r-- 1 root root 4096 Feb 9 10:55 polarity drwxr-xr-x 2 root root 0 Feb 9 10:54 power -rw-r--r-- 1 root root 4096 Feb 9 10:54 uevent root@sama5d2-xplained:/sys/class/pwm/pwmchip0/pwm1# cat mode normal The PWM push-pull mode could be usefull in applications like half bridge converters. This series also add support for PWM modes on atmel SAMA5D2 SoC. Thank you, Claudiu Beznea [1] https://www.spinics.net/lists/arm-kernel/msg580275.html Changes in v2: - remove of_xlate and of_pwm_n_cells and use generic functions to pharse DT inputs; this is done in patches 1, 2, 3, 4, 5, 6, 7 of this series; this will make easy the addition of PWM mode support from DT - add PWM mode normal - register PWM modes as capabilities of PWM chips at driver probe and, in case driver doesn't provide these capabilities use default ones - change the way PWM mode is pharsed via DT by using a new input for pwms binding property Claudiu Beznea (16): drivers: pwm: core: use a single of xlate function pwm: pxa: update documentation regarding pwm-cells pwm: cros-ec: update documentation regarding pwm-cells pwm: clps711x: update documentation regarding pwm-cells ARM: dts: clps711x: update pwm-cells ARM: dts: pxa: update pwm-cells arm64: dts: rockchip: update pwm-cells drivers: pwm: core: extend PWM framework with PWM modes drivers: pwm: core: add PWM mode to pwm_config() pwm: Add PWM modes pwm: add documentation for PWM modes pwm: atmel: add pwm capabilities drivers: pwm: core: add push-pull mode support pwm: add push-pull mode pwm: add documentation for pwm push-pull mode pwm: atmel: add push-pull mode support .../bindings/pwm/cirrus,clps711x-pwm.txt | 4 +- .../devicetree/bindings/pwm/google,cros-ec-pwm.txt | 4 +- Documentation/devicetree/bindings/pwm/pwm.txt | 23 ++++- Documentation/devicetree/bindings/pwm/pxa-pwm.txt | 6 +- Documentation/pwm.txt | 47 ++++++++- arch/arm/boot/dts/ep7209.dtsi | 2 +- arch/arm/boot/dts/pxa25x.dtsi | 4 +- arch/arm/boot/dts/pxa27x.dtsi | 8 +- arch/arm/boot/dts/pxa3xx.dtsi | 8 +- arch/arm/mach-s3c24xx/mach-rx1950.c | 5 +- arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 2 +- arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 2 +- drivers/bus/ts-nbus.c | 2 +- drivers/clk/clk-pwm.c | 3 +- drivers/gpu/drm/i915/intel_panel.c | 8 +- drivers/hwmon/pwm-fan.c | 2 +- drivers/input/misc/max77693-haptic.c | 2 +- drivers/input/misc/max8997_haptic.c | 3 +- drivers/leds/leds-pwm.c | 2 +- drivers/media/rc/ir-rx51.c | 2 +- drivers/media/rc/pwm-ir-tx.c | 2 +- drivers/pwm/core.c | 112 ++++++++++++++------- drivers/pwm/pwm-atmel-hlcdc.c | 2 - drivers/pwm/pwm-atmel-tcb.c | 2 - drivers/pwm/pwm-atmel.c | 100 ++++++++++++------ drivers/pwm/pwm-bcm-iproc.c | 2 - drivers/pwm/pwm-bcm-kona.c | 2 - drivers/pwm/pwm-bcm2835.c | 2 - drivers/pwm/pwm-berlin.c | 2 - drivers/pwm/pwm-clps711x.c | 11 -- drivers/pwm/pwm-cros-ec.c | 20 ---- drivers/pwm/pwm-fsl-ftm.c | 2 - drivers/pwm/pwm-hibvt.c | 2 - drivers/pwm/pwm-imx.c | 8 -- drivers/pwm/pwm-lpc18xx-sct.c | 2 - drivers/pwm/pwm-meson.c | 2 - drivers/pwm/pwm-omap-dmtimer.c | 2 - drivers/pwm/pwm-pxa.c | 19 ---- drivers/pwm/pwm-renesas-tpu.c | 2 - drivers/pwm/pwm-rockchip.c | 5 - drivers/pwm/pwm-samsung.c | 3 - drivers/pwm/pwm-sun4i.c | 2 - drivers/pwm/pwm-tiecap.c | 2 - drivers/pwm/pwm-tiehrpwm.c | 2 - drivers/pwm/pwm-vt8500.c | 2 - drivers/pwm/pwm-zx.c | 2 - drivers/pwm/sysfs.c | 64 ++++++++++++ drivers/video/backlight/lm3630a_bl.c | 2 +- drivers/video/backlight/lp855x_bl.c | 2 +- drivers/video/backlight/lp8788_bl.c | 2 +- drivers/video/backlight/pwm_bl.c | 4 +- drivers/video/fbdev/ssd1307fb.c | 3 +- include/dt-bindings/pwm/pwm.h | 4 + include/linux/pwm.h | 90 +++++++++++++++-- 54 files changed, 402 insertions(+), 222 deletions(-)