mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®