* [RCF PATCH v2 0/2] pwm: imx: Configure output to GPIO in disabled state @ 2018-10-10 9:33 Vokáč Michal 2018-10-10 9:33 ` [RCF PATCH v2 1/2] dt-bindings: pwm: imx: Allow switching PWM output between PWM and GPIO Vokáč Michal 2018-10-10 9:33 ` [RCF PATCH v2 2/2] pwm: imx: Configure output to GPIO in disabled state Vokáč Michal 0 siblings, 2 replies; 60+ messages in thread From: Vokáč Michal @ 2018-10-10 9:33 UTC (permalink / raw) To: Thierry Reding, Rob Herring Cc: Mark Rutland, devicetree, linux-pwm, linux-kernel, Lukasz Majewski, Fabio Estevam, Lothar Waßmann, Vokáč Michal This is an attempt to deal with i.MX SoC PWM HW limitation. When a pad is configured as a PWM output the output level is always 0V if the PWM block is disabled. This can cause problems when inverted PWM signal is needed to drive the connected circuit. With inverted output duty cycle = 0% corresponds to high output level and duty cycle = 100% corresponds to low output level. This means that whenever the PWM block is disabled the connected circuit is fed with 100% duty cycle. This issue has been discussed in various threads about inverted PWM support implementation. Finally this commit 326ed314fefe ("pwm: imx: Add polarity inversion support to i.MX's PWMv2") from Lukasz was merged. Later on Fabio came up with the same problem as I described. His commit 1f6eefeb7cd4 ("pwm: imx: Let PWM be active during suspend") solves the problem only in suspend state and not whenever PWM is disabled. In the discussion Fabio also suggested a pinctrl solution though it was still only for suspend [1]. I would like to bring attention to that pinctrl solution once again. The code is basically a copy of the I2C recovery function [2]. This binding is totally optional and current users are not affected. The idea is to use two new pinctrl states, "pwm" and "gpio", instead of the "default" pinctrl state. The gpio state is selected when PWM is disabled and the pwm pinctrl state is selected when PWM is enabled. In the gpio state level on the output is controlled by a new pwm-gpios signal. Note that there is no conflict with the "default" pinctrl state. You can actually define all the three states at the same time. The only effect is that the pinctl driver will configure the pins to the default pinctrl state as usual. Then when the imx-pwm driver gets control of the HW, it configures the right pinctrl state according to the PWM state. So you may end up with some additional level changes on the output during probe. When switching the pinctrl states it is important to do it in the right order. When disabling PWM, first set the GPIO output value, then change the muxing and at last disable the PWM. And vice versa to enable the PWM output. Otherwise you will get unwanted level changes on the output. I would like to know your opinion on this, thanks. Michal [1] https://patchwork.ozlabs.org/patch/839834/#1819865 [2] https://elixir.bootlin.com/linux/latest/source/drivers/i2c/busses/i2c-imx.c#L989 Changes in v2: - Do not use the "default" pinctrl state for GPIO. - Use extra "pwm" and "gpio" pinctrl states. - Add a pwm-gpios signal to drive the output in "gpio" pinctrl state. - Select the right pinctrl state in probe. Michal Vokáč (2): dt-bindings: pwm: imx: Allow switching PWM output between PWM and GPIO pwm: imx: Configure output to GPIO in disabled state Documentation/devicetree/bindings/pwm/imx-pwm.txt | 51 ++++++++++++++ drivers/pwm/pwm-imx.c | 86 +++++++++++++++++++++++ 2 files changed, 137 insertions(+) -- 2.1.4 ^ permalink raw reply [flat|nested] 60+ messages in thread
* [RCF PATCH v2 1/2] dt-bindings: pwm: imx: Allow switching PWM output between PWM and GPIO 2018-10-10 9:33 [RCF PATCH v2 0/2] pwm: imx: Configure output to GPIO in disabled state Vokáč Michal @ 2018-10-10 9:33 ` Vokáč Michal 2018-10-10 13:39 ` Thierry Reding 2018-10-10 9:33 ` [RCF PATCH v2 2/2] pwm: imx: Configure output to GPIO in disabled state Vokáč Michal 1 sibling, 1 reply; 60+ messages in thread From: Vokáč Michal @ 2018-10-10 9:33 UTC (permalink / raw) To: Thierry Reding, Rob Herring Cc: Mark Rutland, devicetree, linux-pwm, linux-kernel, Lukasz Majewski, Fabio Estevam, Lothar Waßmann, Vokáč Michal Output of the PWM block on i.MX SoCs is always low when the block is disabled. This can cause issues when inverted PWM polarity is needed. With inverted polarity a duty cycle = 0% corresponds to high level on the output. Now, when PWM is disabled its output instantly goes low which corresponds to duty cycle = 100%. To get a truly inverted PWM output two pinctrl states of the PWM pin can be used. Configure the pin to GPIO function when PWM is disabled and switch back to PWM function whenever non-zero duty cycle is needed. Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com> --- Changes in v2: - Do not use the "default" pinctrl state for GPIO. - Use two new "pwm" and "gpio" pinctrl states. - Add a new pwm-gpios signal. Documentation/devicetree/bindings/pwm/imx-pwm.txt | 51 +++++++++++++++++++++++ 1 file changed, 51 insertions(+) diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.txt b/Documentation/devicetree/bindings/pwm/imx-pwm.txt index c61bdf8..bd5b6bd 100644 --- a/Documentation/devicetree/bindings/pwm/imx-pwm.txt +++ b/Documentation/devicetree/bindings/pwm/imx-pwm.txt @@ -14,6 +14,17 @@ See the clock consumer binding, Documentation/devicetree/bindings/clock/clock-bindings.txt - interrupts: The interrupt for the pwm controller +Optional properties: +- pinctrl: For i.MX27 and newer SoCs. Use "pwm" and "gpio" specific pinctrls + instead of the "default" to configure the PWM pin to GPIO and PWM function. + It allows control over the pin output level when the PWM block is disabled. + This is useful if you use the PWM for single purpose and you need inverted + polarity of the PWM signal. See "Inverted PWM output" section bellow. +- pwm-gpios: Specify the GPIO pin that will act as the PWM output. This should + be the same pin as is used for normal PWM output. Define the pin as + GPIO_ACTIVE_LOW to get HIGH level on the output when PWM is disabled. See + "Inverted PWM output" section bellow. + Example: pwm1: pwm@53fb4000 { @@ -25,3 +36,43 @@ pwm1: pwm@53fb4000 { clock-names = "ipg", "per"; interrupts = <61>; }; + +Inverted PWM output +------------------- + +The i.MX SoC has such limitation that whenever a pin is configured as a PWM +output, the output level on the pin is always low when the PWM block is +disabled. The low output level is actively driven by the output stage of the +PWM block and can not be overridden by pull-up. It also does not matter what +PWM polarity a PWM client (e.g. backlight) requested. + +To gain control of the output level in PWM disabled state two pinctrl states +can be used. A "gpio" state and a "pwm" state. In the gpio state the pin is +configured as a GPIO. In the pwm state the pin is configured as a normal PWM +output. In the gpio state the output level can be controlled by actively +driving the output by the pwm-gpios signal. This setup assures that the PWM +output is at the required level that corresponds to duty cycle = 0 when PWM +is disabled. + +Example: + +&pwm1 { + pinctrl-names = "pwm", "gpio"; + pinctrl-0 = <&pinctrl_backlight_pwm>; + pinctrl-1 = <&pinctrl_backlight_gpio>; + pwm-gpios = <&gpio1 9 GPIO_ACTIVE_LOW> +} + +pinctrl_backlight_gpio: pwm1grp-gpio { + fsl,pins = < + /* GPIO with 100kOhm pull-up */ + MX6QDL_PAD_GPIO_9__GPIO1_IO09 0xb000 + >; +}; + +pinctrl_backlight_pwm: pwm1grp-pwm { + fsl,pins = < + /* PWM output */ + MX6QDL_PAD_GPIO_9__PWM1_OUT 0x8 + >; +}; -- 2.1.4 ^ permalink raw reply related [flat|nested] 60+ messages in thread
* Re: [RCF PATCH v2 1/2] dt-bindings: pwm: imx: Allow switching PWM output between PWM and GPIO 2018-10-10 9:33 ` [RCF PATCH v2 1/2] dt-bindings: pwm: imx: Allow switching PWM output between PWM and GPIO Vokáč Michal @ 2018-10-10 13:39 ` Thierry Reding 2018-10-29 15:52 ` Vokáč Michal 0 siblings, 1 reply; 60+ messages in thread From: Thierry Reding @ 2018-10-10 13:39 UTC (permalink / raw) To: Vokáč Michal Cc: Rob Herring, Mark Rutland, devicetree, linux-pwm, linux-kernel, Lukasz Majewski, Fabio Estevam, Lothar Waßmann [-- Attachment #1: Type: text/plain, Size: 3360 bytes --] On Wed, Oct 10, 2018 at 09:33:25AM +0000, Vokáč Michal wrote: > Output of the PWM block on i.MX SoCs is always low when the block is > disabled. This can cause issues when inverted PWM polarity is needed. > With inverted polarity a duty cycle = 0% corresponds to high level on > the output. Now, when PWM is disabled its output instantly goes low > which corresponds to duty cycle = 100%. > > To get a truly inverted PWM output two pinctrl states of the PWM pin > can be used. Configure the pin to GPIO function when PWM is disabled > and switch back to PWM function whenever non-zero duty cycle is needed. > > Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com> > --- > Changes in v2: > - Do not use the "default" pinctrl state for GPIO. > - Use two new "pwm" and "gpio" pinctrl states. > - Add a new pwm-gpios signal. > > Documentation/devicetree/bindings/pwm/imx-pwm.txt | 51 +++++++++++++++++++++++ > 1 file changed, 51 insertions(+) > > diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.txt b/Documentation/devicetree/bindings/pwm/imx-pwm.txt > index c61bdf8..bd5b6bd 100644 > --- a/Documentation/devicetree/bindings/pwm/imx-pwm.txt > +++ b/Documentation/devicetree/bindings/pwm/imx-pwm.txt > @@ -14,6 +14,17 @@ See the clock consumer binding, > Documentation/devicetree/bindings/clock/clock-bindings.txt > - interrupts: The interrupt for the pwm controller > > +Optional properties: > +- pinctrl: For i.MX27 and newer SoCs. Use "pwm" and "gpio" specific pinctrls > + instead of the "default" to configure the PWM pin to GPIO and PWM function. > + It allows control over the pin output level when the PWM block is disabled. > + This is useful if you use the PWM for single purpose and you need inverted > + polarity of the PWM signal. See "Inverted PWM output" section bellow. > +- pwm-gpios: Specify the GPIO pin that will act as the PWM output. This should > + be the same pin as is used for normal PWM output. Define the pin as > + GPIO_ACTIVE_LOW to get HIGH level on the output when PWM is disabled. See > + "Inverted PWM output" section bellow. It's somewhat unfortunate that we have to specify this in DT. For one thing, we don't really want to use the pin as GPIO, we really only care about whether it is "active" or "inactive". We also already specify the GPIO in the pinctrl nodes, albeit via a different name. So we're effectively duplicating information here. It'd be nice to avoid that. Two possibilities that I could think about are: 1) Do not explicitly rely on driving the GPIO as output: I know this was discussed before and it sounds like this is not an option for PWM because the GPIO may be configured as output by the firmware, and hence switching to GPIO mode may not give the expected result. I suppose one way to solve this is by using a gpio-hog entry for the PWM GPIO so that it will automatically get configured as an input and at the same time marked as busy so that nobody can go and just request it again (via sysfs for example). 2) Derive the GPIO from the pin. I'm not sure there's anything in the pinctrl framework to do that. The reverse (GPIO -> pin) can be done, so perhaps this is something that could be added? Other than than I think this looks very nice. Thierry [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH v2 1/2] dt-bindings: pwm: imx: Allow switching PWM output between PWM and GPIO 2018-10-10 13:39 ` Thierry Reding @ 2018-10-29 15:52 ` Vokáč Michal 0 siblings, 0 replies; 60+ messages in thread From: Vokáč Michal @ 2018-10-29 15:52 UTC (permalink / raw) To: Thierry Reding Cc: Rob Herring, Mark Rutland, devicetree, linux-pwm, linux-kernel, Lukasz Majewski, Fabio Estevam, Lothar Waßmann On 10.10.2018 15:39, Thierry Reding wrote: > On Wed, Oct 10, 2018 at 09:33:25AM +0000, Vokáč Michal wrote: >> Output of the PWM block on i.MX SoCs is always low when the block is >> disabled. This can cause issues when inverted PWM polarity is needed. >> With inverted polarity a duty cycle = 0% corresponds to high level on >> the output. Now, when PWM is disabled its output instantly goes low >> which corresponds to duty cycle = 100%. >> >> To get a truly inverted PWM output two pinctrl states of the PWM pin >> can be used. Configure the pin to GPIO function when PWM is disabled >> and switch back to PWM function whenever non-zero duty cycle is needed. >> >> Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com> >> --- >> Changes in v2: >> - Do not use the "default" pinctrl state for GPIO. >> - Use two new "pwm" and "gpio" pinctrl states. >> - Add a new pwm-gpios signal. >> >> Documentation/devicetree/bindings/pwm/imx-pwm.txt | 51 +++++++++++++++++++++++ >> 1 file changed, 51 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.txt b/Documentation/devicetree/bindings/pwm/imx-pwm.txt >> index c61bdf8..bd5b6bd 100644 >> --- a/Documentation/devicetree/bindings/pwm/imx-pwm.txt >> +++ b/Documentation/devicetree/bindings/pwm/imx-pwm.txt >> @@ -14,6 +14,17 @@ See the clock consumer binding, >> Documentation/devicetree/bindings/clock/clock-bindings.txt >> - interrupts: The interrupt for the pwm controller >> >> +Optional properties: >> +- pinctrl: For i.MX27 and newer SoCs. Use "pwm" and "gpio" specific pinctrls >> + instead of the "default" to configure the PWM pin to GPIO and PWM function. >> + It allows control over the pin output level when the PWM block is disabled. >> + This is useful if you use the PWM for single purpose and you need inverted >> + polarity of the PWM signal. See "Inverted PWM output" section bellow. >> +- pwm-gpios: Specify the GPIO pin that will act as the PWM output. This should >> + be the same pin as is used for normal PWM output. Define the pin as >> + GPIO_ACTIVE_LOW to get HIGH level on the output when PWM is disabled. See >> + "Inverted PWM output" section bellow. > > It's somewhat unfortunate that we have to specify this in DT. For one > thing, we don't really want to use the pin as GPIO, we really only care > about whether it is "active" or "inactive". We also already specify the > GPIO in the pinctrl nodes, albeit via a different name. So we're > effectively duplicating information here. It'd be nice to avoid that. From reading the pinctrl binding doc I understand that you can specify as much pinctrl states as you need to configure a pin appropriately for different "use cases". Eg. init, sleep, default, tx, rx ... as all might need different pull-up/down and DSE configuration. So I did not think this might be considered "duplicating information". > Two possibilities that I could think about are: > > 1) Do not explicitly rely on driving the GPIO as output: I know this > was discussed before and it sounds like this is not an option for > PWM because the GPIO may be configured as output by the firmware, > and hence switching to GPIO mode may not give the expected result. I think it is actually possible. Previously I only saw two extremes. No GPIO at all (only the pinctrl states) or full GPIO control including driving the output. But once we request the GPIO as an input with devm_gpiod_get_optional(&pdev->dev, "pwm", GPIOD_IN); it will be configured as input regardless what state it was left in from bootloader. And hence the pull-up/down setting from DTS will be applied. > I suppose one way to solve this is by using a gpio-hog entry for > the PWM GPIO so that it will automatically get configured as an > input and at the same time marked as busy so that nobody can go > and just request it again (via sysfs for example). I think this is still valid in the case I described above - nobody else can request that pin once we acquire it in pwm-imx. > 2) Derive the GPIO from the pin. I'm not sure there's anything in the > pinctrl framework to do that. The reverse (GPIO -> pin) can be > done, so perhaps this is something that could be added? I can look at that option if you really want but I would like to avoid doing that. > Other than than I think this looks very nice. Thanks. Would you prefer RFC v3 or non-RFC v1 when I respin? Best regards, Michal ^ permalink raw reply [flat|nested] 60+ messages in thread
* [RCF PATCH v2 2/2] pwm: imx: Configure output to GPIO in disabled state 2018-10-10 9:33 [RCF PATCH v2 0/2] pwm: imx: Configure output to GPIO in disabled state Vokáč Michal 2018-10-10 9:33 ` [RCF PATCH v2 1/2] dt-bindings: pwm: imx: Allow switching PWM output between PWM and GPIO Vokáč Michal @ 2018-10-10 9:33 ` Vokáč Michal 2018-10-12 8:57 ` [RCF PATCH,v2,2/2] " Uwe Kleine-König 2018-10-12 16:00 ` [RCF PATCH v2 2/2] " Thierry Reding 1 sibling, 2 replies; 60+ messages in thread From: Vokáč Michal @ 2018-10-10 9:33 UTC (permalink / raw) To: Thierry Reding, Rob Herring Cc: Mark Rutland, devicetree, linux-pwm, linux-kernel, Lukasz Majewski, Fabio Estevam, Lothar Waßmann, Vokáč Michal Normally the PWM output is held LOW when PWM is disabled. This can cause problems when inverted PWM signal polarity is needed. With this behavior the connected circuit is fed by 100% duty cycle instead of being shut-off. Allow users to define a "gpio" and a "pwm" pinctrl states. The pwm pinctrl state is then selected when PWM is enabled and the gpio pinctrl state is selected when PWM is disabled. Also add a new pwm-gpios GPIO that is used to drive the output in the gpio state. If all the pinctrl states and the pwm-gpios are not correctly specified in DT the logic will work as before. As an example, with this patch a PWM controlled backlight with inversed signal polarity can be used in full brightness range. Without this patch the backlight can not be turned off as brightness = 0 disables the PWM and that in turn set PWM output LOW, that is full brightness. Output of the PWM with "default" pinctrl and with "pwm"+"gpio" pinctrl: +--------------+------------+---------------+---------------------------+ | After reset | Bootloader | Linux pinctrl | User (sysfs, backlight..) | | 100k pull-up | (not used) | | enable | disable | +--------------+------------+---------------+---------------------------+ ___________________________ default _ _ _ |_________________| |_| |_| |_|_____________ pwm + gpio ___________________________________________ _ _ _ _____________ |_| |_| |_| |_| Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com> --- Changes in v2: - Utilize the "pwm" and "gpio" pinctrl states. - Use the pwm-gpios signal to drive the output in "gpio" pinctrl state. - Select the right pinctrl state in probe. drivers/pwm/pwm-imx.c | 86 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 86 insertions(+) diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c index 6cd3b72..3502123 100644 --- a/drivers/pwm/pwm-imx.c +++ b/drivers/pwm/pwm-imx.c @@ -10,11 +10,13 @@ #include <linux/clk.h> #include <linux/delay.h> #include <linux/err.h> +#include <linux/gpio/consumer.h> #include <linux/io.h> #include <linux/kernel.h> #include <linux/module.h> #include <linux/of.h> #include <linux/of_device.h> +#include <linux/pinctrl/consumer.h> #include <linux/platform_device.h> #include <linux/pwm.h> #include <linux/slab.h> @@ -92,10 +94,45 @@ struct imx_chip { void __iomem *mmio_base; struct pwm_chip chip; + + struct pinctrl *pinctrl; + struct pinctrl_state *pinctrl_pins_gpio; + struct pinctrl_state *pinctrl_pins_pwm; + struct gpio_desc *pwm_gpiod; }; + #define to_imx_chip(chip) container_of(chip, struct imx_chip, chip) +static int imx_pwm_init_pinctrl_info(struct imx_chip *imx_chip, + struct platform_device *pdev) +{ + imx_chip->pinctrl = devm_pinctrl_get(&pdev->dev); + if (!imx_chip->pinctrl || IS_ERR(imx_chip->pinctrl)) { + dev_info(&pdev->dev, "can not get pinctrl\n"); + return PTR_ERR(imx_chip->pinctrl); + } + + imx_chip->pinctrl_pins_pwm = pinctrl_lookup_state(imx_chip->pinctrl, + "pwm"); + imx_chip->pinctrl_pins_gpio = pinctrl_lookup_state(imx_chip->pinctrl, + "gpio"); + imx_chip->pwm_gpiod = devm_gpiod_get_optional(&pdev->dev, "pwm", + GPIOD_IN); + + if (PTR_ERR(imx_chip->pwm_gpiod) == -EPROBE_DEFER) { + return -EPROBE_DEFER; + } else if (IS_ERR(imx_chip->pwm_gpiod) || + IS_ERR(imx_chip->pinctrl_pins_pwm) || + IS_ERR(imx_chip->pinctrl_pins_gpio)) { + dev_dbg(&pdev->dev, "PWM pinctrl information incomplete\n"); + devm_pinctrl_put(imx_chip->pinctrl); + imx_chip->pinctrl = NULL; + } + + return 0; +} + static void imx_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm, struct pwm_state *state) { @@ -306,7 +343,31 @@ static int imx_pwm_apply_v2(struct pwm_chip *chip, struct pwm_device *pwm, MX3_PWMCR_POUTC_INVERTED); writel(cr, imx->mmio_base + MX3_PWMCR); + + /* + * If we are in charge of pinctrl then switch output to + * the PWM signal. + */ + if (imx->pinctrl) + pinctrl_select_state(imx->pinctrl, + imx->pinctrl_pins_pwm); } else if (cstate.enabled) { + /* + * PWM block will be disabled. Normally its output will be set + * low no matter what output polarity is configured. Lets use + * pinctrl to switch the output pin to GPIO functon and keep + * the output at the same level as for duty-cycle = 0. + * + * First set the GPIO to the desired level, then switch the + * muxing and at last disable PWM. In that order we do not get + * unwanted logic level changes on the output. + */ + if (imx->pinctrl) { + gpiod_set_value_cansleep(imx->pwm_gpiod, 0); + pinctrl_select_state(imx->pinctrl, + imx->pinctrl_pins_gpio); + } + writel(0, imx->mmio_base + MX3_PWMCR); clk_disable_unprepare(imx->clk_per); @@ -354,6 +415,7 @@ static int imx_pwm_probe(struct platform_device *pdev) const struct of_device_id *of_id = of_match_device(imx_pwm_dt_ids, &pdev->dev); const struct imx_pwm_data *data; + struct pwm_state cstate; struct imx_chip *imx; struct resource *r; int ret = 0; @@ -385,6 +447,10 @@ static int imx_pwm_probe(struct platform_device *pdev) imx->chip.of_pwm_n_cells = 3; } + ret = imx_pwm_init_pinctrl_info(imx, pdev); + if (ret) + return ret; + r = platform_get_resource(pdev, IORESOURCE_MEM, 0); imx->mmio_base = devm_ioremap_resource(&pdev->dev, r); if (IS_ERR(imx->mmio_base)) @@ -394,6 +460,26 @@ static int imx_pwm_probe(struct platform_device *pdev) if (ret < 0) return ret; + if (imx->pinctrl) { + /* + * Update cstate after pwmchip_add() call as the core might + * call the get_state() function to read the PWM registers + * to get the actual HW state. + */ + pwm_get_state(imx->chip.pwms, &cstate); + if (cstate.enabled) { + dev_dbg(&pdev->dev, + "PWM entered probe in enabled state\n"); + pinctrl_select_state(imx->pinctrl, + imx->pinctrl_pins_pwm); + } else { + gpiod_set_value_cansleep(imx->pwm_gpiod, 0); + pinctrl_select_state(imx->pinctrl, + imx->pinctrl_pins_gpio); + + } + } + platform_set_drvdata(pdev, imx); return 0; } -- 2.1.4 ^ permalink raw reply related [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-10-10 9:33 ` [RCF PATCH v2 2/2] pwm: imx: Configure output to GPIO in disabled state Vokáč Michal @ 2018-10-12 8:57 ` Uwe Kleine-König 2018-10-12 15:04 ` Vokáč Michal 2018-10-12 16:00 ` [RCF PATCH v2 2/2] " Thierry Reding 1 sibling, 1 reply; 60+ messages in thread From: Uwe Kleine-König @ 2018-10-12 8:57 UTC (permalink / raw) To: Vokáč Michal Cc: Thierry Reding, Rob Herring, Mark Rutland, devicetree, linux-pwm, linux-kernel, Lukasz Majewski, Fabio Estevam, Lothar Waßmann, kernel [-- Attachment #1: Type: text/plain, Size: 8535 bytes --] Hello, On Wed, Oct 10, 2018 at 09:33:26AM +0000, Vokáč Michal wrote: > Normally the PWM output is held LOW when PWM is disabled. This can cause > problems when inverted PWM signal polarity is needed. With this behavior > the connected circuit is fed by 100% duty cycle instead of being shut-off. > > Allow users to define a "gpio" and a "pwm" pinctrl states. The pwm pinctrl > state is then selected when PWM is enabled and the gpio pinctrl state is > selected when PWM is disabled. Also add a new pwm-gpios GPIO that is used > to drive the output in the gpio state. > > If all the pinctrl states and the pwm-gpios are not correctly specified > in DT the logic will work as before. > > As an example, with this patch a PWM controlled backlight with inversed > signal polarity can be used in full brightness range. Without this patch > the backlight can not be turned off as brightness = 0 disables the PWM > and that in turn set PWM output LOW, that is full brightness. > > Output of the PWM with "default" pinctrl and with "pwm"+"gpio" pinctrl: > > +--------------+------------+---------------+---------------------------+ > | After reset | Bootloader | Linux pinctrl | User (sysfs, backlight..) | > | 100k pull-up | (not used) | | enable | disable | > +--------------+------------+---------------+---------------------------+ > ___________________________ default _ _ _ > |_________________| |_| |_| |_|_____________ > > pwm + gpio > ___________________________________________ _ _ _ _____________ > |_| |_| |_| |_| I was made aware of this patch by Thierry while discussion about a patch opportunity. I already pointed out some stuff I don't like about this patch in the repective thread, but I repeat it here to have it at the right place. > Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com> > --- > Changes in v2: > - Utilize the "pwm" and "gpio" pinctrl states. > - Use the pwm-gpios signal to drive the output in "gpio" pinctrl state. > - Select the right pinctrl state in probe. > > drivers/pwm/pwm-imx.c | 86 +++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 86 insertions(+) > > diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c > index 6cd3b72..3502123 100644 > --- a/drivers/pwm/pwm-imx.c > +++ b/drivers/pwm/pwm-imx.c > @@ -10,11 +10,13 @@ > #include <linux/clk.h> > #include <linux/delay.h> > #include <linux/err.h> > +#include <linux/gpio/consumer.h> > #include <linux/io.h> > #include <linux/kernel.h> > #include <linux/module.h> > #include <linux/of.h> > #include <linux/of_device.h> > +#include <linux/pinctrl/consumer.h> > #include <linux/platform_device.h> > #include <linux/pwm.h> > #include <linux/slab.h> > @@ -92,10 +94,45 @@ struct imx_chip { > void __iomem *mmio_base; > > struct pwm_chip chip; > + > + struct pinctrl *pinctrl; > + struct pinctrl_state *pinctrl_pins_gpio; > + struct pinctrl_state *pinctrl_pins_pwm; > + struct gpio_desc *pwm_gpiod; The pinctrl framework already knows about "init" and "default". These should be enough. i.e. "init" configures as gpio and "default" als pwm. > }; > > + > #define to_imx_chip(chip) container_of(chip, struct imx_chip, chip) > > +static int imx_pwm_init_pinctrl_info(struct imx_chip *imx_chip, > + struct platform_device *pdev) > +{ > + imx_chip->pinctrl = devm_pinctrl_get(&pdev->dev); > + if (!imx_chip->pinctrl || IS_ERR(imx_chip->pinctrl)) { > + dev_info(&pdev->dev, "can not get pinctrl\n"); > + return PTR_ERR(imx_chip->pinctrl); > + } > + > + imx_chip->pinctrl_pins_pwm = pinctrl_lookup_state(imx_chip->pinctrl, > + "pwm"); > + imx_chip->pinctrl_pins_gpio = pinctrl_lookup_state(imx_chip->pinctrl, > + "gpio"); > + imx_chip->pwm_gpiod = devm_gpiod_get_optional(&pdev->dev, "pwm", > + GPIOD_IN); > + > + if (PTR_ERR(imx_chip->pwm_gpiod) == -EPROBE_DEFER) { You must not use PTR_ERR on a value that might not contain an error pointer. > + return -EPROBE_DEFER; > + } else if (IS_ERR(imx_chip->pwm_gpiod) || > + IS_ERR(imx_chip->pinctrl_pins_pwm) || > + IS_ERR(imx_chip->pinctrl_pins_gpio)) { Would it be more correct to handle imx_chip->pinctrl_pins_pwm == ERR_PTR(-EPROBE_DEFER) similar to imx_chip->pwm_gpiod == ERR_PTR(-EPROBE_DEFER)? > + dev_dbg(&pdev->dev, "PWM pinctrl information incomplete\n"); I wouldn't call that "incomplete". It's incomplete for the gpio switching trick, but enough in general. > + devm_pinctrl_put(imx_chip->pinctrl); > + imx_chip->pinctrl = NULL; > + } > + > + return 0; > +} > + > static void imx_pwm_get_state(struct pwm_chip *chip, > struct pwm_device *pwm, struct pwm_state *state) > { > @@ -306,7 +343,31 @@ static int imx_pwm_apply_v2(struct pwm_chip *chip, struct pwm_device *pwm, > MX3_PWMCR_POUTC_INVERTED); > > writel(cr, imx->mmio_base + MX3_PWMCR); > + > + /* > + * If we are in charge of pinctrl then switch output to > + * the PWM signal. > + */ > + if (imx->pinctrl) > + pinctrl_select_state(imx->pinctrl, > + imx->pinctrl_pins_pwm); > } else if (cstate.enabled) { > + /* > + * PWM block will be disabled. Normally its output will be set > + * low no matter what output polarity is configured. Lets use s/Lets/Let's/ > + * pinctrl to switch the output pin to GPIO functon and keep > + * the output at the same level as for duty-cycle = 0. Is it obvious that using a GPIO is more efficient/better/worth the complexity than just enabling the PWM with duty-cycle 0 and the right polarity? > + * First set the GPIO to the desired level, then switch the > + * muxing and at last disable PWM. In that order we do not get > + * unwanted logic level changes on the output. > + */ > + if (imx->pinctrl) { > + gpiod_set_value_cansleep(imx->pwm_gpiod, 0); You must call gpiod_direction_output for this to have any effect. There might be mechanisms in pincontrol that automatically mux the pin if it's configured as gpio, I didn't follow the details though. Also it should be possible to configure the GPIO as output immediatly. If the pinmuxing is set to the PWM function this doesn't have a visible side effect. > + pinctrl_select_state(imx->pinctrl, > + imx->pinctrl_pins_gpio); Usually align function arguments to the opening (. > + } > + > writel(0, imx->mmio_base + MX3_PWMCR); > > clk_disable_unprepare(imx->clk_per); > @@ -354,6 +415,7 @@ static int imx_pwm_probe(struct platform_device *pdev) > const struct of_device_id *of_id = > of_match_device(imx_pwm_dt_ids, &pdev->dev); > const struct imx_pwm_data *data; > + struct pwm_state cstate; > struct imx_chip *imx; > struct resource *r; > int ret = 0; > @@ -385,6 +447,10 @@ static int imx_pwm_probe(struct platform_device *pdev) > imx->chip.of_pwm_n_cells = 3; > } > > + ret = imx_pwm_init_pinctrl_info(imx, pdev); > + if (ret) > + return ret; > + > r = platform_get_resource(pdev, IORESOURCE_MEM, 0); > imx->mmio_base = devm_ioremap_resource(&pdev->dev, r); > if (IS_ERR(imx->mmio_base)) > @@ -394,6 +460,26 @@ static int imx_pwm_probe(struct platform_device *pdev) > if (ret < 0) > return ret; > > + if (imx->pinctrl) { > + /* > + * Update cstate after pwmchip_add() call as the core might > + * call the get_state() function to read the PWM registers > + * to get the actual HW state. > + */ > + pwm_get_state(imx->chip.pwms, &cstate); > + if (cstate.enabled) { > + dev_dbg(&pdev->dev, > + "PWM entered probe in enabled state\n"); > + pinctrl_select_state(imx->pinctrl, > + imx->pinctrl_pins_pwm); > + } else { > + gpiod_set_value_cansleep(imx->pwm_gpiod, 0); > + pinctrl_select_state(imx->pinctrl, > + imx->pinctrl_pins_gpio); > + > + } > + } > + > platform_set_drvdata(pdev, imx); > return 0; > } There is nothing in this patch that would prevent this code to live in a place where other drivers could reuse this. (But attention, there are dragons: Thierry already replied on my topic that his view is different in this aspect compared to other maintainers though. His POV is that as long as there is only a single driver known that has a problem this should be handled in driver specific code.) Best regards Uwe [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-10-12 8:57 ` [RCF PATCH,v2,2/2] " Uwe Kleine-König @ 2018-10-12 15:04 ` Vokáč Michal 2018-10-12 15:54 ` Thierry Reding 2018-10-12 16:08 ` Uwe Kleine-König 0 siblings, 2 replies; 60+ messages in thread From: Vokáč Michal @ 2018-10-12 15:04 UTC (permalink / raw) To: Uwe Kleine-König Cc: Thierry Reding, Rob Herring, Mark Rutland, devicetree, linux-pwm, linux-kernel, Lukasz Majewski, Fabio Estevam, Lothar Waßmann, kernel On 12.10.2018 10:57, Uwe Kleine-König wrote: > Hello, > > On Wed, Oct 10, 2018 at 09:33:26AM +0000, Vokáč Michal wrote: >> Normally the PWM output is held LOW when PWM is disabled. This can cause >> problems when inverted PWM signal polarity is needed. With this behavior >> the connected circuit is fed by 100% duty cycle instead of being shut-off. >> >> Allow users to define a "gpio" and a "pwm" pinctrl states. The pwm pinctrl >> state is then selected when PWM is enabled and the gpio pinctrl state is >> selected when PWM is disabled. Also add a new pwm-gpios GPIO that is used >> to drive the output in the gpio state. >> >> If all the pinctrl states and the pwm-gpios are not correctly specified >> in DT the logic will work as before. >> >> As an example, with this patch a PWM controlled backlight with inversed >> signal polarity can be used in full brightness range. Without this patch >> the backlight can not be turned off as brightness = 0 disables the PWM >> and that in turn set PWM output LOW, that is full brightness. >> >> Output of the PWM with "default" pinctrl and with "pwm"+"gpio" pinctrl: >> >> +--------------+------------+---------------+---------------------------+ >> | After reset | Bootloader | Linux pinctrl | User (sysfs, backlight..) | >> | 100k pull-up | (not used) | | enable | disable | >> +--------------+------------+---------------+---------------------------+ >> ___________________________ default _ _ _ >> |_________________| |_| |_| |_|_____________ >> >> pwm + gpio >> ___________________________________________ _ _ _ _____________ >> |_| |_| |_| |_| > > I was made aware of this patch by Thierry while discussion about a patch > opportunity. I already pointed out some stuff I don't like about this > patch in the repective thread, but I repeat it here to have it at the > right place. Thank you for taking time to comment on this one as well Uwe. >> Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com> >> --- >> Changes in v2: >> - Utilize the "pwm" and "gpio" pinctrl states. >> - Use the pwm-gpios signal to drive the output in "gpio" pinctrl state. >> - Select the right pinctrl state in probe. >> >> drivers/pwm/pwm-imx.c | 86 +++++++++++++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 86 insertions(+) >> >> diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c >> index 6cd3b72..3502123 100644 >> --- a/drivers/pwm/pwm-imx.c >> +++ b/drivers/pwm/pwm-imx.c >> @@ -10,11 +10,13 @@ >> #include <linux/clk.h> >> #include <linux/delay.h> >> #include <linux/err.h> >> +#include <linux/gpio/consumer.h> >> #include <linux/io.h> >> #include <linux/kernel.h> >> #include <linux/module.h> >> #include <linux/of.h> >> #include <linux/of_device.h> >> +#include <linux/pinctrl/consumer.h> >> #include <linux/platform_device.h> >> #include <linux/pwm.h> >> #include <linux/slab.h> >> @@ -92,10 +94,45 @@ struct imx_chip { >> void __iomem *mmio_base; >> >> struct pwm_chip chip; >> + >> + struct pinctrl *pinctrl; >> + struct pinctrl_state *pinctrl_pins_gpio; >> + struct pinctrl_state *pinctrl_pins_pwm; >> + struct gpio_desc *pwm_gpiod; > > The pinctrl framework already knows about "init" and "default". These > should be enough. i.e. "init" configures as gpio and "default" als pwm. That is totally new information for me. I've never seen any usage of "init" pinctrl state before. The total number of users is 6 (rockchip) so that explains a lot. I think that it would not work though. The basic idea behind my solution is that the pinctrl driver does not know what is the correct pin configuration at probe whereas the pwm-imx driver does. With the "init" and "default" states the pinctrl driver will always select the "default" if it find the pins in "init" state. https://elixir.bootlin.com/linux/latest/source/drivers/pinctrl/core.c#L1469 But we want the pins to stay in the "init" GPIO state unless a client enables the PWM. >> }; >> >> + >> #define to_imx_chip(chip) container_of(chip, struct imx_chip, chip) >> >> +static int imx_pwm_init_pinctrl_info(struct imx_chip *imx_chip, >> + struct platform_device *pdev) >> +{ >> + imx_chip->pinctrl = devm_pinctrl_get(&pdev->dev); >> + if (!imx_chip->pinctrl || IS_ERR(imx_chip->pinctrl)) { >> + dev_info(&pdev->dev, "can not get pinctrl\n"); >> + return PTR_ERR(imx_chip->pinctrl); >> + } >> + >> + imx_chip->pinctrl_pins_pwm = pinctrl_lookup_state(imx_chip->pinctrl, >> + "pwm"); >> + imx_chip->pinctrl_pins_gpio = pinctrl_lookup_state(imx_chip->pinctrl, >> + "gpio"); >> + imx_chip->pwm_gpiod = devm_gpiod_get_optional(&pdev->dev, "pwm", >> + GPIOD_IN); >> + >> + if (PTR_ERR(imx_chip->pwm_gpiod) == -EPROBE_DEFER) { > > You must not use PTR_ERR on a value that might not contain an error > pointer. OK, thank you for valuable info. So it seems like the I2C folks are in troubles as well: https://elixir.bootlin.com/linux/latest/source/drivers/i2c/busses/i2c-imx.c#L996 >> + return -EPROBE_DEFER; >> + } else if (IS_ERR(imx_chip->pwm_gpiod) || >> + IS_ERR(imx_chip->pinctrl_pins_pwm) || >> + IS_ERR(imx_chip->pinctrl_pins_gpio)) { > > Would it be more correct to handle imx_chip->pinctrl_pins_pwm == > ERR_PTR(-EPROBE_DEFER) similar to imx_chip->pwm_gpiod == > ERR_PTR(-EPROBE_DEFER)? Sorry, I can't answer that now. I need to look deeper into that. >> + dev_dbg(&pdev->dev, "PWM pinctrl information incomplete\n"); > > I wouldn't call that "incomplete". It's incomplete for the gpio > switching trick, but enough in general. True. It is a copy-paste and I could not really come up with something more sensible for our case. I am happy to change that. >> + devm_pinctrl_put(imx_chip->pinctrl); >> + imx_chip->pinctrl = NULL; >> + } >> + >> + return 0; >> +} >> + >> static void imx_pwm_get_state(struct pwm_chip *chip, >> struct pwm_device *pwm, struct pwm_state *state) >> { >> @@ -306,7 +343,31 @@ static int imx_pwm_apply_v2(struct pwm_chip *chip, struct pwm_device *pwm, >> MX3_PWMCR_POUTC_INVERTED); >> >> writel(cr, imx->mmio_base + MX3_PWMCR); >> + >> + /* >> + * If we are in charge of pinctrl then switch output to >> + * the PWM signal. >> + */ >> + if (imx->pinctrl) >> + pinctrl_select_state(imx->pinctrl, >> + imx->pinctrl_pins_pwm); >> } else if (cstate.enabled) { >> + /* >> + * PWM block will be disabled. Normally its output will be set >> + * low no matter what output polarity is configured. Lets use > > s/Lets/Let's/ Ack. >> + * pinctrl to switch the output pin to GPIO functon and keep >> + * the output at the same level as for duty-cycle = 0. > > Is it obvious that using a GPIO is more efficient/better/worth the > complexity than just enabling the PWM with duty-cycle 0 and the right > polarity? To me, it does more than just setting duty-cycle = 0. I think that the user expect to find the PWM chip in disabled state after this. So that when you read the HW registers you see the chip is disabled. >> + * First set the GPIO to the desired level, then switch the >> + * muxing and at last disable PWM. In that order we do not get >> + * unwanted logic level changes on the output. >> + */ >> + if (imx->pinctrl) { >> + gpiod_set_value_cansleep(imx->pwm_gpiod, 0); > > You must call gpiod_direction_output for this to have any effect. Obviously not. It is working (not only) for me like that a long time. But I agree, a comment in gpiolib I found recently is clear about that you must call that function beforehand. > There might be mechanisms in pincontrol that automatically mux the pin > if it's configured as gpio, I didn't follow the details though. > > Also it should be possible to configure the GPIO as output immediatly. > If the pinmuxing is set to the PWM function this doesn't have a visible > side effect. This could be the first time that we want to disable the PWM as you might start with PWM enabled from probe. And hence the GPIO is still configured as input. >> + pinctrl_select_state(imx->pinctrl, >> + imx->pinctrl_pins_gpio); > > Usually align function arguments to the opening (. Oops, I will fix those. There is more than this one.. >> + } >> + >> writel(0, imx->mmio_base + MX3_PWMCR); >> >> clk_disable_unprepare(imx->clk_per); >> @@ -354,6 +415,7 @@ static int imx_pwm_probe(struct platform_device *pdev) >> const struct of_device_id *of_id = >> of_match_device(imx_pwm_dt_ids, &pdev->dev); >> const struct imx_pwm_data *data; >> + struct pwm_state cstate; >> struct imx_chip *imx; >> struct resource *r; >> int ret = 0; >> @@ -385,6 +447,10 @@ static int imx_pwm_probe(struct platform_device *pdev) >> imx->chip.of_pwm_n_cells = 3; >> } >> >> + ret = imx_pwm_init_pinctrl_info(imx, pdev); >> + if (ret) >> + return ret; >> + >> r = platform_get_resource(pdev, IORESOURCE_MEM, 0); >> imx->mmio_base = devm_ioremap_resource(&pdev->dev, r); >> if (IS_ERR(imx->mmio_base)) >> @@ -394,6 +460,26 @@ static int imx_pwm_probe(struct platform_device *pdev) >> if (ret < 0) >> return ret; >> >> + if (imx->pinctrl) { >> + /* >> + * Update cstate after pwmchip_add() call as the core might >> + * call the get_state() function to read the PWM registers >> + * to get the actual HW state. >> + */ >> + pwm_get_state(imx->chip.pwms, &cstate); >> + if (cstate.enabled) { >> + dev_dbg(&pdev->dev, >> + "PWM entered probe in enabled state\n"); >> + pinctrl_select_state(imx->pinctrl, >> + imx->pinctrl_pins_pwm); >> + } else { >> + gpiod_set_value_cansleep(imx->pwm_gpiod, 0); >> + pinctrl_select_state(imx->pinctrl, >> + imx->pinctrl_pins_gpio); >> + >> + } >> + } >> + >> platform_set_drvdata(pdev, imx); >> return 0; >> } > > There is nothing in this patch that would prevent this code to live in a > place where other drivers could reuse this. (But attention, there are > dragons: Thierry already replied on my topic that his view is different > in this aspect compared to other maintainers though. His POV is that as > long as there is only a single driver known that has a problem this > should be handled in driver specific code.) When I tripped over that issue I also thought it is i.MX specific. It never came to my mind that something like that should be done in higher layer. But I have to admit that my current understanding of the overall architecture is at such level that I will just do it how the maintainer wants me to do it. Given that the solution improves the situation and solves my original problem. And the pinctrl solution was already suggested by Fabio Estevam a year ago [1] so I went that way. [1] https://patchwork.ozlabs.org/patch/839834/#1819865 Michal ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-10-12 15:04 ` Vokáč Michal @ 2018-10-12 15:54 ` Thierry Reding 2018-10-12 16:08 ` Uwe Kleine-König 1 sibling, 0 replies; 60+ messages in thread From: Thierry Reding @ 2018-10-12 15:54 UTC (permalink / raw) To: Vokáč Michal Cc: Uwe Kleine-König, Rob Herring, Mark Rutland, devicetree, linux-pwm, linux-kernel, Lukasz Majewski, Fabio Estevam, Lothar Waßmann, kernel [-- Attachment #1: Type: text/plain, Size: 1804 bytes --] On Fri, Oct 12, 2018 at 03:04:48PM +0000, Vokáč Michal wrote: > On 12.10.2018 10:57, Uwe Kleine-König wrote: > > On Wed, Oct 10, 2018 at 09:33:26AM +0000, Vokáč Michal wrote: [...] > >> +static int imx_pwm_init_pinctrl_info(struct imx_chip *imx_chip, > >> + struct platform_device *pdev) > >> +{ > >> + imx_chip->pinctrl = devm_pinctrl_get(&pdev->dev); > >> + if (!imx_chip->pinctrl || IS_ERR(imx_chip->pinctrl)) { > >> + dev_info(&pdev->dev, "can not get pinctrl\n"); > >> + return PTR_ERR(imx_chip->pinctrl); > >> + } > >> + > >> + imx_chip->pinctrl_pins_pwm = pinctrl_lookup_state(imx_chip->pinctrl, > >> + "pwm"); > >> + imx_chip->pinctrl_pins_gpio = pinctrl_lookup_state(imx_chip->pinctrl, > >> + "gpio"); > >> + imx_chip->pwm_gpiod = devm_gpiod_get_optional(&pdev->dev, "pwm", > >> + GPIOD_IN); > >> + > >> + if (PTR_ERR(imx_chip->pwm_gpiod) == -EPROBE_DEFER) { > > > > You must not use PTR_ERR on a value that might not contain an error > > pointer. > > OK, thank you for valuable info. > So it seems like the I2C folks are in troubles as well: > > https://elixir.bootlin.com/linux/latest/source/drivers/i2c/busses/i2c-imx.c#L996 There's nothing inherently wrong with doing it like the above, just maybe slightly unusual. PTR_ERR() is really just casting from a pointer to an integer, so if the pointer happens to contain the value -EPROBE_DEFER, then the above will be true. If it contains a valid pointer, the above will be false, so it does exactly what you want. Perhaps a more idiomatic way to write this would be: if (IS_ERR(imx_chip->pwm_gpiod)) { if (PTR_ERR(imx_chip->pwm_gpiod) == -EPROBE_DEFER) return -EPROBE_DEFER; } But that's not much clearer than what you have, so feel free to keep it that way. Thierry [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-10-12 15:04 ` Vokáč Michal 2018-10-12 15:54 ` Thierry Reding @ 2018-10-12 16:08 ` Uwe Kleine-König 2018-10-14 20:24 ` Uwe Kleine-König 2018-10-29 15:54 ` Vokáč Michal 1 sibling, 2 replies; 60+ messages in thread From: Uwe Kleine-König @ 2018-10-12 16:08 UTC (permalink / raw) To: Vokáč Michal Cc: Thierry Reding, Rob Herring, Mark Rutland, devicetree, linux-pwm, linux-kernel, Lukasz Majewski, Fabio Estevam, Lothar Waßmann, kernel Hello, On Fri, Oct 12, 2018 at 03:04:48PM +0000, Vokáč Michal wrote: > On 12.10.2018 10:57, Uwe Kleine-König wrote: > > On Wed, Oct 10, 2018 at 09:33:26AM +0000, Vokáč Michal wrote: > >> Normally the PWM output is held LOW when PWM is disabled. This can cause > >> problems when inverted PWM signal polarity is needed. With this behavior > >> the connected circuit is fed by 100% duty cycle instead of being shut-off. > >> > >> Allow users to define a "gpio" and a "pwm" pinctrl states. The pwm pinctrl > >> state is then selected when PWM is enabled and the gpio pinctrl state is > >> selected when PWM is disabled. Also add a new pwm-gpios GPIO that is used > >> to drive the output in the gpio state. > >> > >> If all the pinctrl states and the pwm-gpios are not correctly specified > >> in DT the logic will work as before. > >> > >> As an example, with this patch a PWM controlled backlight with inversed > >> signal polarity can be used in full brightness range. Without this patch > >> the backlight can not be turned off as brightness = 0 disables the PWM > >> and that in turn set PWM output LOW, that is full brightness. > >> > >> Output of the PWM with "default" pinctrl and with "pwm"+"gpio" pinctrl: > >> > >> +--------------+------------+---------------+---------------------------+ > >> | After reset | Bootloader | Linux pinctrl | User (sysfs, backlight..) | > >> | 100k pull-up | (not used) | | enable | disable | > >> +--------------+------------+---------------+---------------------------+ > >> ___________________________ default _ _ _ > >> |_________________| |_| |_| |_|_____________ > >> > >> pwm + gpio > >> ___________________________________________ _ _ _ _____________ > >> |_| |_| |_| |_| > > > > I was made aware of this patch by Thierry while discussion about a patch > > opportunity. I already pointed out some stuff I don't like about this > > patch in the repective thread, but I repeat it here to have it at the > > right place. > > Thank you for taking time to comment on this one as well Uwe. > > >> Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com> > >> --- > >> Changes in v2: > >> - Utilize the "pwm" and "gpio" pinctrl states. > >> - Use the pwm-gpios signal to drive the output in "gpio" pinctrl state. > >> - Select the right pinctrl state in probe. > >> > >> drivers/pwm/pwm-imx.c | 86 +++++++++++++++++++++++++++++++++++++++++++++++++++ > >> 1 file changed, 86 insertions(+) > >> > >> diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c > >> index 6cd3b72..3502123 100644 > >> --- a/drivers/pwm/pwm-imx.c > >> +++ b/drivers/pwm/pwm-imx.c > >> @@ -10,11 +10,13 @@ > >> #include <linux/clk.h> > >> #include <linux/delay.h> > >> #include <linux/err.h> > >> +#include <linux/gpio/consumer.h> > >> #include <linux/io.h> > >> #include <linux/kernel.h> > >> #include <linux/module.h> > >> #include <linux/of.h> > >> #include <linux/of_device.h> > >> +#include <linux/pinctrl/consumer.h> > >> #include <linux/platform_device.h> > >> #include <linux/pwm.h> > >> #include <linux/slab.h> > >> @@ -92,10 +94,45 @@ struct imx_chip { > >> void __iomem *mmio_base; > >> > >> struct pwm_chip chip; > >> + > >> + struct pinctrl *pinctrl; > >> + struct pinctrl_state *pinctrl_pins_gpio; > >> + struct pinctrl_state *pinctrl_pins_pwm; > >> + struct gpio_desc *pwm_gpiod; > > > > The pinctrl framework already knows about "init" and "default". These > > should be enough. i.e. "init" configures as gpio and "default" als pwm. > > That is totally new information for me. I've never seen any usage of > "init" pinctrl state before. The total number of users is 6 (rockchip) > so that explains a lot. > > I think that it would not work though. The basic idea behind my > solution is that the pinctrl driver does not know what is the correct > pin configuration at probe whereas the pwm-imx driver does. > > With the "init" and "default" states the pinctrl driver will always > select the "default" if it find the pins in "init" state. > > https://elixir.bootlin.com/linux/latest/source/drivers/pinctrl/core.c#L1469 > > But we want the pins to stay in the "init" GPIO state unless a client > enables the PWM. Note I don't know this very well either. What should work then is to have "init" as GPIO and "active" as PWM. Well, though this breaks if you intend to probe a running pwm without stopping it. > >> }; > >> > >> + > >> #define to_imx_chip(chip) container_of(chip, struct imx_chip, chip) > >> > >> +static int imx_pwm_init_pinctrl_info(struct imx_chip *imx_chip, > >> + struct platform_device *pdev) > >> +{ > >> + imx_chip->pinctrl = devm_pinctrl_get(&pdev->dev); > >> + if (!imx_chip->pinctrl || IS_ERR(imx_chip->pinctrl)) { > >> + dev_info(&pdev->dev, "can not get pinctrl\n"); > >> + return PTR_ERR(imx_chip->pinctrl); > >> + } > >> + > >> + imx_chip->pinctrl_pins_pwm = pinctrl_lookup_state(imx_chip->pinctrl, > >> + "pwm"); > >> + imx_chip->pinctrl_pins_gpio = pinctrl_lookup_state(imx_chip->pinctrl, > >> + "gpio"); > >> + imx_chip->pwm_gpiod = devm_gpiod_get_optional(&pdev->dev, "pwm", > >> + GPIOD_IN); > >> + > >> + if (PTR_ERR(imx_chip->pwm_gpiod) == -EPROBE_DEFER) { > > > > You must not use PTR_ERR on a value that might not contain an error > > pointer. > > OK, thank you for valuable info. > So it seems like the I2C folks are in troubles as well: > > https://elixir.bootlin.com/linux/latest/source/drivers/i2c/busses/i2c-imx.c#L996 correct. I cannot find this documented though. > >> + * pinctrl to switch the output pin to GPIO functon and keep > >> + * the output at the same level as for duty-cycle = 0. > > > > Is it obvious that using a GPIO is more efficient/better/worth the > > complexity than just enabling the PWM with duty-cycle 0 and the right > > polarity? > > To me, it does more than just setting duty-cycle = 0. I think that the > user expect to find the PWM chip in disabled state after this. So that > when you read the HW registers you see the chip is disabled. The PWM API user doesn't (have to) care how the lowlevel driver implements the .disable() callback. I personally would prefer to keep the driver simple (without pinctrl and gpio stuff which also simplifies matters for dts authors) and spend that little energy keeping the HW on. > > There might be mechanisms in pincontrol that automatically mux the pin > > if it's configured as gpio, I didn't follow the details though. > > > > Also it should be possible to configure the GPIO as output immediatly. > > If the pinmuxing is set to the PWM function this doesn't have a visible > > side effect. > > This could be the first time that we want to disable the PWM as you > might start with PWM enabled from probe. And hence the GPIO is still > configured as input. I fail to follow your case. Do you mean the pwm is already running when the driver probes? Then it is save to set the gpio to output as this has no effect as long as the pin is muxed in its pwm function. > >> + pinctrl_select_state(imx->pinctrl, > >> + imx->pinctrl_pins_gpio); > > > > Usually align function arguments to the opening (. > > Oops, I will fix those. There is more than this one.. > > >> + } > >> + > >> writel(0, imx->mmio_base + MX3_PWMCR); > >> > >> clk_disable_unprepare(imx->clk_per); > >> @@ -354,6 +415,7 @@ static int imx_pwm_probe(struct platform_device *pdev) > >> const struct of_device_id *of_id = > >> of_match_device(imx_pwm_dt_ids, &pdev->dev); > >> const struct imx_pwm_data *data; > >> + struct pwm_state cstate; > >> struct imx_chip *imx; > >> struct resource *r; > >> int ret = 0; > >> @@ -385,6 +447,10 @@ static int imx_pwm_probe(struct platform_device *pdev) > >> imx->chip.of_pwm_n_cells = 3; > >> } > >> > >> + ret = imx_pwm_init_pinctrl_info(imx, pdev); > >> + if (ret) > >> + return ret; > >> + > >> r = platform_get_resource(pdev, IORESOURCE_MEM, 0); > >> imx->mmio_base = devm_ioremap_resource(&pdev->dev, r); > >> if (IS_ERR(imx->mmio_base)) > >> @@ -394,6 +460,26 @@ static int imx_pwm_probe(struct platform_device *pdev) > >> if (ret < 0) > >> return ret; > >> > >> + if (imx->pinctrl) { > >> + /* > >> + * Update cstate after pwmchip_add() call as the core might > >> + * call the get_state() function to read the PWM registers > >> + * to get the actual HW state. > >> + */ > >> + pwm_get_state(imx->chip.pwms, &cstate); > >> + if (cstate.enabled) { > >> + dev_dbg(&pdev->dev, > >> + "PWM entered probe in enabled state\n"); > >> + pinctrl_select_state(imx->pinctrl, > >> + imx->pinctrl_pins_pwm); > >> + } else { > >> + gpiod_set_value_cansleep(imx->pwm_gpiod, 0); > >> + pinctrl_select_state(imx->pinctrl, > >> + imx->pinctrl_pins_gpio); > >> + > >> + } > >> + } > >> + > >> platform_set_drvdata(pdev, imx); > >> return 0; > >> } > > > > There is nothing in this patch that would prevent this code to live in a > > place where other drivers could reuse this. (But attention, there are > > dragons: Thierry already replied on my topic that his view is different > > in this aspect compared to other maintainers though. His POV is that as > > long as there is only a single driver known that has a problem this > > should be handled in driver specific code.) > > When I tripped over that issue I also thought it is i.MX specific. > It never came to my mind that something like that should be done in > higher layer. > > But I have to admit that my current understanding of the overall > architecture is at such level that I will just do it how the maintainer > wants me to do it. Given that the solution improves the situation and > solves my original problem. And the pinctrl solution was already > suggested by Fabio Estevam a year ago [1] so I went that way. > > [1] https://patchwork.ozlabs.org/patch/839834/#1819865 In message 15 both Lothar and Fabio agree that they would prefer a solution without messing with pin configs. But also note that they discussed about suspend, too, not only pwm_disable(). Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-10-12 16:08 ` Uwe Kleine-König @ 2018-10-14 20:24 ` Uwe Kleine-König 2018-10-15 8:45 ` Thierry Reding 2018-10-29 15:54 ` Vokáč Michal 1 sibling, 1 reply; 60+ messages in thread From: Uwe Kleine-König @ 2018-10-14 20:24 UTC (permalink / raw) To: Vokáč Michal Cc: Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, Thierry Reding, kernel, Fabio Estevam, Lothar Waßmann Hello, On Fri, Oct 12, 2018 at 06:08:54PM +0200, Uwe Kleine-König wrote: > > >> + if (PTR_ERR(imx_chip->pwm_gpiod) == -EPROBE_DEFER) { > > > > > > You must not use PTR_ERR on a value that might not contain an error > > > pointer. > > > > OK, thank you for valuable info. > > So it seems like the I2C folks are in troubles as well: > > > > https://elixir.bootlin.com/linux/latest/source/drivers/i2c/busses/i2c-imx.c#L996 > > correct. I cannot find this documented though. I found in LDD3[1], chapter 11 on page 295: If you need the actual error code, it can be extracted with: long PTR_ERR(const void *ptr); You should use PTR_ERR only on a value for which IS_ERR returns a true value; any other value is a valid pointer. That is probably where I have my claim from. There is no further explanation though, so I'll post a patch adding a comment to the definition of PTR_ERR to find out if there is a relevant reason. Best regards Uwe [1] https://lwn.net/Kernel/LDD3/ -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-10-14 20:24 ` Uwe Kleine-König @ 2018-10-15 8:45 ` Thierry Reding 2018-10-29 15:55 ` Vokáč Michal 0 siblings, 1 reply; 60+ messages in thread From: Thierry Reding @ 2018-10-15 8:45 UTC (permalink / raw) To: Uwe Kleine-König Cc: Vokáč Michal, Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, kernel, Fabio Estevam, Lothar Waßmann [-- Attachment #1: Type: text/plain, Size: 1565 bytes --] On Sun, Oct 14, 2018 at 10:24:57PM +0200, Uwe Kleine-König wrote: > Hello, > > On Fri, Oct 12, 2018 at 06:08:54PM +0200, Uwe Kleine-König wrote: > > > >> + if (PTR_ERR(imx_chip->pwm_gpiod) == -EPROBE_DEFER) { > > > > > > > > You must not use PTR_ERR on a value that might not contain an error > > > > pointer. > > > > > > OK, thank you for valuable info. > > > So it seems like the I2C folks are in troubles as well: > > > > > > https://elixir.bootlin.com/linux/latest/source/drivers/i2c/busses/i2c-imx.c#L996 > > > > correct. I cannot find this documented though. > > I found in LDD3[1], chapter 11 on page 295: > > If you need the actual error code, it can be extracted with: > > long PTR_ERR(const void *ptr); > > You should use PTR_ERR only on a value for which IS_ERR returns a true > value; any other value is a valid pointer. > > That is probably where I have my claim from. There is no further > explanation though, so I'll post a patch adding a comment to the > definition of PTR_ERR to find out if there is a relevant reason. Michal's code above does an implicit IS_ERR() by comparing to an actual error code. It's certainly true that PTR_ERR() on any pointer and then using that value can be risky because it may not actually be an error. So if you go and unconditionally print that error code even if it isn't an error but a valid pointer, you've leaked a kernel address. However, it's perfectly safe to use PTR_ERR(ptr) == -EPROBE_DEFER (or for any other error code for that matter). Thierry [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-10-15 8:45 ` Thierry Reding @ 2018-10-29 15:55 ` Vokáč Michal 0 siblings, 0 replies; 60+ messages in thread From: Vokáč Michal @ 2018-10-29 15:55 UTC (permalink / raw) To: Thierry Reding, Uwe Kleine-König Cc: Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, kernel, Fabio Estevam, Lothar Waßmann On 15.10.2018 10:45, Thierry Reding wrote: > On Sun, Oct 14, 2018 at 10:24:57PM +0200, Uwe Kleine-König wrote: >> Hello, >> >> On Fri, Oct 12, 2018 at 06:08:54PM +0200, Uwe Kleine-König wrote: >>>>>> + if (PTR_ERR(imx_chip->pwm_gpiod) == -EPROBE_DEFER) { >>>>> >>>>> You must not use PTR_ERR on a value that might not contain an error >>>>> pointer. >>>> >>>> OK, thank you for valuable info. >>>> So it seems like the I2C folks are in troubles as well: >>>> >>>> https://elixir.bootlin.com/linux/latest/source/drivers/i2c/busses/i2c-imx.c#L996 >>> >>> correct. I cannot find this documented though. >> >> I found in LDD3[1], chapter 11 on page 295: >> >> If you need the actual error code, it can be extracted with: >> >> long PTR_ERR(const void *ptr); >> >> You should use PTR_ERR only on a value for which IS_ERR returns a true >> value; any other value is a valid pointer. >> >> That is probably where I have my claim from. There is no further >> explanation though, so I'll post a patch adding a comment to the >> definition of PTR_ERR to find out if there is a relevant reason. Thanks for mentioning the LDD3 Uwe. I almost forgot it exist. I will dust-off my electronic copy ;) > Michal's code above does an implicit IS_ERR() by comparing to an actual > error code. It's certainly true that PTR_ERR() on any pointer and then > using that value can be risky because it may not actually be an error. > So if you go and unconditionally print that error code even if it isn't > an error but a valid pointer, you've leaked a kernel address. > > However, it's perfectly safe to use PTR_ERR(ptr) == -EPROBE_DEFER (or > for any other error code for that matter). OK, I will leave that as is. And thanks for all the details. I always learn something new from the comments! Michal ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-10-12 16:08 ` Uwe Kleine-König 2018-10-14 20:24 ` Uwe Kleine-König @ 2018-10-29 15:54 ` Vokáč Michal 2018-11-07 9:33 ` Uwe Kleine-König 1 sibling, 1 reply; 60+ messages in thread From: Vokáč Michal @ 2018-10-29 15:54 UTC (permalink / raw) To: Uwe Kleine-König Cc: Thierry Reding, Rob Herring, Mark Rutland, devicetree, linux-pwm, linux-kernel, Lukasz Majewski, Fabio Estevam, Lothar Waßmann, kernel On 12.10.2018 18:08, Uwe Kleine-König wrote: > Hello, > > On Fri, Oct 12, 2018 at 03:04:48PM +0000, Vokáč Michal wrote: >> On 12.10.2018 10:57, Uwe Kleine-König wrote: >>> On Wed, Oct 10, 2018 at 09:33:26AM +0000, Vokáč Michal wrote: >>>> Normally the PWM output is held LOW when PWM is disabled. This can cause >>>> problems when inverted PWM signal polarity is needed. With this behavior >>>> the connected circuit is fed by 100% duty cycle instead of being shut-off. >>>> >>>> Allow users to define a "gpio" and a "pwm" pinctrl states. The pwm pinctrl >>>> state is then selected when PWM is enabled and the gpio pinctrl state is >>>> selected when PWM is disabled. Also add a new pwm-gpios GPIO that is used >>>> to drive the output in the gpio state. >>>> >>>> If all the pinctrl states and the pwm-gpios are not correctly specified >>>> in DT the logic will work as before. >>>> >>>> As an example, with this patch a PWM controlled backlight with inversed >>>> signal polarity can be used in full brightness range. Without this patch >>>> the backlight can not be turned off as brightness = 0 disables the PWM >>>> and that in turn set PWM output LOW, that is full brightness. >>>> >>>> Output of the PWM with "default" pinctrl and with "pwm"+"gpio" pinctrl: >>>> >>>> +--------------+------------+---------------+---------------------------+ >>>> | After reset | Bootloader | Linux pinctrl | User (sysfs, backlight..) | >>>> | 100k pull-up | (not used) | | enable | disable | >>>> +--------------+------------+---------------+---------------------------+ >>>> ___________________________ default _ _ _ >>>> |_________________| |_| |_| |_|_____________ >>>> >>>> pwm + gpio >>>> ___________________________________________ _ _ _ _____________ >>>> |_| |_| |_| |_| >>> >>> I was made aware of this patch by Thierry while discussion about a patch >>> opportunity. I already pointed out some stuff I don't like about this >>> patch in the repective thread, but I repeat it here to have it at the >>> right place. >> >> Thank you for taking time to comment on this one as well Uwe. >> >>>> Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com> >>>> --- >>>> Changes in v2: >>>> - Utilize the "pwm" and "gpio" pinctrl states. >>>> - Use the pwm-gpios signal to drive the output in "gpio" pinctrl state. >>>> - Select the right pinctrl state in probe. >>>> >>>> drivers/pwm/pwm-imx.c | 86 +++++++++++++++++++++++++++++++++++++++++++++++++++ >>>> 1 file changed, 86 insertions(+) >>>> >>>> diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c >>>> index 6cd3b72..3502123 100644 >>>> --- a/drivers/pwm/pwm-imx.c >>>> +++ b/drivers/pwm/pwm-imx.c >>>> @@ -10,11 +10,13 @@ >>>> #include <linux/clk.h> >>>> #include <linux/delay.h> >>>> #include <linux/err.h> >>>> +#include <linux/gpio/consumer.h> >>>> #include <linux/io.h> >>>> #include <linux/kernel.h> >>>> #include <linux/module.h> >>>> #include <linux/of.h> >>>> #include <linux/of_device.h> >>>> +#include <linux/pinctrl/consumer.h> >>>> #include <linux/platform_device.h> >>>> #include <linux/pwm.h> >>>> #include <linux/slab.h> >>>> @@ -92,10 +94,45 @@ struct imx_chip { >>>> void __iomem *mmio_base; >>>> >>>> struct pwm_chip chip; >>>> + >>>> + struct pinctrl *pinctrl; >>>> + struct pinctrl_state *pinctrl_pins_gpio; >>>> + struct pinctrl_state *pinctrl_pins_pwm; >>>> + struct gpio_desc *pwm_gpiod; >>> >>> The pinctrl framework already knows about "init" and "default". These >>> should be enough. i.e. "init" configures as gpio and "default" als pwm. >> >> That is totally new information for me. I've never seen any usage of >> "init" pinctrl state before. The total number of users is 6 (rockchip) >> so that explains a lot. >> >> I think that it would not work though. The basic idea behind my >> solution is that the pinctrl driver does not know what is the correct >> pin configuration at probe whereas the pwm-imx driver does. >> >> With the "init" and "default" states the pinctrl driver will always >> select the "default" if it find the pins in "init" state. >> >> https://elixir.bootlin.com/linux/latest/source/drivers/pinctrl/core.c#L1469 >> >> But we want the pins to stay in the "init" GPIO state unless a client >> enables the PWM. > > Note I don't know this very well either. What should work then is to > have "init" as GPIO and "active" as PWM. Well, though this breaks if you > intend to probe a running pwm without stopping it. I'm not sure what you mean by "active". I tried to find more info about that and it looks like it is not a natively supported pinctrl state. Only "init", "default" and "sleep" are, right? I could not find any current users of "active". Few TI dra7 boards pretend to use it for dcan1 pinctrl but I did not find any code handling that state. Or do you propose to rename what I call "pwm" state to "active"? Anyway, as you said - this still does not work as I would like to have an option not to stop PWM that is already running. As a side note - while greping the "active" state, I found a pwm-renesas-tpu driver that is doing something very "pinctrl-ish" to switch between pin states. Though the PWM chip has a built-in HW support for that. https://elixir.bootlin.com/linux/latest/source/drivers/pwm/pwm-renesas-tpu.c#L108 >>>> }; >>>> >>>> + >>>> #define to_imx_chip(chip) container_of(chip, struct imx_chip, chip) >>>> >>>> +static int imx_pwm_init_pinctrl_info(struct imx_chip *imx_chip, >>>> + struct platform_device *pdev) >>>> +{ >>>> + imx_chip->pinctrl = devm_pinctrl_get(&pdev->dev); >>>> + if (!imx_chip->pinctrl || IS_ERR(imx_chip->pinctrl)) { >>>> + dev_info(&pdev->dev, "can not get pinctrl\n"); >>>> + return PTR_ERR(imx_chip->pinctrl); >>>> + } >>>> + >>>> + imx_chip->pinctrl_pins_pwm = pinctrl_lookup_state(imx_chip->pinctrl, >>>> + "pwm"); >>>> + imx_chip->pinctrl_pins_gpio = pinctrl_lookup_state(imx_chip->pinctrl, >>>> + "gpio"); >>>> + imx_chip->pwm_gpiod = devm_gpiod_get_optional(&pdev->dev, "pwm", >>>> + GPIOD_IN); >>>> + >>>> + if (PTR_ERR(imx_chip->pwm_gpiod) == -EPROBE_DEFER) { >>> >>> You must not use PTR_ERR on a value that might not contain an error >>> pointer. >> >> OK, thank you for valuable info. >> So it seems like the I2C folks are in troubles as well: >> >> https://elixir.bootlin.com/linux/latest/source/drivers/i2c/busses/i2c-imx.c#L996 > > correct. I cannot find this documented though. > >>>> + * pinctrl to switch the output pin to GPIO functon and keep >>>> + * the output at the same level as for duty-cycle = 0. >>> >>> Is it obvious that using a GPIO is more efficient/better/worth the >>> complexity than just enabling the PWM with duty-cycle 0 and the right >>> polarity? >> >> To me, it does more than just setting duty-cycle = 0. I think that the >> user expect to find the PWM chip in disabled state after this. So that >> when you read the HW registers you see the chip is disabled. > > The PWM API user doesn't (have to) care how the lowlevel driver > implements the .disable() callback. Sure, I agree the PWM API doesn't care. What I wanted to say is that I, as a real person/user/developer kind of expect the PWM HW to be really disabled when I do $(echo 0 > pwm0/enabled) as I know the HW is capable of being disabled. But yeah, better is not to expect anything. > I personally would prefer to keep the driver simple (without pinctrl and > gpio stuff which also simplifies matters for dts authors) and spend that > little energy keeping the HW on. > >>> There might be mechanisms in pincontrol that automatically mux the pin >>> if it's configured as gpio, I didn't follow the details though. >>> >>> Also it should be possible to configure the GPIO as output immediatly. >>> If the pinmuxing is set to the PWM function this doesn't have a visible >>> side effect. >> >> This could be the first time that we want to disable the PWM as you >> might start with PWM enabled from probe. And hence the GPIO is still >> configured as input. > > I fail to follow your case. Do you mean the pwm is already running when > the driver probes? Then it is save to set the gpio to output as this has > no effect as long as the pin is muxed in its pwm function. Sorry, I admit my skills to explain things in English are not the best. Maybe I misunderstood what you meant by "configure the GPIO as output immediately". I read that as: "You do not need gpiod_set_value(0), use pinctrl_select_state(gpio) straight away.". Now when I think about that again - you are right. I actually did it like that in v1. But I did not use pwm-gpios at all. I was relying on the input and pull-up setting from reset. But that is not right as the bootloader might change it. Now, when I use devm_gpiod_get_optional("pwm", GPIOD_IN), it is ensured that the pin is configured as input so the pull-up keeps the right level. >>>> + pinctrl_select_state(imx->pinctrl, >>>> + imx->pinctrl_pins_gpio); >>> >>> Usually align function arguments to the opening (. >> >> Oops, I will fix those. There is more than this one.. >> >>>> + } >>>> + >>>> writel(0, imx->mmio_base + MX3_PWMCR); >>>> >>>> clk_disable_unprepare(imx->clk_per); >>>> @@ -354,6 +415,7 @@ static int imx_pwm_probe(struct platform_device *pdev) >>>> const struct of_device_id *of_id = >>>> of_match_device(imx_pwm_dt_ids, &pdev->dev); >>>> const struct imx_pwm_data *data; >>>> + struct pwm_state cstate; >>>> struct imx_chip *imx; >>>> struct resource *r; >>>> int ret = 0; >>>> @@ -385,6 +447,10 @@ static int imx_pwm_probe(struct platform_device *pdev) >>>> imx->chip.of_pwm_n_cells = 3; >>>> } >>>> >>>> + ret = imx_pwm_init_pinctrl_info(imx, pdev); >>>> + if (ret) >>>> + return ret; >>>> + >>>> r = platform_get_resource(pdev, IORESOURCE_MEM, 0); >>>> imx->mmio_base = devm_ioremap_resource(&pdev->dev, r); >>>> if (IS_ERR(imx->mmio_base)) >>>> @@ -394,6 +460,26 @@ static int imx_pwm_probe(struct platform_device *pdev) >>>> if (ret < 0) >>>> return ret; >>>> >>>> + if (imx->pinctrl) { >>>> + /* >>>> + * Update cstate after pwmchip_add() call as the core might >>>> + * call the get_state() function to read the PWM registers >>>> + * to get the actual HW state. >>>> + */ >>>> + pwm_get_state(imx->chip.pwms, &cstate); >>>> + if (cstate.enabled) { >>>> + dev_dbg(&pdev->dev, >>>> + "PWM entered probe in enabled state\n"); >>>> + pinctrl_select_state(imx->pinctrl, >>>> + imx->pinctrl_pins_pwm); >>>> + } else { >>>> + gpiod_set_value_cansleep(imx->pwm_gpiod, 0); >>>> + pinctrl_select_state(imx->pinctrl, >>>> + imx->pinctrl_pins_gpio); >>>> + >>>> + } >>>> + } >>>> + >>>> platform_set_drvdata(pdev, imx); >>>> return 0; >>>> } >>> >>> There is nothing in this patch that would prevent this code to live in a >>> place where other drivers could reuse this. (But attention, there are >>> dragons: Thierry already replied on my topic that his view is different >>> in this aspect compared to other maintainers though. His POV is that as >>> long as there is only a single driver known that has a problem this >>> should be handled in driver specific code.) >> >> When I tripped over that issue I also thought it is i.MX specific. >> It never came to my mind that something like that should be done in >> higher layer. >> >> But I have to admit that my current understanding of the overall >> architecture is at such level that I will just do it how the maintainer >> wants me to do it. Given that the solution improves the situation and >> solves my original problem. And the pinctrl solution was already >> suggested by Fabio Estevam a year ago [1] so I went that way. >> >> [1] https://patchwork.ozlabs.org/patch/839834/#1819865 > > In message 15 both Lothar and Fabio agree that they would prefer a > solution without messing with pin configs. But also note that they > discussed about suspend, too, not only pwm_disable(). Sorry, I did not want it to look like I said: "Fabio wants it to be done the pinctrl way". I came up with the pinctrl solution on my own. Then when I was searching in archives if someone have the same problem I tripped over that thread. So I was happy that they discussed that as a possible solution. Fabio did not need it for his suspend case though. So I thought involving pinctrl is probably the last option to solve the problem at pwm-imx driver level. So far, Thierry seems he support that solution. All the best, Michal ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-10-29 15:54 ` Vokáč Michal @ 2018-11-07 9:33 ` Uwe Kleine-König 2018-11-07 13:32 ` Vokáč Michal 0 siblings, 1 reply; 60+ messages in thread From: Uwe Kleine-König @ 2018-11-07 9:33 UTC (permalink / raw) To: Vokáč Michal Cc: Thierry Reding, Rob Herring, Mark Rutland, devicetree, linux-pwm, linux-kernel, Lukasz Majewski, Fabio Estevam, Lothar Waßmann, kernel Hello Michal, just to state it more explicitly, I think the following patch (not even compile tested) is much preferable over your approach: diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c index 1d5242c9cde0..af88644b5efb 100644 --- a/drivers/pwm/pwm-imx.c +++ b/drivers/pwm/pwm-imx.c @@ -216,7 +216,14 @@ static int imx_pwm_apply_v2(struct pwm_chip *chip, struct pwm_device *pwm, cr |= MX3_PWMCR_POUTC; writel(cr, imx->mmio_base + MX3_PWMCR); - } else if (cstate.enabled) { + } else if (cstate.enabled && state->polarity == PWM_POLARITY_NORMAL) { + /* + * When disabled in hardware the output pin goes to 0 + * independant of the polarity setting. The expectation of some + * people however is that after disabling the pin goes to the + * inactive level which isn't given for an inversed pwm, so + * only disable for normal polarity. + */ writel(0, imx->mmio_base + MX3_PWMCR); clk_disable_unprepare(imx->clk_per); I think it solves most if not all problems you want to address with the pinctrl stuff. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply related [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-07 9:33 ` Uwe Kleine-König @ 2018-11-07 13:32 ` Vokáč Michal 2018-11-07 15:01 ` Uwe Kleine-König 0 siblings, 1 reply; 60+ messages in thread From: Vokáč Michal @ 2018-11-07 13:32 UTC (permalink / raw) To: Uwe Kleine-König Cc: Thierry Reding, Rob Herring, Mark Rutland, devicetree, linux-pwm, linux-kernel, Lukasz Majewski, Fabio Estevam, Lothar Waßmann, kernel Hi Uwe, On 7.11.2018 10:33, Uwe Kleine-König wrote: > Hello Michal, > > just to state it more explicitly, I think the following patch (not even > compile tested) is much preferable over your approach: Interesting idea. I just wonder why nobody else did not come up with such a simple solution before. > diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c > index 1d5242c9cde0..af88644b5efb 100644 > --- a/drivers/pwm/pwm-imx.c > +++ b/drivers/pwm/pwm-imx.c > @@ -216,7 +216,14 @@ static int imx_pwm_apply_v2(struct pwm_chip *chip, struct pwm_device *pwm, > cr |= MX3_PWMCR_POUTC; > > writel(cr, imx->mmio_base + MX3_PWMCR); > - } else if (cstate.enabled) { > + } else if (cstate.enabled && state->polarity == PWM_POLARITY_NORMAL) { > + /* > + * When disabled in hardware the output pin goes to 0 > + * independant of the polarity setting. The expectation of some > + * people however is that after disabling the pin goes to the > + * inactive level which isn't given for an inversed pwm, so > + * only disable for normal polarity. > + */ > writel(0, imx->mmio_base + MX3_PWMCR); > > clk_disable_unprepare(imx->clk_per); I tested your patch. It does not work as you expected. In v4.20-rc1 the pwm-backlight driver has been converted to atomic API. So the pwm_apply_v2 function is called only once to set new period/duty and state. With your patch that means that "echo 0 > brightness" has no visible effect. It leaves the PWM chip enabled with period/duty set to however it was. But the core thinks it was reconfigured: # cat /sys/class/backlight/backight/brightness 0 # cat /sys/kernel/debug/pwm platform/2080000.pwm, 1 PWM device pwm-0 (backlight ): requested period: 500000 ns duty: 0 ns polarity: inverse > I think it solves most if not all problems you want to address with the > pinctrl stuff. Unfortunately not. I also tested your patch on v4.19. It works as you probably intended - it is possible to disable backlight without the PWM chip being disabled. But it does not solve the time frame between imx_pwm_probe() and imx_pwm_apply_v2(). In probe you do not have any users yet. So you do not know the requested output polarity. With "default" pinctrl the PWM output would be muxed to the selected pin and since the PWM chip is most probably disabled (unless you enabled it in bootloader) you would get low level on the pin. That means your backlight is fully enabled until the first call to imx_pwm_apply_v2(). On my system this is 2 seconds. It might not be a big issue for backlight but for motor control it is not the right thing to do. The other thing is I would prefer to make the change optional. With your approach you are changing the behavior for all current users of inverted PWM. I do not think all imx6 users are aware of the problem so they might not be OK with the sudden change in the behavior. I agree it would be nice if such a simple change as you proposed would solve the problem. Still, I do not see any other solution than pinctrl to deal with all the problems I would like to address. Anyway, thank you for the idea! All the best, Michal ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-07 13:32 ` Vokáč Michal @ 2018-11-07 15:01 ` Uwe Kleine-König 2018-11-08 15:21 ` Vokáč Michal 0 siblings, 1 reply; 60+ messages in thread From: Uwe Kleine-König @ 2018-11-07 15:01 UTC (permalink / raw) To: Vokáč Michal Cc: Thierry Reding, Rob Herring, Mark Rutland, devicetree, linux-pwm, linux-kernel, Lukasz Majewski, Fabio Estevam, Lothar Waßmann, kernel Hello Michal, On Wed, Nov 07, 2018 at 01:32:10PM +0000, Vokáč Michal wrote: > On 7.11.2018 10:33, Uwe Kleine-König wrote: > > Hello Michal, > > > > just to state it more explicitly, I think the following patch (not even > > compile tested) is much preferable over your approach: > > Interesting idea. I just wonder why nobody else did not come up with such > a simple solution before. I think I mentioned it already in this thread, but it went unnoticed :-) > > diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c > > index 1d5242c9cde0..af88644b5efb 100644 > > --- a/drivers/pwm/pwm-imx.c > > +++ b/drivers/pwm/pwm-imx.c > > @@ -216,7 +216,14 @@ static int imx_pwm_apply_v2(struct pwm_chip *chip, struct pwm_device *pwm, > > cr |= MX3_PWMCR_POUTC; > > > > writel(cr, imx->mmio_base + MX3_PWMCR); > > - } else if (cstate.enabled) { > > + } else if (cstate.enabled && state->polarity == PWM_POLARITY_NORMAL) { > > + /* > > + * When disabled in hardware the output pin goes to 0 > > + * independant of the polarity setting. The expectation of some > > + * people however is that after disabling the pin goes to the > > + * inactive level which isn't given for an inversed pwm, so > > + * only disable for normal polarity. > > + */ > > writel(0, imx->mmio_base + MX3_PWMCR); > > > > clk_disable_unprepare(imx->clk_per); > > I tested your patch. It does not work as you expected. > > In v4.20-rc1 the pwm-backlight driver has been converted to atomic API. > So the pwm_apply_v2 function is called only once to set new period/duty > and state. With your patch that means that "echo 0 > brightness" has no > visible effect. It leaves the PWM chip enabled with period/duty set to > however it was. But the core thinks it was reconfigured: Then the patch isn't correct yet. The idea is always keep the hardware running and only disable it if it's uninverted. > > # cat /sys/class/backlight/backight/brightness > 0 > > # cat /sys/kernel/debug/pwm > platform/2080000.pwm, 1 PWM device > pwm-0 (backlight ): requested period: 500000 ns duty: 0 ns polarity: inverse > > > I think it solves most if not all problems you want to address with the > > pinctrl stuff. > > Unfortunately not. I also tested your patch on v4.19. It works as you > probably intended - it is possible to disable backlight without the PWM > chip being disabled. But it does not solve the time frame between > imx_pwm_probe() and imx_pwm_apply_v2(). In imx_pwm_probe it's not yet known what the polarity is supposed to be, right? So the right thing to do there is to not touch the configuration of the pwm. I think all states that are problematic then are also problematic with the gpio/pinmux approach. (I might be wrong here, so feel free to invest some brain cycles to prove me wrong. But I'd be surprised if there are problems that are relevant.) > In probe you do not have any users yet. So you do not know the requested > output polarity. With "default" pinctrl the PWM output would be muxed to > the selected pin and since the PWM chip is most probably disabled > (unless you enabled it in bootloader) you would get low level on the pin. > That means your backlight is fully enabled until the first call to > imx_pwm_apply_v2(). On my system this is 2 seconds. With the gpio/pinmux approach you don't know the intended polarity either and maybe enable the display, too. For both the solution is to let the bootloader enable the pwm with the right output level. Am I missing something? > It might not be a big issue for backlight but for motor control it is > not the right thing to do. > > The other thing is I would prefer to make the change optional. With your > approach you are changing the behavior for all current users of inverted > PWM. I do not think all imx6 users are aware of the problem so they might > not be OK with the sudden change in the behavior. Isn't my change an improvement for all users? What state do you have in mind that make things worse than they are now? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-07 15:01 ` Uwe Kleine-König @ 2018-11-08 15:21 ` Vokáč Michal 2018-11-08 19:18 ` Uwe Kleine-König 2018-11-14 11:14 ` Thierry Reding 0 siblings, 2 replies; 60+ messages in thread From: Vokáč Michal @ 2018-11-08 15:21 UTC (permalink / raw) To: Uwe Kleine-König Cc: Thierry Reding, Rob Herring, Mark Rutland, devicetree, linux-pwm, linux-kernel, Lukasz Majewski, Fabio Estevam, Lothar Waßmann, kernel Hi Uwe, On 7.11.2018 16:01, Uwe Kleine-König wrote: >> Interesting idea. I just wonder why nobody else did not come up with such >> a simple solution before. > > I think I mentioned it already in this thread, but it went unnoticed :-) I meant it like "How happened this was not invented years ago, when people first noticed the issue with using inverted PWM for backlight on i.MX6." In our project, this issue dates back to 2015 :( > Then the patch isn't correct yet. The idea is always keep the hardware > running and only disable it if it's uninverted. OK, I got the point. > In imx_pwm_probe it's not yet known what the polarity is supposed to be, > right? Not really. It can already be known but currently there is no way how to pass the information to the probe function. I, as a creator of the device (and author of a DTS file) know that the circuit needs inverted PWM signal. And I know that the circuit needs to be disabled until I say it can be enabled. How I say that can warry. It may be default brightness level > 0 in DTS file or from a userspace program using PWM sysfs interface. > So the right thing to do there is to not touch the configuration > of the pwm. I think all states that are problematic then are also > problematic with the gpio/pinmux approach. I think my use-case I already presented before is an example where involving pinctrl solves the problem while the "leave PWM enabled for inverted users" does not. That is all the time between imx_pwm_probe() and imx_pwm_apply_v2(). >> In probe you do not have any users yet. So you do not know the requested >> output polarity. With "default" pinctrl the PWM output would be muxed to >> the selected pin and since the PWM chip is most probably disabled >> (unless you enabled it in bootloader) you would get low level on the pin. >> That means your backlight is fully enabled until the first call to >> imx_pwm_apply_v2(). On my system this is 2 seconds. > > With the gpio/pinmux approach you don't know the intended polarity > either and maybe enable the display, too. You know it because the pinctrl solution is optional. So if you use it, you use it on purpose to override the default PWM output level in PWM disabled state. It is very useful in cases where you need inverted and disabled PWM signal from power-up to userspace. Or until some kernel driver (backlight, led, fan..) enables it. For this it is the only solution I think. It allows you to boot with disabled PWM that has normal polarity set by default. Later on from your userspace program you configure the PWM to desired period/duty, set PWM output to inversed and enable it. Until this point the circuit is disabled with my solution. > For both the solution is to let the bootloader enable the pwm with > the right output level. Am I missing something? Bootloader is only a small part of the whole solution I think. And I suppose you meant: "enable the *GPIO* with the right output level". - Even if you use GPIO in bootloader to set the required level the time frame from imx_pwm_probe to imx_pwm_apply is not covered. - Currently there is no support in Linux pwm-imx driver to detect the PWM chip is already enabled at probe time. I actually send patches for this a month ago [1]. No response yet. - Inverted PWM does not work in U-Boot (on imx at least). And it does not seam like it can be fixed easily. I do not know what is the situation in other bootloaders. So my current bootloader solution is one of: - Set the pin to the appropriate (HIGH) level using GPIO. - Do not touch the pin at all, it has 100k pull-up by default. >> The other thing is I would prefer to make the change optional. With your >> approach you are changing the behavior for all current users of inverted >> PWM. I do not think all imx6 users are aware of the problem so they might >> not be OK with the sudden change in the behavior. > > Isn't my change an improvement for all users? What state do you have in > mind that make things worse than they are now? Lets say that the user: - Needs inverted PWM signal. - Needs it to be disabled all the time unless he enable it. Current situation: H|____________________ L| \_________________________________________________ +-------+------------+-----------------+-----------------+-------------+ | reset | bootloader | default pinctrl | PWM enable 100% | PWM disable | What you propose (for all users of inverted PWM): H|____________________ _____________ L| \___________________________________/ +-------+------------+-----------------+-----------------+-------------+ | reset | bootloader | default pinctrl | PWM enable 100% | PWM disable | My solution (for those who want it): H|______________________________________ _____________ L| \_________________/ +-------+------------+-----------------+-----------------+-------------+ | reset | bootloader | default pinctrl | PWM enable 100% | PWM disable | So your solution at least allows the user to really disable the circuit. I can not really think of cases where this might not be good for current users. Maybe that they simply expect that no matter what polarity is set, the output in disabled state is always low. And they may have HW that get already used to that and does not like the change :) And it reminds me of something similar I have done for OLED display reset recently [2]. I tried to fix active-low reset sequence that is hardcoded in the driver. So you are supposed to use GPIO_ACTIVE_HIGH in DT to make the active-low reset work. It was rejected. The reason was backward DTB compatibility [3]. In other words: "Users of newer kernels expect that the reset still work the same if they do not update DTBs on their boards". I think this is kind of similar? [1] http://patchwork.ozlabs.org/project/linux-pwm/list/?series=68445 [2] https://patchwork.kernel.org/project/linux-fbdev/list/?series=23775 [3] https://lkml.org/lkml/2018/10/9/135 Best regards, Michal ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-08 15:21 ` Vokáč Michal @ 2018-11-08 19:18 ` Uwe Kleine-König 2018-11-09 14:24 ` Vokáč Michal 2018-11-14 11:14 ` Thierry Reding 1 sibling, 1 reply; 60+ messages in thread From: Uwe Kleine-König @ 2018-11-08 19:18 UTC (permalink / raw) To: Vokáč Michal Cc: Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, Thierry Reding, kernel, Fabio Estevam, Lothar Waßmann On Thu, Nov 08, 2018 at 03:21:44PM +0000, Vokáč Michal wrote: > Hi Uwe, > > On 7.11.2018 16:01, Uwe Kleine-König wrote: > >> Interesting idea. I just wonder why nobody else did not come up with such > >> a simple solution before. > > > > I think I mentioned it already in this thread, but it went unnoticed :-) > > I meant it like "How happened this was not invented years ago, when people > first noticed the issue with using inverted PWM for backlight on i.MX6." > In our project, this issue dates back to 2015 :( > > > Then the patch isn't correct yet. The idea is always keep the hardware > > running and only disable it if it's uninverted. > > OK, I got the point. > > > In imx_pwm_probe it's not yet known what the polarity is supposed to be, > > right? > > Not really. It can already be known but currently there is no way how to > pass the information to the probe function. I, as a creator of the device > (and author of a DTS file) know that the circuit needs inverted PWM signal. > And I know that the circuit needs to be disabled until I say it can be > enabled. How I say that can warry. It may be default brightness level > 0 > in DTS file or from a userspace program using PWM sysfs interface. > > > So the right thing to do there is to not touch the configuration > > of the pwm. I think all states that are problematic then are also > > problematic with the gpio/pinmux approach. > > I think my use-case I already presented before is an example where > involving pinctrl solves the problem while the "leave PWM enabled > for inverted users" does not. That is all the time between > imx_pwm_probe() and imx_pwm_apply_v2(). You're doing in probe: if (pwm_is_running()): mux(pin, function=pwm) else: gpio_set_value(gpio, 0) mux(pin, function=gpio) This gives you the right level assuming the gpio specification uses the right flag (GPIO_ACTIVE_HIGH or GPIO_ACTIVE_LOW). Taking your example with the backlight device you specify an "init" and a "default" pinctrl and only "default" contains the muxing for the PWM pin everything should be as smooth as necessary: The pwm is only muxed when the backlight device is successfully bound. The probe function (of the backlight) should have initialized the PWM with the right polarity. Until then nothing happens on the pin (either because it's not muxed as PWM or because the PWM is already initialized by the bootloader). The only thing that is (maybe) needed on top of my change is that the pwm isn't stopped in pwm-imx's .probe. > >> In probe you do not have any users yet. So you do not know the requested > >> output polarity. With "default" pinctrl the PWM output would be muxed to > >> the selected pin and since the PWM chip is most probably disabled > >> (unless you enabled it in bootloader) you would get low level on the pin. > >> That means your backlight is fully enabled until the first call to > >> imx_pwm_apply_v2(). On my system this is 2 seconds. > > > > With the gpio/pinmux approach you don't know the intended polarity > > either and maybe enable the display, too. > > You know it because the pinctrl solution is optional. So if you use it, > you use it on purpose to override the default PWM output level in PWM > disabled state. It is very useful in cases where you need inverted and > disabled PWM signal from power-up to userspace. Or until some kernel > driver (backlight, led, fan..) enables it. For this it is the only > solution I think. > > It allows you to boot with disabled PWM that has normal polarity set > by default. Later on from your userspace program you configure the PWM > to desired period/duty, set PWM output to inversed and enable it. > Until this point the circuit is disabled with my solution. > > > For both the solution is to let the bootloader enable the pwm with > > the right output level. Am I missing something? > > Bootloader is only a small part of the whole solution I think. And I > suppose you meant: "enable the *GPIO* with the right output level". No I meant the pwm. Well, it's as easy as that: Whenever with your approach you configure the pin as GPIO with the output set to low, instead configure the pwm with duty_cycle to zero (or disable it). Whenever with your approach you configure the pin as GPIO with the output set to high, configure the pwm with duty_cycle to 100%. (Keeping out inverted PWMs for the ease of discussion, but the procedure can be adapted accordingly.) The only difference then is that with your approach you already "know" in pwm-imx's .probe the idle level and can configure the GPIO accordingly. With my approach you just have to wait until the first pwm_apply which (as described above) works just as well. > - Even if you use GPIO in bootloader to set the required level the > time frame from imx_pwm_probe to imx_pwm_apply is not covered. > > - Currently there is no support in Linux pwm-imx driver to detect > the PWM chip is already enabled at probe time. I actually send > patches for this a month ago [1]. No response yet. > > - Inverted PWM does not work in U-Boot (on imx at least). And it > does not seam like it can be fixed easily. I do not know what is > the situation in other bootloaders. > > So my current bootloader solution is one of: > - Set the pin to the appropriate (HIGH) level using GPIO. > - Do not touch the pin at all, it has 100k pull-up by default. > > >> The other thing is I would prefer to make the change optional. With your > >> approach you are changing the behavior for all current users of inverted > >> PWM. I do not think all imx6 users are aware of the problem so they might > >> not be OK with the sudden change in the behavior. > > > > Isn't my change an improvement for all users? What state do you have in > > mind that make things worse than they are now? > > Lets say that the user: > - Needs inverted PWM signal. > - Needs it to be disabled all the time unless he enable it. I don't see why anybody should care if the PWM is "disabled". A user should only care about the output level, how the pwm-imx driver implements this is out of scope. As backlight-pwm user/author you shouldn't even care which PWM driver is in use. It might be even an implementation that cannot be disabled (like the bcm-kona one). > What you propose (for all users of inverted PWM): > H|____________________ _____________ > L| \___________________________________/ > +-------+------------+-----------------+-----------------+-------------+ > | reset | bootloader | default pinctrl | PWM enable 100% | PWM disable | > > My solution (for those who want it): > H|______________________________________ _____________ > L| \_________________/ > +-------+------------+-----------------+-----------------+-------------+ > | reset | bootloader | default pinctrl | PWM enable 100% | PWM disable | > With the above changes there is no relevant difference between your and my approach. I save your and my time to repeat this once more with these nice pictures. (If you don't believe me, I can do this later if you wish.) The nice upside of my approach however is that the pwm-imx driver stays simpler and the dts author doesn't need to care to add a gpio specifier and two pinmux configurations instead of one. > So your solution at least allows the user to really disable the circuit. > I can not really think of cases where this might not be good for current > users. Maybe that they simply expect that no matter what polarity is set, > the output in disabled state is always low. And they may have HW that > get already used to that and does not like the change :) > > And it reminds me of something similar I have done for OLED display reset > recently [2]. I tried to fix active-low reset sequence that is hardcoded > in the driver. So you are supposed to use GPIO_ACTIVE_HIGH in DT to make > the active-low reset work. It was rejected. The reason was backward DTB > compatibility [3]. In other words: "Users of newer kernels expect that > the reset still work the same if they do not update DTBs on their boards". > I think this is kind of similar? I don't see a compatibility issue here. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-08 19:18 ` Uwe Kleine-König @ 2018-11-09 14:24 ` Vokáč Michal 2018-11-09 16:55 ` Uwe Kleine-König 0 siblings, 1 reply; 60+ messages in thread From: Vokáč Michal @ 2018-11-09 14:24 UTC (permalink / raw) To: Uwe Kleine-König Cc: Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, Thierry Reding, kernel, Fabio Estevam, Lothar Waßmann On 8.11.2018 20:18, Uwe Kleine-König wrote: > On Thu, Nov 08, 2018 at 03:21:44PM +0000, Vokáč Michal wrote: >> Hi Uwe, >> >> On 7.11.2018 16:01, Uwe Kleine-König wrote: >>>> Interesting idea. I just wonder why nobody else did not come up with such >>>> a simple solution before. >>> >>> I think I mentioned it already in this thread, but it went unnoticed :-) >> >> I meant it like "How happened this was not invented years ago, when people >> first noticed the issue with using inverted PWM for backlight on i.MX6." >> In our project, this issue dates back to 2015 :( >> >>> Then the patch isn't correct yet. The idea is always keep the hardware >>> running and only disable it if it's uninverted. >> >> OK, I got the point. >> >>> In imx_pwm_probe it's not yet known what the polarity is supposed to be, >>> right? >> >> Not really. It can already be known but currently there is no way how to >> pass the information to the probe function. I, as a creator of the device >> (and author of a DTS file) know that the circuit needs inverted PWM signal. >> And I know that the circuit needs to be disabled until I say it can be >> enabled. How I say that can warry. It may be default brightness level > 0 >> in DTS file or from a userspace program using PWM sysfs interface. >> >>> So the right thing to do there is to not touch the configuration >>> of the pwm. I think all states that are problematic then are also >>> problematic with the gpio/pinmux approach. >> >> I think my use-case I already presented before is an example where >> involving pinctrl solves the problem while the "leave PWM enabled >> for inverted users" does not. That is all the time between >> imx_pwm_probe() and imx_pwm_apply_v2(). > > You're doing in probe: > > if (pwm_is_running()): > mux(pin, function=pwm) > else: > gpio_set_value(gpio, 0) > mux(pin, function=gpio) > > This gives you the right level assuming the gpio specification uses the > right flag (GPIO_ACTIVE_HIGH or GPIO_ACTIVE_LOW). Agree. > Taking your example with the backlight device you specify an "init" and > a "default" pinctrl and only "default" contains the muxing for the PWM > pin everything should be as smooth as necessary: The pwm is only muxed > when the backlight device is successfully bound. Have you tried that Uwe? The bad news is I tested that before and now again and it does not work like that. We already discussed that earlier. The "default" state is selected by the pinctrl core driver when imx-pwm's driver probe is finished. And it does not matter if the imx-pwm driver has some in-kernel users or not. See: https://elixir.bootlin.com/linux/v4.20-rc1/source/drivers/pinctrl/core.c#L1497 It is possible that I made some mistake. So this is what I have in DT: pinctrl_pwm: pwm1grp { // PWM out fsl,pins = <MX6QDL_PAD_GPIO_9__PWM1_OUT 0x8>; }: pinctrl_pwm_gpio: pwm1gpiogrp { // GPIO, 100k pull-up fsl,pins = <MX6QDL_PAD_GPIO_9__GPIO1_IO09 0xb000>; }; &pwm1 { #pwm-cells = <3>; pinctrl-names = "init", "default"; pinctrl-0 = <&pinctrl_pwm_gpio>; pinctrl-1 = <&pinctrl_pwm>; status = "okay"; }; The PWM output pin is not connected anywhere. It is flying in the breeze. I do not touch the pin configuration from bootloader. So the default is input, 100k pull-up. There is no user of the pwm1 anywhere in my DT. If what you say is correct I should see a straight HIGH level line on a scope from power-up to userspace. Unfortunately I do not. The output goes low as soon as the imx-pwm probe is finished. > The probe function (of > the backlight) should have initialized the PWM with the right polarity. Agree. > Until then nothing happens on the pin (either because it's not muxed as > PWM or because the PWM is already initialized by the bootloader). I do not agree. My tests repeatedly show it does not work like that. > The only thing that is (maybe) needed on top of my change is that the > pwm isn't stopped in pwm-imx's .probe. > >>>> In probe you do not have any users yet. So you do not know the requested >>>> output polarity. With "default" pinctrl the PWM output would be muxed to >>>> the selected pin and since the PWM chip is most probably disabled >>>> (unless you enabled it in bootloader) you would get low level on the pin. >>>> That means your backlight is fully enabled until the first call to >>>> imx_pwm_apply_v2(). On my system this is 2 seconds. >>> >>> With the gpio/pinmux approach you don't know the intended polarity >>> either and maybe enable the display, too. >> >> You know it because the pinctrl solution is optional. So if you use it, >> you use it on purpose to override the default PWM output level in PWM >> disabled state. It is very useful in cases where you need inverted and >> disabled PWM signal from power-up to userspace. Or until some kernel >> driver (backlight, led, fan..) enables it. For this it is the only >> solution I think. >> >> It allows you to boot with disabled PWM that has normal polarity set >> by default. Later on from your userspace program you configure the PWM >> to desired period/duty, set PWM output to inversed and enable it. >> Until this point the circuit is disabled with my solution. >> >>> For both the solution is to let the bootloader enable the pwm with >>> the right output level. Am I missing something? >> >> Bootloader is only a small part of the whole solution I think. And I >> suppose you meant: "enable the *GPIO* with the right output level". I am sorry I am confused. Were you talking about the bootloader code or about the kernel code? Because your previous sentence was clear to me: "For both the solution is to let the bootloader enable the pwm with the right output level". My comment to that is: I think it is not necessery to configure and enable PWM just to keep the right level on the pin. In bootloader. I would certainly use GPIO or nothing at all depending on what logic level I actually need. > No I meant the pwm. Well, it's as easy as that: Whenever with your > approach you configure the pin as GPIO with the output set to low, > instead configure the pwm with duty_cycle to zero (or disable it). > Whenever with your approach you configure the pin as GPIO with the > output set to high, configure the pwm with duty_cycle to 100%. (Keeping > out inverted PWMs for the ease of discussion, but the procedure can be > adapted accordingly.) The only difference then is that with your > approach you already "know" in pwm-imx's .probe the idle level and can > configure the GPIO accordingly. With my approach you just have to wait > until the first pwm_apply which (as described above) works just as well. While here I am quite confident you are talking about kernel code, right? If yes, then your approach is clear to me. The problem is I am quite sure your approach does not solve the cases the pinctrl solution does. And according to my tests so far it does not work at all because the "init" and "default" states does not work as you are saying. >> - Even if you use GPIO in bootloader to set the required level the >> time frame from imx_pwm_probe to imx_pwm_apply is not covered. >> >> - Currently there is no support in Linux pwm-imx driver to detect >> the PWM chip is already enabled at probe time. I actually send >> patches for this a month ago [1]. No response yet. >> >> - Inverted PWM does not work in U-Boot (on imx at least). And it >> does not seam like it can be fixed easily. I do not know what is >> the situation in other bootloaders. >> >> So my current bootloader solution is one of: >> - Set the pin to the appropriate (HIGH) level using GPIO. >> - Do not touch the pin at all, it has 100k pull-up by default. >> >>>> The other thing is I would prefer to make the change optional. With your >>>> approach you are changing the behavior for all current users of inverted >>>> PWM. I do not think all imx6 users are aware of the problem so they might >>>> not be OK with the sudden change in the behavior. >>> >>> Isn't my change an improvement for all users? What state do you have in >>> mind that make things worse than they are now? >> >> Lets say that the user: >> - Needs inverted PWM signal. >> - Needs it to be disabled all the time unless he enable it. > > I don't see why anybody should care if the PWM is "disabled". A user > should only care about the output level, how the pwm-imx driver > implements this is out of scope. Agree. That is what I meant. Here my "PWM signal disabled" == yours "right output level". > As backlight-pwm user/author you > shouldn't even care which PWM driver is in use. It might be even an > implementation that cannot be disabled (like the bcm-kona one). > >> What you propose (for all users of inverted PWM): >> H|____________________ _____________ >> L| \___________________________________/ >> +-------+------------+-----------------+-----------------+-------------+ >> | reset | bootloader | default pinctrl | PWM enable 100% | PWM disable | >> >> My solution (for those who want it): >> H|______________________________________ _____________ >> L| \_________________/ >> +-------+------------+-----------------+-----------------+-------------+ >> | reset | bootloader | default pinctrl | PWM enable 100% | PWM disable | I made a copy-paste mistake here, ^this^ should be "gpio pinctrl". And: "PWM enable 100%" == "echo $(cat period) > duty_cycle" "PWM disable" == "echo 0 > enabled" > With the above changes there is no relevant difference between your and > my approach. I save your and my time to repeat this once more with these > nice pictures. (If you don't believe me, I can do this later if you > wish.) The nice upside of my approach however is that the pwm-imx driver > stays simpler and the dts author doesn't need to care to add a gpio > specifier and two pinmux configurations instead of one. Even if it would work I am aware your solution would not be as simple as you think. Do you have a working code/example? What about this case: - Boot the system into userspace. - At this point user configures the PWM like this: $ echo 500000 > period $ echo 100000 > duty_cycle $ echo inversed > polarity $ echo 1 > enabled - After some time the user decides to stop the PWM signal: $ echo 0 > enabled With your approach you need to fully configure the PWM to produce 0% duty cycle signal to keep HIGH level on the pin. Not just let it run as it is. I only spent short time looking at the code trying to figure out how I would do that. And I could not come up with a simple solution that does not radically change all the current if-else logic. But my experience is limited. >> So your solution at least allows the user to really disable the circuit. >> I can not really think of cases where this might not be good for current >> users. Maybe that they simply expect that no matter what polarity is set, >> the output in disabled state is always low. And they may have HW that >> get already used to that and does not like the change :) >> >> And it reminds me of something similar I have done for OLED display reset >> recently [2]. I tried to fix active-low reset sequence that is hardcoded >> in the driver. So you are supposed to use GPIO_ACTIVE_HIGH in DT to make >> the active-low reset work. It was rejected. The reason was backward DTB >> compatibility [3]. In other words: "Users of newer kernels expect that >> the reset still work the same if they do not update DTBs on their boards". >> I think this is kind of similar? > > I don't see a compatibility issue here. Then it is fine. I am happy to accept/implement any "non-pinctrl/GPIO" solution as soon as it solves all the cases I am trying to cover. That is: - Allow pwm-backlight users to disable their backlight with inverted PWM. - Allow unchanged level on the PWM pin from power-up to first pwm_apply. - Allow to enable and configure PWM to any period/duty in bootloader and reuse that state in Linux imx-pwm driver. Anyway, thank you for all the comments and your time you are spending on this. Michal ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-09 14:24 ` Vokáč Michal @ 2018-11-09 16:55 ` Uwe Kleine-König 2018-11-14 9:09 ` Uwe Kleine-König 2018-11-14 11:34 ` Thierry Reding 0 siblings, 2 replies; 60+ messages in thread From: Uwe Kleine-König @ 2018-11-09 16:55 UTC (permalink / raw) To: Vokáč Michal Cc: Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, Thierry Reding, kernel, Fabio Estevam, Lothar Waßmann On Fri, Nov 09, 2018 at 02:24:42PM +0000, Vokáč Michal wrote: > On 8.11.2018 20:18, Uwe Kleine-König wrote: > > On Thu, Nov 08, 2018 at 03:21:44PM +0000, Vokáč Michal wrote: > >> Hi Uwe, > >> > >> On 7.11.2018 16:01, Uwe Kleine-König wrote: > >>>> Interesting idea. I just wonder why nobody else did not come up with such > >>>> a simple solution before. > >>> > >>> I think I mentioned it already in this thread, but it went unnoticed :-) > >> > >> I meant it like "How happened this was not invented years ago, when people > >> first noticed the issue with using inverted PWM for backlight on i.MX6." > >> In our project, this issue dates back to 2015 :( > >> > >>> Then the patch isn't correct yet. The idea is always keep the hardware > >>> running and only disable it if it's uninverted. > >> > >> OK, I got the point. > >> > >>> In imx_pwm_probe it's not yet known what the polarity is supposed to be, > >>> right? > >> > >> Not really. It can already be known but currently there is no way how to > >> pass the information to the probe function. I, as a creator of the device > >> (and author of a DTS file) know that the circuit needs inverted PWM signal. > >> And I know that the circuit needs to be disabled until I say it can be > >> enabled. How I say that can warry. It may be default brightness level > 0 > >> in DTS file or from a userspace program using PWM sysfs interface. > >> > >>> So the right thing to do there is to not touch the configuration > >>> of the pwm. I think all states that are problematic then are also > >>> problematic with the gpio/pinmux approach. > >> > >> I think my use-case I already presented before is an example where > >> involving pinctrl solves the problem while the "leave PWM enabled > >> for inverted users" does not. That is all the time between > >> imx_pwm_probe() and imx_pwm_apply_v2(). > > > > You're doing in probe: > > > > if (pwm_is_running()): > > mux(pin, function=pwm) > > else: > > gpio_set_value(gpio, 0) > > mux(pin, function=gpio) > > > > This gives you the right level assuming the gpio specification uses the > > right flag (GPIO_ACTIVE_HIGH or GPIO_ACTIVE_LOW). > > Agree. > > > Taking your example with the backlight device you specify an "init" and > > a "default" pinctrl and only "default" contains the muxing for the PWM > > pin everything should be as smooth as necessary: The pwm is only muxed > > when the backlight device is successfully bound. > > Have you tried that Uwe? The bad news is I tested that before and now > again and it does not work like that. We already discussed that earlier. The key is that the pinmux setting for the PWM pin should be part of the bl pinctrl, not the pwm pinctrl. Then "default" is only setup when the bl device is successfully bound which is after the bl's .probe callback called pwm_apply(). > The "default" state is selected by the pinctrl core driver when imx-pwm's > driver probe is finished. And it does not matter if the imx-pwm driver > has some in-kernel users or not. See: > > https://elixir.bootlin.com/linux/v4.20-rc1/source/drivers/pinctrl/core.c#L1497 > > It is possible that I made some mistake. So this is what I have in DT: > > pinctrl_pwm: pwm1grp { > // PWM out > fsl,pins = <MX6QDL_PAD_GPIO_9__PWM1_OUT 0x8>; > }: > > pinctrl_pwm_gpio: pwm1gpiogrp { > // GPIO, 100k pull-up > fsl,pins = <MX6QDL_PAD_GPIO_9__GPIO1_IO09 0xb000>; > }; > > &pwm1 { > #pwm-cells = <3>; > pinctrl-names = "init", "default"; > pinctrl-0 = <&pinctrl_pwm_gpio>; > pinctrl-1 = <&pinctrl_pwm>; > status = "okay"; > }; With this dt snippet the effect is as you describe. But that's not what I meant. (Also "init" should/could be empty.) > > The probe function (of > > the backlight) should have initialized the PWM with the right polarity. > > Agree. > > > Until then nothing happens on the pin (either because it's not muxed as > > PWM or because the PWM is already initialized by the bootloader). > > I do not agree. My tests repeatedly show it does not work like that. See above. > > The only thing that is (maybe) needed on top of my change is that the > > pwm isn't stopped in pwm-imx's .probe. > > > >>>> In probe you do not have any users yet. So you do not know the requested > >>>> output polarity. With "default" pinctrl the PWM output would be muxed to > >>>> the selected pin and since the PWM chip is most probably disabled > >>>> (unless you enabled it in bootloader) you would get low level on the pin. > >>>> That means your backlight is fully enabled until the first call to > >>>> imx_pwm_apply_v2(). On my system this is 2 seconds. > >>> > >>> With the gpio/pinmux approach you don't know the intended polarity > >>> either and maybe enable the display, too. > >> > >> You know it because the pinctrl solution is optional. So if you use it, > >> you use it on purpose to override the default PWM output level in PWM > >> disabled state. It is very useful in cases where you need inverted and > >> disabled PWM signal from power-up to userspace. Or until some kernel > >> driver (backlight, led, fan..) enables it. For this it is the only > >> solution I think. > >> > >> It allows you to boot with disabled PWM that has normal polarity set > >> by default. Later on from your userspace program you configure the PWM > >> to desired period/duty, set PWM output to inversed and enable it. > >> Until this point the circuit is disabled with my solution. > >> > >>> For both the solution is to let the bootloader enable the pwm with > >>> the right output level. Am I missing something? > >> > >> Bootloader is only a small part of the whole solution I think. And I > >> suppose you meant: "enable the *GPIO* with the right output level". > > I am sorry I am confused. Were you talking about the bootloader code or > about the kernel code? Because your previous sentence was clear to me: > > "For both the solution is to let the bootloader enable the pwm > with the right output level". > > My comment to that is: I think it is not necessery to configure and > enable PWM just to keep the right level on the pin. In bootloader. > I would certainly use GPIO or nothing at all depending on what logic > level I actually need. That's a valid option, too, that should work with the solution that is implemented in the end. Both our ideas are compatible with that. > > No I meant the pwm. Well, it's as easy as that: Whenever with your > > approach you configure the pin as GPIO with the output set to low, > > instead configure the pwm with duty_cycle to zero (or disable it). > > Whenever with your approach you configure the pin as GPIO with the > > output set to high, configure the pwm with duty_cycle to 100%. (Keeping > > out inverted PWMs for the ease of discussion, but the procedure can be > > adapted accordingly.) The only difference then is that with your > > approach you already "know" in pwm-imx's .probe the idle level and can > > configure the GPIO accordingly. With my approach you just have to wait > > until the first pwm_apply which (as described above) works just as well. > > While here I am quite confident you are talking about kernel code, right? > If yes, then your approach is clear to me. > > The problem is I am quite sure your approach does not solve the cases > the pinctrl solution does. And according to my tests so far it does not > work at all because the "init" and "default" states does not work as you > are saying. That's as pointed out above, because you're looking at the pwm's pinctrl and I at the pwm-consumer's pinctrl. Note that a sysfs consumer cannot be operated smoothly here, because there is no pinctrl node to add the PWM mode to that only gets active after the first configuration. This however is something that should not be addressed in the imx driver but in the pwm core (if at all). > With your approach you need to fully configure the PWM to produce 0% duty > cycle signal to keep HIGH level on the pin. Not just let it run as it is. > I only spent short time looking at the code trying to figure out how I > would do that. And I could not come up with a simple solution that does > not radically change all the current if-else logic. But my experience is > limited. Ah right, that's something I forgot in my patch. On disable of an inverted PWM it is necessary to configure the pwm to output a 1. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-09 16:55 ` Uwe Kleine-König @ 2018-11-14 9:09 ` Uwe Kleine-König 2018-11-14 11:34 ` Thierry Reding 1 sibling, 0 replies; 60+ messages in thread From: Uwe Kleine-König @ 2018-11-14 9:09 UTC (permalink / raw) To: Vokáč Michal Cc: Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, Thierry Reding, kernel, Fabio Estevam, Lothar Waßmann Hello Michal, On Fri, Nov 09, 2018 at 05:55:55PM +0100, Uwe Kleine-König wrote: > On Fri, Nov 09, 2018 at 02:24:42PM +0000, Vokáč Michal wrote: > > On 8.11.2018 20:18, Uwe Kleine-König wrote: > > > On Thu, Nov 08, 2018 at 03:21:44PM +0000, Vokáč Michal wrote: > > >> Hi Uwe, > > >> > > >> On 7.11.2018 16:01, Uwe Kleine-König wrote: > > >>>> Interesting idea. I just wonder why nobody else did not come up with such > > >>>> a simple solution before. > > >>> > > >>> I think I mentioned it already in this thread, but it went unnoticed :-) > > >> > > >> I meant it like "How happened this was not invented years ago, when people > > >> first noticed the issue with using inverted PWM for backlight on i.MX6." > > >> In our project, this issue dates back to 2015 :( > > >> > > >>> Then the patch isn't correct yet. The idea is always keep the hardware > > >>> running and only disable it if it's uninverted. > > >> > > >> OK, I got the point. > > >> > > >>> In imx_pwm_probe it's not yet known what the polarity is supposed to be, > > >>> right? > > >> > > >> Not really. It can already be known but currently there is no way how to > > >> pass the information to the probe function. I, as a creator of the device > > >> (and author of a DTS file) know that the circuit needs inverted PWM signal. > > >> And I know that the circuit needs to be disabled until I say it can be > > >> enabled. How I say that can warry. It may be default brightness level > 0 > > >> in DTS file or from a userspace program using PWM sysfs interface. > > >> > > >>> So the right thing to do there is to not touch the configuration > > >>> of the pwm. I think all states that are problematic then are also > > >>> problematic with the gpio/pinmux approach. > > >> > > >> I think my use-case I already presented before is an example where > > >> involving pinctrl solves the problem while the "leave PWM enabled > > >> for inverted users" does not. That is all the time between > > >> imx_pwm_probe() and imx_pwm_apply_v2(). > > > > > > You're doing in probe: > > > > > > if (pwm_is_running()): > > > mux(pin, function=pwm) > > > else: > > > gpio_set_value(gpio, 0) > > > mux(pin, function=gpio) > > > > > > This gives you the right level assuming the gpio specification uses the > > > right flag (GPIO_ACTIVE_HIGH or GPIO_ACTIVE_LOW). > > > > Agree. > > > > > Taking your example with the backlight device you specify an "init" and > > > a "default" pinctrl and only "default" contains the muxing for the PWM > > > pin everything should be as smooth as necessary: The pwm is only muxed > > > when the backlight device is successfully bound. > > > > Have you tried that Uwe? The bad news is I tested that before and now > > again and it does not work like that. We already discussed that earlier. > > The key is that the pinmux setting for the PWM pin should be part of the > bl pinctrl, not the pwm pinctrl. Then "default" is only setup when the > bl device is successfully bound which is after the bl's .probe callback > called pwm_apply(). Did my mail clear up my suggestion? Do you agree it should work like this (or even did you test that, as I did not)? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-09 16:55 ` Uwe Kleine-König 2018-11-14 9:09 ` Uwe Kleine-König @ 2018-11-14 11:34 ` Thierry Reding 2018-11-14 21:51 ` Uwe Kleine-König 1 sibling, 1 reply; 60+ messages in thread From: Thierry Reding @ 2018-11-14 11:34 UTC (permalink / raw) To: Uwe Kleine-König Cc: Vokáč Michal, Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, kernel, Fabio Estevam, Lothar Waßmann [-- Attachment #1: Type: text/plain, Size: 6569 bytes --] On Fri, Nov 09, 2018 at 05:55:55PM +0100, Uwe Kleine-König wrote: > On Fri, Nov 09, 2018 at 02:24:42PM +0000, Vokáč Michal wrote: > > On 8.11.2018 20:18, Uwe Kleine-König wrote: > > > On Thu, Nov 08, 2018 at 03:21:44PM +0000, Vokáč Michal wrote: > > >> Hi Uwe, > > >> > > >> On 7.11.2018 16:01, Uwe Kleine-König wrote: > > >>>> Interesting idea. I just wonder why nobody else did not come up with such > > >>>> a simple solution before. > > >>> > > >>> I think I mentioned it already in this thread, but it went unnoticed :-) > > >> > > >> I meant it like "How happened this was not invented years ago, when people > > >> first noticed the issue with using inverted PWM for backlight on i.MX6." > > >> In our project, this issue dates back to 2015 :( > > >> > > >>> Then the patch isn't correct yet. The idea is always keep the hardware > > >>> running and only disable it if it's uninverted. > > >> > > >> OK, I got the point. > > >> > > >>> In imx_pwm_probe it's not yet known what the polarity is supposed to be, > > >>> right? > > >> > > >> Not really. It can already be known but currently there is no way how to > > >> pass the information to the probe function. I, as a creator of the device > > >> (and author of a DTS file) know that the circuit needs inverted PWM signal. > > >> And I know that the circuit needs to be disabled until I say it can be > > >> enabled. How I say that can warry. It may be default brightness level > 0 > > >> in DTS file or from a userspace program using PWM sysfs interface. > > >> > > >>> So the right thing to do there is to not touch the configuration > > >>> of the pwm. I think all states that are problematic then are also > > >>> problematic with the gpio/pinmux approach. > > >> > > >> I think my use-case I already presented before is an example where > > >> involving pinctrl solves the problem while the "leave PWM enabled > > >> for inverted users" does not. That is all the time between > > >> imx_pwm_probe() and imx_pwm_apply_v2(). > > > > > > You're doing in probe: > > > > > > if (pwm_is_running()): > > > mux(pin, function=pwm) > > > else: > > > gpio_set_value(gpio, 0) > > > mux(pin, function=gpio) > > > > > > This gives you the right level assuming the gpio specification uses the > > > right flag (GPIO_ACTIVE_HIGH or GPIO_ACTIVE_LOW). > > > > Agree. > > > > > Taking your example with the backlight device you specify an "init" and > > > a "default" pinctrl and only "default" contains the muxing for the PWM > > > pin everything should be as smooth as necessary: The pwm is only muxed > > > when the backlight device is successfully bound. > > > > Have you tried that Uwe? The bad news is I tested that before and now > > again and it does not work like that. We already discussed that earlier. > > The key is that the pinmux setting for the PWM pin should be part of the > bl pinctrl, not the pwm pinctrl. Then "default" is only setup when the > bl device is successfully bound which is after the bl's .probe callback > called pwm_apply(). No, that's not at all correct. Pinmux settings should reside with the consumer of the pin. In this case, the PWM is the consumer of the pin, whereas the backlight is the consumer of the *PWM*. The problem with making the PWM mode the "default" pinctrl state is that the default state will be applied before the driver is even probed. That makes it unsuitable for this case. I think what we really want here is explicitly "active" and "inactive" states for pinctrl where the PWM driver controls when exactly each state is applied. This solves the problem quite nicely because by default the pinctrl state isn't touched. For the case where the bootloader didn't initialize the PWM pin at all, the driver core won't do anything and keep it at the 100k pull-up default. Only when the PWM is actually taken into active use will the "active" state (i.e. PWM mode) be applied, so that the PWM can drive it with the right configuration to give the desired result. If the bootloader did initialize the PWM it would also work because then at PWM driver probe time we don't do anything either, keeping the pin in the PWM mode as configured by the bootloader and not touching the PWM configuration either. If hardware readout is implemented, we can load the exact state that we're in and seamlessly take over in the kernel driver. Enabling the PWM in this case would apply the current setting, which should be a no-op, or at least idempotent. > > > No I meant the pwm. Well, it's as easy as that: Whenever with your > > > approach you configure the pin as GPIO with the output set to low, > > > instead configure the pwm with duty_cycle to zero (or disable it). > > > Whenever with your approach you configure the pin as GPIO with the > > > output set to high, configure the pwm with duty_cycle to 100%. (Keeping > > > out inverted PWMs for the ease of discussion, but the procedure can be > > > adapted accordingly.) The only difference then is that with your > > > approach you already "know" in pwm-imx's .probe the idle level and can > > > configure the GPIO accordingly. With my approach you just have to wait > > > until the first pwm_apply which (as described above) works just as well. > > > > While here I am quite confident you are talking about kernel code, right? > > If yes, then your approach is clear to me. > > > > The problem is I am quite sure your approach does not solve the cases > > the pinctrl solution does. And according to my tests so far it does not > > work at all because the "init" and "default" states does not work as you > > are saying. > > That's as pointed out above, because you're looking at the pwm's pinctrl > and I at the pwm-consumer's pinctrl. > > Note that a sysfs consumer cannot be operated smoothly here, because > there is no pinctrl node to add the PWM mode to that only gets active > after the first configuration. This however is something that should not > be addressed in the imx driver but in the pwm core (if at all). With the pinctrl-based solution outlined above you can even operate a sysfs consumer properly. The pinctrl states are where they belong, with the PWM device and therefore they can be properly set when the PWM is used, rather than waiting for a PWM consumer to muck with the pinmux. Note how all the pieces are suddenly falling into place. In my experience that's usually a good indication that you're on the right track. Thierry [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-14 11:34 ` Thierry Reding @ 2018-11-14 21:51 ` Uwe Kleine-König 2018-11-15 15:25 ` Thierry Reding 2018-11-19 7:44 ` Linus Walleij 0 siblings, 2 replies; 60+ messages in thread From: Uwe Kleine-König @ 2018-11-14 21:51 UTC (permalink / raw) To: Thierry Reding Cc: Vokáč Michal, Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, kernel, Fabio Estevam, Lothar Waßmann, Linus Walleij Hello Thierry, On Wed, Nov 14, 2018 at 12:34:49PM +0100, Thierry Reding wrote: > On Fri, Nov 09, 2018 at 05:55:55PM +0100, Uwe Kleine-König wrote: > > On Fri, Nov 09, 2018 at 02:24:42PM +0000, Vokáč Michal wrote: > > > On 8.11.2018 20:18, Uwe Kleine-König wrote: > > > > Taking your example with the backlight device you specify an "init" and > > > > a "default" pinctrl and only "default" contains the muxing for the PWM > > > > pin everything should be as smooth as necessary: The pwm is only muxed > > > > when the backlight device is successfully bound. > > > > > > Have you tried that Uwe? The bad news is I tested that before and now > > > again and it does not work like that. We already discussed that earlier. > > > > The key is that the pinmux setting for the PWM pin should be part of the > > bl pinctrl, not the pwm pinctrl. Then "default" is only setup when the > > bl device is successfully bound which is after the bl's .probe callback > > called pwm_apply(). > > No, that's not at all correct. Pinmux settings should reside with the > consumer of the pin. In this case, the PWM is the consumer of the pin, > whereas the backlight is the consumer of the *PWM*. This is news to me. Adding Linus W. to Cc, maybe he can comment?! Grepping through the arm device trees it really seems common to put the pinctrl for the pwm pin into the pwm device. I didn't search in depth, but I didn't find a counter example. For GPIOs it is common that the pinmuxing is included in the GPIO's consumer pinctrl. Ditto for mdio busses whose pinctrl is included in the ethernet pinctrl. > The problem with making the PWM mode the "default" pinctrl state is that > the default state will be applied before the driver is even probed. That > makes it unsuitable for this case. I think what we really want here is > explicitly "active" and "inactive" states for pinctrl where the PWM > driver controls when exactly each state is applied. Note that this problem goes away nicely if the pwm pin is attached to the backlight. Because it's the backlight's driver that "knows" when the pwm is configured correctly and so the already existing mechanisms that setup the mux when the bl is correctly probed do the right thing at the right time. > This solves the problem quite nicely because by default the pinctrl > state isn't touched. For the case where the bootloader didn't initialize > the PWM pin at all, the driver core won't do anything and keep it at the > 100k pull-up default. Ditto if the pwm pinctrl is attached to the consumer without having to introduce new pwm-specific stuff. > Only when the PWM is actually taken into active use will the "active" > state (i.e. PWM mode) be applied, so that the PWM can drive it with > the right configuration to give the desired result. If the bootloader > did initialize the PWM it would also work because then at PWM driver > probe time we don't do anything either, keeping the pin in the PWM > mode as configured by the bootloader and not touching the PWM > configuration either. Ditto if the pwm pinctrl is attached to the consumer without having to introduce new pwm-specific stuff. > If hardware readout is implemented, we can load > the exact state that we're in and seamlessly take over in the kernel > driver. Enabling the PWM in this case would apply the current setting, > which should be a no-op, or at least idempotent. Ditto if the pwm pinctrl is attached to the consumer without having to introduce new pwm-specific stuff. > > > > No I meant the pwm. Well, it's as easy as that: Whenever with your > > > > approach you configure the pin as GPIO with the output set to low, > > > > instead configure the pwm with duty_cycle to zero (or disable it). > > > > Whenever with your approach you configure the pin as GPIO with the > > > > output set to high, configure the pwm with duty_cycle to 100%. (Keeping > > > > out inverted PWMs for the ease of discussion, but the procedure can be > > > > adapted accordingly.) The only difference then is that with your > > > > approach you already "know" in pwm-imx's .probe the idle level and can > > > > configure the GPIO accordingly. With my approach you just have to wait > > > > until the first pwm_apply which (as described above) works just as well. > > > > > > While here I am quite confident you are talking about kernel code, right? > > > If yes, then your approach is clear to me. > > > > > > The problem is I am quite sure your approach does not solve the cases > > > the pinctrl solution does. And according to my tests so far it does not > > > work at all because the "init" and "default" states does not work as you > > > are saying. > > > > That's as pointed out above, because you're looking at the pwm's pinctrl > > and I at the pwm-consumer's pinctrl. > > > > Note that a sysfs consumer cannot be operated smoothly here, because > > there is no pinctrl node to add the PWM mode to that only gets active > > after the first configuration. This however is something that should not > > be addressed in the imx driver but in the pwm core (if at all). > > With the pinctrl-based solution outlined above you can even operate a > sysfs consumer properly. The pinctrl states are where they belong, with > the PWM device and therefore they can be properly set when the PWM is > used, rather than waiting for a PWM consumer to muck with the pinmux. > > Note how all the pieces are suddenly falling into place. In my > experience that's usually a good indication that you're on the right > track. OK, sysfs is the only point where the "put pinctrl stuff into the pwm core (or driver)" is superior to the already existing and otherwise completely working status quo. (Apart from bugs that need fixing in your scenario, too.) Given that I would not want to encourage people to stick to the sysfs interface for their use case, that's ok IMHO. (And note that with the bootloader's help you can even do this in a smooth way today.) Other than that my approach looks more elegant to me (which obviously is subjective). It works in all cases apart from sysfs (which is special because it's not integrated into the device model) and there is no need to teach the pwm framework about pinmuxing and invent new pinctrl modes for it. Also dts writes don't need to lookup the needed GPIO numbers and pinctrl. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-14 21:51 ` Uwe Kleine-König @ 2018-11-15 15:25 ` Thierry Reding 2018-11-15 20:37 ` Uwe Kleine-König 2018-11-19 7:44 ` Linus Walleij 1 sibling, 1 reply; 60+ messages in thread From: Thierry Reding @ 2018-11-15 15:25 UTC (permalink / raw) To: Uwe Kleine-König Cc: Vokáč Michal, Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, kernel, Fabio Estevam, Lothar Waßmann, Linus Walleij [-- Attachment #1: Type: text/plain, Size: 9095 bytes --] On Wed, Nov 14, 2018 at 10:51:20PM +0100, Uwe Kleine-König wrote: > Hello Thierry, > > On Wed, Nov 14, 2018 at 12:34:49PM +0100, Thierry Reding wrote: > > On Fri, Nov 09, 2018 at 05:55:55PM +0100, Uwe Kleine-König wrote: > > > On Fri, Nov 09, 2018 at 02:24:42PM +0000, Vokáč Michal wrote: > > > > On 8.11.2018 20:18, Uwe Kleine-König wrote: > > > > > Taking your example with the backlight device you specify an "init" and > > > > > a "default" pinctrl and only "default" contains the muxing for the PWM > > > > > pin everything should be as smooth as necessary: The pwm is only muxed > > > > > when the backlight device is successfully bound. > > > > > > > > Have you tried that Uwe? The bad news is I tested that before and now > > > > again and it does not work like that. We already discussed that earlier. > > > > > > The key is that the pinmux setting for the PWM pin should be part of the > > > bl pinctrl, not the pwm pinctrl. Then "default" is only setup when the > > > bl device is successfully bound which is after the bl's .probe callback > > > called pwm_apply(). > > > > No, that's not at all correct. Pinmux settings should reside with the > > consumer of the pin. In this case, the PWM is the consumer of the pin, > > whereas the backlight is the consumer of the *PWM*. > > This is news to me. Adding Linus W. to Cc, maybe he can comment?! > > Grepping through the arm device trees it really seems common to put the > pinctrl for the pwm pin into the pwm device. I didn't search in depth, > but I didn't find a counter example. > > For GPIOs it is common that the pinmuxing is included in the GPIO's > consumer pinctrl. Ditto for mdio busses whose pinctrl is included in the > ethernet pinctrl. GPIO is different from PWM in that the GPIO is already the pin itself and is otherwise generic. So typically you put the pinmuxing options into the device tree node for the consumer of the GPIO, because it is only when the consumer uses the GPIO that you need to configure that pin as GPIO. For PWM, however, the PWM consumer is only the consumer of the PWM, but the PWM device itself is the real consumer of the pin that outputs the PWM signal. So the PWM determines when the pinmux states need to be applied, whereas the consumer of the PWM only deals with the PWM. For MDIO busses, I think they are usually part of, and driven by, the ethernet controller, so again it makes sense to put the pinmux into the node of the ethernet controller, because the ethernet controller is the user of the pins. > > The problem with making the PWM mode the "default" pinctrl state is that > > the default state will be applied before the driver is even probed. That > > makes it unsuitable for this case. I think what we really want here is > > explicitly "active" and "inactive" states for pinctrl where the PWM > > driver controls when exactly each state is applied. > > Note that this problem goes away nicely if the pwm pin is attached to > the backlight. Because it's the backlight's driver that "knows" when the > pwm is configured correctly and so the already existing mechanisms that > setup the mux when the bl is correctly probed do the right thing at the > right time. Actually that's not exactly true. The default pinctrl state will be applied before the driver's ->probe() implementation, so the pinctrl state will be active some time before even the backlight driver gets around to setting up the PWM. If you look at drivers/base/dd.c you'll see that really_probe() calls pinctrl_bind_pins() before calling the driver's ->probe() and will select the default state (unless there's also an "init" state defined, in which case that will get applied and only after successful probe will the default state be selected). So if you use only a default state, then you could even get into a situation where ->probe() return -EPROBE_DEFER and it would potentially take several seconds before the driver is reprobed, during which time the pinmux will already be set up but the PWM not configured properly and potentially outputting the wrong level. > > This solves the problem quite nicely because by default the pinctrl > > state isn't touched. For the case where the bootloader didn't initialize > > the PWM pin at all, the driver core won't do anything and keep it at the > > 100k pull-up default. > > Ditto if the pwm pinctrl is attached to the consumer without having to > introduce new pwm-specific stuff. Well yes, but you'd obviously also have to avoid using the "default" state, otherwise you'd run into the issues that I described above. > > > > > No I meant the pwm. Well, it's as easy as that: Whenever with your > > > > > approach you configure the pin as GPIO with the output set to low, > > > > > instead configure the pwm with duty_cycle to zero (or disable it). > > > > > Whenever with your approach you configure the pin as GPIO with the > > > > > output set to high, configure the pwm with duty_cycle to 100%. (Keeping > > > > > out inverted PWMs for the ease of discussion, but the procedure can be > > > > > adapted accordingly.) The only difference then is that with your > > > > > approach you already "know" in pwm-imx's .probe the idle level and can > > > > > configure the GPIO accordingly. With my approach you just have to wait > > > > > until the first pwm_apply which (as described above) works just as well. > > > > > > > > While here I am quite confident you are talking about kernel code, right? > > > > If yes, then your approach is clear to me. > > > > > > > > The problem is I am quite sure your approach does not solve the cases > > > > the pinctrl solution does. And according to my tests so far it does not > > > > work at all because the "init" and "default" states does not work as you > > > > are saying. > > > > > > That's as pointed out above, because you're looking at the pwm's pinctrl > > > and I at the pwm-consumer's pinctrl. > > > > > > Note that a sysfs consumer cannot be operated smoothly here, because > > > there is no pinctrl node to add the PWM mode to that only gets active > > > after the first configuration. This however is something that should not > > > be addressed in the imx driver but in the pwm core (if at all). > > > > With the pinctrl-based solution outlined above you can even operate a > > sysfs consumer properly. The pinctrl states are where they belong, with > > the PWM device and therefore they can be properly set when the PWM is > > used, rather than waiting for a PWM consumer to muck with the pinmux. > > > > Note how all the pieces are suddenly falling into place. In my > > experience that's usually a good indication that you're on the right > > track. > > OK, sysfs is the only point where the "put pinctrl stuff into the pwm > core (or driver)" is superior to the already existing and otherwise > completely working status quo. (Apart from bugs that need fixing in > your scenario, too.) Nope, sorry. It's superior in all of the other cases as well. You've said elsewhere already that the prerequisite for the current solution to support inverse polarity with the i.MX driver is to keep the driver running, even after the PWM is no longer used. Sorry but that's just not an option for me. > Given that I would not want to encourage people to stick to the sysfs > interface for their use case, that's ok IMHO. (And note that with the > bootloader's help you can even do this in a smooth way today.) No it's not. sysfs is a supported interface, so we shouldn't treat it differently from the other in-kernel users. And we also shouldn't rely on bootloaders to always do the right thing. People may not always be able to update the bootloader, or they may not have a use to drive a PWM from the bootloader and hence choose to leave it uninitialized. > Other than that my approach looks more elegant to me (which obviously is > subjective). It works in all cases apart from sysfs (which is special > because it's not integrated into the device model) and there is no need > to teach the pwm framework about pinmuxing and invent new pinctrl modes > for it. Elegance is useless if what you have doesn't work consistently and reliably. I don't understand your resistance to the pinctrl work. It's not rocket science. Michal already posted patches showing how it can be done and they're not very complicated. Also we're not doing anything out of the ordinary here. This is exactly the purpose of the pinctrl framework, so let's use the best tool at hand. > Also dts writes don't need to lookup the needed GPIO numbers and pinctrl. Just to clarify: I don't think that we need to get the GPIO number involved in this case, because we don't have to reconfigure the pin as GPIO to make this work. The only reason that Michal's proposal did that is because that was believed to be necessary. But if the pin can just be configured with a 100k pull-up, that's enough to pull the pin high when we need it. Thierry [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-15 15:25 ` Thierry Reding @ 2018-11-15 20:37 ` Uwe Kleine-König 2018-11-16 7:34 ` Lothar Waßmann 2018-11-16 9:51 ` Thierry Reding 0 siblings, 2 replies; 60+ messages in thread From: Uwe Kleine-König @ 2018-11-15 20:37 UTC (permalink / raw) To: Thierry Reding Cc: Vokáč Michal, Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, kernel, Fabio Estevam, Lothar Waßmann, Linus Walleij Hello Thierry, On Thu, Nov 15, 2018 at 04:25:45PM +0100, Thierry Reding wrote: > On Wed, Nov 14, 2018 at 10:51:20PM +0100, Uwe Kleine-König wrote: > > On Wed, Nov 14, 2018 at 12:34:49PM +0100, Thierry Reding wrote: > > > On Fri, Nov 09, 2018 at 05:55:55PM +0100, Uwe Kleine-König wrote: > > > > On Fri, Nov 09, 2018 at 02:24:42PM +0000, Vokáč Michal wrote: > > > > > On 8.11.2018 20:18, Uwe Kleine-König wrote: > > > > > > Taking your example with the backlight device you specify an "init" and > > > > > > a "default" pinctrl and only "default" contains the muxing for the PWM > > > > > > pin everything should be as smooth as necessary: The pwm is only muxed > > > > > > when the backlight device is successfully bound. > > > > > > > > > > Have you tried that Uwe? The bad news is I tested that before and now > > > > > again and it does not work like that. We already discussed that earlier. > > > > > > > > The key is that the pinmux setting for the PWM pin should be part of the > > > > bl pinctrl, not the pwm pinctrl. Then "default" is only setup when the > > > > bl device is successfully bound which is after the bl's .probe callback > > > > called pwm_apply(). > > > > > > No, that's not at all correct. Pinmux settings should reside with the > > > consumer of the pin. In this case, the PWM is the consumer of the pin, > > > whereas the backlight is the consumer of the *PWM*. > > > > This is news to me. Adding Linus W. to Cc, maybe he can comment?! > > > > Grepping through the arm device trees it really seems common to put the > > pinctrl for the pwm pin into the pwm device. I didn't search in depth, > > but I didn't find a counter example. > > > > For GPIOs it is common that the pinmuxing is included in the GPIO's > > consumer pinctrl. Ditto for mdio busses whose pinctrl is included in the > > ethernet pinctrl. > > GPIO is different from PWM in that the GPIO is already the pin itself > and is otherwise generic. So typically you put the pinmuxing options > into the device tree node for the consumer of the GPIO, because it is > only when the consumer uses the GPIO that you need to configure that > pin as GPIO. > > For PWM, however, the PWM consumer is only the consumer of the PWM, but > the PWM device itself is the real consumer of the pin that outputs the > PWM signal. So the PWM determines when the pinmux states need to be > applied, whereas the consumer of the PWM only deals with the PWM. > > For MDIO busses, I think they are usually part of, and driven by, the > ethernet controller, so again it makes sense to put the pinmux into the > node of the ethernet controller, because the ethernet controller is the > user of the pins. Maybe it was a bad idea to broaden the discussion to talk about gpios and ethernet stuff here. I'd still consider it a valid construct to put the pwm pin into the backlight's pinctrl unless Linux W. disagrees. > > > The problem with making the PWM mode the "default" pinctrl state is that > > > the default state will be applied before the driver is even probed. That > > > makes it unsuitable for this case. I think what we really want here is > > > explicitly "active" and "inactive" states for pinctrl where the PWM > > > driver controls when exactly each state is applied. > > > > Note that this problem goes away nicely if the pwm pin is attached to > > the backlight. Because it's the backlight's driver that "knows" when the > > pwm is configured correctly and so the already existing mechanisms that > > setup the mux when the bl is correctly probed do the right thing at the > > right time. > > Actually that's not exactly true. The default pinctrl state will be > applied before the driver's ->probe() implementation, so the pinctrl > state will be active some time before even the backlight driver gets > around to setting up the PWM. If you look at drivers/base/dd.c you'll > see that really_probe() calls pinctrl_bind_pins() before calling the > driver's ->probe() and will select the default state (unless there's > also an "init" state defined, in which case that will get applied and > only after successful probe will the default state be selected). > > So if you use only a default state, then you could even get into a > situation where ->probe() return -EPROBE_DEFER and it would potentially > take several seconds before the driver is reprobed, during which time > the pinmux will already be set up but the PWM not configured properly > and potentially outputting the wrong level. If you reread my suggestion to Michal completely you will notice I got that right. > > > This solves the problem quite nicely because by default the pinctrl > > > state isn't touched. For the case where the bootloader didn't initialize > > > the PWM pin at all, the driver core won't do anything and keep it at the > > > 100k pull-up default. > > > > Ditto if the pwm pinctrl is attached to the consumer without having to > > introduce new pwm-specific stuff. > > Well yes, but you'd obviously also have to avoid using the "default" > state, otherwise you'd run into the issues that I described above. I'd need "default" and "init", right. > > > > > > No I meant the pwm. Well, it's as easy as that: Whenever with your > > > > > > approach you configure the pin as GPIO with the output set to low, > > > > > > instead configure the pwm with duty_cycle to zero (or disable it). > > > > > > Whenever with your approach you configure the pin as GPIO with the > > > > > > output set to high, configure the pwm with duty_cycle to 100%. (Keeping > > > > > > out inverted PWMs for the ease of discussion, but the procedure can be > > > > > > adapted accordingly.) The only difference then is that with your > > > > > > approach you already "know" in pwm-imx's .probe the idle level and can > > > > > > configure the GPIO accordingly. With my approach you just have to wait > > > > > > until the first pwm_apply which (as described above) works just as well. > > > > > > > > > > While here I am quite confident you are talking about kernel code, right? > > > > > If yes, then your approach is clear to me. > > > > > > > > > > The problem is I am quite sure your approach does not solve the cases > > > > > the pinctrl solution does. And according to my tests so far it does not > > > > > work at all because the "init" and "default" states does not work as you > > > > > are saying. > > > > > > > > That's as pointed out above, because you're looking at the pwm's pinctrl > > > > and I at the pwm-consumer's pinctrl. > > > > > > > > Note that a sysfs consumer cannot be operated smoothly here, because > > > > there is no pinctrl node to add the PWM mode to that only gets active > > > > after the first configuration. This however is something that should not > > > > be addressed in the imx driver but in the pwm core (if at all). > > > > > > With the pinctrl-based solution outlined above you can even operate a > > > sysfs consumer properly. The pinctrl states are where they belong, with > > > the PWM device and therefore they can be properly set when the PWM is > > > used, rather than waiting for a PWM consumer to muck with the pinmux. > > > > > > Note how all the pieces are suddenly falling into place. In my > > > experience that's usually a good indication that you're on the right > > > track. > > > > OK, sysfs is the only point where the "put pinctrl stuff into the pwm > > core (or driver)" is superior to the already existing and otherwise > > completely working status quo. (Apart from bugs that need fixing in > > your scenario, too.) > > Nope, sorry. It's superior in all of the other cases as well. You've > said elsewhere already that the prerequisite for the current solution to > support inverse polarity with the i.MX driver is to keep the driver > running, even after the PWM is no longer used. Sorry but that's just not > an option for me. You want that after pwm_disable() the pin still keeps the idle level. As the hardware doesn't provide this feature "as is" something has to be done about it. This can be reached either by operating the pin as PWM with 0% duty cycle or by switching to GPIO that is configured to the desired level. From the PWM driver's POV the first is the more natural, as this can be accomplished with the registers this driver cares about anyhow. Also note this is similar in the pwm-bcm-kona driver that doesn't seem to have the concept of "disable" at all. kona_pwmc_disable() just sets up 0% duty cycle. In my eyes this is an argument that is good enough to at least nack the imx-specific implementation of that pinctrl stuff. If the pinctrl idea is implemented in the pwm core, I won't object. > > Given that I would not want to encourage people to stick to the sysfs > > interface for their use case, that's ok IMHO. (And note that with the > > bootloader's help you can even do this in a smooth way today.) > > No it's not. sysfs is a supported interface, so we shouldn't treat it > differently from the other in-kernel users. And we also shouldn't rely > on bootloaders to always do the right thing. People may not always be > able to update the bootloader, or they may not have a use to drive a > PWM from the bootloader and hence choose to leave it uninitialized. If they are unable to adapt the bootloader they might be unable to (for example) keep a display off until the kernel takes full control of all necessary hardware to disable it. Yes, you might call that "bad hardware design" if the display is on after a power cycle. I call it "reality". And if these people care about each edge on the pwm output because the PWM is connected to a rocket engine, they better have control over the bootloader. > > Other than that my approach looks more elegant to me (which obviously is > > subjective). It works in all cases apart from sysfs (which is special > > because it's not integrated into the device model) and there is no need > > to teach the pwm framework about pinmuxing and invent new pinctrl modes > > for it. > > Elegance is useless if what you have doesn't work consistently and > reliably. > > I don't understand your resistance to the pinctrl work. It's not rocket > science. Michal already posted patches showing how it can be done and > they're not very complicated. Also we're not doing anything out of the > ordinary here. This is exactly the purpose of the pinctrl framework, so > let's use the best tool at hand. In my last exchange with Michal I had the impression that he liked my approach, too. > > Also dts writes don't need to lookup the needed GPIO numbers and pinctrl. > > Just to clarify: I don't think that we need to get the GPIO number > involved in this case, because we don't have to reconfigure the pin as > GPIO to make this work. The only reason that Michal's proposal did that > is because that was believed to be necessary. But if the pin can just be > configured with a 100k pull-up, that's enough to pull the pin high when > we need it. Unless the gpio happens to be configured as output at the wrong value. Further I'm not sure if the pwm in disabled state actively pulls to 0 and if in this state the PU of the pin is good enough to ensure a one here. That would need verification first. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-15 20:37 ` Uwe Kleine-König @ 2018-11-16 7:34 ` Lothar Waßmann 2018-11-16 8:25 ` Uwe Kleine-König 2018-11-16 9:51 ` Thierry Reding 1 sibling, 1 reply; 60+ messages in thread From: Lothar Waßmann @ 2018-11-16 7:34 UTC (permalink / raw) To: Uwe Kleine-König Cc: Thierry Reding, Vokáč Michal, Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, kernel, Fabio Estevam, Linus Walleij Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote: > Hello Thierry, > > On Thu, Nov 15, 2018 at 04:25:45PM +0100, Thierry Reding wrote: > > On Wed, Nov 14, 2018 at 10:51:20PM +0100, Uwe Kleine-König wrote: > > > On Wed, Nov 14, 2018 at 12:34:49PM +0100, Thierry Reding wrote: [...] > > > Also dts writes don't need to lookup the needed GPIO numbers and pinctrl. > > > > Just to clarify: I don't think that we need to get the GPIO number > > involved in this case, because we don't have to reconfigure the pin as > > GPIO to make this work. The only reason that Michal's proposal did that > > is because that was believed to be necessary. But if the pin can just be > > configured with a 100k pull-up, that's enough to pull the pin high when > > we need it. > > Unless the gpio happens to be configured as output at the wrong value. > Further I'm not sure if the pwm in disabled state actively pulls to 0 > and if in this state the PU of the pin is good enough to ensure a one > here. That would need verification first. > No. You can disable the output driver via pinctrl, so that only the selected pull-up/down is relevant. The pin function and GPIO register settings don't matter at all in this case. Lothar Waßmann -- ___________________________________________________________ Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10 Geschäftsführer: Matthias Kaussen Handelsregistereintrag: Amtsgericht Aachen, HRB 4996 www.karo-electronics.de | info@karo-electronics.de ___________________________________________________________ ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-16 7:34 ` Lothar Waßmann @ 2018-11-16 8:25 ` Uwe Kleine-König 2018-11-22 15:42 ` Vokáč Michal 0 siblings, 1 reply; 60+ messages in thread From: Uwe Kleine-König @ 2018-11-16 8:25 UTC (permalink / raw) To: Lothar Waßmann Cc: Thierry Reding, Vokáč Michal, Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, kernel, Fabio Estevam, Linus Walleij On Fri, Nov 16, 2018 at 08:34:30AM +0100, Lothar Waßmann wrote: > Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote: > > > Hello Thierry, > > > > On Thu, Nov 15, 2018 at 04:25:45PM +0100, Thierry Reding wrote: > > > On Wed, Nov 14, 2018 at 10:51:20PM +0100, Uwe Kleine-König wrote: > > > > On Wed, Nov 14, 2018 at 12:34:49PM +0100, Thierry Reding wrote: > [...] > > > > Also dts writes don't need to lookup the needed GPIO numbers and pinctrl. > > > > > > Just to clarify: I don't think that we need to get the GPIO number > > > involved in this case, because we don't have to reconfigure the pin as > > > GPIO to make this work. The only reason that Michal's proposal did that > > > is because that was believed to be necessary. But if the pin can just be > > > configured with a 100k pull-up, that's enough to pull the pin high when > > > we need it. > > > > Unless the gpio happens to be configured as output at the wrong value. > > Further I'm not sure if the pwm in disabled state actively pulls to 0 > > and if in this state the PU of the pin is good enough to ensure a one > > here. That would need verification first. > > No. You can disable the output driver via pinctrl, so that only the > selected pull-up/down is relevant. The pin function and GPIO register > settings don't matter at all in this case. Is this about DSE=HI-Z in the pad control register? I didn't know about this. I see this exists on i.MX6 but not on i.MX25. Also i.MX51 doesn't seem to have this feature. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-16 8:25 ` Uwe Kleine-König @ 2018-11-22 15:42 ` Vokáč Michal 2018-11-22 16:23 ` Uwe Kleine-König 0 siblings, 1 reply; 60+ messages in thread From: Vokáč Michal @ 2018-11-22 15:42 UTC (permalink / raw) To: Uwe Kleine-König, Lothar Waßmann, Thierry Reding Cc: Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, kernel, Fabio Estevam, Linus Walleij, viresh kumar On 16.11.2018 09:25, Uwe Kleine-König wrote: > On Fri, Nov 16, 2018 at 08:34:30AM +0100, Lothar Waßmann wrote: >> Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote: >>> On Thu, Nov 15, 2018 at 04:25:45PM +0100, Thierry Reding wrote: >>>> On Wed, Nov 14, 2018 at 10:51:20PM +0100, Uwe Kleine-König wrote: >>>>> On Wed, Nov 14, 2018 at 12:34:49PM +0100, Thierry Reding wrote: >> [...] >>>>> Also dts writes don't need to lookup the needed GPIO numbers and pinctrl. >>>> >>>> Just to clarify: I don't think that we need to get the GPIO number >>>> involved in this case, because we don't have to reconfigure the pin as >>>> GPIO to make this work. The only reason that Michal's proposal did that >>>> is because that was believed to be necessary. But if the pin can just be >>>> configured with a 100k pull-up, that's enough to pull the pin high when >>>> we need it. Thierry, I have to disagree here. I do not really know how to activate the internal pull-up without requesting the GPIO and configuring the pin as *input*. And to do it the GPIO number needs to be specified in DT. >>> Unless the gpio happens to be configured as output at the wrong value. >>> Further I'm not sure if the pwm in disabled state actively pulls to 0 >>> and if in this state the PU of the pin is good enough to ensure a one >>> here. That would need verification first. >> >> No. You can disable the output driver via pinctrl, so that only the >> selected pull-up/down is relevant. The pin function and GPIO register >> settings don't matter at all in this case. Lothar, please can you be more specific how would you do that? IFAIK the pull-up/down internal resistors have effect only if the pin is configured as GPIO *input* (on i.MX6 at least). See the TRM, 29.4.2.2 Output driver: "Internal pull-up, pull-down resistors, and pad keeper are disabled in output mode." > Is this about DSE=HI-Z in the pad control register? I didn't know about > this. I see this exists on i.MX6 but not on i.MX25. Also i.MX51 doesn't > seem to have this feature. Uwe, I also did not find the DSE option on other SoCs in their respective manuals and source code. But even if it would be available on all SoCs I still think it is not enough. Best regards, Michal ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-22 15:42 ` Vokáč Michal @ 2018-11-22 16:23 ` Uwe Kleine-König 2018-11-22 16:46 ` Vokáč Michal 0 siblings, 1 reply; 60+ messages in thread From: Uwe Kleine-König @ 2018-11-22 16:23 UTC (permalink / raw) To: Vokáč Michal Cc: Lothar Waßmann, Thierry Reding, Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, kernel, Fabio Estevam, Linus Walleij, viresh kumar Hello Michal, On Thu, Nov 22, 2018 at 03:42:14PM +0000, Vokáč Michal wrote: > On 16.11.2018 09:25, Uwe Kleine-König wrote: > > On Fri, Nov 16, 2018 at 08:34:30AM +0100, Lothar Waßmann wrote: > > > No. You can disable the output driver via pinctrl, so that only the > > > selected pull-up/down is relevant. The pin function and GPIO register > > > settings don't matter at all in this case. > > Lothar, please can you be more specific how would you do that? IFAIK the > pull-up/down internal resistors have effect only if the pin is configured > as GPIO *input* (on i.MX6 at least). See the TRM, 29.4.2.2 Output driver: > > "Internal pull-up, pull-down resistors, and pad keeper are disabled in > output mode." > > > Is this about DSE=HI-Z in the pad control register? I didn't know about > > this. I see this exists on i.MX6 but not on i.MX25. Also i.MX51 doesn't > > seem to have this feature. > > Uwe, I also did not find the DSE option on other SoCs in their respective > manuals and source code. But even if it would be available on all SoCs > I still think it is not enough. If I understand Lothar correctly and this is about the pad control register, there is no need for software support. You just specify the value you want to have written to the pad register in the device tree. So I'd expect this to really work on i.MX6 but not the earlier SoCs without a gpio specifier. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-22 16:23 ` Uwe Kleine-König @ 2018-11-22 16:46 ` Vokáč Michal 2018-11-22 19:03 ` Uwe Kleine-König 0 siblings, 1 reply; 60+ messages in thread From: Vokáč Michal @ 2018-11-22 16:46 UTC (permalink / raw) To: Uwe Kleine-König Cc: Lothar Waßmann, Thierry Reding, Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, kernel, Fabio Estevam, Linus Walleij, viresh kumar On 22.11.2018 17:23, Uwe Kleine-König wrote: > Hello Michal, > > On Thu, Nov 22, 2018 at 03:42:14PM +0000, Vokáč Michal wrote: >> On 16.11.2018 09:25, Uwe Kleine-König wrote: >>> On Fri, Nov 16, 2018 at 08:34:30AM +0100, Lothar Waßmann wrote: >>>> No. You can disable the output driver via pinctrl, so that only the >>>> selected pull-up/down is relevant. The pin function and GPIO register >>>> settings don't matter at all in this case. >> >> Lothar, please can you be more specific how would you do that? IFAIK the >> pull-up/down internal resistors have effect only if the pin is configured >> as GPIO *input* (on i.MX6 at least). See the TRM, 29.4.2.2 Output driver: >> >> "Internal pull-up, pull-down resistors, and pad keeper are disabled in >> output mode." >> >>> Is this about DSE=HI-Z in the pad control register? I didn't know about >>> this. I see this exists on i.MX6 but not on i.MX25. Also i.MX51 doesn't >>> seem to have this feature. >> >> Uwe, I also did not find the DSE option on other SoCs in their respective >> manuals and source code. But even if it would be available on all SoCs >> I still think it is not enough. > > If I understand Lothar correctly and this is about the pad control > register, there is no need for software support. You just specify the > value you want to have written to the pad register in the device tree. I agree. But the pad control register is not the one that controls if the pad is configured as input or output. So if the pin happens to be configured as output the pull/keeper setting simply has no effect. > So I'd expect this to really work on i.MX6 but not the earlier SoCs > without a gpio specifier. Maybe you would expect it to work but I already tested and measured that weeks ago ;) It did not work. Michal ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-22 16:46 ` Vokáč Michal @ 2018-11-22 19:03 ` Uwe Kleine-König 2018-11-23 15:15 ` Vokáč Michal 0 siblings, 1 reply; 60+ messages in thread From: Uwe Kleine-König @ 2018-11-22 19:03 UTC (permalink / raw) To: Vokáč Michal Cc: Lothar Waßmann, Thierry Reding, Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, kernel, Fabio Estevam, Linus Walleij, viresh kumar Hello Michal, On Thu, Nov 22, 2018 at 04:46:39PM +0000, Vokáč Michal wrote: > On 22.11.2018 17:23, Uwe Kleine-König wrote: > > On Thu, Nov 22, 2018 at 03:42:14PM +0000, Vokáč Michal wrote: > >> On 16.11.2018 09:25, Uwe Kleine-König wrote: > >>> On Fri, Nov 16, 2018 at 08:34:30AM +0100, Lothar Waßmann wrote: > >>>> No. You can disable the output driver via pinctrl, so that only the > >>>> selected pull-up/down is relevant. The pin function and GPIO register > >>>> settings don't matter at all in this case. > >> > >> Lothar, please can you be more specific how would you do that? IFAIK the > >> pull-up/down internal resistors have effect only if the pin is configured > >> as GPIO *input* (on i.MX6 at least). See the TRM, 29.4.2.2 Output driver: > >> > >> "Internal pull-up, pull-down resistors, and pad keeper are disabled in > >> output mode." This would mean you'd have to rely on an external pull up for your use case. I wouldn't be surprised however if DSE=0 wouldn't count as "output mode". Given the reliability of NXP documentation I wouldn't bet neither on one nor the other possibility. > > So I'd expect this to really work on i.MX6 but not the earlier SoCs > > without a gpio specifier. > > Maybe you would expect it to work but I already tested and measured > that weeks ago ;) It did not work. Which pin/gpio do we talk about? Which i.MX6 variant did you test this on? (Assuming i.MX6D or i.MX6Q and PAD_DISP0_DATA09, did you try setting IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA09 (0x020E0194) = 0x00000005 IOMUXC_SW_PAD_CTL_PAD_DISP0_DATA09 (0x020E04A8) = 0x0000b080 and then play with GPIO 4.30 direction and output value?) Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-22 19:03 ` Uwe Kleine-König @ 2018-11-23 15:15 ` Vokáč Michal 2018-11-25 20:56 ` Uwe Kleine-König 2018-11-26 11:51 ` Thierry Reding 0 siblings, 2 replies; 60+ messages in thread From: Vokáč Michal @ 2018-11-23 15:15 UTC (permalink / raw) To: Uwe Kleine-König Cc: Lothar Waßmann, Thierry Reding, Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, kernel, Fabio Estevam, Linus Walleij, viresh kumar On 22.11.2018 20:03, Uwe Kleine-König wrote: > On Thu, Nov 22, 2018 at 04:46:39PM +0000, Vokáč Michal wrote: >> On 22.11.2018 17:23, Uwe Kleine-König wrote: >>> On Thu, Nov 22, 2018 at 03:42:14PM +0000, Vokáč Michal wrote: >>>> On 16.11.2018 09:25, Uwe Kleine-König wrote: >>>>> On Fri, Nov 16, 2018 at 08:34:30AM +0100, Lothar Waßmann wrote: >>>>>> No. You can disable the output driver via pinctrl, so that only the >>>>>> selected pull-up/down is relevant. The pin function and GPIO register >>>>>> settings don't matter at all in this case. >>>> >>>> Lothar, please can you be more specific how would you do that? IFAIK the >>>> pull-up/down internal resistors have effect only if the pin is configured >>>> as GPIO *input* (on i.MX6 at least). See the TRM, 29.4.2.2 Output driver: >>>> >>>> "Internal pull-up, pull-down resistors, and pad keeper are disabled in >>>> output mode." > > This would mean you'd have to rely on an external pull up for your use > case. I wouldn't be surprised however if DSE=0 wouldn't count as "output > mode". Given the reliability of NXP documentation I wouldn't bet neither > on one nor the other possibility. Yeah, the NXP documentation sometimes does not really match reality. My use case is based on the fact that I configure the pin as input in the driver. Then it works just fine. >>> So I'd expect this to really work on i.MX6 but not the earlier SoCs >>> without a gpio specifier. >> >> Maybe you would expect it to work but I already tested and measured >> that weeks ago ;) It did not work. > > Which pin/gpio do we talk about? Which i.MX6 variant did you test this > on? (Assuming i.MX6D or i.MX6Q and PAD_DISP0_DATA09, did you try setting > > IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA09 (0x020E0194) = 0x00000005 > IOMUXC_SW_PAD_CTL_PAD_DISP0_DATA09 (0x020E04A8) = 0x0000b080 > > and then play with GPIO 4.30 direction and output value?) My test setup is as follows: - SoC is i.MX6DL or i.MX6S - I have three board variants in total. - Pin used for PWM/GPIO is PAD_GPIO9. - The pin is not connected to any circuit. Just a test point. - pinctrl setup in DT: - for "pwm": - fsl,pins = <MX6QDL_PAD_GPIO_9__PWM1_OUT 0x8> - IOMUXC_SW_MUX_CTL_PAD_GPIO09 = 0x00000004 - IOMUXC_SW_PAD_CTL_PAD_GPIO09 = 0x00000008 - for "gpio": - fsl,pins = <MX6QDL_PAD_GPIO_9__GPIO1_IO09 0xb000> - IOMUXC_SW_MUX_CTL_PAD_GPIO09 = 0x00000005 - IOMUXC_SW_PAD_CTL_PAD_GPIO09 = 0x0000b000 Test scenario: - In bootloader configure the pin as GPIO output, set it LOW (0V). I set it LOW to start in the oposite state than I want to end up in. - Boot Linux - Use sysfs to configure the PWM to produce some signal. - In the PWM driver select the "pwm" pinctrl state. - Measure the output - expected waveform on the scope. - Use sysfs to stop the PWM "echo 0 > /sys/class/pwm/pwmchip0/pwm0/enable° - In the PWM driver select the "gpio" pinctrl state. - Then in the PWM driver: a) non-working variant - Do not request the GPIO - so do not touch its pad control reg. It is set as output from the bootloader, data register = 0. - Measure voltage on the output - against GND = 0V - against VCC = 0V - Measure resistance against VCC: Hi-Z The pin is in Hi-Z mode. That is fine but that does not satisfy any logic level. b) working variant - Request the GPIO, configure it as input. - Measure voltage on the output - against GND = VCC (3.3V) - against VCC = 0V - Measure resistance against VCC = 91.1kOhm The pull-up is active. I can repeat the results on both i.MX6DL and i.MX6S on pwm1 and pwm4. All pull-up and pull-down combinations gave me the expected results only if the pin is configured as input. So if I repeat the test and do not touch the pin in bootloader at all, it works as well even if I do not request/configure the GPIO in the PWM driver. But we can not rely on the fact that the pin is correctly configured from bootloader or that it is in the after-reset state. It should just work regardless of what state it was left in. Best regards, Michal ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-23 15:15 ` Vokáč Michal @ 2018-11-25 20:56 ` Uwe Kleine-König 2018-11-26 9:11 ` Lothar Waßmann 2018-11-26 11:51 ` Thierry Reding 1 sibling, 1 reply; 60+ messages in thread From: Uwe Kleine-König @ 2018-11-25 20:56 UTC (permalink / raw) To: Vokáč Michal Cc: Lothar Waßmann, Thierry Reding, Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, kernel, Fabio Estevam, Linus Walleij, viresh kumar Hello Michal, On Fri, Nov 23, 2018 at 03:15:11PM +0000, Vokáč Michal wrote: > On 22.11.2018 20:03, Uwe Kleine-König wrote: > > On Thu, Nov 22, 2018 at 04:46:39PM +0000, Vokáč Michal wrote: > >> On 22.11.2018 17:23, Uwe Kleine-König wrote: > >>> So I'd expect this to really work on i.MX6 but not the earlier SoCs > >>> without a gpio specifier. > >> > >> Maybe you would expect it to work but I already tested and measured > >> that weeks ago ;) It did not work. > > > > Which pin/gpio do we talk about? Which i.MX6 variant did you test this > > on? (Assuming i.MX6D or i.MX6Q and PAD_DISP0_DATA09, did you try setting > > > > IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA09 (0x020E0194) = 0x00000005 > > IOMUXC_SW_PAD_CTL_PAD_DISP0_DATA09 (0x020E04A8) = 0x0000b080 > > > > and then play with GPIO 4.30 direction and output value?) > > My test setup is as follows: > - SoC is i.MX6DL or i.MX6S - I have three board variants in total. > - Pin used for PWM/GPIO is PAD_GPIO9. > - The pin is not connected to any circuit. Just a test point. > - pinctrl setup in DT: > - for "pwm": > - fsl,pins = <MX6QDL_PAD_GPIO_9__PWM1_OUT 0x8> > - IOMUXC_SW_MUX_CTL_PAD_GPIO09 = 0x00000004 > - IOMUXC_SW_PAD_CTL_PAD_GPIO09 = 0x00000008 > > - for "gpio": > - fsl,pins = <MX6QDL_PAD_GPIO_9__GPIO1_IO09 0xb000> > - IOMUXC_SW_MUX_CTL_PAD_GPIO09 = 0x00000005 > - IOMUXC_SW_PAD_CTL_PAD_GPIO09 = 0x0000b000 FTR: I suggested 0x0000b080 here, but 0x0000b000 is just fine. > Test scenario: > > - In bootloader configure the pin as GPIO output, set it LOW (0V). > I set it LOW to start in the oposite state than I want to end up in. > - Boot Linux > - Use sysfs to configure the PWM to produce some signal. > - In the PWM driver select the "pwm" pinctrl state. > - Measure the output - expected waveform on the scope. > - Use sysfs to stop the PWM "echo 0 > /sys/class/pwm/pwmchip0/pwm0/enable° > - In the PWM driver select the "gpio" pinctrl state. > - Then in the PWM driver: > > a) non-working variant > - Do not request the GPIO - so do not touch its pad control reg. > It is set as output from the bootloader, data register = 0. > - Measure voltage on the output > - against GND = 0V > - against VCC = 0V > - Measure resistance against VCC: Hi-Z > > The pin is in Hi-Z mode. That is fine but that does not satisfy any > logic level. > > b) working variant > - Request the GPIO, configure it as input. > - Measure voltage on the output > - against GND = VCC (3.3V) > - against VCC = 0V > - Measure resistance against VCC = 91.1kOhm > > The pull-up is active. Thanks for your detailed test. So DSE = 0 doesn't work as I (and I think Lothar) expected. @Lothar: if Michal did something different than you expected, please tell us with a few more details. > I can repeat the results on both i.MX6DL and i.MX6S on pwm1 and pwm4. > All pull-up and pull-down combinations gave me the expected results > only if the pin is configured as input. So if I repeat the test and > do not touch the pin in bootloader at all, it works as well even if > I do not request/configure the GPIO in the PWM driver. OK. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-25 20:56 ` Uwe Kleine-König @ 2018-11-26 9:11 ` Lothar Waßmann 2018-11-26 9:18 ` Uwe Kleine-König 0 siblings, 1 reply; 60+ messages in thread From: Lothar Waßmann @ 2018-11-26 9:11 UTC (permalink / raw) To: Uwe Kleine-König Cc: Vokáč Michal, Thierry Reding, Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, kernel, Fabio Estevam, Linus Walleij, viresh kumar Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote: > Hello Michal, > > On Fri, Nov 23, 2018 at 03:15:11PM +0000, Vokáč Michal wrote: > > On 22.11.2018 20:03, Uwe Kleine-König wrote: > > > On Thu, Nov 22, 2018 at 04:46:39PM +0000, Vokáč Michal wrote: > > >> On 22.11.2018 17:23, Uwe Kleine-König wrote: > > >>> So I'd expect this to really work on i.MX6 but not the earlier SoCs > > >>> without a gpio specifier. > > >> > > >> Maybe you would expect it to work but I already tested and measured > > >> that weeks ago ;) It did not work. > > > > > > Which pin/gpio do we talk about? Which i.MX6 variant did you test this > > > on? (Assuming i.MX6D or i.MX6Q and PAD_DISP0_DATA09, did you try setting > > > > > > IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA09 (0x020E0194) = 0x00000005 > > > IOMUXC_SW_PAD_CTL_PAD_DISP0_DATA09 (0x020E04A8) = 0x0000b080 > > > > > > and then play with GPIO 4.30 direction and output value?) > > > > My test setup is as follows: > > - SoC is i.MX6DL or i.MX6S - I have three board variants in total. > > - Pin used for PWM/GPIO is PAD_GPIO9. > > - The pin is not connected to any circuit. Just a test point. > > - pinctrl setup in DT: > > - for "pwm": > > - fsl,pins = <MX6QDL_PAD_GPIO_9__PWM1_OUT 0x8> > > - IOMUXC_SW_MUX_CTL_PAD_GPIO09 = 0x00000004 > > - IOMUXC_SW_PAD_CTL_PAD_GPIO09 = 0x00000008 > > > > - for "gpio": > > - fsl,pins = <MX6QDL_PAD_GPIO_9__GPIO1_IO09 0xb000> > > - IOMUXC_SW_MUX_CTL_PAD_GPIO09 = 0x00000005 > > - IOMUXC_SW_PAD_CTL_PAD_GPIO09 = 0x0000b000 > > FTR: I suggested 0x0000b080 here, but 0x0000b000 is just fine. > > > Test scenario: > > > > - In bootloader configure the pin as GPIO output, set it LOW (0V). > > I set it LOW to start in the oposite state than I want to end up in. > > - Boot Linux > > - Use sysfs to configure the PWM to produce some signal. > > - In the PWM driver select the "pwm" pinctrl state. > > - Measure the output - expected waveform on the scope. > > - Use sysfs to stop the PWM "echo 0 > /sys/class/pwm/pwmchip0/pwm0/enable° > > - In the PWM driver select the "gpio" pinctrl state. > > - Then in the PWM driver: > > > > a) non-working variant > > - Do not request the GPIO - so do not touch its pad control reg. > > It is set as output from the bootloader, data register = 0. > > - Measure voltage on the output > > - against GND = 0V > > - against VCC = 0V > > - Measure resistance against VCC: Hi-Z > > > > The pin is in Hi-Z mode. That is fine but that does not satisfy any > > logic level. > > > > b) working variant > > - Request the GPIO, configure it as input. > > - Measure voltage on the output > > - against GND = VCC (3.3V) > > - against VCC = 0V > > - Measure resistance against VCC = 91.1kOhm > > > > The pull-up is active. > > Thanks for your detailed test. So DSE = 0 doesn't work as I (and I think > Lothar) expected. > > @Lothar: if Michal did something different than you expected, please > tell us with a few more details. > No, Michal's findings are in sync with what I checked here. Lothar Waßmann -- ___________________________________________________________ Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10 Geschäftsführer: Matthias Kaussen Handelsregistereintrag: Amtsgericht Aachen, HRB 4996 www.karo-electronics.de | info@karo-electronics.de ___________________________________________________________ ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-26 9:11 ` Lothar Waßmann @ 2018-11-26 9:18 ` Uwe Kleine-König 2018-11-26 10:03 ` Lothar Waßmann 0 siblings, 1 reply; 60+ messages in thread From: Uwe Kleine-König @ 2018-11-26 9:18 UTC (permalink / raw) To: Lothar Waßmann Cc: Vokáč Michal, Thierry Reding, Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, kernel, Fabio Estevam, Linus Walleij, viresh kumar Hallo Lothar, On Mon, Nov 26, 2018 at 10:11:16AM +0100, Lothar Waßmann wrote: > Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote: > > @Lothar: if Michal did something different than you expected, please > > tell us with a few more details. > > No, Michal's findings are in sync with what I checked here. so this is a confirmation that the gpio handling cannot be dropped, right? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-26 9:18 ` Uwe Kleine-König @ 2018-11-26 10:03 ` Lothar Waßmann 0 siblings, 0 replies; 60+ messages in thread From: Lothar Waßmann @ 2018-11-26 10:03 UTC (permalink / raw) To: Uwe Kleine-König Cc: Vokáč Michal, Thierry Reding, Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, kernel, Fabio Estevam, Linus Walleij, viresh kumar Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote: > Hallo Lothar, > > On Mon, Nov 26, 2018 at 10:11:16AM +0100, Lothar Waßmann wrote: > > Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote: > > > @Lothar: if Michal did something different than you expected, please > > > tell us with a few more details. > > > > No, Michal's findings are in sync with what I checked here. > > so this is a confirmation that the gpio handling cannot be dropped, > right? > It seems so. Lothar Waßmann -- ___________________________________________________________ Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10 Geschäftsführer: Matthias Kaussen Handelsregistereintrag: Amtsgericht Aachen, HRB 4996 www.karo-electronics.de | info@karo-electronics.de ___________________________________________________________ ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-23 15:15 ` Vokáč Michal 2018-11-25 20:56 ` Uwe Kleine-König @ 2018-11-26 11:51 ` Thierry Reding 2018-11-26 12:23 ` Lothar Waßmann 1 sibling, 1 reply; 60+ messages in thread From: Thierry Reding @ 2018-11-26 11:51 UTC (permalink / raw) To: Vokáč Michal Cc: Uwe Kleine-König, Lothar Waßmann, Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, kernel, Fabio Estevam, Linus Walleij, viresh kumar [-- Attachment #1: Type: text/plain, Size: 2763 bytes --] On Fri, Nov 23, 2018 at 03:15:11PM +0000, Vokáč Michal wrote: > On 22.11.2018 20:03, Uwe Kleine-König wrote: > > On Thu, Nov 22, 2018 at 04:46:39PM +0000, Vokáč Michal wrote: > >> On 22.11.2018 17:23, Uwe Kleine-König wrote: > >>> On Thu, Nov 22, 2018 at 03:42:14PM +0000, Vokáč Michal wrote: > >>>> On 16.11.2018 09:25, Uwe Kleine-König wrote: > >>>>> On Fri, Nov 16, 2018 at 08:34:30AM +0100, Lothar Waßmann wrote: > >>>>>> No. You can disable the output driver via pinctrl, so that only the > >>>>>> selected pull-up/down is relevant. The pin function and GPIO register > >>>>>> settings don't matter at all in this case. > >>>> > >>>> Lothar, please can you be more specific how would you do that? IFAIK the > >>>> pull-up/down internal resistors have effect only if the pin is configured > >>>> as GPIO *input* (on i.MX6 at least). See the TRM, 29.4.2.2 Output driver: > >>>> > >>>> "Internal pull-up, pull-down resistors, and pad keeper are disabled in > >>>> output mode." > > > > This would mean you'd have to rely on an external pull up for your use > > case. I wouldn't be surprised however if DSE=0 wouldn't count as "output > > mode". Given the reliability of NXP documentation I wouldn't bet neither > > on one nor the other possibility. > > Yeah, the NXP documentation sometimes does not really match reality. > My use case is based on the fact that I configure the pin as input in > the driver. Then it works just fine. > > >>> So I'd expect this to really work on i.MX6 but not the earlier SoCs > >>> without a gpio specifier. > >> > >> Maybe you would expect it to work but I already tested and measured > >> that weeks ago ;) It did not work. > > > > Which pin/gpio do we talk about? Which i.MX6 variant did you test this > > on? (Assuming i.MX6D or i.MX6Q and PAD_DISP0_DATA09, did you try setting > > > > IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA09 (0x020E0194) = 0x00000005 > > IOMUXC_SW_PAD_CTL_PAD_DISP0_DATA09 (0x020E04A8) = 0x0000b080 > > > > and then play with GPIO 4.30 direction and output value?) > > My test setup is as follows: > - SoC is i.MX6DL or i.MX6S - I have three board variants in total. > - Pin used for PWM/GPIO is PAD_GPIO9. > - The pin is not connected to any circuit. Just a test point. > - pinctrl setup in DT: > - for "pwm": > - fsl,pins = <MX6QDL_PAD_GPIO_9__PWM1_OUT 0x8> > - IOMUXC_SW_MUX_CTL_PAD_GPIO09 = 0x00000004 > - IOMUXC_SW_PAD_CTL_PAD_GPIO09 = 0x00000008 > > - for "gpio": > - fsl,pins = <MX6QDL_PAD_GPIO_9__GPIO1_IO09 0xb000> > - IOMUXC_SW_MUX_CTL_PAD_GPIO09 = 0x00000005 > - IOMUXC_SW_PAD_CTL_PAD_GPIO09 = 0x0000b000 Does it help if you additionally set the ODE bit (bit 11) here? Thierry [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-26 11:51 ` Thierry Reding @ 2018-11-26 12:23 ` Lothar Waßmann 2018-11-26 13:34 ` Thierry Reding 0 siblings, 1 reply; 60+ messages in thread From: Lothar Waßmann @ 2018-11-26 12:23 UTC (permalink / raw) To: Thierry Reding Cc: Vokáč Michal, Uwe Kleine-König, Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, kernel, Fabio Estevam, Linus Walleij, viresh kumar Thierry Reding <thierry.reding@gmail.com> wrote: > On Fri, Nov 23, 2018 at 03:15:11PM +0000, Vokáč Michal wrote: > > On 22.11.2018 20:03, Uwe Kleine-König wrote: > > > On Thu, Nov 22, 2018 at 04:46:39PM +0000, Vokáč Michal wrote: > > >> On 22.11.2018 17:23, Uwe Kleine-König wrote: > > >>> On Thu, Nov 22, 2018 at 03:42:14PM +0000, Vokáč Michal wrote: > > >>>> On 16.11.2018 09:25, Uwe Kleine-König wrote: > > >>>>> On Fri, Nov 16, 2018 at 08:34:30AM +0100, Lothar Waßmann wrote: > > >>>>>> No. You can disable the output driver via pinctrl, so that only the > > >>>>>> selected pull-up/down is relevant. The pin function and GPIO register > > >>>>>> settings don't matter at all in this case. > > >>>> > > >>>> Lothar, please can you be more specific how would you do that? IFAIK the > > >>>> pull-up/down internal resistors have effect only if the pin is configured > > >>>> as GPIO *input* (on i.MX6 at least). See the TRM, 29.4.2.2 Output driver: > > >>>> > > >>>> "Internal pull-up, pull-down resistors, and pad keeper are disabled in > > >>>> output mode." > > > > > > This would mean you'd have to rely on an external pull up for your use > > > case. I wouldn't be surprised however if DSE=0 wouldn't count as "output > > > mode". Given the reliability of NXP documentation I wouldn't bet neither > > > on one nor the other possibility. > > > > Yeah, the NXP documentation sometimes does not really match reality. > > My use case is based on the fact that I configure the pin as input in > > the driver. Then it works just fine. > > > > >>> So I'd expect this to really work on i.MX6 but not the earlier SoCs > > >>> without a gpio specifier. > > >> > > >> Maybe you would expect it to work but I already tested and measured > > >> that weeks ago ;) It did not work. > > > > > > Which pin/gpio do we talk about? Which i.MX6 variant did you test this > > > on? (Assuming i.MX6D or i.MX6Q and PAD_DISP0_DATA09, did you try setting > > > > > > IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA09 (0x020E0194) = 0x00000005 > > > IOMUXC_SW_PAD_CTL_PAD_DISP0_DATA09 (0x020E04A8) = 0x0000b080 > > > > > > and then play with GPIO 4.30 direction and output value?) > > > > My test setup is as follows: > > - SoC is i.MX6DL or i.MX6S - I have three board variants in total. > > - Pin used for PWM/GPIO is PAD_GPIO9. > > - The pin is not connected to any circuit. Just a test point. > > - pinctrl setup in DT: > > - for "pwm": > > - fsl,pins = <MX6QDL_PAD_GPIO_9__PWM1_OUT 0x8> > > - IOMUXC_SW_MUX_CTL_PAD_GPIO09 = 0x00000004 > > - IOMUXC_SW_PAD_CTL_PAD_GPIO09 = 0x00000008 > > > > - for "gpio": > > - fsl,pins = <MX6QDL_PAD_GPIO_9__GPIO1_IO09 0xb000> > > - IOMUXC_SW_MUX_CTL_PAD_GPIO09 = 0x00000005 > > - IOMUXC_SW_PAD_CTL_PAD_GPIO09 = 0x0000b000 > > Does it help if you additionally set the ODE bit (bit 11) here? > That only helps to NOT actively pulling the pin HIGH, but the opposite is what is needed here. Lothar Waßmann -- ___________________________________________________________ Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10 Geschäftsführer: Matthias Kaussen Handelsregistereintrag: Amtsgericht Aachen, HRB 4996 www.karo-electronics.de | info@karo-electronics.de ___________________________________________________________ ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-26 12:23 ` Lothar Waßmann @ 2018-11-26 13:34 ` Thierry Reding 2018-11-26 15:50 ` Vokáč Michal 0 siblings, 1 reply; 60+ messages in thread From: Thierry Reding @ 2018-11-26 13:34 UTC (permalink / raw) To: Lothar Waßmann Cc: Vokáč Michal, Uwe Kleine-König, Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, kernel, Fabio Estevam, Linus Walleij, viresh kumar [-- Attachment #1: Type: text/plain, Size: 3495 bytes --] On Mon, Nov 26, 2018 at 01:23:16PM +0100, Lothar Waßmann wrote: > Thierry Reding <thierry.reding@gmail.com> wrote: > > > On Fri, Nov 23, 2018 at 03:15:11PM +0000, Vokáč Michal wrote: > > > On 22.11.2018 20:03, Uwe Kleine-König wrote: > > > > On Thu, Nov 22, 2018 at 04:46:39PM +0000, Vokáč Michal wrote: > > > >> On 22.11.2018 17:23, Uwe Kleine-König wrote: > > > >>> On Thu, Nov 22, 2018 at 03:42:14PM +0000, Vokáč Michal wrote: > > > >>>> On 16.11.2018 09:25, Uwe Kleine-König wrote: > > > >>>>> On Fri, Nov 16, 2018 at 08:34:30AM +0100, Lothar Waßmann wrote: > > > >>>>>> No. You can disable the output driver via pinctrl, so that only the > > > >>>>>> selected pull-up/down is relevant. The pin function and GPIO register > > > >>>>>> settings don't matter at all in this case. > > > >>>> > > > >>>> Lothar, please can you be more specific how would you do that? IFAIK the > > > >>>> pull-up/down internal resistors have effect only if the pin is configured > > > >>>> as GPIO *input* (on i.MX6 at least). See the TRM, 29.4.2.2 Output driver: > > > >>>> > > > >>>> "Internal pull-up, pull-down resistors, and pad keeper are disabled in > > > >>>> output mode." > > > > > > > > This would mean you'd have to rely on an external pull up for your use > > > > case. I wouldn't be surprised however if DSE=0 wouldn't count as "output > > > > mode". Given the reliability of NXP documentation I wouldn't bet neither > > > > on one nor the other possibility. > > > > > > Yeah, the NXP documentation sometimes does not really match reality. > > > My use case is based on the fact that I configure the pin as input in > > > the driver. Then it works just fine. > > > > > > >>> So I'd expect this to really work on i.MX6 but not the earlier SoCs > > > >>> without a gpio specifier. > > > >> > > > >> Maybe you would expect it to work but I already tested and measured > > > >> that weeks ago ;) It did not work. > > > > > > > > Which pin/gpio do we talk about? Which i.MX6 variant did you test this > > > > on? (Assuming i.MX6D or i.MX6Q and PAD_DISP0_DATA09, did you try setting > > > > > > > > IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA09 (0x020E0194) = 0x00000005 > > > > IOMUXC_SW_PAD_CTL_PAD_DISP0_DATA09 (0x020E04A8) = 0x0000b080 > > > > > > > > and then play with GPIO 4.30 direction and output value?) > > > > > > My test setup is as follows: > > > - SoC is i.MX6DL or i.MX6S - I have three board variants in total. > > > - Pin used for PWM/GPIO is PAD_GPIO9. > > > - The pin is not connected to any circuit. Just a test point. > > > - pinctrl setup in DT: > > > - for "pwm": > > > - fsl,pins = <MX6QDL_PAD_GPIO_9__PWM1_OUT 0x8> > > > - IOMUXC_SW_MUX_CTL_PAD_GPIO09 = 0x00000004 > > > - IOMUXC_SW_PAD_CTL_PAD_GPIO09 = 0x00000008 > > > > > > - for "gpio": > > > - fsl,pins = <MX6QDL_PAD_GPIO_9__GPIO1_IO09 0xb000> > > > - IOMUXC_SW_MUX_CTL_PAD_GPIO09 = 0x00000005 > > > - IOMUXC_SW_PAD_CTL_PAD_GPIO09 = 0x0000b000 > > > > Does it help if you additionally set the ODE bit (bit 11) here? > > > That only helps to NOT actively pulling the pin HIGH, but the opposite > is what is needed here. From the description in the reference manual it sounded like the ODE would avoid the pin from actively being driven anywhere if configured as output. So I was hoping that in conjunction with the pull-up it would actually do the right thing. Thierry [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-26 13:34 ` Thierry Reding @ 2018-11-26 15:50 ` Vokáč Michal 0 siblings, 0 replies; 60+ messages in thread From: Vokáč Michal @ 2018-11-26 15:50 UTC (permalink / raw) To: Thierry Reding Cc: Lothar Waßmann, Uwe Kleine-König, Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, kernel, Fabio Estevam, Linus Walleij, viresh kumar On 26.11.2018 14:34, Thierry Reding wrote: > On Mon, Nov 26, 2018 at 01:23:16PM +0100, Lothar Waßmann wrote: >> Thierry Reding <thierry.reding@gmail.com> wrote: >> >>> On Fri, Nov 23, 2018 at 03:15:11PM +0000, Vokáč Michal wrote: >>>> On 22.11.2018 20:03, Uwe Kleine-König wrote: >>>>> On Thu, Nov 22, 2018 at 04:46:39PM +0000, Vokáč Michal wrote: >>>>>> On 22.11.2018 17:23, Uwe Kleine-König wrote: >>>>>>> On Thu, Nov 22, 2018 at 03:42:14PM +0000, Vokáč Michal wrote: >>>>>>>> On 16.11.2018 09:25, Uwe Kleine-König wrote: >>>>>>>>> On Fri, Nov 16, 2018 at 08:34:30AM +0100, Lothar Waßmann wrote: >>>>>>>>>> No. You can disable the output driver via pinctrl, so that only the >>>>>>>>>> selected pull-up/down is relevant. The pin function and GPIO register >>>>>>>>>> settings don't matter at all in this case. >>>>>>>> >>>>>>>> Lothar, please can you be more specific how would you do that? IFAIK the >>>>>>>> pull-up/down internal resistors have effect only if the pin is configured >>>>>>>> as GPIO *input* (on i.MX6 at least). See the TRM, 29.4.2.2 Output driver: >>>>>>>> >>>>>>>> "Internal pull-up, pull-down resistors, and pad keeper are disabled in >>>>>>>> output mode." >>>>> >>>>> This would mean you'd have to rely on an external pull up for your use >>>>> case. I wouldn't be surprised however if DSE=0 wouldn't count as "output >>>>> mode". Given the reliability of NXP documentation I wouldn't bet neither >>>>> on one nor the other possibility. >>>> >>>> Yeah, the NXP documentation sometimes does not really match reality. >>>> My use case is based on the fact that I configure the pin as input in >>>> the driver. Then it works just fine. >>>> >>>>>>> So I'd expect this to really work on i.MX6 but not the earlier SoCs >>>>>>> without a gpio specifier. >>>>>> >>>>>> Maybe you would expect it to work but I already tested and measured >>>>>> that weeks ago ;) It did not work. >>>>> >>>>> Which pin/gpio do we talk about? Which i.MX6 variant did you test this >>>>> on? (Assuming i.MX6D or i.MX6Q and PAD_DISP0_DATA09, did you try setting >>>>> >>>>> IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA09 (0x020E0194) = 0x00000005 >>>>> IOMUXC_SW_PAD_CTL_PAD_DISP0_DATA09 (0x020E04A8) = 0x0000b080 >>>>> >>>>> and then play with GPIO 4.30 direction and output value?) >>>> >>>> My test setup is as follows: >>>> - SoC is i.MX6DL or i.MX6S - I have three board variants in total. >>>> - Pin used for PWM/GPIO is PAD_GPIO9. >>>> - The pin is not connected to any circuit. Just a test point. >>>> - pinctrl setup in DT: >>>> - for "pwm": >>>> - fsl,pins = <MX6QDL_PAD_GPIO_9__PWM1_OUT 0x8> >>>> - IOMUXC_SW_MUX_CTL_PAD_GPIO09 = 0x00000004 >>>> - IOMUXC_SW_PAD_CTL_PAD_GPIO09 = 0x00000008 >>>> >>>> - for "gpio": >>>> - fsl,pins = <MX6QDL_PAD_GPIO_9__GPIO1_IO09 0xb000> >>>> - IOMUXC_SW_MUX_CTL_PAD_GPIO09 = 0x00000005 >>>> - IOMUXC_SW_PAD_CTL_PAD_GPIO09 = 0x0000b000 >>> >>> Does it help if you additionally set the ODE bit (bit 11) here? >>> >> That only helps to NOT actively pulling the pin HIGH, but the opposite >> is what is needed here. > > From the description in the reference manual it sounded like the ODE > would avoid the pin from actively being driven anywhere if configured as > output. So I was hoping that in conjunction with the pull-up it would > actually do the right thing. Not exactly. I tested/measured this and the ODE setting works like Lothar said. If ODE=1 and GPIO is in output mode: - The internal pull resistors are enabled even if PKE=0 (pull/keeper is disabled). That's news to me but it actually matches the GPIO pad functional diagram. See Figure 29-3 in RM. - If the GPIO output is set LOW, the output is actively pulled down by the low side transistor. - If the GPIO output is set HIGH the output is passively pulled up by the internal pull-up resistor. The value of the resistor can be selected by PUS and I am able to measure it. That does not solve the issue that the pin may me configured as output and set LOW from bootloader though. Michal ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-15 20:37 ` Uwe Kleine-König 2018-11-16 7:34 ` Lothar Waßmann @ 2018-11-16 9:51 ` Thierry Reding 2018-11-16 10:39 ` Uwe Kleine-König 2018-11-20 13:14 ` Vokáč Michal 1 sibling, 2 replies; 60+ messages in thread From: Thierry Reding @ 2018-11-16 9:51 UTC (permalink / raw) To: Uwe Kleine-König Cc: Vokáč Michal, Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, kernel, Fabio Estevam, Lothar Waßmann, Linus Walleij [-- Attachment #1: Type: text/plain, Size: 12176 bytes --] On Thu, Nov 15, 2018 at 09:37:33PM +0100, Uwe Kleine-König wrote: > Hello Thierry, > > On Thu, Nov 15, 2018 at 04:25:45PM +0100, Thierry Reding wrote: > > On Wed, Nov 14, 2018 at 10:51:20PM +0100, Uwe Kleine-König wrote: > > > On Wed, Nov 14, 2018 at 12:34:49PM +0100, Thierry Reding wrote: > > > > On Fri, Nov 09, 2018 at 05:55:55PM +0100, Uwe Kleine-König wrote: > > > > > On Fri, Nov 09, 2018 at 02:24:42PM +0000, Vokáč Michal wrote: > > > > > > On 8.11.2018 20:18, Uwe Kleine-König wrote: > > > > > > > Taking your example with the backlight device you specify an "init" and > > > > > > > a "default" pinctrl and only "default" contains the muxing for the PWM > > > > > > > pin everything should be as smooth as necessary: The pwm is only muxed > > > > > > > when the backlight device is successfully bound. > > > > > > > > > > > > Have you tried that Uwe? The bad news is I tested that before and now > > > > > > again and it does not work like that. We already discussed that earlier. > > > > > > > > > > The key is that the pinmux setting for the PWM pin should be part of the > > > > > bl pinctrl, not the pwm pinctrl. Then "default" is only setup when the > > > > > bl device is successfully bound which is after the bl's .probe callback > > > > > called pwm_apply(). > > > > > > > > No, that's not at all correct. Pinmux settings should reside with the > > > > consumer of the pin. In this case, the PWM is the consumer of the pin, > > > > whereas the backlight is the consumer of the *PWM*. > > > > > > This is news to me. Adding Linus W. to Cc, maybe he can comment?! > > > > > > Grepping through the arm device trees it really seems common to put the > > > pinctrl for the pwm pin into the pwm device. I didn't search in depth, > > > but I didn't find a counter example. > > > > > > For GPIOs it is common that the pinmuxing is included in the GPIO's > > > consumer pinctrl. Ditto for mdio busses whose pinctrl is included in the > > > ethernet pinctrl. > > > > GPIO is different from PWM in that the GPIO is already the pin itself > > and is otherwise generic. So typically you put the pinmuxing options > > into the device tree node for the consumer of the GPIO, because it is > > only when the consumer uses the GPIO that you need to configure that > > pin as GPIO. > > > > For PWM, however, the PWM consumer is only the consumer of the PWM, but > > the PWM device itself is the real consumer of the pin that outputs the > > PWM signal. So the PWM determines when the pinmux states need to be > > applied, whereas the consumer of the PWM only deals with the PWM. > > > > For MDIO busses, I think they are usually part of, and driven by, the > > ethernet controller, so again it makes sense to put the pinmux into the > > node of the ethernet controller, because the ethernet controller is the > > user of the pins. > > Maybe it was a bad idea to broaden the discussion to talk about gpios > and ethernet stuff here. I'd still consider it a valid construct to put > the pwm pin into the backlight's pinctrl unless Linux W. disagrees. But why? The backlight doesn't care about the specific pinmuxing of the PWM pin. All it cares about is the PWM signal. That's the level of abstraction that the PWM consumer expects, anything lower level belongs in the PWM driver. > > > > The problem with making the PWM mode the "default" pinctrl state is that > > > > the default state will be applied before the driver is even probed. That > > > > makes it unsuitable for this case. I think what we really want here is > > > > explicitly "active" and "inactive" states for pinctrl where the PWM > > > > driver controls when exactly each state is applied. > > > > > > Note that this problem goes away nicely if the pwm pin is attached to > > > the backlight. Because it's the backlight's driver that "knows" when the > > > pwm is configured correctly and so the already existing mechanisms that > > > setup the mux when the bl is correctly probed do the right thing at the > > > right time. > > > > Actually that's not exactly true. The default pinctrl state will be > > applied before the driver's ->probe() implementation, so the pinctrl > > state will be active some time before even the backlight driver gets > > around to setting up the PWM. If you look at drivers/base/dd.c you'll > > see that really_probe() calls pinctrl_bind_pins() before calling the > > driver's ->probe() and will select the default state (unless there's > > also an "init" state defined, in which case that will get applied and > > only after successful probe will the default state be selected). > > > > So if you use only a default state, then you could even get into a > > situation where ->probe() return -EPROBE_DEFER and it would potentially > > take several seconds before the driver is reprobed, during which time > > the pinmux will already be set up but the PWM not configured properly > > and potentially outputting the wrong level. > > If you reread my suggestion to Michal completely you will notice I got > that right. > > > > > This solves the problem quite nicely because by default the pinctrl > > > > state isn't touched. For the case where the bootloader didn't initialize > > > > the PWM pin at all, the driver core won't do anything and keep it at the > > > > 100k pull-up default. > > > > > > Ditto if the pwm pinctrl is attached to the consumer without having to > > > introduce new pwm-specific stuff. > > > > Well yes, but you'd obviously also have to avoid using the "default" > > state, otherwise you'd run into the issues that I described above. > > I'd need "default" and "init", right. > > > > > > > > No I meant the pwm. Well, it's as easy as that: Whenever with your > > > > > > > approach you configure the pin as GPIO with the output set to low, > > > > > > > instead configure the pwm with duty_cycle to zero (or disable it). > > > > > > > Whenever with your approach you configure the pin as GPIO with the > > > > > > > output set to high, configure the pwm with duty_cycle to 100%. (Keeping > > > > > > > out inverted PWMs for the ease of discussion, but the procedure can be > > > > > > > adapted accordingly.) The only difference then is that with your > > > > > > > approach you already "know" in pwm-imx's .probe the idle level and can > > > > > > > configure the GPIO accordingly. With my approach you just have to wait > > > > > > > until the first pwm_apply which (as described above) works just as well. > > > > > > > > > > > > While here I am quite confident you are talking about kernel code, right? > > > > > > If yes, then your approach is clear to me. > > > > > > > > > > > > The problem is I am quite sure your approach does not solve the cases > > > > > > the pinctrl solution does. And according to my tests so far it does not > > > > > > work at all because the "init" and "default" states does not work as you > > > > > > are saying. > > > > > > > > > > That's as pointed out above, because you're looking at the pwm's pinctrl > > > > > and I at the pwm-consumer's pinctrl. > > > > > > > > > > Note that a sysfs consumer cannot be operated smoothly here, because > > > > > there is no pinctrl node to add the PWM mode to that only gets active > > > > > after the first configuration. This however is something that should not > > > > > be addressed in the imx driver but in the pwm core (if at all). > > > > > > > > With the pinctrl-based solution outlined above you can even operate a > > > > sysfs consumer properly. The pinctrl states are where they belong, with > > > > the PWM device and therefore they can be properly set when the PWM is > > > > used, rather than waiting for a PWM consumer to muck with the pinmux. > > > > > > > > Note how all the pieces are suddenly falling into place. In my > > > > experience that's usually a good indication that you're on the right > > > > track. > > > > > > OK, sysfs is the only point where the "put pinctrl stuff into the pwm > > > core (or driver)" is superior to the already existing and otherwise > > > completely working status quo. (Apart from bugs that need fixing in > > > your scenario, too.) > > > > Nope, sorry. It's superior in all of the other cases as well. You've > > said elsewhere already that the prerequisite for the current solution to > > support inverse polarity with the i.MX driver is to keep the driver > > running, even after the PWM is no longer used. Sorry but that's just not > > an option for me. > > You want that after pwm_disable() the pin still keeps the idle level. As > the hardware doesn't provide this feature "as is" something has to be > done about it. This can be reached either by operating the pin as PWM > with 0% duty cycle or by switching to GPIO that is configured to the > desired level. From the PWM driver's POV the first is the more natural, > as this can be accomplished with the registers this driver cares about > anyhow. We've been over this before. Yes, as long as you operate the pin as PWM it's okay to just actively drive it. But once you no longer use the pin, why would you want to still actively drive it? > Also note this is similar in the pwm-bcm-kona driver that doesn't seem > to have the concept of "disable" at all. kona_pwmc_disable() just sets > up 0% duty cycle. In my eyes this is an argument that is good enough to > at least nack the imx-specific implementation of that pinctrl stuff. It's not a good enough argument for me. It's certainly possible that not all PWM driver can be made to behave exactly as needed. pwm-bcm-kona might be one of those, but that doesn't mean that everybody else should be restricted to the same behaviour. If we can make i.MX behave exactly right, then we should do that. > If the pinctrl idea is implemented in the pwm core, I won't object. Let me see if I get this straight: you're not objecting to the idea of implementing the pinctrl solution, your only objection is to put it in the i.MX driver? > > > Other than that my approach looks more elegant to me (which obviously is > > > subjective). It works in all cases apart from sysfs (which is special > > > because it's not integrated into the device model) and there is no need > > > to teach the pwm framework about pinmuxing and invent new pinctrl modes > > > for it. > > > > Elegance is useless if what you have doesn't work consistently and > > reliably. > > > > I don't understand your resistance to the pinctrl work. It's not rocket > > science. Michal already posted patches showing how it can be done and > > they're not very complicated. Also we're not doing anything out of the > > ordinary here. This is exactly the purpose of the pinctrl framework, so > > let's use the best tool at hand. > > In my last exchange with Michal I had the impression that he liked > my approach, too. My impression was that he was trying to find concensus. But the way I read it he was still arguing that the pinctrl solution was still the most complete, and would therefore still prefer it. > > > Also dts writes don't need to lookup the needed GPIO numbers and pinctrl. > > > > Just to clarify: I don't think that we need to get the GPIO number > > involved in this case, because we don't have to reconfigure the pin as > > GPIO to make this work. The only reason that Michal's proposal did that > > is because that was believed to be necessary. But if the pin can just be > > configured with a 100k pull-up, that's enough to pull the pin high when > > we need it. > > Unless the gpio happens to be configured as output at the wrong value. > Further I'm not sure if the pwm in disabled state actively pulls to 0 > and if in this state the PU of the pin is good enough to ensure a one > here. That would need verification first. The idea is to *not* configure the GPIO as output and output the wrong value. The idea is to not use the GPIO at all and instead use whatever the hardware default is that makes it such that the backlight is off by default at boot. Thierry [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-16 9:51 ` Thierry Reding @ 2018-11-16 10:39 ` Uwe Kleine-König 2018-11-16 11:56 ` Lothar Waßmann 2018-11-16 12:24 ` Thierry Reding 2018-11-20 13:14 ` Vokáč Michal 1 sibling, 2 replies; 60+ messages in thread From: Uwe Kleine-König @ 2018-11-16 10:39 UTC (permalink / raw) To: Thierry Reding Cc: Vokáč Michal, Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, kernel, Fabio Estevam, Lothar Waßmann, Linus Walleij Hello Thierry, On Fri, Nov 16, 2018 at 10:51:24AM +0100, Thierry Reding wrote: > On Thu, Nov 15, 2018 at 09:37:33PM +0100, Uwe Kleine-König wrote: > > On Thu, Nov 15, 2018 at 04:25:45PM +0100, Thierry Reding wrote: > > > On Wed, Nov 14, 2018 at 10:51:20PM +0100, Uwe Kleine-König wrote: > > > > On Wed, Nov 14, 2018 at 12:34:49PM +0100, Thierry Reding wrote: > > > > > On Fri, Nov 09, 2018 at 05:55:55PM +0100, Uwe Kleine-König wrote: > > > > > > On Fri, Nov 09, 2018 at 02:24:42PM +0000, Vokáč Michal wrote: > > > > > > > On 8.11.2018 20:18, Uwe Kleine-König wrote: > > > > > > > > Taking your example with the backlight device you specify an "init" and > > > > > > > > a "default" pinctrl and only "default" contains the muxing for the PWM > > > > > > > > pin everything should be as smooth as necessary: The pwm is only muxed > > > > > > > > when the backlight device is successfully bound. > > > > > > > > > > > > > > Have you tried that Uwe? The bad news is I tested that before and now > > > > > > > again and it does not work like that. We already discussed that earlier. > > > > > > > > > > > > The key is that the pinmux setting for the PWM pin should be part of the > > > > > > bl pinctrl, not the pwm pinctrl. Then "default" is only setup when the > > > > > > bl device is successfully bound which is after the bl's .probe callback > > > > > > called pwm_apply(). > > > > > > > > > > No, that's not at all correct. Pinmux settings should reside with the > > > > > consumer of the pin. In this case, the PWM is the consumer of the pin, > > > > > whereas the backlight is the consumer of the *PWM*. > > > > > > > > This is news to me. Adding Linus W. to Cc, maybe he can comment?! > > > > > > > > Grepping through the arm device trees it really seems common to put the > > > > pinctrl for the pwm pin into the pwm device. I didn't search in depth, > > > > but I didn't find a counter example. > > > > > > > > For GPIOs it is common that the pinmuxing is included in the GPIO's > > > > consumer pinctrl. Ditto for mdio busses whose pinctrl is included in the > > > > ethernet pinctrl. > > > > > > GPIO is different from PWM in that the GPIO is already the pin itself > > > and is otherwise generic. So typically you put the pinmuxing options > > > into the device tree node for the consumer of the GPIO, because it is > > > only when the consumer uses the GPIO that you need to configure that > > > pin as GPIO. > > > > > > For PWM, however, the PWM consumer is only the consumer of the PWM, but > > > the PWM device itself is the real consumer of the pin that outputs the > > > PWM signal. So the PWM determines when the pinmux states need to be > > > applied, whereas the consumer of the PWM only deals with the PWM. > > > > > > For MDIO busses, I think they are usually part of, and driven by, the > > > ethernet controller, so again it makes sense to put the pinmux into the > > > node of the ethernet controller, because the ethernet controller is the > > > user of the pins. > > > > Maybe it was a bad idea to broaden the discussion to talk about gpios > > and ethernet stuff here. I'd still consider it a valid construct to put > > the pwm pin into the backlight's pinctrl unless Linux W. disagrees. > > But why? The backlight doesn't care about the specific pinmuxing of the > PWM pin. All it cares about is the PWM signal. That's the level of > abstraction that the PWM consumer expects, anything lower level belongs > in the PWM driver. The backlight driver cares about the PWM pin muxing because if it's wrongly muxed the backlight doesn't work as intended. > > > > > The problem with making the PWM mode the "default" pinctrl state is that > > > > > the default state will be applied before the driver is even probed. That > > > > > makes it unsuitable for this case. I think what we really want here is > > > > > explicitly "active" and "inactive" states for pinctrl where the PWM > > > > > driver controls when exactly each state is applied. > > > > > > > > Note that this problem goes away nicely if the pwm pin is attached to > > > > the backlight. Because it's the backlight's driver that "knows" when the > > > > pwm is configured correctly and so the already existing mechanisms that > > > > setup the mux when the bl is correctly probed do the right thing at the > > > > right time. > > > > > > Actually that's not exactly true. The default pinctrl state will be > > > applied before the driver's ->probe() implementation, so the pinctrl > > > state will be active some time before even the backlight driver gets > > > around to setting up the PWM. If you look at drivers/base/dd.c you'll > > > see that really_probe() calls pinctrl_bind_pins() before calling the > > > driver's ->probe() and will select the default state (unless there's > > > also an "init" state defined, in which case that will get applied and > > > only after successful probe will the default state be selected). > > > > > > So if you use only a default state, then you could even get into a > > > situation where ->probe() return -EPROBE_DEFER and it would potentially > > > take several seconds before the driver is reprobed, during which time > > > the pinmux will already be set up but the PWM not configured properly > > > and potentially outputting the wrong level. > > > > If you reread my suggestion to Michal completely you will notice I got > > that right. > > > > > > > This solves the problem quite nicely because by default the pinctrl > > > > > state isn't touched. For the case where the bootloader didn't initialize > > > > > the PWM pin at all, the driver core won't do anything and keep it at the > > > > > 100k pull-up default. > > > > > > > > Ditto if the pwm pinctrl is attached to the consumer without having to > > > > introduce new pwm-specific stuff. > > > > > > Well yes, but you'd obviously also have to avoid using the "default" > > > state, otherwise you'd run into the issues that I described above. > > > > I'd need "default" and "init", right. > > > > > > > > > > No I meant the pwm. Well, it's as easy as that: Whenever with your > > > > > > > > approach you configure the pin as GPIO with the output set to low, > > > > > > > > instead configure the pwm with duty_cycle to zero (or disable it). > > > > > > > > Whenever with your approach you configure the pin as GPIO with the > > > > > > > > output set to high, configure the pwm with duty_cycle to 100%. (Keeping > > > > > > > > out inverted PWMs for the ease of discussion, but the procedure can be > > > > > > > > adapted accordingly.) The only difference then is that with your > > > > > > > > approach you already "know" in pwm-imx's .probe the idle level and can > > > > > > > > configure the GPIO accordingly. With my approach you just have to wait > > > > > > > > until the first pwm_apply which (as described above) works just as well. > > > > > > > > > > > > > > While here I am quite confident you are talking about kernel code, right? > > > > > > > If yes, then your approach is clear to me. > > > > > > > > > > > > > > The problem is I am quite sure your approach does not solve the cases > > > > > > > the pinctrl solution does. And according to my tests so far it does not > > > > > > > work at all because the "init" and "default" states does not work as you > > > > > > > are saying. > > > > > > > > > > > > That's as pointed out above, because you're looking at the pwm's pinctrl > > > > > > and I at the pwm-consumer's pinctrl. > > > > > > > > > > > > Note that a sysfs consumer cannot be operated smoothly here, because > > > > > > there is no pinctrl node to add the PWM mode to that only gets active > > > > > > after the first configuration. This however is something that should not > > > > > > be addressed in the imx driver but in the pwm core (if at all). > > > > > > > > > > With the pinctrl-based solution outlined above you can even operate a > > > > > sysfs consumer properly. The pinctrl states are where they belong, with > > > > > the PWM device and therefore they can be properly set when the PWM is > > > > > used, rather than waiting for a PWM consumer to muck with the pinmux. > > > > > > > > > > Note how all the pieces are suddenly falling into place. In my > > > > > experience that's usually a good indication that you're on the right > > > > > track. > > > > > > > > OK, sysfs is the only point where the "put pinctrl stuff into the pwm > > > > core (or driver)" is superior to the already existing and otherwise > > > > completely working status quo. (Apart from bugs that need fixing in > > > > your scenario, too.) > > > > > > Nope, sorry. It's superior in all of the other cases as well. You've > > > said elsewhere already that the prerequisite for the current solution to > > > support inverse polarity with the i.MX driver is to keep the driver > > > running, even after the PWM is no longer used. Sorry but that's just not > > > an option for me. > > > > You want that after pwm_disable() the pin still keeps the idle level. As > > the hardware doesn't provide this feature "as is" something has to be > > done about it. This can be reached either by operating the pin as PWM > > with 0% duty cycle or by switching to GPIO that is configured to the > > desired level. From the PWM driver's POV the first is the more natural, > > as this can be accomplished with the registers this driver cares about > > anyhow. > > We've been over this before. Yes, as long as you operate the pin as PWM > it's okay to just actively drive it. But once you no longer use the pin, > why would you want to still actively drive it? This is because you say the pin should keep its level as inactive even though that's not what the hardware does without keeping care. I say this is strange: The consumer specifies if the pwm should be inverted or not because the pwm alone doesn't know that. Then with the consumer gone *you* want the pwm to "remember" its last user requested inversion and so the pin should stay at 1. To answer your question: I don't want to actively drive the pin when the user is gone. That's a requirement comming from you. If it was my decision, I'd say: If the backlight driver calls pwm_config(pwm, 0, 100); pwm_disable(pwm); I'd interpret that as: The consumer doesn't use the pin any more, so I'm not bound to keep the pin at a certain level. If however after pwm_disable the consumer is still considered to use the pin, then implementing it the same way as pwm_config(pwm, 0, 100) is the right thing to do. This applies then to all pwm implementations and so should be solved in the pwm core, not in the imx driver. In this case the concept of "disabling a PWM" can go away completely. In another mail you wrote: > Your example of keeping an LED in the current state is actually an > example of where the consumer still needs it. As long as you want to use > the LED you need to keep the LED driver around, and as long as the LED > driver is around you have a consumer for the PWM. With an analog reasoning I'd say: As long as the backlight driver cares about the backlight being off, it should not disable (or put) the PWM. > > Also note this is similar in the pwm-bcm-kona driver that doesn't seem > > to have the concept of "disable" at all. kona_pwmc_disable() just sets > > up 0% duty cycle. In my eyes this is an argument that is good enough to > > at least nack the imx-specific implementation of that pinctrl stuff. > > It's not a good enough argument for me. It's certainly possible that not > all PWM driver can be made to behave exactly as needed. pwm-bcm-kona > might be one of those, but that doesn't mean that everybody else should > be restricted to the same behaviour. If we can make i.MX behave exactly > right, then we should do that. And if we can make the imx-specific implementation right in a generic way in the pwm core that might help the bcm-kona driver for free. > > If the pinctrl idea is implemented in the pwm core, I won't object. > > Let me see if I get this straight: you're not objecting to the idea of > implementing the pinctrl solution, your only objection is to put it in > the i.MX driver? Given that the pinctrl solution is a generic solution that might help other drivers, too, I think it should not go into the imx specific driver just because for now this is the only driver that might benefit from it. I still don't think it's the best solution for the imx problem but as I care more for imx in general than for pwm in general I'm interested in keeping the imx driver focused to the imx specific parts. I won't repeat the advantages of putting generic stuff into a generic location instead of its first user. > > > > Also dts writes don't need to lookup the needed GPIO numbers and pinctrl. > > > > > > Just to clarify: I don't think that we need to get the GPIO number > > > involved in this case, because we don't have to reconfigure the pin as > > > GPIO to make this work. The only reason that Michal's proposal did that > > > is because that was believed to be necessary. But if the pin can just be > > > configured with a 100k pull-up, that's enough to pull the pin high when > > > we need it. > > > > Unless the gpio happens to be configured as output at the wrong value. > > Further I'm not sure if the pwm in disabled state actively pulls to 0 > > and if in this state the PU of the pin is good enough to ensure a one > > here. That would need verification first. > > The idea is to *not* configure the GPIO as output and output the wrong > value. The idea is to not use the GPIO at all and instead use whatever > the hardware default is that makes it such that the backlight is off by > default at boot. Which might be possible with Lothar's idea for some machines, but not for all users of the pwm-imx driver. Also note that you don't include the poor souls where there is no hardware pullup into the right direction. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-16 10:39 ` Uwe Kleine-König @ 2018-11-16 11:56 ` Lothar Waßmann 2018-11-18 11:30 ` Uwe Kleine-König 2018-11-16 12:24 ` Thierry Reding 1 sibling, 1 reply; 60+ messages in thread From: Lothar Waßmann @ 2018-11-16 11:56 UTC (permalink / raw) To: Uwe Kleine-König Cc: Thierry Reding, Vokáč Michal, Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, kernel, Fabio Estevam, Linus Walleij Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote: > Hello Thierry, > > On Fri, Nov 16, 2018 at 10:51:24AM +0100, Thierry Reding wrote: > > On Thu, Nov 15, 2018 at 09:37:33PM +0100, Uwe Kleine-König wrote: > > > On Thu, Nov 15, 2018 at 04:25:45PM +0100, Thierry Reding wrote: [...] > > But why? The backlight doesn't care about the specific pinmuxing of the > > PWM pin. All it cares about is the PWM signal. That's the level of > > abstraction that the PWM consumer expects, anything lower level belongs > > in the PWM driver. > > The backlight driver cares about the PWM pin muxing because if it's > wrongly muxed the backlight doesn't work as intended. > With this argumentation you would also have to define the clocks needed for the PWM in the backlight (or whatever pwm consumer) driver, because if the clocks are not set up correctly the backlight won't work as expected... The PWM driver is driving the pins, so that is where the pinctrls belong. Lothar Waßmann -- ___________________________________________________________ Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10 Geschäftsführer: Matthias Kaussen Handelsregistereintrag: Amtsgericht Aachen, HRB 4996 www.karo-electronics.de | info@karo-electronics.de ___________________________________________________________ ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-16 11:56 ` Lothar Waßmann @ 2018-11-18 11:30 ` Uwe Kleine-König 0 siblings, 0 replies; 60+ messages in thread From: Uwe Kleine-König @ 2018-11-18 11:30 UTC (permalink / raw) To: Lothar Waßmann Cc: Thierry Reding, Vokáč Michal, Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, kernel, Fabio Estevam, Linus Walleij Hello Lothar, On Fri, Nov 16, 2018 at 12:56:33PM +0100, Lothar Waßmann wrote: > Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote: > > On Fri, Nov 16, 2018 at 10:51:24AM +0100, Thierry Reding wrote: > > > On Thu, Nov 15, 2018 at 09:37:33PM +0100, Uwe Kleine-König wrote: > > > > On Thu, Nov 15, 2018 at 04:25:45PM +0100, Thierry Reding wrote: > [...] > > > But why? The backlight doesn't care about the specific pinmuxing of the > > > PWM pin. All it cares about is the PWM signal. That's the level of > > > abstraction that the PWM consumer expects, anything lower level belongs > > > in the PWM driver. > > > > The backlight driver cares about the PWM pin muxing because if it's > > wrongly muxed the backlight doesn't work as intended. > > With this argumentation you would also have to define the clocks needed > for the PWM in the backlight (or whatever pwm consumer) driver, because > if the clocks are not set up correctly the backlight won't work as > expected... The reason why I think it is sensible to put the PWM pin into the consumer's pinctrl is that only after the consumer grabbed the PWM it is fixed (in software) what the idle level is. So the pwm alone isn't complete and it's not clear what to do with this pin. High-Z is probably a good choice for most setups, but this relies on a PU or PD into the right direction that isn't always present. (I'm currently working with such a machine, where such a PD/PU is missing. Not entirely sure this is a problem because maybe the display unit has a pull. Didn't take the time yet to verify.) Also this needs some care because the PWM might already running on purpose (e.g. to show a splash screen) then switching to High-Z should be avoided. So IMHO it is sensible to delay setting up the pinmux until the boundary conditions are fixed. This is also the general idea with the involvement of pinctrl stuff, but given that even without handling pinctrl specially it already works just fine when the pwm is only muxed as part of the consumer. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-16 10:39 ` Uwe Kleine-König 2018-11-16 11:56 ` Lothar Waßmann @ 2018-11-16 12:24 ` Thierry Reding 2018-11-18 20:08 ` Uwe Kleine-König 1 sibling, 1 reply; 60+ messages in thread From: Thierry Reding @ 2018-11-16 12:24 UTC (permalink / raw) To: Uwe Kleine-König Cc: Vokáč Michal, Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, kernel, Fabio Estevam, Lothar Waßmann, Linus Walleij [-- Attachment #1: Type: text/plain, Size: 17181 bytes --] On Fri, Nov 16, 2018 at 11:39:29AM +0100, Uwe Kleine-König wrote: > Hello Thierry, > > On Fri, Nov 16, 2018 at 10:51:24AM +0100, Thierry Reding wrote: > > On Thu, Nov 15, 2018 at 09:37:33PM +0100, Uwe Kleine-König wrote: > > > On Thu, Nov 15, 2018 at 04:25:45PM +0100, Thierry Reding wrote: > > > > On Wed, Nov 14, 2018 at 10:51:20PM +0100, Uwe Kleine-König wrote: > > > > > On Wed, Nov 14, 2018 at 12:34:49PM +0100, Thierry Reding wrote: > > > > > > On Fri, Nov 09, 2018 at 05:55:55PM +0100, Uwe Kleine-König wrote: > > > > > > > On Fri, Nov 09, 2018 at 02:24:42PM +0000, Vokáč Michal wrote: > > > > > > > > On 8.11.2018 20:18, Uwe Kleine-König wrote: > > > > > > > > > Taking your example with the backlight device you specify an "init" and > > > > > > > > > a "default" pinctrl and only "default" contains the muxing for the PWM > > > > > > > > > pin everything should be as smooth as necessary: The pwm is only muxed > > > > > > > > > when the backlight device is successfully bound. > > > > > > > > > > > > > > > > Have you tried that Uwe? The bad news is I tested that before and now > > > > > > > > again and it does not work like that. We already discussed that earlier. > > > > > > > > > > > > > > The key is that the pinmux setting for the PWM pin should be part of the > > > > > > > bl pinctrl, not the pwm pinctrl. Then "default" is only setup when the > > > > > > > bl device is successfully bound which is after the bl's .probe callback > > > > > > > called pwm_apply(). > > > > > > > > > > > > No, that's not at all correct. Pinmux settings should reside with the > > > > > > consumer of the pin. In this case, the PWM is the consumer of the pin, > > > > > > whereas the backlight is the consumer of the *PWM*. > > > > > > > > > > This is news to me. Adding Linus W. to Cc, maybe he can comment?! > > > > > > > > > > Grepping through the arm device trees it really seems common to put the > > > > > pinctrl for the pwm pin into the pwm device. I didn't search in depth, > > > > > but I didn't find a counter example. > > > > > > > > > > For GPIOs it is common that the pinmuxing is included in the GPIO's > > > > > consumer pinctrl. Ditto for mdio busses whose pinctrl is included in the > > > > > ethernet pinctrl. > > > > > > > > GPIO is different from PWM in that the GPIO is already the pin itself > > > > and is otherwise generic. So typically you put the pinmuxing options > > > > into the device tree node for the consumer of the GPIO, because it is > > > > only when the consumer uses the GPIO that you need to configure that > > > > pin as GPIO. > > > > > > > > For PWM, however, the PWM consumer is only the consumer of the PWM, but > > > > the PWM device itself is the real consumer of the pin that outputs the > > > > PWM signal. So the PWM determines when the pinmux states need to be > > > > applied, whereas the consumer of the PWM only deals with the PWM. > > > > > > > > For MDIO busses, I think they are usually part of, and driven by, the > > > > ethernet controller, so again it makes sense to put the pinmux into the > > > > node of the ethernet controller, because the ethernet controller is the > > > > user of the pins. > > > > > > Maybe it was a bad idea to broaden the discussion to talk about gpios > > > and ethernet stuff here. I'd still consider it a valid construct to put > > > the pwm pin into the backlight's pinctrl unless Linux W. disagrees. > > > > But why? The backlight doesn't care about the specific pinmuxing of the > > PWM pin. All it cares about is the PWM signal. That's the level of > > abstraction that the PWM consumer expects, anything lower level belongs > > in the PWM driver. > > The backlight driver cares about the PWM pin muxing because if it's > wrongly muxed the backlight doesn't work as intended. It shouldn't care about that. It should only care about the PWM and the PWM should make sure that the pin is correctly muxed because otherwise it can't work as expected. > > > > > > The problem with making the PWM mode the "default" pinctrl state is that > > > > > > the default state will be applied before the driver is even probed. That > > > > > > makes it unsuitable for this case. I think what we really want here is > > > > > > explicitly "active" and "inactive" states for pinctrl where the PWM > > > > > > driver controls when exactly each state is applied. > > > > > > > > > > Note that this problem goes away nicely if the pwm pin is attached to > > > > > the backlight. Because it's the backlight's driver that "knows" when the > > > > > pwm is configured correctly and so the already existing mechanisms that > > > > > setup the mux when the bl is correctly probed do the right thing at the > > > > > right time. > > > > > > > > Actually that's not exactly true. The default pinctrl state will be > > > > applied before the driver's ->probe() implementation, so the pinctrl > > > > state will be active some time before even the backlight driver gets > > > > around to setting up the PWM. If you look at drivers/base/dd.c you'll > > > > see that really_probe() calls pinctrl_bind_pins() before calling the > > > > driver's ->probe() and will select the default state (unless there's > > > > also an "init" state defined, in which case that will get applied and > > > > only after successful probe will the default state be selected). > > > > > > > > So if you use only a default state, then you could even get into a > > > > situation where ->probe() return -EPROBE_DEFER and it would potentially > > > > take several seconds before the driver is reprobed, during which time > > > > the pinmux will already be set up but the PWM not configured properly > > > > and potentially outputting the wrong level. > > > > > > If you reread my suggestion to Michal completely you will notice I got > > > that right. > > > > > > > > > This solves the problem quite nicely because by default the pinctrl > > > > > > state isn't touched. For the case where the bootloader didn't initialize > > > > > > the PWM pin at all, the driver core won't do anything and keep it at the > > > > > > 100k pull-up default. > > > > > > > > > > Ditto if the pwm pinctrl is attached to the consumer without having to > > > > > introduce new pwm-specific stuff. > > > > > > > > Well yes, but you'd obviously also have to avoid using the "default" > > > > state, otherwise you'd run into the issues that I described above. > > > > > > I'd need "default" and "init", right. > > > > > > > > > > > > No I meant the pwm. Well, it's as easy as that: Whenever with your > > > > > > > > > approach you configure the pin as GPIO with the output set to low, > > > > > > > > > instead configure the pwm with duty_cycle to zero (or disable it). > > > > > > > > > Whenever with your approach you configure the pin as GPIO with the > > > > > > > > > output set to high, configure the pwm with duty_cycle to 100%. (Keeping > > > > > > > > > out inverted PWMs for the ease of discussion, but the procedure can be > > > > > > > > > adapted accordingly.) The only difference then is that with your > > > > > > > > > approach you already "know" in pwm-imx's .probe the idle level and can > > > > > > > > > configure the GPIO accordingly. With my approach you just have to wait > > > > > > > > > until the first pwm_apply which (as described above) works just as well. > > > > > > > > > > > > > > > > While here I am quite confident you are talking about kernel code, right? > > > > > > > > If yes, then your approach is clear to me. > > > > > > > > > > > > > > > > The problem is I am quite sure your approach does not solve the cases > > > > > > > > the pinctrl solution does. And according to my tests so far it does not > > > > > > > > work at all because the "init" and "default" states does not work as you > > > > > > > > are saying. > > > > > > > > > > > > > > That's as pointed out above, because you're looking at the pwm's pinctrl > > > > > > > and I at the pwm-consumer's pinctrl. > > > > > > > > > > > > > > Note that a sysfs consumer cannot be operated smoothly here, because > > > > > > > there is no pinctrl node to add the PWM mode to that only gets active > > > > > > > after the first configuration. This however is something that should not > > > > > > > be addressed in the imx driver but in the pwm core (if at all). > > > > > > > > > > > > With the pinctrl-based solution outlined above you can even operate a > > > > > > sysfs consumer properly. The pinctrl states are where they belong, with > > > > > > the PWM device and therefore they can be properly set when the PWM is > > > > > > used, rather than waiting for a PWM consumer to muck with the pinmux. > > > > > > > > > > > > Note how all the pieces are suddenly falling into place. In my > > > > > > experience that's usually a good indication that you're on the right > > > > > > track. > > > > > > > > > > OK, sysfs is the only point where the "put pinctrl stuff into the pwm > > > > > core (or driver)" is superior to the already existing and otherwise > > > > > completely working status quo. (Apart from bugs that need fixing in > > > > > your scenario, too.) > > > > > > > > Nope, sorry. It's superior in all of the other cases as well. You've > > > > said elsewhere already that the prerequisite for the current solution to > > > > support inverse polarity with the i.MX driver is to keep the driver > > > > running, even after the PWM is no longer used. Sorry but that's just not > > > > an option for me. > > > > > > You want that after pwm_disable() the pin still keeps the idle level. As > > > the hardware doesn't provide this feature "as is" something has to be > > > done about it. This can be reached either by operating the pin as PWM > > > with 0% duty cycle or by switching to GPIO that is configured to the > > > desired level. From the PWM driver's POV the first is the more natural, > > > as this can be accomplished with the registers this driver cares about > > > anyhow. > > > > We've been over this before. Yes, as long as you operate the pin as PWM > > it's okay to just actively drive it. But once you no longer use the pin, > > why would you want to still actively drive it? > > This is because you say the pin should keep its level as inactive even > though that's not what the hardware does without keeping care. > > I say this is strange: The consumer specifies if the pwm should be > inverted or not because the pwm alone doesn't know that. Then with the > consumer gone *you* want the pwm to "remember" its last user requested > inversion and so the pin should stay at 1. > > To answer your question: I don't want to actively drive the pin when the > user is gone. That's a requirement comming from you. That's not actually what I'm suggesting. What I'm saying is that the PWM should not actively drive the pin at all. That's my entire point here. If the device gets out of boot, nobody is actively driving the pin either, so it has that 100k pull-up to make sure it is high by default, which in turn causes the backlight to remain off. I'm saying that that is exactly the state that the pin should be put back into when nobody is using the PWM. So in other words I'm saying that that pin should be passively driven by that 100k pull-up if it is not actively used by the PWM. What you are saying is that either we actively drive irrespective of whether there are any users, or that we leave it undefined what we do with a pin when it is no longer used. I think those are both wrong because the former doesn't allow you to properly shut down the system and the latter gives you undefined results, which is pretty useless because it is completely non-deterministic. > If it was my decision, I'd say: If the backlight driver calls > > pwm_config(pwm, 0, 100); > pwm_disable(pwm); > > I'd interpret that as: The consumer doesn't use the pin any more, so I'm > not bound to keep the pin at a certain level. If however after > pwm_disable the consumer is still considered to use the pin, then > implementing it the same way as pwm_config(pwm, 0, 100) is the right > thing to do. This applies then to all pwm implementations and so should > be solved in the pwm core, not in the imx driver. In this case the > concept of "disabling a PWM" can go away completely. But again, why should PWMs be special? You turn off all other resources when you no longer need them, right? If you power your panel with a regulator, then when the panel is disabled you want to disable the regulator, right? Similarily if you don't use your I2C controller you want to turn off the clock that drives it, right? This is the same for any resource in your system: if you no longer need it, disable it. The fact that "disabling" the PWM is not straightforward on i.MX doesn't mean that we should simply ignore it. > In another mail you wrote: > > Your example of keeping an LED in the current state is actually an > > example of where the consumer still needs it. As long as you want to use > > the LED you need to keep the LED driver around, and as long as the LED > > driver is around you have a consumer for the PWM. > > With an analog reasoning I'd say: As long as the backlight driver cares > about the backlight being off, it should not disable (or put) the PWM. It shouldn't put the PWM because it still needs it. But it should be totally fine to disable it. Disabling a PWM should result in the PWM not outputting any power. > > > Also note this is similar in the pwm-bcm-kona driver that doesn't seem > > > to have the concept of "disable" at all. kona_pwmc_disable() just sets > > > up 0% duty cycle. In my eyes this is an argument that is good enough to > > > at least nack the imx-specific implementation of that pinctrl stuff. > > > > It's not a good enough argument for me. It's certainly possible that not > > all PWM driver can be made to behave exactly as needed. pwm-bcm-kona > > might be one of those, but that doesn't mean that everybody else should > > be restricted to the same behaviour. If we can make i.MX behave exactly > > right, then we should do that. > > And if we can make the imx-specific implementation right in a generic > way in the pwm core that might help the bcm-kona driver for free. It may, but we don't know that. Look, I'm not generally opposed to do this in the core, but I'm not going to implement it in the core until I'm convinced that it is useful in a large number of cases. One or two are not large numbers. > > > If the pinctrl idea is implemented in the pwm core, I won't object. > > > > Let me see if I get this straight: you're not objecting to the idea of > > implementing the pinctrl solution, your only objection is to put it in > > the i.MX driver? > > Given that the pinctrl solution is a generic solution that might help > other drivers, too, I think it should not go into the imx specific > driver just because for now this is the only driver that might benefit > from it. > > I still don't think it's the best solution for the imx problem but as I > care more for imx in general than for pwm in general I'm interested in > keeping the imx driver focused to the imx specific parts. I won't repeat > the advantages of putting generic stuff into a generic location instead > of its first user. We can debate this for another few weeks, but I don't think you're going to be able to convince me, so let's cut this short: pinctrl support goes in the i.MX driver for now. Let's move on. > > > > > Also dts writes don't need to lookup the needed GPIO numbers and pinctrl. > > > > > > > > Just to clarify: I don't think that we need to get the GPIO number > > > > involved in this case, because we don't have to reconfigure the pin as > > > > GPIO to make this work. The only reason that Michal's proposal did that > > > > is because that was believed to be necessary. But if the pin can just be > > > > configured with a 100k pull-up, that's enough to pull the pin high when > > > > we need it. > > > > > > Unless the gpio happens to be configured as output at the wrong value. > > > Further I'm not sure if the pwm in disabled state actively pulls to 0 > > > and if in this state the PU of the pin is good enough to ensure a one > > > here. That would need verification first. > > > > The idea is to *not* configure the GPIO as output and output the wrong > > value. The idea is to not use the GPIO at all and instead use whatever > > the hardware default is that makes it such that the backlight is off by > > default at boot. > > Which might be possible with Lothar's idea for some machines, but not > for all users of the pwm-imx driver. > > Also note that you don't include the poor souls where there is no > hardware pullup into the right direction. The poor souls should speak up and then we can look into finding a good solution for them. I'm pretty sure there must be some equivalent that can be used for other users. Thierry [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-16 12:24 ` Thierry Reding @ 2018-11-18 20:08 ` Uwe Kleine-König 2018-11-19 8:48 ` Uwe Kleine-König 2018-11-22 15:03 ` Thierry Reding 0 siblings, 2 replies; 60+ messages in thread From: Uwe Kleine-König @ 2018-11-18 20:08 UTC (permalink / raw) To: Thierry Reding Cc: Vokáč Michal, Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, kernel, Fabio Estevam, Lothar Waßmann, Linus Walleij Hello Thierry, On Fri, Nov 16, 2018 at 01:24:45PM +0100, Thierry Reding wrote: > On Fri, Nov 16, 2018 at 11:39:29AM +0100, Uwe Kleine-König wrote: > > On Fri, Nov 16, 2018 at 10:51:24AM +0100, Thierry Reding wrote: > > > On Thu, Nov 15, 2018 at 09:37:33PM +0100, Uwe Kleine-König wrote: > > > > On Thu, Nov 15, 2018 at 04:25:45PM +0100, Thierry Reding wrote: > > > > > On Wed, Nov 14, 2018 at 10:51:20PM +0100, Uwe Kleine-König wrote: > > > > > > On Wed, Nov 14, 2018 at 12:34:49PM +0100, Thierry Reding wrote: > > > > > > > On Fri, Nov 09, 2018 at 05:55:55PM +0100, Uwe Kleine-König wrote: > > > > > > > > On Fri, Nov 09, 2018 at 02:24:42PM +0000, Vokáč Michal wrote: > > > > > > > > > On 8.11.2018 20:18, Uwe Kleine-König wrote: > > > > > > > > > > Taking your example with the backlight device you specify an "init" and > > > > > > > > > > a "default" pinctrl and only "default" contains the muxing for the PWM > > > > > > > > > > pin everything should be as smooth as necessary: The pwm is only muxed > > > > > > > > > > when the backlight device is successfully bound. > > > > > > > > > > > > > > > > > > Have you tried that Uwe? The bad news is I tested that before and now > > > > > > > > > again and it does not work like that. We already discussed that earlier. > > > > > > > > > > > > > > > > The key is that the pinmux setting for the PWM pin should be part of the > > > > > > > > bl pinctrl, not the pwm pinctrl. Then "default" is only setup when the > > > > > > > > bl device is successfully bound which is after the bl's .probe callback > > > > > > > > called pwm_apply(). > > > > > > > > > > > > > > No, that's not at all correct. Pinmux settings should reside with the > > > > > > > consumer of the pin. In this case, the PWM is the consumer of the pin, > > > > > > > whereas the backlight is the consumer of the *PWM*. > > > > > > > > > > > > This is news to me. Adding Linus W. to Cc, maybe he can comment?! > > > > > > > > > > > > Grepping through the arm device trees it really seems common to put the > > > > > > pinctrl for the pwm pin into the pwm device. I didn't search in depth, > > > > > > but I didn't find a counter example. > > > > > > > > > > > > For GPIOs it is common that the pinmuxing is included in the GPIO's > > > > > > consumer pinctrl. Ditto for mdio busses whose pinctrl is included in the > > > > > > ethernet pinctrl. > > > > > > > > > > GPIO is different from PWM in that the GPIO is already the pin itself > > > > > and is otherwise generic. So typically you put the pinmuxing options > > > > > into the device tree node for the consumer of the GPIO, because it is > > > > > only when the consumer uses the GPIO that you need to configure that > > > > > pin as GPIO. > > > > > > > > > > For PWM, however, the PWM consumer is only the consumer of the PWM, but > > > > > the PWM device itself is the real consumer of the pin that outputs the > > > > > PWM signal. So the PWM determines when the pinmux states need to be > > > > > applied, whereas the consumer of the PWM only deals with the PWM. > > > > > > > > > > For MDIO busses, I think they are usually part of, and driven by, the > > > > > ethernet controller, so again it makes sense to put the pinmux into the > > > > > node of the ethernet controller, because the ethernet controller is the > > > > > user of the pins. > > > > > > > > Maybe it was a bad idea to broaden the discussion to talk about gpios > > > > and ethernet stuff here. I'd still consider it a valid construct to put > > > > the pwm pin into the backlight's pinctrl unless Linux W. disagrees. > > > > > > But why? The backlight doesn't care about the specific pinmuxing of the > > > PWM pin. All it cares about is the PWM signal. That's the level of > > > abstraction that the PWM consumer expects, anything lower level belongs > > > in the PWM driver. > > > > The backlight driver cares about the PWM pin muxing because if it's > > wrongly muxed the backlight doesn't work as intended. > > It shouldn't care about that. It should only care about the PWM and the > PWM should make sure that the pin is correctly muxed because otherwise > it can't work as expected. > > > > > > > > The problem with making the PWM mode the "default" pinctrl state is that > > > > > > > the default state will be applied before the driver is even probed. That > > > > > > > makes it unsuitable for this case. I think what we really want here is > > > > > > > explicitly "active" and "inactive" states for pinctrl where the PWM > > > > > > > driver controls when exactly each state is applied. > > > > > > > > > > > > Note that this problem goes away nicely if the pwm pin is attached to > > > > > > the backlight. Because it's the backlight's driver that "knows" when the > > > > > > pwm is configured correctly and so the already existing mechanisms that > > > > > > setup the mux when the bl is correctly probed do the right thing at the > > > > > > right time. > > > > > > > > > > Actually that's not exactly true. The default pinctrl state will be > > > > > applied before the driver's ->probe() implementation, so the pinctrl > > > > > state will be active some time before even the backlight driver gets > > > > > around to setting up the PWM. If you look at drivers/base/dd.c you'll > > > > > see that really_probe() calls pinctrl_bind_pins() before calling the > > > > > driver's ->probe() and will select the default state (unless there's > > > > > also an "init" state defined, in which case that will get applied and > > > > > only after successful probe will the default state be selected). > > > > > > > > > > So if you use only a default state, then you could even get into a > > > > > situation where ->probe() return -EPROBE_DEFER and it would potentially > > > > > take several seconds before the driver is reprobed, during which time > > > > > the pinmux will already be set up but the PWM not configured properly > > > > > and potentially outputting the wrong level. > > > > > > > > If you reread my suggestion to Michal completely you will notice I got > > > > that right. > > > > > > > > > > > This solves the problem quite nicely because by default the pinctrl > > > > > > > state isn't touched. For the case where the bootloader didn't initialize > > > > > > > the PWM pin at all, the driver core won't do anything and keep it at the > > > > > > > 100k pull-up default. > > > > > > > > > > > > Ditto if the pwm pinctrl is attached to the consumer without having to > > > > > > introduce new pwm-specific stuff. > > > > > > > > > > Well yes, but you'd obviously also have to avoid using the "default" > > > > > state, otherwise you'd run into the issues that I described above. > > > > > > > > I'd need "default" and "init", right. > > > > > > > > > > > > > > No I meant the pwm. Well, it's as easy as that: Whenever with your > > > > > > > > > > approach you configure the pin as GPIO with the output set to low, > > > > > > > > > > instead configure the pwm with duty_cycle to zero (or disable it). > > > > > > > > > > Whenever with your approach you configure the pin as GPIO with the > > > > > > > > > > output set to high, configure the pwm with duty_cycle to 100%. (Keeping > > > > > > > > > > out inverted PWMs for the ease of discussion, but the procedure can be > > > > > > > > > > adapted accordingly.) The only difference then is that with your > > > > > > > > > > approach you already "know" in pwm-imx's .probe the idle level and can > > > > > > > > > > configure the GPIO accordingly. With my approach you just have to wait > > > > > > > > > > until the first pwm_apply which (as described above) works just as well. > > > > > > > > > > > > > > > > > > While here I am quite confident you are talking about kernel code, right? > > > > > > > > > If yes, then your approach is clear to me. > > > > > > > > > > > > > > > > > > The problem is I am quite sure your approach does not solve the cases > > > > > > > > > the pinctrl solution does. And according to my tests so far it does not > > > > > > > > > work at all because the "init" and "default" states does not work as you > > > > > > > > > are saying. > > > > > > > > > > > > > > > > That's as pointed out above, because you're looking at the pwm's pinctrl > > > > > > > > and I at the pwm-consumer's pinctrl. > > > > > > > > > > > > > > > > Note that a sysfs consumer cannot be operated smoothly here, because > > > > > > > > there is no pinctrl node to add the PWM mode to that only gets active > > > > > > > > after the first configuration. This however is something that should not > > > > > > > > be addressed in the imx driver but in the pwm core (if at all). > > > > > > > > > > > > > > With the pinctrl-based solution outlined above you can even operate a > > > > > > > sysfs consumer properly. The pinctrl states are where they belong, with > > > > > > > the PWM device and therefore they can be properly set when the PWM is > > > > > > > used, rather than waiting for a PWM consumer to muck with the pinmux. > > > > > > > > > > > > > > Note how all the pieces are suddenly falling into place. In my > > > > > > > experience that's usually a good indication that you're on the right > > > > > > > track. > > > > > > > > > > > > OK, sysfs is the only point where the "put pinctrl stuff into the pwm > > > > > > core (or driver)" is superior to the already existing and otherwise > > > > > > completely working status quo. (Apart from bugs that need fixing in > > > > > > your scenario, too.) > > > > > > > > > > Nope, sorry. It's superior in all of the other cases as well. You've > > > > > said elsewhere already that the prerequisite for the current solution to > > > > > support inverse polarity with the i.MX driver is to keep the driver > > > > > running, even after the PWM is no longer used. Sorry but that's just not > > > > > an option for me. > > > > > > > > You want that after pwm_disable() the pin still keeps the idle level. As > > > > the hardware doesn't provide this feature "as is" something has to be > > > > done about it. This can be reached either by operating the pin as PWM > > > > with 0% duty cycle or by switching to GPIO that is configured to the > > > > desired level. From the PWM driver's POV the first is the more natural, > > > > as this can be accomplished with the registers this driver cares about > > > > anyhow. > > > > > > We've been over this before. Yes, as long as you operate the pin as PWM > > > it's okay to just actively drive it. But once you no longer use the pin, > > > why would you want to still actively drive it? > > > > This is because you say the pin should keep its level as inactive even > > though that's not what the hardware does without keeping care. > > > > I say this is strange: The consumer specifies if the pwm should be > > inverted or not because the pwm alone doesn't know that. Then with the > > consumer gone *you* want the pwm to "remember" its last user requested > > inversion and so the pin should stay at 1. > > > > To answer your question: I don't want to actively drive the pin when the > > user is gone. That's a requirement comming from you. > > That's not actually what I'm suggesting. What I'm saying is that the PWM > should not actively drive the pin at all. I'm a tad annoyed and grumpy here. We're discussing since quite some time about what is the right thing to do on pwm_disable(). Up to now I understood you that it should make the pin drive the inactive level. Thinking a bit about this it doesn't really matter for the consumer if the pin stays in the idle level because there is a pull into the right direction and the PWM is high-Z or if the PWM pulls actively in the right direction. Also for pwm_config(pwm, 0, 100) the PWM could disable its output in the presence of a pull, so the property says true that the effects of pwm_config(pwm, 0, 100) and pwm_disable(pwm) should be the same. And so my claim that pwm_disable is a part of the API that doesn't give any value stays true. > That's my entire point here. > If the device gets out of boot, nobody is actively driving the pin > either, so it has that 100k pull-up to make sure it is high by default, > which in turn causes the backlight to remain off. I'm saying that that > is exactly the state that the pin should be put back into when nobody is > using the PWM. > > So in other words I'm saying that that pin should be passively driven by > that 100k pull-up if it is not actively used by the PWM. > > What you are saying is that either we actively drive irrespective of > whether there are any users, or that we leave it undefined what we do > with a pin when it is no longer used. I think those are both wrong > because the former doesn't allow you to properly shut down the system > and the latter gives you undefined results, which is pretty useless > because it is completely non-deterministic. I think shut down doesn't matter because on shutdown the backlight driver doesn't release the pwm and so it continues to keep the intended level. > > If it was my decision, I'd say: If the backlight driver calls > > > > pwm_config(pwm, 0, 100); > > pwm_disable(pwm); > > > > I'd interpret that as: The consumer doesn't use the pin any more, so I'm > > not bound to keep the pin at a certain level. If however after > > pwm_disable the consumer is still considered to use the pin, then > > implementing it the same way as pwm_config(pwm, 0, 100) is the right > > thing to do. This applies then to all pwm implementations and so should > > be solved in the pwm core, not in the imx driver. In this case the > > concept of "disabling a PWM" can go away completely. > > But again, why should PWMs be special? You turn off all other resources > when you no longer need them, right? If you power your panel with a > regulator, then when the panel is disabled you want to disable the > regulator, right? Similarily if you don't use your I2C controller you > want to turn off the clock that drives it, right? This is the same for > any resource in your system: if you no longer need it, disable it. The > fact that "disabling" the PWM is not straightforward on i.MX doesn't > mean that we should simply ignore it. I don't say we should ignore it. I say we shouldn't disable the hardware if the consumer calls pwm_disable() if disabling the hardware results in a state that shouldn't happen on pwm_disable(). Also note, that there are two different "disable" you are talking about. One is disable in the sense of "pwm_disable". This is about the pwm to stop oscillating. And the other is about unsetting the enable bit in a control register and stopping the input clock. Even though both usually go hand in hand, if you still have requirements on the hardware state after pwm_disable that are not given if you disable the hardware it is stupid to require to disable the hardware and then implement something else on top to undo this unwanted result. > > In another mail you wrote: > > > Your example of keeping an LED in the current state is actually an > > > example of where the consumer still needs it. As long as you want to use > > > the LED you need to keep the LED driver around, and as long as the LED > > > driver is around you have a consumer for the PWM. > > > > With an analog reasoning I'd say: As long as the backlight driver cares > > about the backlight being off, it should not disable (or put) the PWM. > > It shouldn't put the PWM because it still needs it. But it should be > totally fine to disable it. Disabling a PWM should result in the PWM not > outputting any power. > > > > > Also note this is similar in the pwm-bcm-kona driver that doesn't seem > > > > to have the concept of "disable" at all. kona_pwmc_disable() just sets > > > > up 0% duty cycle. In my eyes this is an argument that is good enough to > > > > at least nack the imx-specific implementation of that pinctrl stuff. > > > > > > It's not a good enough argument for me. It's certainly possible that not > > > all PWM driver can be made to behave exactly as needed. pwm-bcm-kona > > > might be one of those, but that doesn't mean that everybody else should > > > be restricted to the same behaviour. If we can make i.MX behave exactly > > > right, then we should do that. > > > > And if we can make the imx-specific implementation right in a generic > > way in the pwm core that might help the bcm-kona driver for free. > > It may, but we don't know that. Look at the .disable callback of the bcm-kona driver. The way it is written together with the comments in it makes it obvious that this driver also actively drives the pin after disable. > Look, I'm not generally opposed to do this in the core, but I'm not > going to implement it in the core until I'm convinced that it is > useful in a large number of cases. One or two are not large numbers. Last time I suggested to implement this is in the core you said: "So I try not to attempt genericity until there are at least two or more use-cases that can be the basis for a generic solution." Now that I found a 2nd driver that can benefit you suddenly request "a large number of cases". I believe one reason for Linux being as good as it is today is, that usually with this kind of scenario things are done in the generic way even if there is only a single user up to now. And even if this solution doesn't 100% satisfies the needs for the next user, it is much easier for the next one to adapt and adopt generic code than to first cut it out from a hardware driver. And until the second user appears the separation helps to better understand the code because it is not bound to a hardware driver that a reviewer might not know. > > > > If the pinctrl idea is implemented in the pwm core, I won't object. > > > > > > Let me see if I get this straight: you're not objecting to the idea of > > > implementing the pinctrl solution, your only objection is to put it in > > > the i.MX driver? > > > > Given that the pinctrl solution is a generic solution that might help > > other drivers, too, I think it should not go into the imx specific > > driver just because for now this is the only driver that might benefit > > from it. > > > > I still don't think it's the best solution for the imx problem but as I > > care more for imx in general than for pwm in general I'm interested in > > keeping the imx driver focused to the imx specific parts. I won't repeat > > the advantages of putting generic stuff into a generic location instead > > of its first user. > > We can debate this for another few weeks, but I don't think you're going > to be able to convince me, so let's cut this short: pinctrl support goes > in the i.MX driver for now. Let's move on. OK, you're taking out your maintainer's club. That's sad because I'm convinced you're forcing a solution that is not optimal. I accept that the pinctrl stuff solves the problem, but I'm sure it's wrong to put it into a hardware driver. > > > > > > Also dts writes don't need to lookup the needed GPIO numbers and pinctrl. > > > > > > > > > > Just to clarify: I don't think that we need to get the GPIO number > > > > > involved in this case, because we don't have to reconfigure the pin as > > > > > GPIO to make this work. The only reason that Michal's proposal did that > > > > > is because that was believed to be necessary. But if the pin can just be > > > > > configured with a 100k pull-up, that's enough to pull the pin high when > > > > > we need it. > > > > > > > > Unless the gpio happens to be configured as output at the wrong value. > > > > Further I'm not sure if the pwm in disabled state actively pulls to 0 > > > > and if in this state the PU of the pin is good enough to ensure a one > > > > here. That would need verification first. > > > > > > The idea is to *not* configure the GPIO as output and output the wrong > > > value. The idea is to not use the GPIO at all and instead use whatever > > > the hardware default is that makes it such that the backlight is off by > > > default at boot. > > > > Which might be possible with Lothar's idea for some machines, but not > > for all users of the pwm-imx driver. > > > > Also note that you don't include the poor souls where there is no > > hardware pullup into the right direction. > > The poor souls should speak up and then we can look into finding a good > solution for them. I'm pretty sure there must be some equivalent that > can be used for other users. I think one of the boards that I'm working with has an enabled backlight at power on until the bootloader actively drives the related pwm to the right level (either using the pwm or the gpio function of the pin). I will double check that but assuming that is right, just disabling the output won't work here. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-18 20:08 ` Uwe Kleine-König @ 2018-11-19 8:48 ` Uwe Kleine-König 2018-11-22 15:03 ` Thierry Reding 1 sibling, 0 replies; 60+ messages in thread From: Uwe Kleine-König @ 2018-11-19 8:48 UTC (permalink / raw) To: Thierry Reding Cc: Vokáč Michal, Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, kernel, Fabio Estevam, Lothar Waßmann, Linus Walleij Hello, On Sun, Nov 18, 2018 at 09:08:15PM +0100, Uwe Kleine-König wrote: > On Fri, Nov 16, 2018 at 01:24:45PM +0100, Thierry Reding wrote: > > On Fri, Nov 16, 2018 at 11:39:29AM +0100, Uwe Kleine-König wrote: > > > Also note that you don't include the poor souls where there is no > > > hardware pullup into the right direction. > > > > The poor souls should speak up and then we can look into finding a good > > solution for them. I'm pretty sure there must be some equivalent that > > can be used for other users. > > I think one of the boards that I'm working with has an enabled backlight > at power on until the bootloader actively drives the related pwm to > the right level (either using the pwm or the gpio function of the pin). > I will double check that but assuming that is right, just disabling the > output won't work here. I just confirmed this. On the board I have in mind the backlight really goes on during powerup. One of the first things the bootloader does is to ensure the backlight goes off again by actively driving the respective pin. I fully agree with you this is unfortunate and the hardware team could have made the situation smoother if there were a pull up. I guess asking them to go back and fix that won't be accepted[1]. So please whatever solution you force through, please consider it should work without a sane pull and also with the imx SoCs before i.MX6 which cannot disable the output driver via pinmux. Best regards Uwe [1] Additionally this is a bought display+backlight+touch combo, so the right place to put the pull would be in this unit, because the board designer rightfully says: I won't put a pull up on my board because for the next batch we're maybe switching to the similar display combo that needs an active high signal for the backlight and I won't create another factor 2 for the board variants for stuff that can be fixed in software. -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-18 20:08 ` Uwe Kleine-König 2018-11-19 8:48 ` Uwe Kleine-König @ 2018-11-22 15:03 ` Thierry Reding 2018-11-22 16:17 ` Uwe Kleine-König 1 sibling, 1 reply; 60+ messages in thread From: Thierry Reding @ 2018-11-22 15:03 UTC (permalink / raw) To: Uwe Kleine-König Cc: Vokáč Michal, Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, kernel, Fabio Estevam, Lothar Waßmann, Linus Walleij [-- Attachment #1: Type: text/plain, Size: 25467 bytes --] On Sun, Nov 18, 2018 at 09:08:15PM +0100, Uwe Kleine-König wrote: > Hello Thierry, > > On Fri, Nov 16, 2018 at 01:24:45PM +0100, Thierry Reding wrote: > > On Fri, Nov 16, 2018 at 11:39:29AM +0100, Uwe Kleine-König wrote: > > > On Fri, Nov 16, 2018 at 10:51:24AM +0100, Thierry Reding wrote: > > > > On Thu, Nov 15, 2018 at 09:37:33PM +0100, Uwe Kleine-König wrote: > > > > > On Thu, Nov 15, 2018 at 04:25:45PM +0100, Thierry Reding wrote: > > > > > > On Wed, Nov 14, 2018 at 10:51:20PM +0100, Uwe Kleine-König wrote: > > > > > > > On Wed, Nov 14, 2018 at 12:34:49PM +0100, Thierry Reding wrote: > > > > > > > > On Fri, Nov 09, 2018 at 05:55:55PM +0100, Uwe Kleine-König wrote: > > > > > > > > > On Fri, Nov 09, 2018 at 02:24:42PM +0000, Vokáč Michal wrote: > > > > > > > > > > On 8.11.2018 20:18, Uwe Kleine-König wrote: > > > > > > > > > > > Taking your example with the backlight device you specify an "init" and > > > > > > > > > > > a "default" pinctrl and only "default" contains the muxing for the PWM > > > > > > > > > > > pin everything should be as smooth as necessary: The pwm is only muxed > > > > > > > > > > > when the backlight device is successfully bound. > > > > > > > > > > > > > > > > > > > > Have you tried that Uwe? The bad news is I tested that before and now > > > > > > > > > > again and it does not work like that. We already discussed that earlier. > > > > > > > > > > > > > > > > > > The key is that the pinmux setting for the PWM pin should be part of the > > > > > > > > > bl pinctrl, not the pwm pinctrl. Then "default" is only setup when the > > > > > > > > > bl device is successfully bound which is after the bl's .probe callback > > > > > > > > > called pwm_apply(). > > > > > > > > > > > > > > > > No, that's not at all correct. Pinmux settings should reside with the > > > > > > > > consumer of the pin. In this case, the PWM is the consumer of the pin, > > > > > > > > whereas the backlight is the consumer of the *PWM*. > > > > > > > > > > > > > > This is news to me. Adding Linus W. to Cc, maybe he can comment?! > > > > > > > > > > > > > > Grepping through the arm device trees it really seems common to put the > > > > > > > pinctrl for the pwm pin into the pwm device. I didn't search in depth, > > > > > > > but I didn't find a counter example. > > > > > > > > > > > > > > For GPIOs it is common that the pinmuxing is included in the GPIO's > > > > > > > consumer pinctrl. Ditto for mdio busses whose pinctrl is included in the > > > > > > > ethernet pinctrl. > > > > > > > > > > > > GPIO is different from PWM in that the GPIO is already the pin itself > > > > > > and is otherwise generic. So typically you put the pinmuxing options > > > > > > into the device tree node for the consumer of the GPIO, because it is > > > > > > only when the consumer uses the GPIO that you need to configure that > > > > > > pin as GPIO. > > > > > > > > > > > > For PWM, however, the PWM consumer is only the consumer of the PWM, but > > > > > > the PWM device itself is the real consumer of the pin that outputs the > > > > > > PWM signal. So the PWM determines when the pinmux states need to be > > > > > > applied, whereas the consumer of the PWM only deals with the PWM. > > > > > > > > > > > > For MDIO busses, I think they are usually part of, and driven by, the > > > > > > ethernet controller, so again it makes sense to put the pinmux into the > > > > > > node of the ethernet controller, because the ethernet controller is the > > > > > > user of the pins. > > > > > > > > > > Maybe it was a bad idea to broaden the discussion to talk about gpios > > > > > and ethernet stuff here. I'd still consider it a valid construct to put > > > > > the pwm pin into the backlight's pinctrl unless Linux W. disagrees. > > > > > > > > But why? The backlight doesn't care about the specific pinmuxing of the > > > > PWM pin. All it cares about is the PWM signal. That's the level of > > > > abstraction that the PWM consumer expects, anything lower level belongs > > > > in the PWM driver. > > > > > > The backlight driver cares about the PWM pin muxing because if it's > > > wrongly muxed the backlight doesn't work as intended. > > > > It shouldn't care about that. It should only care about the PWM and the > > PWM should make sure that the pin is correctly muxed because otherwise > > it can't work as expected. > > > > > > > > > > The problem with making the PWM mode the "default" pinctrl state is that > > > > > > > > the default state will be applied before the driver is even probed. That > > > > > > > > makes it unsuitable for this case. I think what we really want here is > > > > > > > > explicitly "active" and "inactive" states for pinctrl where the PWM > > > > > > > > driver controls when exactly each state is applied. > > > > > > > > > > > > > > Note that this problem goes away nicely if the pwm pin is attached to > > > > > > > the backlight. Because it's the backlight's driver that "knows" when the > > > > > > > pwm is configured correctly and so the already existing mechanisms that > > > > > > > setup the mux when the bl is correctly probed do the right thing at the > > > > > > > right time. > > > > > > > > > > > > Actually that's not exactly true. The default pinctrl state will be > > > > > > applied before the driver's ->probe() implementation, so the pinctrl > > > > > > state will be active some time before even the backlight driver gets > > > > > > around to setting up the PWM. If you look at drivers/base/dd.c you'll > > > > > > see that really_probe() calls pinctrl_bind_pins() before calling the > > > > > > driver's ->probe() and will select the default state (unless there's > > > > > > also an "init" state defined, in which case that will get applied and > > > > > > only after successful probe will the default state be selected). > > > > > > > > > > > > So if you use only a default state, then you could even get into a > > > > > > situation where ->probe() return -EPROBE_DEFER and it would potentially > > > > > > take several seconds before the driver is reprobed, during which time > > > > > > the pinmux will already be set up but the PWM not configured properly > > > > > > and potentially outputting the wrong level. > > > > > > > > > > If you reread my suggestion to Michal completely you will notice I got > > > > > that right. > > > > > > > > > > > > > This solves the problem quite nicely because by default the pinctrl > > > > > > > > state isn't touched. For the case where the bootloader didn't initialize > > > > > > > > the PWM pin at all, the driver core won't do anything and keep it at the > > > > > > > > 100k pull-up default. > > > > > > > > > > > > > > Ditto if the pwm pinctrl is attached to the consumer without having to > > > > > > > introduce new pwm-specific stuff. > > > > > > > > > > > > Well yes, but you'd obviously also have to avoid using the "default" > > > > > > state, otherwise you'd run into the issues that I described above. > > > > > > > > > > I'd need "default" and "init", right. > > > > > > > > > > > > > > > > No I meant the pwm. Well, it's as easy as that: Whenever with your > > > > > > > > > > > approach you configure the pin as GPIO with the output set to low, > > > > > > > > > > > instead configure the pwm with duty_cycle to zero (or disable it). > > > > > > > > > > > Whenever with your approach you configure the pin as GPIO with the > > > > > > > > > > > output set to high, configure the pwm with duty_cycle to 100%. (Keeping > > > > > > > > > > > out inverted PWMs for the ease of discussion, but the procedure can be > > > > > > > > > > > adapted accordingly.) The only difference then is that with your > > > > > > > > > > > approach you already "know" in pwm-imx's .probe the idle level and can > > > > > > > > > > > configure the GPIO accordingly. With my approach you just have to wait > > > > > > > > > > > until the first pwm_apply which (as described above) works just as well. > > > > > > > > > > > > > > > > > > > > While here I am quite confident you are talking about kernel code, right? > > > > > > > > > > If yes, then your approach is clear to me. > > > > > > > > > > > > > > > > > > > > The problem is I am quite sure your approach does not solve the cases > > > > > > > > > > the pinctrl solution does. And according to my tests so far it does not > > > > > > > > > > work at all because the "init" and "default" states does not work as you > > > > > > > > > > are saying. > > > > > > > > > > > > > > > > > > That's as pointed out above, because you're looking at the pwm's pinctrl > > > > > > > > > and I at the pwm-consumer's pinctrl. > > > > > > > > > > > > > > > > > > Note that a sysfs consumer cannot be operated smoothly here, because > > > > > > > > > there is no pinctrl node to add the PWM mode to that only gets active > > > > > > > > > after the first configuration. This however is something that should not > > > > > > > > > be addressed in the imx driver but in the pwm core (if at all). > > > > > > > > > > > > > > > > With the pinctrl-based solution outlined above you can even operate a > > > > > > > > sysfs consumer properly. The pinctrl states are where they belong, with > > > > > > > > the PWM device and therefore they can be properly set when the PWM is > > > > > > > > used, rather than waiting for a PWM consumer to muck with the pinmux. > > > > > > > > > > > > > > > > Note how all the pieces are suddenly falling into place. In my > > > > > > > > experience that's usually a good indication that you're on the right > > > > > > > > track. > > > > > > > > > > > > > > OK, sysfs is the only point where the "put pinctrl stuff into the pwm > > > > > > > core (or driver)" is superior to the already existing and otherwise > > > > > > > completely working status quo. (Apart from bugs that need fixing in > > > > > > > your scenario, too.) > > > > > > > > > > > > Nope, sorry. It's superior in all of the other cases as well. You've > > > > > > said elsewhere already that the prerequisite for the current solution to > > > > > > support inverse polarity with the i.MX driver is to keep the driver > > > > > > running, even after the PWM is no longer used. Sorry but that's just not > > > > > > an option for me. > > > > > > > > > > You want that after pwm_disable() the pin still keeps the idle level. As > > > > > the hardware doesn't provide this feature "as is" something has to be > > > > > done about it. This can be reached either by operating the pin as PWM > > > > > with 0% duty cycle or by switching to GPIO that is configured to the > > > > > desired level. From the PWM driver's POV the first is the more natural, > > > > > as this can be accomplished with the registers this driver cares about > > > > > anyhow. > > > > > > > > We've been over this before. Yes, as long as you operate the pin as PWM > > > > it's okay to just actively drive it. But once you no longer use the pin, > > > > why would you want to still actively drive it? > > > > > > This is because you say the pin should keep its level as inactive even > > > though that's not what the hardware does without keeping care. > > > > > > I say this is strange: The consumer specifies if the pwm should be > > > inverted or not because the pwm alone doesn't know that. Then with the > > > consumer gone *you* want the pwm to "remember" its last user requested > > > inversion and so the pin should stay at 1. > > > > > > To answer your question: I don't want to actively drive the pin when the > > > user is gone. That's a requirement comming from you. > > > > That's not actually what I'm suggesting. What I'm saying is that the PWM > > should not actively drive the pin at all. > > I'm a tad annoyed and grumpy here. We're discussing since quite some > time about what is the right thing to do on pwm_disable(). Up to now I > understood you that it should make the pin drive the inactive level. All I said was that the pin should be at the inactive level after pwm_disable(). It can't be actively driven by the PWM because the PWM is supposed to be off, so really the only option is to have a pull-up or be Hi-Z. > Thinking a bit about this it doesn't really matter for the consumer if > the pin stays in the idle level because there is a pull into the right > direction and the PWM is high-Z or if the PWM pulls actively in the > right direction. Also for pwm_config(pwm, 0, 100) the PWM could disable > its output in the presence of a pull, so the property says true that the > effects of pwm_config(pwm, 0, 100) and pwm_disable(pwm) should be the > same. And so my claim that pwm_disable is a part of the API that > doesn't give any value stays true. I still think there's a slight difference there. Granted the effect on the consumer is the same whether you disable or set the duty-cycle to zero because the power output is the same. pwm_disable() is still more explicit, though, so it may involve more than just setting the duty- cycle. > > That's my entire point here. > > If the device gets out of boot, nobody is actively driving the pin > > either, so it has that 100k pull-up to make sure it is high by default, > > which in turn causes the backlight to remain off. I'm saying that that > > is exactly the state that the pin should be put back into when nobody is > > using the PWM. > > > > So in other words I'm saying that that pin should be passively driven by > > that 100k pull-up if it is not actively used by the PWM. > > > > What you are saying is that either we actively drive irrespective of > > whether there are any users, or that we leave it undefined what we do > > with a pin when it is no longer used. I think those are both wrong > > because the former doesn't allow you to properly shut down the system > > and the latter gives you undefined results, which is pretty useless > > because it is completely non-deterministic. > > I think shut down doesn't matter because on shutdown the backlight > driver doesn't release the pwm and so it continues to keep the intended > level. In my opinion shutdown should matter just as much. pwm-backlight gets that right as well, because it calls pwm_backlight_power_off() at that time which will set the duty-cycle to 0 and disable the PWM. In practice this may not always matter because at some point your system is likely going to cut power anyway and the backlight will turn off at that point at the latest. However, there could be any number of things happening between backlight/PWM shutdown and actual shutdown. In order to avoid any surprises you really want your system to go down in an orderly fashion. > > > If it was my decision, I'd say: If the backlight driver calls > > > > > > pwm_config(pwm, 0, 100); > > > pwm_disable(pwm); > > > > > > I'd interpret that as: The consumer doesn't use the pin any more, so I'm > > > not bound to keep the pin at a certain level. If however after > > > pwm_disable the consumer is still considered to use the pin, then > > > implementing it the same way as pwm_config(pwm, 0, 100) is the right > > > thing to do. This applies then to all pwm implementations and so should > > > be solved in the pwm core, not in the imx driver. In this case the > > > concept of "disabling a PWM" can go away completely. > > > > But again, why should PWMs be special? You turn off all other resources > > when you no longer need them, right? If you power your panel with a > > regulator, then when the panel is disabled you want to disable the > > regulator, right? Similarily if you don't use your I2C controller you > > want to turn off the clock that drives it, right? This is the same for > > any resource in your system: if you no longer need it, disable it. The > > fact that "disabling" the PWM is not straightforward on i.MX doesn't > > mean that we should simply ignore it. > > I don't say we should ignore it. I say we shouldn't disable the hardware > if the consumer calls pwm_disable() if disabling the hardware results in > a state that shouldn't happen on pwm_disable(). That's backwards. If disabling the hardware results in a state that shouldn't happen when you disable the hardware, that just means that you're doing something wrong. When you do something wrong you fix it. It's really that simple. > Also note, that there are two different "disable" you are talking about. > One is disable in the sense of "pwm_disable". This is about the pwm to > stop oscillating. And the other is about unsetting the enable bit in a > control register and stopping the input clock. Even though both usually > go hand in hand, if you still have requirements on the hardware state > after pwm_disable that are not given if you disable the hardware it is > stupid to require to disable the hardware and then implement something > else on top to undo this unwanted result. I don't consider this undoing the unwanted result. I consider the unwanted result to be the result of an incomplete implementation. If the pin goes to the wrong level when you disable the hardware, the natural fix for the problem is to make sure the pin stays at the right level. > > > In another mail you wrote: > > > > Your example of keeping an LED in the current state is actually an > > > > example of where the consumer still needs it. As long as you want to use > > > > the LED you need to keep the LED driver around, and as long as the LED > > > > driver is around you have a consumer for the PWM. > > > > > > With an analog reasoning I'd say: As long as the backlight driver cares > > > about the backlight being off, it should not disable (or put) the PWM. > > > > It shouldn't put the PWM because it still needs it. But it should be > > totally fine to disable it. Disabling a PWM should result in the PWM not > > outputting any power. > > > > > > > Also note this is similar in the pwm-bcm-kona driver that doesn't seem > > > > > to have the concept of "disable" at all. kona_pwmc_disable() just sets > > > > > up 0% duty cycle. In my eyes this is an argument that is good enough to > > > > > at least nack the imx-specific implementation of that pinctrl stuff. > > > > > > > > It's not a good enough argument for me. It's certainly possible that not > > > > all PWM driver can be made to behave exactly as needed. pwm-bcm-kona > > > > might be one of those, but that doesn't mean that everybody else should > > > > be restricted to the same behaviour. If we can make i.MX behave exactly > > > > right, then we should do that. > > > > > > And if we can make the imx-specific implementation right in a generic > > > way in the pwm core that might help the bcm-kona driver for free. > > > > It may, but we don't know that. > > Look at the .disable callback of the bcm-kona driver. The way it is > written together with the comments in it makes it obvious that this > driver also actively drives the pin after disable. Yes, that may be, but we don't know at this point that involving pinmux is the right solution for the problem on BCM Kona. > > Look, I'm not generally opposed to do this in the core, but I'm not > > going to implement it in the core until I'm convinced that it is > > useful in a large number of cases. One or two are not large numbers. > > Last time I suggested to implement this is in the core you said: "So I > try not to attempt genericity until there are at least two or more > use-cases that can be the basis for a generic solution." Now that I > found a 2nd driver that can benefit you suddenly request "a large number > of cases". When I say "at least" it means I'm already on the fence about the lower bound, and if you then provide an example that you just assume would be the same, that doesn't change things in your favour. > I believe one reason for Linux being as good as it is today is, that > usually with this kind of scenario things are done in the generic way > even if there is only a single user up to now. And even if this solution > doesn't 100% satisfies the needs for the next user, it is much easier > for the next one to adapt and adopt generic code than to first cut it > out from a hardware driver. And until the second user appears the > separation helps to better understand the code because it is not bound > to a hardware driver that a reviewer might not know. One reason for Linux being as good as it is is also that we don't do premature optimization or generalization. Look, I said before that if this really turns out to be generally useful, then by all means let's move this to the core, or better yet implement some sort of helper that drivers can use to get this support if they want to. But until we have at least two implementations that show the exact pattern that we need I don't think we should burden the core with it. In my opinion the core of a framework should be lightweight and not concern itself with too many details. I've seen this happen in a number of cases where some core infrastructure is so "generic" that you actually have to work around the core infrastructure to accomodate the specifics of your driver. That usually happens when you don't have a good enough idea of what exactly generic is for your specific use-case. > > > > > If the pinctrl idea is implemented in the pwm core, I won't object. > > > > > > > > Let me see if I get this straight: you're not objecting to the idea of > > > > implementing the pinctrl solution, your only objection is to put it in > > > > the i.MX driver? > > > > > > Given that the pinctrl solution is a generic solution that might help > > > other drivers, too, I think it should not go into the imx specific > > > driver just because for now this is the only driver that might benefit > > > from it. > > > > > > I still don't think it's the best solution for the imx problem but as I > > > care more for imx in general than for pwm in general I'm interested in > > > keeping the imx driver focused to the imx specific parts. I won't repeat > > > the advantages of putting generic stuff into a generic location instead > > > of its first user. > > > > We can debate this for another few weeks, but I don't think you're going > > to be able to convince me, so let's cut this short: pinctrl support goes > > in the i.MX driver for now. Let's move on. > > OK, you're taking out your maintainer's club. That's sad because I'm > convinced you're forcing a solution that is not optimal. I accept that > the pinctrl stuff solves the problem, but I'm sure it's wrong to put it > into a hardware driver. And it may turn out that you're right. You may also be wrong. Ultimately this is my responsibility, so it's got to be my decision as well. We've already spent way too much time arguing about this, so at this point we should just move past it so that we can actually get things done. Also, it's called software for a reason. It's not like we're going to write anything in stone here. This does not involve ABI or anything, so we can easily evolve the code if necessary. > > > > > > > Also dts writes don't need to lookup the needed GPIO numbers and pinctrl. > > > > > > > > > > > > Just to clarify: I don't think that we need to get the GPIO number > > > > > > involved in this case, because we don't have to reconfigure the pin as > > > > > > GPIO to make this work. The only reason that Michal's proposal did that > > > > > > is because that was believed to be necessary. But if the pin can just be > > > > > > configured with a 100k pull-up, that's enough to pull the pin high when > > > > > > we need it. > > > > > > > > > > Unless the gpio happens to be configured as output at the wrong value. > > > > > Further I'm not sure if the pwm in disabled state actively pulls to 0 > > > > > and if in this state the PU of the pin is good enough to ensure a one > > > > > here. That would need verification first. > > > > > > > > The idea is to *not* configure the GPIO as output and output the wrong > > > > value. The idea is to not use the GPIO at all and instead use whatever > > > > the hardware default is that makes it such that the backlight is off by > > > > default at boot. > > > > > > Which might be possible with Lothar's idea for some machines, but not > > > for all users of the pwm-imx driver. > > > > > > Also note that you don't include the poor souls where there is no > > > hardware pullup into the right direction. > > > > The poor souls should speak up and then we can look into finding a good > > solution for them. I'm pretty sure there must be some equivalent that > > can be used for other users. > > I think one of the boards that I'm working with has an enabled backlight > at power on until the bootloader actively drives the related pwm to > the right level (either using the pwm or the gpio function of the pin). > I will double check that but assuming that is right, just disabling the > output won't work here. That would be very surprising to me. In either case, just because there is an exception doesn't mean we shouldn't do the right thing in general. If we then have to special case some extraordinary quirky hardware, that is still an option. Thierry [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-22 15:03 ` Thierry Reding @ 2018-11-22 16:17 ` Uwe Kleine-König 0 siblings, 0 replies; 60+ messages in thread From: Uwe Kleine-König @ 2018-11-22 16:17 UTC (permalink / raw) To: Thierry Reding Cc: Vokáč Michal, Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, kernel, Fabio Estevam, Lothar Waßmann, Linus Walleij Hello Thierry, On Thu, Nov 22, 2018 at 04:03:38PM +0100, Thierry Reding wrote: > On Sun, Nov 18, 2018 at 09:08:15PM +0100, Uwe Kleine-König wrote: > > Thinking a bit about this it doesn't really matter for the consumer if > > the pin stays in the idle level because there is a pull into the right > > direction and the PWM is high-Z or if the PWM pulls actively in the > > right direction. Also for pwm_config(pwm, 0, 100) the PWM could disable > > its output in the presence of a pull, so the property says true that the > > effects of pwm_config(pwm, 0, 100) and pwm_disable(pwm) should be the > > same. And so my claim that pwm_disable is a part of the API that > > doesn't give any value stays true. > > I still think there's a slight difference there. Granted the effect on > the consumer is the same whether you disable or set the duty-cycle to > zero because the power output is the same. pwm_disable() is still more > explicit, though, so it may involve more than just setting the duty- > cycle. If pwm_disable() vs. duty-cycle=0 doesn't make a difference to the consumer, who do we do a favour by providing pwm_disable()? > > > But again, why should PWMs be special? You turn off all other resources > > > when you no longer need them, right? If you power your panel with a > > > regulator, then when the panel is disabled you want to disable the > > > regulator, right? Similarily if you don't use your I2C controller you > > > want to turn off the clock that drives it, right? This is the same for > > > any resource in your system: if you no longer need it, disable it. The > > > fact that "disabling" the PWM is not straightforward on i.MX doesn't > > > mean that we should simply ignore it. > > > > I don't say we should ignore it. I say we shouldn't disable the hardware > > if the consumer calls pwm_disable() if disabling the hardware results in > > a state that shouldn't happen on pwm_disable(). > > That's backwards. If disabling the hardware results in a state that > shouldn't happen when you disable the hardware, that just means that > you're doing something wrong. When you do something wrong you fix it. For you pwm_disable must imply disabling the PWM hardware. As you cannot have both (disable the hardware and keep the pin on the idle level without involving pinmux and GPIO) on i.MX in my eyes it is sensible to drop one requirement from the framework's expectations to make it possible for i.MX to fulfill them. As there is no advantage for anyone to force .disable() to actually disable the hardware (apart from a little power saving that probably isn't even measurable) that's IMHO the one to drop. > If the pin goes to the wrong level when you disable the hardware, the > natural fix for the problem is to make sure the pin stays at the right > level. Ack. And you can do this either in an easy variant or in a more complicated one. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-16 9:51 ` Thierry Reding 2018-11-16 10:39 ` Uwe Kleine-König @ 2018-11-20 13:14 ` Vokáč Michal 2018-11-20 16:54 ` Uwe Kleine-König 1 sibling, 1 reply; 60+ messages in thread From: Vokáč Michal @ 2018-11-20 13:14 UTC (permalink / raw) To: Thierry Reding, Uwe Kleine-König Cc: Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, kernel, Fabio Estevam, Lothar Waßmann, Linus Walleij, viresh kumar Hi, sorry for the delay, I was out of office last week. My comments below are just to clarify my attitude to the topic as my name was mentioned few times while I was offline. On 16.11.2018 10:51, Thierry Reding wrote: > On Thu, Nov 15, 2018 at 09:37:33PM +0100, Uwe Kleine-König wrote: >> On Thu, Nov 15, 2018 at 04:25:45PM +0100, Thierry Reding wrote: >>> On Wed, Nov 14, 2018 at 10:51:20PM +0100, Uwe Kleine-König wrote: >>>> On Wed, Nov 14, 2018 at 12:34:49PM +0100, Thierry Reding wrote: >> Maybe it was a bad idea to broaden the discussion to talk about gpios >> and ethernet stuff here. I'd still consider it a valid construct to put >> the pwm pin into the backlight's pinctrl unless Linux W. disagrees. > > But why? The backlight doesn't care about the specific pinmuxing of the > PWM pin. All it cares about is the PWM signal. That's the level of > abstraction that the PWM consumer expects, anything lower level belongs > in the PWM driver. I also do not like the idea of putting the pinmuxing of the PWM pin into the PWM consumer. That is why it never came to my mind to do it when I tested what Uwe was suggesting. >>>> Other than that my approach looks more elegant to me (which obviously is >>>> subjective). It works in all cases apart from sysfs (which is special >>>> because it's not integrated into the device model) and there is no need >>>> to teach the pwm framework about pinmuxing and invent new pinctrl modes >>>> for it. >>> >>> Elegance is useless if what you have doesn't work consistently and >>> reliably. >>> >>> I don't understand your resistance to the pinctrl work. It's not rocket >>> science. Michal already posted patches showing how it can be done and >>> they're not very complicated. Also we're not doing anything out of the >>> ordinary here. This is exactly the purpose of the pinctrl framework, so >>> let's use the best tool at hand. >> >> In my last exchange with Michal I had the impression that he liked >> my approach, too. > > My impression was that he was trying to find concensus. But the way I > read it he was still arguing that the pinctrl solution was still the > most complete, and would therefore still prefer it. It is like you said Thierry. I am only trying to remain open to test Uwe's ideas. After what I have tested so far I still prefer a imx-specific pinctrl solution. Michal ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-20 13:14 ` Vokáč Michal @ 2018-11-20 16:54 ` Uwe Kleine-König 2018-11-22 14:23 ` Vokáč Michal 0 siblings, 1 reply; 60+ messages in thread From: Uwe Kleine-König @ 2018-11-20 16:54 UTC (permalink / raw) To: Vokáč Michal Cc: Thierry Reding, Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, kernel, Fabio Estevam, Lothar Waßmann, Linus Walleij, viresh kumar Hello Michal, On Tue, Nov 20, 2018 at 01:14:33PM +0000, Vokáč Michal wrote: > On 16.11.2018 10:51, Thierry Reding wrote: > > On Thu, Nov 15, 2018 at 09:37:33PM +0100, Uwe Kleine-König wrote: > >> On Thu, Nov 15, 2018 at 04:25:45PM +0100, Thierry Reding wrote: > > My impression was that he was trying to find concensus. But the way I > > read it he was still arguing that the pinctrl solution was still the > > most complete, and would therefore still prefer it. > > It is like you said Thierry. I am only trying to remain open to test > Uwe's ideas. After what I have tested so far I still prefer a imx-specific > pinctrl solution. Is that because you consider it right to be imx-specific or because that's what you already have? Is there a flaw in my explanation that the problem isn't imx-specific per se and so the solution shouldn't be that either? Is the problem with the "tests so far" that it doesn't work yet, or is there something conceptually wrong in your eyes? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-20 16:54 ` Uwe Kleine-König @ 2018-11-22 14:23 ` Vokáč Michal 0 siblings, 0 replies; 60+ messages in thread From: Vokáč Michal @ 2018-11-22 14:23 UTC (permalink / raw) To: Uwe Kleine-König Cc: Thierry Reding, Mark Rutland, devicetree, linux-pwm, Lukasz Majewski, linux-kernel, Rob Herring, kernel, Fabio Estevam, Lothar Waßmann, Linus Walleij, viresh kumar Ahoj Uwe, On 20.11.2018 17:54, Uwe Kleine-König wrote: > On Tue, Nov 20, 2018 at 01:14:33PM +0000, Vokáč Michal wrote: >> On 16.11.2018 10:51, Thierry Reding wrote: >>> On Thu, Nov 15, 2018 at 09:37:33PM +0100, Uwe Kleine-König wrote: >>>> On Thu, Nov 15, 2018 at 04:25:45PM +0100, Thierry Reding wrote: >>> My impression was that he was trying to find concensus. But the way I >>> read it he was still arguing that the pinctrl solution was still the >>> most complete, and would therefore still prefer it. >> >> It is like you said Thierry. I am only trying to remain open to test >> Uwe's ideas. After what I have tested so far I still prefer a imx-specific >> pinctrl solution. > > Is that because you consider it right to be imx-specific or because > that's what you already have? Is there a flaw in my explanation that > the problem isn't imx-specific per se and so the solution shouldn't be > that either? I consider it right to be imx-specific because of the current state of awareness and interest in this problem from other SoC's communities. I spent quite some time looking for a solution and my impression is that only imx users perceive this problem and are the only one that already did some attempts to solve it. I think this is in line with what Thierry said - if other users have the same problem, they should speak-up. In my eyes as he is the pwm subsystem maintainer he knows the best if others have the same problem or not. My understanding of his arguments is such that they do not. I understand that having a more generic solution may be better. I am not really sure if it is valid in this case. > Is the problem with the "tests so far" that it doesn't work yet, or is > there something conceptually wrong in your eyes? It does not work yet. And it would not solve all the cases. Namely the sysfs use-case. And Thierry confirmed sysfs is a supported interface. I do not dare to speculate whether your idea is conceptually wrong or not. I only can say that putting the pinctrl of the PWM pin into the PWM consumer seems very unnatural to me. I have not seen any example of such usage yet. That does not mean it is wrong of course. On the other hand, you said that we are inventing new pinctrl names. But I see quite a lot of usages of non-["init", "default", "sleep"] pinctrl names in the DTS files. Most of them are actually imx users. Still, the main problem is it is not possible to turn-off the backlight or cooling fan or whoever is the PWM consumer if inverted PWM is used. Not that it is not possible to keep it turned-off until it is turned-on by the user. So for me, any solution that at least allows that is better than the current state. The pinctrl solution just solves all at once. I fully agree the pinctrl solution has drawbacks. It needs to be well documented and DT authors need to know how to use it and in what cases. Best regards, Michal ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-14 21:51 ` Uwe Kleine-König 2018-11-15 15:25 ` Thierry Reding @ 2018-11-19 7:44 ` Linus Walleij 2018-11-19 8:32 ` Uwe Kleine-König 1 sibling, 1 reply; 60+ messages in thread From: Linus Walleij @ 2018-11-19 7:44 UTC (permalink / raw) To: Uwe Kleine-König Cc: thierry.reding, Michal.Vokac, Mark Rutland, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, linux-pwm, l.majewski, linux-kernel, Rob Herring, Sascha Hauer, Fabio Estevam, Lothar Waßmann On Wed, Nov 14, 2018 at 10:51 PM Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote: > On Wed, Nov 14, 2018 at 12:34:49PM +0100, Thierry Reding wrote: > > On Fri, Nov 09, 2018 at 05:55:55PM +0100, Uwe Kleine-König wrote: > > > On Fri, Nov 09, 2018 at 02:24:42PM +0000, Vokáč Michal wrote: > > > > On 8.11.2018 20:18, Uwe Kleine-König wrote: > > > > > Taking your example with the backlight device you specify an "init" and > > > > > a "default" pinctrl and only "default" contains the muxing for the PWM > > > > > pin everything should be as smooth as necessary: The pwm is only muxed > > > > > when the backlight device is successfully bound. > > > > > > > > Have you tried that Uwe? The bad news is I tested that before and now > > > > again and it does not work like that. We already discussed that earlier. > > > > > > The key is that the pinmux setting for the PWM pin should be part of the > > > bl pinctrl, not the pwm pinctrl. Then "default" is only setup when the > > > bl device is successfully bound which is after the bl's .probe callback > > > called pwm_apply(). > > > > No, that's not at all correct. Pinmux settings should reside with the > > consumer of the pin. In this case, the PWM is the consumer of the pin, > > whereas the backlight is the consumer of the *PWM*. > > This is news to me. Adding Linus W. to Cc, maybe he can comment?! > > Grepping through the arm device trees it really seems common to put the > pinctrl for the pwm pin into the pwm device. I didn't search in depth, > but I didn't find a counter example. > > For GPIOs it is common that the pinmuxing is included in the GPIO's > consumer pinctrl. Ditto for mdio busses whose pinctrl is included in the > ethernet pinctrl. There is quite a discussion you folks have going on here. I tried to grasp it but I can't. I can try to answer the above question specifically. For pin control it is mainly paramount that the state is associated with *a* consumer. The problem we were facing when fleshing out the subsystem can be seen in horrific solutions such as in Documentation/devicetree/bindings/gpio/gpio-twl4030.txt where you see that pull-ups and pull-downs are set on the PRODUCER side, which just make everything a complete mess. So compared to things like that (that we still have to support forever) whatever you are doing here you're doing great as long as it is consumer controlled. Whether that consumer is the previous driver thingie in the daisy-chain of consumers or the final end user consumer of the pin doesn't really matter to pin control, as long as it is a consumer. I would tend to say it is up to the subsystem, and the old IETF motto "rough consensus and running code". It seems in the current discussion the "rough consensus" part is the problem, and I'm afraid I can't fix that. Yours, Linus Walleij ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-19 7:44 ` Linus Walleij @ 2018-11-19 8:32 ` Uwe Kleine-König 2018-11-20 8:35 ` Linus Walleij 0 siblings, 1 reply; 60+ messages in thread From: Uwe Kleine-König @ 2018-11-19 8:32 UTC (permalink / raw) To: Linus Walleij Cc: thierry.reding, Michal.Vokac, Mark Rutland, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, linux-pwm, l.majewski, linux-kernel, Rob Herring, Sascha Hauer, Fabio Estevam, Lothar Waßmann Hello Linus, On Mon, Nov 19, 2018 at 08:44:38AM +0100, Linus Walleij wrote: > There is quite a discussion you folks have going on here. I tried to > grasp it but I can't. I can try to answer the above question specifically. To sumarize: When the pwm driver probes it is not yet clear if the idle state of the output pin is high or low. Even when the pinctrl device has an "init" and a "default" pinctrl, it is not yet fixed when its "default" is configured. The way Thierry wants to fix that is by disabling the output driver until the pwm is in use und rely on a pull-up or pull-down in hardware. The way I want to fix this is to only configure the pwm pin as part of the consumer. This is late enough that the consumer already requested and configured the pwm such that the idle level is known. Thierry's and Lothar's claim was that putting the pin setup of the pwm pin into the pwm consumer's pinctrl was forbidden. That's why I asked you as pinctrl maintainer if there is a requirement that I don't know of. > So compared to things like that (that we still have to support > forever) whatever you are doing here you're doing great as long > as it is consumer controlled. > > Whether that consumer is the previous driver thingie in the > daisy-chain of consumers or the final end user consumer of > the pin doesn't really matter to pin control, as long as it is a > consumer. I would tend to say it is up to the subsystem, > and the old IETF motto "rough consensus and running code". So I understand that from the pinctrl side there is no hard requirement that the PWM pin must be muxed as part of the pwm device. And if things work better when the pin is only configured as part of its consumer this is legitimate. Thanks for your feedback. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-19 8:32 ` Uwe Kleine-König @ 2018-11-20 8:35 ` Linus Walleij 2018-11-20 9:16 ` Viresh Kumar 2018-11-20 9:53 ` Uwe Kleine-König 0 siblings, 2 replies; 60+ messages in thread From: Linus Walleij @ 2018-11-20 8:35 UTC (permalink / raw) To: Uwe Kleine-König, viresh kumar Cc: thierry.reding, Michal.Vokac, Mark Rutland, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, linux-pwm, l.majewski, linux-kernel, Rob Herring, Sascha Hauer, Fabio Estevam, Lothar Waßmann On Mon, Nov 19, 2018 at 9:32 AM Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote: > To sumarize: When the pwm driver probes it is not yet clear if the idle > state of the output pin is high or low. Even when the pinctrl device has > an "init" and a "default" pinctrl, it is not yet fixed when its > "default" is configured. > > The way Thierry wants to fix that is by disabling the output driver > until the pwm is in use und rely on a pull-up or pull-down in hardware. > > The way I want to fix this is to only configure the pwm pin as part of > the consumer. This is late enough that the consumer already requested > and configured the pwm such that the idle level is known. > Thierry's and Lothar's claim was that putting the pin setup of the pwm > pin into the pwm consumer's pinctrl was forbidden. That's why I asked > you as pinctrl maintainer if there is a requirement that I don't know > of. I think we need to be pragmatic and listen most to whoever has the hardware and need to get it to work. The system needs to come up in some reasonable way, preferably so that vendors doing products with it do not have to apply a fat patch stack to get that backlight working in an acceptable way. Else the end result is out-of-tree code to paper over the issue and that IMO is worse than some minor ugliness in the kernel. However the whole ordeal points to a problem that is with the pin control system and Thierry's and Lothar's intuition about this is right in a way: if the pin control system could read out the state of the hardware at boot (as we nowadays do with GPIO, which also has a consumer flag cleverly named GPIOD_ASIS) the whole thing would be no problem. The same kind of goes for PWM itself in this case I guess. The whole issue with splash screens and different hardware turned over to Linux in running state is a bit imperfect I would say, I think Viresh was working on boot constraints to get handover of different systems components into some kind of shape but maybe that stopped short because of the complexities involved. Isn't that the real problem here? https://lkml.org/lkml/2017/8/1/191 Yours, Linus Walleij ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-20 8:35 ` Linus Walleij @ 2018-11-20 9:16 ` Viresh Kumar 2018-11-20 9:53 ` Uwe Kleine-König 1 sibling, 0 replies; 60+ messages in thread From: Viresh Kumar @ 2018-11-20 9:16 UTC (permalink / raw) To: Linus Walleij Cc: Uwe Kleine-König, thierry.reding, Michal.Vokac, Mark Rutland, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, linux-pwm, l.majewski, linux-kernel, Rob Herring, Sascha Hauer, Fabio Estevam, Lothar Waßmann, vincent.guittot On 20-11-18, 09:35, Linus Walleij wrote: > The whole issue with splash screens and different hardware > turned over to Linux in running state is a bit imperfect I would > say, I think Viresh was working on boot constraints to get > handover of different systems components into some kind > of shape but maybe that stopped short because of the > complexities involved. It got stuck mostly due to lack of use-cases where that can be useful. All I could find until now is LCD and earlycon stuff. Though things may change soon after the interconnect subsystem gets merged, as we will have bootloader requirements for each and every device in that case which the boot loader enables and passes on to kernel. -- viresh ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-20 8:35 ` Linus Walleij 2018-11-20 9:16 ` Viresh Kumar @ 2018-11-20 9:53 ` Uwe Kleine-König 1 sibling, 0 replies; 60+ messages in thread From: Uwe Kleine-König @ 2018-11-20 9:53 UTC (permalink / raw) To: Linus Walleij Cc: viresh kumar, thierry.reding, Michal.Vokac, Mark Rutland, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, linux-pwm, l.majewski, linux-kernel, Rob Herring, Sascha Hauer, Fabio Estevam, Lothar Waßmann Hello, On Tue, Nov 20, 2018 at 09:35:47AM +0100, Linus Walleij wrote: > On Mon, Nov 19, 2018 at 9:32 AM Uwe Kleine-König > <u.kleine-koenig@pengutronix.de> wrote: > > > To sumarize: When the pwm driver probes it is not yet clear if the idle > > state of the output pin is high or low. Even when the pinctrl device has > > an "init" and a "default" pinctrl, it is not yet fixed when its > > "default" is configured. > > > > The way Thierry wants to fix that is by disabling the output driver > > until the pwm is in use und rely on a pull-up or pull-down in hardware. > > > > The way I want to fix this is to only configure the pwm pin as part of > > the consumer. This is late enough that the consumer already requested > > and configured the pwm such that the idle level is known. > > Thierry's and Lothar's claim was that putting the pin setup of the pwm > > pin into the pwm consumer's pinctrl was forbidden. That's why I asked > > you as pinctrl maintainer if there is a requirement that I don't know > > of. > > I think we need to be pragmatic and listen most to whoever has > the hardware and need to get it to work. The system needs > to come up in some reasonable way, preferably so that vendors > doing products with it do not have to apply a fat patch stack > to get that backlight working in an acceptable way. Else the > end result is out-of-tree code to paper over the issue and that > IMO is worse than some minor ugliness in the kernel. > > However the whole ordeal points to a problem that is with the > pin control system and Thierry's and Lothar's intuition about this > is right in a way: if the pin control system could read out the > state of the hardware at boot (as we nowadays do with GPIO, > which also has a consumer flag cleverly named GPIOD_ASIS) > the whole thing would be no problem. Well, on the problematic machine the setup currently is: The bootloader configures the brightness pin as GPIO high output to disable the backlight, the PWM isn't touched and so is off and uninverted. The next relevant event is that the PWM driver is probed. The PWM registers are not touched, so keeps being off and outputs a 0. If in this state the pin is muxed as PWM the output becomes 0 which should be prevented, so this must not be part of a "default" or "init" pinctrl for the PWM node. The next event is that the backlight driver is probed. The probe function grabs the PWM, tells it to be inverted and off. So the output of the PWM is a 1 and only after that the PWM pin can be safely muxed as PWM. So the options are: a) In the bootloader setup the PWM as inverted and configure the pin as PWM. b) Make the PWM aware that it is off and let it mux an "idle" setting that depending on the SoC might involve muxing the pin as GPIO and setting the GPIO as input. c) setup the PWM pin as PWM only when the backlight is probed. a) has the downside that configuring a PWM is a tad more complex then setting up a GPIO. Also it's a bit ugly to let Linux impose a limitation on the bootloader about how to disable the backlight there. b) has the downside that the dts author has to specify a GPIO and the idle level and two instead of only one pinctrl setting. Conceptually this is not so nice, because normally the PWM doesn't know if it is used inverted or not. With the GPIO specification this information is implicitly added. (Also there might be additional hurdles, for example on i.MX31 (IIRC) there are pins that cannot be muxed as GPIO but are in use as CS signal for spi. I didn't check if there is a similar limitation for PWM pins.) With c) the pwm is setup only when the backlight driver requests it. If the backlight driver fails to probe or is disabled nothing happens to the PWM pin. If the backlight driver was loaded successfully the PWM pin is muxed just after it was set up with the right polarity. Similar as with b) there is no limitation about how the bootloader disabled the backlight. The beauty I see in c) is this is a solution that doesn't have to care about GPIOs and muxing pins depending on the PWM state. And given that there is such a way, I don't see why we should impose on dts authors to specify these things that are not technically necessary. Both b) and c) is about delaying muxing the pin as PWM late enough. Suggestion b) is about doing this explicitly somewhere below driver/pwm, c) only uses pinctrl as available automatically for all devices. Probably its subjective if you consider b) or c) as the better/prettier solution. Note that the solution b) is independent of the imx uglyness[1] and applies to all PWMs that don't disable its output driver on disable. (And for PWMs that disable the output driver, the solution might be needed anyhow because there is "broken" hardware that doesn't have the right pullups assembled to ensure the right idle level when the pin doesn't drive.) So the sensible options are in my eyes: - Implement b) in the PWM core (and not the pwm-imx driver); or - just use c) accepting that the PWM is muxed not by itself but by its consumer. In my eyes doing b) consequently would result in letting the PWM know the intended idle level even without a consumer. Not only implicitly by a GPIO specification, but explicitly using something like: &pwm3 { pwm-default-inverted; }; in the device tree. (And with that the GPIO solution would loose its importance because every PWM is able to drive a constant 1 and a constant 0. It might just be useful as an optimisation that draws less power.) > The same kind of goes for PWM itself in this case I guess. So as pinmuxing is involved it doesn't solve the problem as the driver would diagnose the PWM to be uninverted and off and so would enable the backlight. There is still a solution needed to delay the muxing. > The whole issue with splash screens and different hardware > turned over to Linux in running state is a bit imperfect I would > say, I think Viresh was working on boot constraints to get > handover of different systems components into some kind > of shape but maybe that stopped short because of the > complexities involved. Isn't that the real problem here? > https://lkml.org/lkml/2017/8/1/191 The Boot Constraints core solves things like "Don't let the UART change the clk frequency of a common parent of the UART itself and the PWM that is needed to show the splash screen." This is orthogonal to the problem here I'd say. Best regards Uwe [1] If you disable the imx PWM while being inverted it outputs a 0 also a 1 would be more consistent. -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state 2018-11-08 15:21 ` Vokáč Michal 2018-11-08 19:18 ` Uwe Kleine-König @ 2018-11-14 11:14 ` Thierry Reding 1 sibling, 0 replies; 60+ messages in thread From: Thierry Reding @ 2018-11-14 11:14 UTC (permalink / raw) To: Vokáč Michal Cc: Uwe Kleine-König, Rob Herring, Mark Rutland, devicetree, linux-pwm, linux-kernel, Lukasz Majewski, Fabio Estevam, Lothar Waßmann, kernel [-- Attachment #1: Type: text/plain, Size: 2306 bytes --] On Thu, Nov 08, 2018 at 03:21:44PM +0000, Vokáč Michal wrote: > On 7.11.2018 16:01, Uwe Kleine-König wrote: [...] > > For both the solution is to let the bootloader enable the pwm with > > the right output level. Am I missing something? > > Bootloader is only a small part of the whole solution I think. And I > suppose you meant: "enable the *GPIO* with the right output level". > > - Even if you use GPIO in bootloader to set the required level the > time frame from imx_pwm_probe to imx_pwm_apply is not covered. > > - Currently there is no support in Linux pwm-imx driver to detect > the PWM chip is already enabled at probe time. I actually send > patches for this a month ago [1]. No response yet. > > - Inverted PWM does not work in U-Boot (on imx at least). And it > does not seam like it can be fixed easily. I do not know what is > the situation in other bootloaders. > > So my current bootloader solution is one of: > - Set the pin to the appropriate (HIGH) level using GPIO. > - Do not touch the pin at all, it has 100k pull-up by default. First of all, I don't think we should rely on any bootloader setting up things properly. I already said elsewhere that the reset defaults will likely already be such that the PWM outputs zero power (i.e. high for inversed PWM). Michal's comments above seem to suggest that this is indeed the case. If the pin is 100k pull-up by default (I assume that means on reset), then that's exactly what I would expect for this kind of pin. And that's also an excellent pin state for the kernel to use when it no longer needs to actively drive the PWM. That means on pwm_disable() we can simply revert to the 100k pull-up default and let the PWM pin be in the very same state that it is on reset. Can't get any better than that. So really, I think the only proper solution to this problem is to get pinctrl involved and configure the pin as PWM when it is actively used, and change it back to 100k pull-up otherwise. And, yes, I understand that this slightly complicates the driver, but it's really the right thing to do and it fixes all known issues, and to me that's clear evidence that it is the right solution and therefore definitely worth the added complexity. Thierry [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH v2 2/2] pwm: imx: Configure output to GPIO in disabled state 2018-10-10 9:33 ` [RCF PATCH v2 2/2] pwm: imx: Configure output to GPIO in disabled state Vokáč Michal 2018-10-12 8:57 ` [RCF PATCH,v2,2/2] " Uwe Kleine-König @ 2018-10-12 16:00 ` Thierry Reding 2018-10-29 15:53 ` Vokáč Michal 1 sibling, 1 reply; 60+ messages in thread From: Thierry Reding @ 2018-10-12 16:00 UTC (permalink / raw) To: Vokáč Michal Cc: Rob Herring, Mark Rutland, devicetree, linux-pwm, linux-kernel, Lukasz Majewski, Fabio Estevam, Lothar Waßmann [-- Attachment #1: Type: text/plain, Size: 4634 bytes --] On Wed, Oct 10, 2018 at 09:33:26AM +0000, Vokáč Michal wrote: > Normally the PWM output is held LOW when PWM is disabled. This can cause > problems when inverted PWM signal polarity is needed. With this behavior > the connected circuit is fed by 100% duty cycle instead of being shut-off. > > Allow users to define a "gpio" and a "pwm" pinctrl states. The pwm pinctrl > state is then selected when PWM is enabled and the gpio pinctrl state is > selected when PWM is disabled. Also add a new pwm-gpios GPIO that is used > to drive the output in the gpio state. > > If all the pinctrl states and the pwm-gpios are not correctly specified > in DT the logic will work as before. > > As an example, with this patch a PWM controlled backlight with inversed > signal polarity can be used in full brightness range. Without this patch > the backlight can not be turned off as brightness = 0 disables the PWM > and that in turn set PWM output LOW, that is full brightness. > > Output of the PWM with "default" pinctrl and with "pwm"+"gpio" pinctrl: > > +--------------+------------+---------------+---------------------------+ > | After reset | Bootloader | Linux pinctrl | User (sysfs, backlight..) | > | 100k pull-up | (not used) | | enable | disable | > +--------------+------------+---------------+---------------------------+ > ___________________________ default _ _ _ > |_________________| |_| |_| |_|_____________ > > pwm + gpio > ___________________________________________ _ _ _ _____________ > |_| |_| |_| |_| > > Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com> > --- > Changes in v2: > - Utilize the "pwm" and "gpio" pinctrl states. > - Use the pwm-gpios signal to drive the output in "gpio" pinctrl state. > - Select the right pinctrl state in probe. > > drivers/pwm/pwm-imx.c | 86 +++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 86 insertions(+) > > diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c > index 6cd3b72..3502123 100644 > --- a/drivers/pwm/pwm-imx.c > +++ b/drivers/pwm/pwm-imx.c > @@ -10,11 +10,13 @@ > #include <linux/clk.h> > #include <linux/delay.h> > #include <linux/err.h> > +#include <linux/gpio/consumer.h> > #include <linux/io.h> > #include <linux/kernel.h> > #include <linux/module.h> > #include <linux/of.h> > #include <linux/of_device.h> > +#include <linux/pinctrl/consumer.h> > #include <linux/platform_device.h> > #include <linux/pwm.h> > #include <linux/slab.h> > @@ -92,10 +94,45 @@ struct imx_chip { > void __iomem *mmio_base; > > struct pwm_chip chip; > + > + struct pinctrl *pinctrl; > + struct pinctrl_state *pinctrl_pins_gpio; > + struct pinctrl_state *pinctrl_pins_pwm; > + struct gpio_desc *pwm_gpiod; > }; > > + > #define to_imx_chip(chip) container_of(chip, struct imx_chip, chip) > > +static int imx_pwm_init_pinctrl_info(struct imx_chip *imx_chip, > + struct platform_device *pdev) > +{ > + imx_chip->pinctrl = devm_pinctrl_get(&pdev->dev); > + if (!imx_chip->pinctrl || IS_ERR(imx_chip->pinctrl)) { This is not correct. First, I don't think devm_pinctrl_get() will ever return NULL, so the !imx_chip->pinctrl is useless. And if it did return NULL and imx_chip->pinctrl could therefore be NULL, then... > + dev_info(&pdev->dev, "can not get pinctrl\n"); > + return PTR_ERR(imx_chip->pinctrl); ... this is rubbish because it returns PTR_ERR(NULL) which is 0 and that represents success. While at it, dev_info() -> dev_err() might be more appropriate here. Or if you want to make pinctrl support optional make this dev_dbg() like the message further below. > + } > + > + imx_chip->pinctrl_pins_pwm = pinctrl_lookup_state(imx_chip->pinctrl, > + "pwm"); > + imx_chip->pinctrl_pins_gpio = pinctrl_lookup_state(imx_chip->pinctrl, > + "gpio"); > + imx_chip->pwm_gpiod = devm_gpiod_get_optional(&pdev->dev, "pwm", > + GPIOD_IN); > + > + if (PTR_ERR(imx_chip->pwm_gpiod) == -EPROBE_DEFER) { > + return -EPROBE_DEFER; > + } else if (IS_ERR(imx_chip->pwm_gpiod) || > + IS_ERR(imx_chip->pinctrl_pins_pwm) || > + IS_ERR(imx_chip->pinctrl_pins_gpio)) { > + dev_dbg(&pdev->dev, "PWM pinctrl information incomplete\n"); Another option would be to make this (and the above) dev_warn() since we do want people to update the DTB if at all possible. Without the DTB the PWM could be susceptible to the issue that we're trying to fix. Thierry [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RCF PATCH v2 2/2] pwm: imx: Configure output to GPIO in disabled state 2018-10-12 16:00 ` [RCF PATCH v2 2/2] " Thierry Reding @ 2018-10-29 15:53 ` Vokáč Michal 0 siblings, 0 replies; 60+ messages in thread From: Vokáč Michal @ 2018-10-29 15:53 UTC (permalink / raw) To: Thierry Reding Cc: Rob Herring, Mark Rutland, devicetree, linux-pwm, linux-kernel, Lukasz Majewski, Fabio Estevam, Lothar Waßmann On 12.10.2018 18:00, Thierry Reding wrote: > On Wed, Oct 10, 2018 at 09:33:26AM +0000, Vokáč Michal wrote: >> Normally the PWM output is held LOW when PWM is disabled. This can cause >> problems when inverted PWM signal polarity is needed. With this behavior >> the connected circuit is fed by 100% duty cycle instead of being shut-off. >> >> Allow users to define a "gpio" and a "pwm" pinctrl states. The pwm pinctrl >> state is then selected when PWM is enabled and the gpio pinctrl state is >> selected when PWM is disabled. Also add a new pwm-gpios GPIO that is used >> to drive the output in the gpio state. >> >> If all the pinctrl states and the pwm-gpios are not correctly specified >> in DT the logic will work as before. >> >> As an example, with this patch a PWM controlled backlight with inversed >> signal polarity can be used in full brightness range. Without this patch >> the backlight can not be turned off as brightness = 0 disables the PWM >> and that in turn set PWM output LOW, that is full brightness. >> >> Output of the PWM with "default" pinctrl and with "pwm"+"gpio" pinctrl: >> >> +--------------+------------+---------------+---------------------------+ >> | After reset | Bootloader | Linux pinctrl | User (sysfs, backlight..) | >> | 100k pull-up | (not used) | | enable | disable | >> +--------------+------------+---------------+---------------------------+ >> ___________________________ default _ _ _ >> |_________________| |_| |_| |_|_____________ >> >> pwm + gpio >> ___________________________________________ _ _ _ _____________ >> |_| |_| |_| |_| >> >> Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com> >> --- >> Changes in v2: >> - Utilize the "pwm" and "gpio" pinctrl states. >> - Use the pwm-gpios signal to drive the output in "gpio" pinctrl state. >> - Select the right pinctrl state in probe. >> >> drivers/pwm/pwm-imx.c | 86 +++++++++++++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 86 insertions(+) >> >> diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c >> index 6cd3b72..3502123 100644 >> --- a/drivers/pwm/pwm-imx.c >> +++ b/drivers/pwm/pwm-imx.c >> @@ -10,11 +10,13 @@ >> #include <linux/clk.h> >> #include <linux/delay.h> >> #include <linux/err.h> >> +#include <linux/gpio/consumer.h> >> #include <linux/io.h> >> #include <linux/kernel.h> >> #include <linux/module.h> >> #include <linux/of.h> >> #include <linux/of_device.h> >> +#include <linux/pinctrl/consumer.h> >> #include <linux/platform_device.h> >> #include <linux/pwm.h> >> #include <linux/slab.h> >> @@ -92,10 +94,45 @@ struct imx_chip { >> void __iomem *mmio_base; >> >> struct pwm_chip chip; >> + >> + struct pinctrl *pinctrl; >> + struct pinctrl_state *pinctrl_pins_gpio; >> + struct pinctrl_state *pinctrl_pins_pwm; >> + struct gpio_desc *pwm_gpiod; >> }; >> >> + >> #define to_imx_chip(chip) container_of(chip, struct imx_chip, chip) >> >> +static int imx_pwm_init_pinctrl_info(struct imx_chip *imx_chip, >> + struct platform_device *pdev) >> +{ >> + imx_chip->pinctrl = devm_pinctrl_get(&pdev->dev); >> + if (!imx_chip->pinctrl || IS_ERR(imx_chip->pinctrl)) { > > This is not correct. First, I don't think devm_pinctrl_get() will ever > return NULL, so the !imx_chip->pinctrl is useless. And if it did return > NULL and imx_chip->pinctrl could therefore be NULL, then... > >> + dev_info(&pdev->dev, "can not get pinctrl\n"); >> + return PTR_ERR(imx_chip->pinctrl); > > ... this is rubbish because it returns PTR_ERR(NULL) which is 0 and that > represents success. Good catch! Again, this code is actually an exact copy from i2c-imx.c. I can send a patch to I2C folks with fix quoting your comment if you do not mind. > While at it, dev_info() -> dev_err() might be more appropriate here. Or > if you want to make pinctrl support optional make this dev_dbg() like > the message further below. I prefer to make the pinctrl support optional so dev_dbg() seems OK. >> + } >> + >> + imx_chip->pinctrl_pins_pwm = pinctrl_lookup_state(imx_chip->pinctrl, >> + "pwm"); >> + imx_chip->pinctrl_pins_gpio = pinctrl_lookup_state(imx_chip->pinctrl, >> + "gpio"); >> + imx_chip->pwm_gpiod = devm_gpiod_get_optional(&pdev->dev, "pwm", >> + GPIOD_IN); >> + >> + if (PTR_ERR(imx_chip->pwm_gpiod) == -EPROBE_DEFER) { >> + return -EPROBE_DEFER; >> + } else if (IS_ERR(imx_chip->pwm_gpiod) || >> + IS_ERR(imx_chip->pinctrl_pins_pwm) || >> + IS_ERR(imx_chip->pinctrl_pins_gpio)) { >> + dev_dbg(&pdev->dev, "PWM pinctrl information incomplete\n"); > > Another option would be to make this (and the above) dev_warn() since we > do want people to update the DTB if at all possible. Without the DTB the > PWM could be susceptible to the issue that we're trying to fix. I do not think dev_warn() is appropriate here. IMHO the issue is only relevant if you want generate inversed PWM signal. Only then you need to specify all the pinctrl related binding. For normal polarity it is almost useless I think. It can still be used of course but you would want to configure the pin with pull-down and as a GPIO_ACTIVE_HIGH in GPIO state. And that case would need additional documentation. It seems little bit redundant to me. I am open to do it that way (use dev_warn() and push DTS authors to use the additional pinctrl binding in all cases) if you think it is sane. Michal ^ permalink raw reply [flat|nested] 60+ messages in thread
end of thread, other threads:[~2018-11-26 15:51 UTC | newest] Thread overview: 60+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-10-10 9:33 [RCF PATCH v2 0/2] pwm: imx: Configure output to GPIO in disabled state Vokáč Michal 2018-10-10 9:33 ` [RCF PATCH v2 1/2] dt-bindings: pwm: imx: Allow switching PWM output between PWM and GPIO Vokáč Michal 2018-10-10 13:39 ` Thierry Reding 2018-10-29 15:52 ` Vokáč Michal 2018-10-10 9:33 ` [RCF PATCH v2 2/2] pwm: imx: Configure output to GPIO in disabled state Vokáč Michal 2018-10-12 8:57 ` [RCF PATCH,v2,2/2] " Uwe Kleine-König 2018-10-12 15:04 ` Vokáč Michal 2018-10-12 15:54 ` Thierry Reding 2018-10-12 16:08 ` Uwe Kleine-König 2018-10-14 20:24 ` Uwe Kleine-König 2018-10-15 8:45 ` Thierry Reding 2018-10-29 15:55 ` Vokáč Michal 2018-10-29 15:54 ` Vokáč Michal 2018-11-07 9:33 ` Uwe Kleine-König 2018-11-07 13:32 ` Vokáč Michal 2018-11-07 15:01 ` Uwe Kleine-König 2018-11-08 15:21 ` Vokáč Michal 2018-11-08 19:18 ` Uwe Kleine-König 2018-11-09 14:24 ` Vokáč Michal 2018-11-09 16:55 ` Uwe Kleine-König 2018-11-14 9:09 ` Uwe Kleine-König 2018-11-14 11:34 ` Thierry Reding 2018-11-14 21:51 ` Uwe Kleine-König 2018-11-15 15:25 ` Thierry Reding 2018-11-15 20:37 ` Uwe Kleine-König 2018-11-16 7:34 ` Lothar Waßmann 2018-11-16 8:25 ` Uwe Kleine-König 2018-11-22 15:42 ` Vokáč Michal 2018-11-22 16:23 ` Uwe Kleine-König 2018-11-22 16:46 ` Vokáč Michal 2018-11-22 19:03 ` Uwe Kleine-König 2018-11-23 15:15 ` Vokáč Michal 2018-11-25 20:56 ` Uwe Kleine-König 2018-11-26 9:11 ` Lothar Waßmann 2018-11-26 9:18 ` Uwe Kleine-König 2018-11-26 10:03 ` Lothar Waßmann 2018-11-26 11:51 ` Thierry Reding 2018-11-26 12:23 ` Lothar Waßmann 2018-11-26 13:34 ` Thierry Reding 2018-11-26 15:50 ` Vokáč Michal 2018-11-16 9:51 ` Thierry Reding 2018-11-16 10:39 ` Uwe Kleine-König 2018-11-16 11:56 ` Lothar Waßmann 2018-11-18 11:30 ` Uwe Kleine-König 2018-11-16 12:24 ` Thierry Reding 2018-11-18 20:08 ` Uwe Kleine-König 2018-11-19 8:48 ` Uwe Kleine-König 2018-11-22 15:03 ` Thierry Reding 2018-11-22 16:17 ` Uwe Kleine-König 2018-11-20 13:14 ` Vokáč Michal 2018-11-20 16:54 ` Uwe Kleine-König 2018-11-22 14:23 ` Vokáč Michal 2018-11-19 7:44 ` Linus Walleij 2018-11-19 8:32 ` Uwe Kleine-König 2018-11-20 8:35 ` Linus Walleij 2018-11-20 9:16 ` Viresh Kumar 2018-11-20 9:53 ` Uwe Kleine-König 2018-11-14 11:14 ` Thierry Reding 2018-10-12 16:00 ` [RCF PATCH v2 2/2] " Thierry Reding 2018-10-29 15:53 ` Vokáč Michal
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).