All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxime Ripard <maxime.ripard@free-electrons.com>
To: Olliver Schinagl <oliver@schinagl.nl>
Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	Chen-Yu Tsai <wens@csie.org>,
	linux-pwm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Olliver Schinagl <o.schinagl@ultimaker.com>
Subject: Re: [PATCH 2/2] pwm: sunxi: Yield some time to the pwm-block to become ready
Date: Sat, 27 Aug 2016 00:25:23 +0200	[thread overview]
Message-ID: <20160826222523.GH3165@lukather> (raw)
In-Reply-To: <1472147411-30424-3-git-send-email-oliver@schinagl.nl>

[-- Attachment #1: Type: text/plain, Size: 2611 bytes --]

Hi,

On Thu, Aug 25, 2016 at 07:50:11PM +0200, Olliver Schinagl wrote:
> From: Olliver Schinagl <o.schinagl@ultimaker.com>
> 
> The pwm-block of some of the sunxi chips feature a 'ready' flag to
> indicate the software that it is ready for new commands.
> 
> Right now, when we call pwm_config and set the period, we write the
> values to the registers, and turn off the clock to the IP. Because of
> this, the hardware does not have time to configure the hardware and set
> the 'ready' flag.
> 
> By running the clock just before making new changes and before checking
> if the hardware is ready, the hardware has time to reconfigure itself
> and set the clear the flag appropriately.
> 
> Signed-off-by: Olliver Schinagl <o.schinagl@ultimaker.com>
> ---
>  drivers/pwm/pwm-sun4i.c | 43 +++++++++++++++++++++++++------------------
>  1 file changed, 25 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
> index 5e97c8a..dd198c3 100644
> --- a/drivers/pwm/pwm-sun4i.c
> +++ b/drivers/pwm/pwm-sun4i.c
> @@ -105,6 +105,22 @@ static int sun4i_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
>  	u64 clk_rate, div = 0;
>  	unsigned int prescaler = 0;
>  	int err;
> +	int ret = 0;
> +
> +	/* Let the PWM hardware run before making any changes. We do this to
> +	 * allow the hardware to have some time to clear the 'ready' flag.
> +	 */

This is not the proper comment style.

> +	err = clk_prepare_enable(sun4i_pwm->clk);
> +	if (err) {
> +		dev_err(chip->dev, "failed to enable PWM clock\n");
> +		return err;
> +	}

New line please.

> +	spin_lock(&sun4i_pwm->ctrl_lock);
> +	val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
> +	clk_gate = val & BIT_CH(PWM_CLK_GATING, pwm->hwpwm);
> +	val |= BIT_CH(PWM_CLK_GATING, pwm->hwpwm);

What are you doing here? You clear a bit, and then put the same one
back in?

> +	sun4i_pwm_writel(sun4i_pwm, val, PWM_CTRL_REG);
> +	spin_unlock(&sun4i_pwm->ctrl_lock);
>  
>  	clk_rate = clk_get_rate(sun4i_pwm->clk);
>  
> @@ -137,7 +153,9 @@ static int sun4i_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
>  
>  		if (div - 1 > PWM_PRD_MASK) {
>  			dev_err(chip->dev, "period exceeds the maximum value\n");
> -			return -EINVAL;
> +			ret = -EINVAL;
> +			spin_lock(&sun4i_pwm->ctrl_lock);

Uh? That's really suspicious. And even if right, please don't do that,
this is just really bad for the comprehension of the workflow.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: maxime.ripard@free-electrons.com (Maxime Ripard)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] pwm: sunxi: Yield some time to the pwm-block to become ready
Date: Sat, 27 Aug 2016 00:25:23 +0200	[thread overview]
Message-ID: <20160826222523.GH3165@lukather> (raw)
In-Reply-To: <1472147411-30424-3-git-send-email-oliver@schinagl.nl>

Hi,

On Thu, Aug 25, 2016 at 07:50:11PM +0200, Olliver Schinagl wrote:
> From: Olliver Schinagl <o.schinagl@ultimaker.com>
> 
> The pwm-block of some of the sunxi chips feature a 'ready' flag to
> indicate the software that it is ready for new commands.
> 
> Right now, when we call pwm_config and set the period, we write the
> values to the registers, and turn off the clock to the IP. Because of
> this, the hardware does not have time to configure the hardware and set
> the 'ready' flag.
> 
> By running the clock just before making new changes and before checking
> if the hardware is ready, the hardware has time to reconfigure itself
> and set the clear the flag appropriately.
> 
> Signed-off-by: Olliver Schinagl <o.schinagl@ultimaker.com>
> ---
>  drivers/pwm/pwm-sun4i.c | 43 +++++++++++++++++++++++++------------------
>  1 file changed, 25 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
> index 5e97c8a..dd198c3 100644
> --- a/drivers/pwm/pwm-sun4i.c
> +++ b/drivers/pwm/pwm-sun4i.c
> @@ -105,6 +105,22 @@ static int sun4i_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
>  	u64 clk_rate, div = 0;
>  	unsigned int prescaler = 0;
>  	int err;
> +	int ret = 0;
> +
> +	/* Let the PWM hardware run before making any changes. We do this to
> +	 * allow the hardware to have some time to clear the 'ready' flag.
> +	 */

This is not the proper comment style.

> +	err = clk_prepare_enable(sun4i_pwm->clk);
> +	if (err) {
> +		dev_err(chip->dev, "failed to enable PWM clock\n");
> +		return err;
> +	}

New line please.

> +	spin_lock(&sun4i_pwm->ctrl_lock);
> +	val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
> +	clk_gate = val & BIT_CH(PWM_CLK_GATING, pwm->hwpwm);
> +	val |= BIT_CH(PWM_CLK_GATING, pwm->hwpwm);

What are you doing here? You clear a bit, and then put the same one
back in?

> +	sun4i_pwm_writel(sun4i_pwm, val, PWM_CTRL_REG);
> +	spin_unlock(&sun4i_pwm->ctrl_lock);
>  
>  	clk_rate = clk_get_rate(sun4i_pwm->clk);
>  
> @@ -137,7 +153,9 @@ static int sun4i_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
>  
>  		if (div - 1 > PWM_PRD_MASK) {
>  			dev_err(chip->dev, "period exceeds the maximum value\n");
> -			return -EINVAL;
> +			ret = -EINVAL;
> +			spin_lock(&sun4i_pwm->ctrl_lock);

Uh? That's really suspicious. And even if right, please don't do that,
this is just really bad for the comprehension of the workflow.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160827/f7e46b13/attachment-0001.sig>

  reply	other threads:[~2016-08-26 22:25 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-25 17:50 [PATCHv2 0/2] pwm: sunxi: give the pwm IP block more time Olliver Schinagl
2016-08-25 17:50 ` Olliver Schinagl
2016-08-25 17:50 ` [PATCH 1/2] pwm: sunxi: allow the pwm to finish its pulse before disable Olliver Schinagl
2016-08-25 17:50   ` Olliver Schinagl
2016-08-26 22:19   ` Maxime Ripard
2016-08-26 22:19     ` Maxime Ripard
2016-09-06  7:12     ` Olliver Schinagl
2016-09-06  7:12       ` Olliver Schinagl
2016-09-06 19:51       ` Maxime Ripard
2016-09-06 19:51         ` Maxime Ripard
2016-09-09  9:01         ` Olliver Schinagl
2016-09-09  9:01           ` Olliver Schinagl
2016-09-24 20:25           ` Maxime Ripard
2016-09-24 20:25             ` Maxime Ripard
2016-09-26  8:46             ` Olliver Schinagl
2016-09-26  8:46               ` Olliver Schinagl
2016-09-27 20:16               ` Maxime Ripard
2016-09-27 20:16                 ` Maxime Ripard
2016-12-08 13:23     ` Olliver Schinagl
2016-12-12 12:24       ` Maxime Ripard
2016-12-12 12:24         ` Maxime Ripard
2017-01-03 15:59         ` Olliver Schinagl
2017-01-03 15:59           ` Olliver Schinagl
2017-01-03 16:55           ` Alexandre Belloni
2017-01-03 16:55             ` Alexandre Belloni
2017-01-03 16:55             ` Alexandre Belloni
2017-01-04  6:36             ` Thierry Reding
2017-01-04  6:36               ` Thierry Reding
2017-01-04  6:36               ` Thierry Reding
2016-09-23 14:02   ` [1/2] " Jonathan Liu
2016-09-23 14:02     ` Jonathan Liu
2016-09-23 14:03     ` Olliver Schinagl
2016-09-23 14:03       ` Olliver Schinagl
2017-05-05  1:54       ` Jonathan Liu
2017-05-05  1:54         ` Jonathan Liu
2016-08-25 17:50 ` [PATCH 2/2] pwm: sunxi: Yield some time to the pwm-block to become ready Olliver Schinagl
2016-08-25 17:50   ` Olliver Schinagl
2016-08-26 22:25   ` Maxime Ripard [this message]
2016-08-26 22:25     ` Maxime Ripard

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=20160826222523.GH3165@lukather \
    --to=maxime.ripard@free-electrons.com \
    --cc=alexandre.belloni@free-electrons.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=o.schinagl@ultimaker.com \
    --cc=oliver@schinagl.nl \
    --cc=thierry.reding@gmail.com \
    --cc=wens@csie.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.