All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bo Shen <voice.shen-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
To: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: linux-pwm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org,
	galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
	plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH v8 1/2] PWM: atmel-pwm: add PWM controller driver
Date: Wed, 4 Dec 2013 10:59:46 +0800	[thread overview]
Message-ID: <529E9AA2.8020400@atmel.com> (raw)
In-Reply-To: <20131203094326.GB21178-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org>

Hi Thierry,

On 12/03/2013 05:43 PM, Thierry Reding wrote:
> On Tue, Dec 03, 2013 at 11:09:12AM +0800, Bo Shen wrote:
>> On 12/02/2013 06:59 PM, Thierry Reding wrote:
>>> On Mon, Nov 18, 2013 at 05:13:21PM +0800, Bo Shen wrote:
> [...]
>>>> diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
> [...]
>>>> +	/* Calculate the period cycles */
>>>> +	while (div > PWM_MAX_PRD) {
>>>> +		div = clk_rate / (1 << pres);
>>>> +		div = div * period_ns;
>>>> +		/* 1/Hz = 100000000 ns */
>>>
>>> I don't think that comment is needed.
>>
>> This is asked to be added.
>> And, I think keep it and it won't hurt, what do you think?
>
> I think it's obvious that you're converting from nanoseconds because of
> the _ns prefix in period_ns. But if somebody requested this and everyone
> else thinks it's useful, I'm okay with keeping it.
>
>>>> +	if (test_bit(PWMF_ENABLED, &pwm->flags)) {
>>>> +		atmel_pwm_ch_writel(atmel_pwm, pwm->hwpwm, PWMV2_CDTYUPD, dty);
>>>> +	} else {
>>>> +		atmel_pwm_ch_writel(atmel_pwm, pwm->hwpwm, PWMV2_CDTY, dty);
>>>> +		atmel_pwm_ch_writel(atmel_pwm, pwm->hwpwm, PWMV2_CPRD, prd);
>>>> +	}
>>>> +}
>>>
>>> Neither version 1 nor version 2 seem to be able to change the period
>>> while the channel is enabled. Perhaps that should be checked for in
>>> atmel_pwm_config() and an error (-EBUSY) returned?
>>
>> The period is configured in dt in device tree, or platform data in non
>> device tree. Nowhere will update period. So, not code to update period.
>> Am I right? If not, please figure out.
>
> The .config() operation allows the period to be specified. Just because
> nobody currently changes it at runtime doesn't mean it can't be done.
>
> It is also possible that whoever wrote the device tree or platform data
> didn't know that the period must be the same for all PWM channels and
> therefore might use different values. If you check for this, at least
> they'll notice. If you don't check for it, then they may end up having
> the period reconfigured behind their backs, which may cause parts of
> their setup to behave unexpectedly.

Thanks for this information.
I will add code for changing period.

> Thierry
>

Best Regards,
Bo Shen
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: voice.shen@atmel.com (Bo Shen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v8 1/2] PWM: atmel-pwm: add PWM controller driver
Date: Wed, 4 Dec 2013 10:59:46 +0800	[thread overview]
Message-ID: <529E9AA2.8020400@atmel.com> (raw)
In-Reply-To: <20131203094326.GB21178@ulmo.nvidia.com>

Hi Thierry,

On 12/03/2013 05:43 PM, Thierry Reding wrote:
> On Tue, Dec 03, 2013 at 11:09:12AM +0800, Bo Shen wrote:
>> On 12/02/2013 06:59 PM, Thierry Reding wrote:
>>> On Mon, Nov 18, 2013 at 05:13:21PM +0800, Bo Shen wrote:
> [...]
>>>> diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
> [...]
>>>> +	/* Calculate the period cycles */
>>>> +	while (div > PWM_MAX_PRD) {
>>>> +		div = clk_rate / (1 << pres);
>>>> +		div = div * period_ns;
>>>> +		/* 1/Hz = 100000000 ns */
>>>
>>> I don't think that comment is needed.
>>
>> This is asked to be added.
>> And, I think keep it and it won't hurt, what do you think?
>
> I think it's obvious that you're converting from nanoseconds because of
> the _ns prefix in period_ns. But if somebody requested this and everyone
> else thinks it's useful, I'm okay with keeping it.
>
>>>> +	if (test_bit(PWMF_ENABLED, &pwm->flags)) {
>>>> +		atmel_pwm_ch_writel(atmel_pwm, pwm->hwpwm, PWMV2_CDTYUPD, dty);
>>>> +	} else {
>>>> +		atmel_pwm_ch_writel(atmel_pwm, pwm->hwpwm, PWMV2_CDTY, dty);
>>>> +		atmel_pwm_ch_writel(atmel_pwm, pwm->hwpwm, PWMV2_CPRD, prd);
>>>> +	}
>>>> +}
>>>
>>> Neither version 1 nor version 2 seem to be able to change the period
>>> while the channel is enabled. Perhaps that should be checked for in
>>> atmel_pwm_config() and an error (-EBUSY) returned?
>>
>> The period is configured in dt in device tree, or platform data in non
>> device tree. Nowhere will update period. So, not code to update period.
>> Am I right? If not, please figure out.
>
> The .config() operation allows the period to be specified. Just because
> nobody currently changes it at runtime doesn't mean it can't be done.
>
> It is also possible that whoever wrote the device tree or platform data
> didn't know that the period must be the same for all PWM channels and
> therefore might use different values. If you check for this, at least
> they'll notice. If you don't check for it, then they may end up having
> the period reconfigured behind their backs, which may cause parts of
> their setup to behave unexpectedly.

