From: Marco Felsch <m.felsch@pengutronix.de>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: thierry.reding@gmail.com, lee.jones@linaro.org,
shawnguo@kernel.org, s.hauer@pengutronix.de, festevam@gmail.com,
linux-imx@nxp.com, Anson.Huang@nxp.com, michal.vokac@ysoft.com,
l.majewski@majess.pl, linux-pwm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, kernel@pengutronix.de
Subject: Re: [PATCH v2 3/5] pwm: imx27: reset the PWM if it is not running
Date: Mon, 28 Sep 2020 11:29:48 +0200 [thread overview]
Message-ID: <20200928092948.GT29466@pengutronix.de> (raw)
In-Reply-To: <20200928073019.led4eyfl3emv6aau@pengutronix.de>
On 20-09-28 09:30, Uwe Kleine-König wrote:
> On Fri, Sep 25, 2020 at 05:53:28PM +0200, Marco Felsch wrote:
> > Trigger a software reset during probe to clear the FIFO and reset the
> > register values to their default. According the datasheet the DBGEN,
> > STOPEN, DOZEN and WAITEN bits should be untouched by the software reset
> > but this is not the case.
> >
> > Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
> > ---
> > v2:
> > - new patch
> >
> > drivers/pwm/pwm-imx27.c | 26 ++++++++++++++------------
> > 1 file changed, 14 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/pwm/pwm-imx27.c b/drivers/pwm/pwm-imx27.c
> > index b761764b8375..3b6bcd8d58b7 100644
> > --- a/drivers/pwm/pwm-imx27.c
> > +++ b/drivers/pwm/pwm-imx27.c
> > @@ -183,10 +183,8 @@ static void pwm_imx27_get_state(struct pwm_chip *chip,
> > pwm_imx27_clk_disable_unprepare(imx);
> > }
> >
> > -static void pwm_imx27_sw_reset(struct pwm_chip *chip)
> > +static void pwm_imx27_sw_reset(struct pwm_imx27_chip *imx, struct device *dev)
> > {
> > - struct pwm_imx27_chip *imx = to_pwm_imx27_chip(chip);
> > - struct device *dev = chip->dev;
> > int wait_count = 0;
> > u32 cr;
>
> This is an unrelated hunk that I don't expect to result in any changes
> in the code. If you consider it better this way, you should at least
> mention it in the commit log.
IMO this is required due to the usage from the probe. I'm not a fan of
passing the 'struct pwm_chip' before initializing it. So it is not
unrelated. I will mention it in v3.
>
> > @@ -266,7 +264,7 @@ static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> > if (imx->enabled)
> > pwm_imx27_wait_fifo_slot(chip, pwm);
> > else
> > - pwm_imx27_sw_reset(chip);
> > + pwm_imx27_sw_reset(imx, chip->dev);
> >
> > writel(duty_cycles, imx->mmio_base + MX3_PWMSAR);
> > writel(period_cycles, imx->mmio_base + MX3_PWMPR);
> > @@ -370,19 +368,23 @@ static int pwm_imx27_probe(struct platform_device *pdev)
> > if (ret)
> > return ret;
> >
> > - mask = MX3_PWMCR_STOPEN | MX3_PWMCR_DOZEN | MX3_PWMCR_WAITEN |
> > - MX3_PWMCR_DBGEN;
> > - pwmcr = MX3_PWMCR_STOPEN | MX3_PWMCR_DOZEN | MX3_PWMCR_WAITEN |
> > - MX3_PWMCR_DBGEN;
> > - pwm_imx27_update_bits(imx->mmio_base + MX3_PWMCR, mask, pwmcr);
> > -
> > /* keep clks on and clk settings unchanged if pwm is running */
> > pwmcr = readl(imx->mmio_base + MX3_PWMCR);
> > if (!(pwmcr & MX3_PWMCR_EN)) {
> > - mask = MX3_PWMCR_CLKSRC;
> > - pwmcr = FIELD_PREP(MX3_PWMCR_CLKSRC, MX3_PWMCR_CLKSRC_IPG_HIGH);
> > + pwm_imx27_sw_reset(imx, &pdev->dev);
> > + mask = MX3_PWMCR_STOPEN | MX3_PWMCR_DOZEN | MX3_PWMCR_WAITEN |
> > + MX3_PWMCR_DBGEN | MX3_PWMCR_CLKSRC;
> > + pwmcr = MX3_PWMCR_STOPEN | MX3_PWMCR_DOZEN | MX3_PWMCR_WAITEN |
> > + MX3_PWMCR_DBGEN |
> > + FIELD_PREP(MX3_PWMCR_CLKSRC, MX3_PWMCR_CLKSRC_IPG_HIGH);
> > pwm_imx27_update_bits(imx->mmio_base + MX3_PWMCR, mask, pwmcr);
> > pwm_imx27_clk_disable_unprepare(imx);
> > + } else {
> > + mask = MX3_PWMCR_STOPEN | MX3_PWMCR_DOZEN | MX3_PWMCR_WAITEN |
> > + MX3_PWMCR_DBGEN;
> > + pwmcr = MX3_PWMCR_STOPEN | MX3_PWMCR_DOZEN | MX3_PWMCR_WAITEN |
> > + MX3_PWMCR_DBGEN;
> > + pwm_imx27_update_bits(imx->mmio_base + MX3_PWMCR, mask, pwmcr);
> > }
>
> IMHO this is worse than the stuff I suggested for one of the earlier
> patches because there is much repetition. I'd put
>
> mask = MX3_PWMCR_STOPEN | MX3_PWMCR_DOZEN | MX3_PWMCR_WAITEN | MX3_PWMCR_DBGEN;
> value = MX3_PWMCR_STOPEN | MX3_PWMCR_DOZEN | MX3_PWMCR_WAITEN | MX3_PWMCR_DBGEN;
>
> before the if and just modify as necessary in the first branch of the
> if.
I've changed the behaviour in v3.
Regards,
Marco
>
> Best regards
> Uwe
>
> --
> Pengutronix e.K. | Uwe Kleine-König |
> Industrial Linux Solutions | https://www.pengutronix.de/ |
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
next prev parent reply other threads:[~2020-09-28 9:29 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-25 15:53 [PATCH v2 0/5] PWM i.MX27 fix disabled state for inverted signals Marco Felsch
2020-09-25 15:53 ` [PATCH v2 1/5] pwm: imx27: enable clock unconditional for register access Marco Felsch
2020-09-26 13:28 ` Uwe Kleine-König
2020-09-26 13:48 ` Uwe Kleine-König
2020-09-28 5:52 ` Marco Felsch
2020-09-25 15:53 ` [PATCH v2 2/5] pwm: imx27: move constant PWMCR register values into probe Marco Felsch
2020-09-26 13:46 ` Uwe Kleine-König
2020-09-28 5:50 ` Marco Felsch
2020-09-25 15:53 ` [PATCH v2 3/5] pwm: imx27: reset the PWM if it is not running Marco Felsch
2020-09-28 7:30 ` Uwe Kleine-König
2020-09-28 9:29 ` Marco Felsch [this message]
2020-09-25 15:53 ` [PATCH v2 4/5] pwm: imx27: fix disable state for inverted PWMs Marco Felsch
2020-09-28 7:47 ` Uwe Kleine-König
2020-09-28 9:52 ` Marco Felsch
2020-09-28 19:06 ` Uwe Kleine-König
2020-09-29 5:23 ` Marco Felsch
2020-09-25 15:53 ` [PATCH v2 5/5] pwm: imx27: wait till the duty cycle is applied Marco Felsch
2020-09-28 8:04 ` Uwe Kleine-König
2020-09-28 9:59 ` Marco Felsch
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=20200928092948.GT29466@pengutronix.de \
--to=m.felsch@pengutronix.de \
--cc=Anson.Huang@nxp.com \
--cc=festevam@gmail.com \
--cc=kernel@pengutronix.de \
--cc=l.majewski@majess.pl \
--cc=lee.jones@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-imx@nxp.com \
--cc=linux-pwm@vger.kernel.org \
--cc=michal.vokac@ysoft.com \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@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;
as well as URLs for NNTP newsgroup(s).