From: viresh.kumar@st.com (viresh kumar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2 1/3] drivers/pwm st_pwm: Add support for ST's Pulse Width Modulator
Date: Tue, 7 Jun 2011 09:25:25 +0530 [thread overview]
Message-ID: <4DEDA12D.6080406@st.com> (raw)
In-Reply-To: <20110606173339.268b9f9c.akpm@linux-foundation.org>
On 06/07/2011 06:03 AM, Andrew Morton wrote:
> On Tue, 31 May 2011 14:21:51 +0530
> Viresh Kumar <viresh.kumar@st.com> wrote:
>> + * lock: lock specific to a pwm device
>
> More specificity here would be helpful. Precisely which data does the
> lock protect?
>
>> + * lock: lock specific to current pwm ip
>
> Ditto.
>
Ok.
>> +int pwm_config(struct pwm_device *pwmd, int duty_ns, int period_ns)
>> +{
>> + u64 val, div, clk_rate;
>> + unsigned long prescale = MIN_PRESCALE, pv, dc;
>> + int ret = 0;
>> +
>> + if (!pwmd) {
>> + pr_err("pwm: config - NULL pwm device pointer\n");
>> + return -EFAULT;
>> + }
>> +
>> + if (period_ns == 0 || duty_ns > period_ns) {
>> + ret = -EINVAL;
>> + goto err;
>> + }
>> +
>> + /* TODO: Need to optimize this loop */
>> + while (1) {
>> + div = 1000000000;
>> + div *= 1 + prescale;
>> + clk_rate = clk_get_rate(pwmd->pwm->clk);
>> + val = clk_rate * period_ns;
>> + pv = div64_u64(val, div);
>> + val = clk_rate * duty_ns;
>> + dc = div64_u64(val, div);
>> +
>> + if ((pv == 0) || (dc == 0)) {
>> + ret = -EINVAL;
>> + goto err;
>> + }
>> + if ((pv > MAX_PERIOD) || (dc > MAX_DUTY)) {
>> + prescale++;
>> + if (prescale > MAX_PRESCALE) {
>> + ret = -EINVAL;
>> + goto err;
>> + }
>> + continue;
>> + }
>> + if ((pv < MIN_PERIOD) || (dc < MIN_DUTY)) {
>> + ret = -EINVAL;
>> + goto err;
>> + }
>> + break;
>> + }
>
> gee, is this some sort of puzzle? So human-readable description of
> what this code is doing would be an improvement.
>
Sure. Will add that.
>> + spin_lock(&pwmd->pwm->lock);
>> + ret = clk_enable(pwmd->pwm->clk);
>> + if (ret) {
>> + spin_unlock(&pwmd->pwm->lock);
>> + goto err;
>> + }
>> +
>> + spin_lock(&pwmd->lock);
>> + writel(prescale << PRESCALE_SHIFT, pwmd->pwm->mmio_base +
>> + pwmd->offset + PWMCR);
>> + writel(dc, pwmd->pwm->mmio_base + pwmd->offset + PWMDCR);
>> + writel(pv, pwmd->pwm->mmio_base + pwmd->offset + PWMPCR);
>> + spin_unlock(&pwmd->lock);
>> + clk_disable(pwmd->pwm->clk);
>> + spin_unlock(&pwmd->pwm->lock);
>
> The nesting rules for these two locks seems sensible and obvious, but I
> guess documenting the rule wouldn't hurt.
>
Ok.
>> + return 0;
>> +err:
>> + dev_err(&pwmd->pwm->pdev->dev, "pwm config fail\n");
>> + return ret;
>> +}
>> +EXPORT_SYMBOL(pwm_config);
>> +
>>
>> ...
>>
>> +static int __devinit st_pwm_probe(struct platform_device *pdev)
>
> And here things get rather odd.
>
> Most of this file is a generic, non-device specific PWM layer, exported
> to other modules. But then we get into driver bits which are specific
> to one paritular type of device. Confused - this is like putting the
> e100 driver inside net/ipv4/tcp.c?
>
Sorry but i couldn't get this one completely. :(
Driver is specific to pwm peripheral by ST. This driver can be used for
SPEAr or may be other SoC or Devices, and is not at all dependent on SPEAr.
--
viresh
WARNING: multiple messages have this Message-ID (diff)
From: viresh kumar <viresh.kumar@st.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"arnd@arndb.de" <arnd@arndb.de>,
Armando VISCONTI <armando.visconti@st.com>,
Shiraz HASHIM <shiraz.hashim@st.com>,
Vipin KUMAR <vipin.kumar@st.com>,
Rajeev KUMAR <rajeev-dlh.kumar@st.com>,
Deepak SIKRI <deepak.sikri@st.com>,
Vipul Kumar SAMAR <vipulkumar.samar@st.com>,
Amit VIRDI <Amit.VIRDI@st.com>,
Pratyush ANAND <pratyush.anand@st.com>,
Bhupesh SHARMA <bhupesh.sharma@st.com>,
"viresh.linux@gmail.com" <viresh.linux@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V2 1/3] drivers/pwm st_pwm: Add support for ST's Pulse Width Modulator
Date: Tue, 7 Jun 2011 09:25:25 +0530 [thread overview]
Message-ID: <4DEDA12D.6080406@st.com> (raw)
In-Reply-To: <20110606173339.268b9f9c.akpm@linux-foundation.org>
On 06/07/2011 06:03 AM, Andrew Morton wrote:
> On Tue, 31 May 2011 14:21:51 +0530
> Viresh Kumar <viresh.kumar@st.com> wrote:
>> + * lock: lock specific to a pwm device
>
> More specificity here would be helpful. Precisely which data does the
> lock protect?
>
>> + * lock: lock specific to current pwm ip
>
> Ditto.
>
Ok.
>> +int pwm_config(struct pwm_device *pwmd, int duty_ns, int period_ns)
>> +{
>> + u64 val, div, clk_rate;
>> + unsigned long prescale = MIN_PRESCALE, pv, dc;
>> + int ret = 0;
>> +
>> + if (!pwmd) {
>> + pr_err("pwm: config - NULL pwm device pointer\n");
>> + return -EFAULT;
>> + }
>> +
>> + if (period_ns == 0 || duty_ns > period_ns) {
>> + ret = -EINVAL;
>> + goto err;
>> + }
>> +
>> + /* TODO: Need to optimize this loop */
>> + while (1) {
>> + div = 1000000000;
>> + div *= 1 + prescale;
>> + clk_rate = clk_get_rate(pwmd->pwm->clk);
>> + val = clk_rate * period_ns;
>> + pv = div64_u64(val, div);
>> + val = clk_rate * duty_ns;
>> + dc = div64_u64(val, div);
>> +
>> + if ((pv == 0) || (dc == 0)) {
>> + ret = -EINVAL;
>> + goto err;
>> + }
>> + if ((pv > MAX_PERIOD) || (dc > MAX_DUTY)) {
>> + prescale++;
>> + if (prescale > MAX_PRESCALE) {
>> + ret = -EINVAL;
>> + goto err;
>> + }
>> + continue;
>> + }
>> + if ((pv < MIN_PERIOD) || (dc < MIN_DUTY)) {
>> + ret = -EINVAL;
>> + goto err;
>> + }
>> + break;
>> + }
>
> gee, is this some sort of puzzle? So human-readable description of
> what this code is doing would be an improvement.
>
Sure. Will add that.
>> + spin_lock(&pwmd->pwm->lock);
>> + ret = clk_enable(pwmd->pwm->clk);
>> + if (ret) {
>> + spin_unlock(&pwmd->pwm->lock);
>> + goto err;
>> + }
>> +
>> + spin_lock(&pwmd->lock);
>> + writel(prescale << PRESCALE_SHIFT, pwmd->pwm->mmio_base +
>> + pwmd->offset + PWMCR);
>> + writel(dc, pwmd->pwm->mmio_base + pwmd->offset + PWMDCR);
>> + writel(pv, pwmd->pwm->mmio_base + pwmd->offset + PWMPCR);
>> + spin_unlock(&pwmd->lock);
>> + clk_disable(pwmd->pwm->clk);
>> + spin_unlock(&pwmd->pwm->lock);
>
> The nesting rules for these two locks seems sensible and obvious, but I
> guess documenting the rule wouldn't hurt.
>
Ok.
>> + return 0;
>> +err:
>> + dev_err(&pwmd->pwm->pdev->dev, "pwm config fail\n");
>> + return ret;
>> +}
>> +EXPORT_SYMBOL(pwm_config);
>> +
>>
>> ...
>>
>> +static int __devinit st_pwm_probe(struct platform_device *pdev)
>
> And here things get rather odd.
>
> Most of this file is a generic, non-device specific PWM layer, exported
> to other modules. But then we get into driver bits which are specific
> to one paritular type of device. Confused - this is like putting the
> e100 driver inside net/ipv4/tcp.c?
>
Sorry but i couldn't get this one completely. :(
Driver is specific to pwm peripheral by ST. This driver can be used for
SPEAr or may be other SoC or Devices, and is not at all dependent on SPEAr.
--
viresh
next prev parent reply other threads:[~2011-06-07 3:55 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-31 8:51 [PATCH V2 0/3] Add drivers/pwm and drivers/pwm/st_pwm.c Viresh Kumar
2011-05-31 8:51 ` Viresh Kumar
2011-05-31 8:51 ` [PATCH V2 1/3] drivers/pwm st_pwm: Add support for ST's Pulse Width Modulator Viresh Kumar
2011-06-07 10:17 ` [PATCH V3 " Viresh Kumar
2011-06-07 0:33 ` [PATCH V2 " Andrew Morton
2011-06-07 0:33 ` Andrew Morton
2011-06-07 3:55 ` viresh kumar [this message]
2011-06-07 3:55 ` viresh kumar
2011-06-07 7:28 ` Arnd Bergmann
2011-06-07 7:28 ` Arnd Bergmann
2011-06-07 10:10 ` viresh kumar
2011-06-07 10:10 ` viresh kumar
2011-05-31 8:51 ` [PATCH V2 2/3] SPEAr3xx: Add machine support for ST's PWM IP Viresh Kumar
2011-05-31 8:51 ` Viresh Kumar
2011-05-31 8:51 ` [PATCH V2 3/3] SPEAr3xx: Update defconfig for ST's PWM Viresh Kumar
2011-05-31 8:51 ` Viresh Kumar
2011-06-27 11:12 ` [PATCH V2 0/3] Add drivers/pwm and drivers/pwm/st_pwm.c viresh kumar
2011-06-27 11:12 ` viresh kumar
2011-06-27 13:26 ` Arnd Bergmann
2011-06-27 13:26 ` Arnd Bergmann
2011-06-28 10:04 ` Sascha Hauer
2011-06-28 10:04 ` Sascha Hauer
2011-06-28 15:13 ` Arnd Bergmann
2011-06-28 15:13 ` Arnd Bergmann
2011-06-29 9:14 ` Sascha Hauer
2011-06-29 9:14 ` Sascha Hauer
2011-06-29 9:35 ` viresh kumar
2011-06-29 9:35 ` viresh kumar
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=4DEDA12D.6080406@st.com \
--to=viresh.kumar@st.com \
--cc=linux-arm-kernel@lists.infradead.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.