From: "Vokáč Michal" <Michal.Vokac@ysoft.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: "Thierry Reding" <thierry.reding@gmail.com>,
"Rob Herring" <robh+dt@kernel.org>,
"Mark Rutland" <mark.rutland@arm.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-pwm@vger.kernel.org" <linux-pwm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Lukasz Majewski" <l.majewski@majess.pl>,
"Fabio Estevam" <fabio.estevam@nxp.com>,
"Lothar Waßmann" <LW@karo-electronics.de>,
"Linus Walleij" <linus.walleij@linaro.org>
Subject: Re: [RFC PATCH v3 2/2] pwm: imx: Configure output to GPIO in disabled state
Date: Thu, 6 Dec 2018 15:37:55 +0000 [thread overview]
Message-ID: <01aaa6ff-fb3e-37a7-0e72-099ad013ee2a@ysoft.com> (raw)
In-Reply-To: <20181206135902.un2nbreqfmi6mpd6@pengutronix.de>
On 6.12.2018 14:59, Uwe Kleine-König wrote:
> On Thu, Dec 06, 2018 at 01:41:31PM +0000, Vokáč Michal wrote:
>>
>> +static int imx_pwm_init_pinctrl_info(struct imx_chip *imx_chip,
>> + struct platform_device *pdev)
>
> Please indent the follow up line to the opening parenthesis.
Meh, I overlooked that one. I will fix it.
>> +{
>> + imx_chip->pinctrl = devm_pinctrl_get(&pdev->dev);
>> + if (IS_ERR(imx_chip->pinctrl)) {
>> + dev_dbg(&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;
>
> Can it happen, that pinctrl_pins_pwm is PTR_ERR(-EPROBE_DEFER)?
No. The pinctrl_lookup_state either returns pointer to the pinctrl state
or ERR_PTR(-ENODEV). But I do not explicitly test the pinctrl_pins_pwm
for PTR_ERR(-EPROBE_DEFER), or do I?
> Maybe you only want to ignore PTR_ERR(-ENODEV) and for example propagate
> -EIO? I think you want to put the gpio if the failure is because there
> is a pinctrl related error.
I think that is what I am doing. In case the GPIO is not ready the probe
is deferred. In case of any other error with the GPIO or pinctrl failure
I put the pinctrl. Or maybe I do not really understand what you mean.
>> + }
>> +
>> + return 0;
>> +}
>> +
[...]
>> @@ -303,6 +362,24 @@ 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 {
>> + pinctrl_select_state(imx->pinctrl,
>> + imx->pinctrl_pins_gpio);
>> + }
>> + }
>> +
>
> ISTR that there was a patch that implements get_state for imx. Is there
> a dependency on that one? Otherwise the state returned by
> pwm_get_state() might not be what is actually configured.
No, it should be independent. One can go without the other. I tested all
three combinations (mainline with .get_state, mainline with this series,
mainline with .get_state AND this series) and got the expected results.
Without the .get_state() patch the core always returns the default which
is disabled state so the gpio pinctrl state is selected in probe.
> Do you know if this is required for the old i.MX pwm, e.g. on i.MX21?
> I ask because of https://patchwork.ozlabs.org/patch/1000071/
Yep, I am aware of that patch. IMHO this is not needed for the v1 on
older i.MX SoCs but I do not have a hands-on experience with those.
Thank you for the review Uwe!
Michal
next prev parent reply other threads:[~2018-12-06 15:38 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-06 13:41 [RFC PATCH v3 0/2] " Vokáč Michal
2018-12-06 13:41 ` [RFC PATCH v3 1/2] dt-bindings: pwm: imx: Allow switching PWM output between PWM and GPIO Vokáč Michal
2018-12-10 23:16 ` Rob Herring
2018-12-14 13:45 ` Linus Walleij
2018-12-06 13:41 ` [RFC PATCH v3 2/2] pwm: imx: Configure output to GPIO in disabled state Vokáč Michal
2018-12-06 13:59 ` Uwe Kleine-König
2018-12-06 15:37 ` Vokáč Michal [this message]
2018-12-06 16:16 ` Uwe Kleine-König
2018-12-10 11:15 ` Vokáč Michal
2018-12-10 11:17 ` Uwe Kleine-König
2018-12-10 11:38 ` Vokáč Michal
2018-12-12 8:01 ` Uwe Kleine-König
2018-12-12 11:42 ` Vokáč Michal
2018-12-12 12:12 ` Uwe Kleine-König
2019-01-24 8:59 ` Michal Vokáč
2019-01-24 9:22 ` Uwe Kleine-König
2019-01-24 10:12 ` Michal Vokáč
2019-01-24 10:44 ` Uwe Kleine-König
2019-01-30 14:42 ` Michal Vokáč
2019-01-30 15:39 ` Uwe Kleine-König
2019-02-01 15:50 ` Michal Vokáč
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=01aaa6ff-fb3e-37a7-0e72-099ad013ee2a@ysoft.com \
--to=michal.vokac@ysoft.com \
--cc=LW@karo-electronics.de \
--cc=devicetree@vger.kernel.org \
--cc=fabio.estevam@nxp.com \
--cc=l.majewski@majess.pl \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
--cc=thierry.reding@gmail.com \
--cc=u.kleine-koenig@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®