Thanks for this information.
I will add code for changing period.

> Thierry
>

Best Regards,
Bo Shen

WARNING: multiple messages have this Message-ID (diff)
From: Bo Shen <voice.shen@atmel.com>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: <linux-pwm@vger.kernel.org>, <devicetree@vger.kernel.org>,
	<nicolas.ferre@atmel.com>, <linux-kernel@vger.kernel.org>,
	<alexandre.belloni@free-electrons.com>, <galak@codeaurora.org>,
	<plagnioj@jcrosoft.com>, <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v8 1/2] PWM: atmel-pwm: add PWM controller driver
Date: Wed, 4 Dec 2013 10:59:46 +0800	[thread overview]
Message-ID: <529E9AA2.8020400@atmel.com> (raw)
In-Reply-To: <20131203094326.GB21178@ulmo.nvidia.com>

Hi Thierry,

On 12/03/2013 05:43 PM, Thierry Reding wrote:
> On Tue, Dec 03, 2013 at 11:09:12AM +0800, Bo Shen wrote:
>> On 12/02/2013 06:59 PM, Thierry Reding wrote:
>>> On Mon, Nov 18, 2013 at 05:13:21PM +0800, Bo Shen wrote:
> [...]
>>>> diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
> [...]
>>>> +	/* Calculate the period cycles */
>>>> +	while (div > PWM_MAX_PRD) {
>>>> +		div = clk_rate / (1 << pres);
>>>> +		div = div * period_ns;
>>>> +		/* 1/Hz = 100000000 ns */
>>>
>>> I don't think that comment is needed.
>>
>> This is asked to be added.
>> And, I think keep it and it won't hurt, what do you think?
>
> I think it's obvious that you're converting from nanoseconds because of
> the _ns prefix in period_ns. But if somebody requested this and everyone
> else thinks it's useful, I'm okay with keeping it.
>
>>>> +	if (test_bit(PWMF_ENABLED, &pwm->flags)) {
>>>> +		atmel_pwm_ch_writel(atmel_pwm, pwm->hwpwm, PWMV2_CDTYUPD, dty);
>>>> +	} else {
>>>> +		atmel_pwm_ch_writel(atmel_pwm, pwm->hwpwm, PWMV2_CDTY, dty);
>>>> +		atmel_pwm_ch_writel(atmel_pwm, pwm->hwpwm, PWMV2_CPRD, prd);
>>>> +	}
>>>> +}
>>>
>>> Neither version 1 nor version 2 seem to be able to change the period
>>> while the channel is enabled. Perhaps that should be checked for in
>>> atmel_pwm_config() and an error (-EBUSY) returned?
>>
>> The period is configured in dt in device tree, or platform data in non
>> device tree. Nowhere will update period. So, not code to update period.
>> Am I right? If not, please figure out.
>
> The .config() operation allows the period to be specified. Just because
> nobody currently changes it at runtime doesn't mean it can't be done.
>
> It is also possible that whoever wrote the device tree or platform data
> didn't know that the period must be the same for all PWM channels and
> therefore might use different values. If you check for this, at least
> they'll notice. If you don't check for it, then they may end up having
> the period reconfigured behind their backs, which may cause parts of
> their setup to behave unexpectedly.

Thanks for this information.
I will add code for changing period.

> Thierry
>

Best Regards,
Bo Shen

  parent reply	other threads:[~2013-12-04  2:59 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-18  9:13 [PATCH v8 1/2] PWM: atmel-pwm: add PWM controller driver Bo Shen
2013-11-18  9:13 ` Bo Shen
2013-11-18  9:13 ` Bo Shen
2013-11-18  9:13 ` [PATCH v8 2/2] PWM: atmel-pwm: add device tree binding document Bo Shen
2013-11-18  9:13   ` Bo Shen
2013-11-18  9:13   ` Bo Shen
2013-12-02  8:01 ` [PATCH v8 1/2] PWM: atmel-pwm: add PWM controller driver Bo Shen
2013-12-02  8:01   ` Bo Shen
2013-12-02  8:01   ` Bo Shen
2013-12-02 10:59 ` Thierry Reding
2013-12-02 10:59   ` Thierry Reding
2013-12-03  3:09   ` Bo Shen
2013-12-03  3:09     ` Bo Shen
2013-12-03  3:09     ` Bo Shen
2013-12-03  9:43     ` Thierry Reding
2013-12-03  9:43       ` Thierry Reding
     [not found]       ` <20131203094326.GB21178-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org>
2013-12-04  2:59         ` Bo Shen [this message]
2013-12-04  2:59           ` Bo Shen
2013-12-04  2:59           ` Bo Shen
2013-12-04 10:03           ` Thierry Reding
2013-12-04 10:03             ` Thierry Reding
2013-12-05  1:11             ` Bo Shen
2013-12-05  1:11               ` Bo Shen
2013-12-05  1:11               ` Bo Shen
2013-12-06 13:02               ` Thierry Reding
2013-12-06 13:02                 ` Thierry Reding
2013-12-06 13:02                 ` Thierry Reding
     [not found]     ` <529D4B58.9020700-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
2013-12-10  2:20       ` Bo Shen
2013-12-10  2:20         ` Bo Shen
2013-12-10  2:20         ` Bo Shen
2013-12-11 15:21         ` Thierry Reding
2013-12-11 15:21           ` Thierry Reding

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=529E9AA2.8020400@atmel.com \
    --to=voice.shen-aife0yeh4naavxtiumwx3w@public.gmane.org \
    --cc=alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-pwm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org \
    --cc=plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org \
    --cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.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.