From: Tony Lindgren <tony@atomide.com>
To: Kevin Hilman <khilman@ti.com>
Cc: Nishanth Menon <nm@ti.com>,
linux-omap <linux-omap@vger.kernel.org>,
linux-arm <linux-arm-kernel@lists.infradead.org>,
Jon <jon-hunter@ti.com>, Yuan Jiangli <jlyuan@motorola.com>
Subject: Re: [PATCH V2] OMAP3+: PM: VP: fix integer truncation error
Date: Tue, 6 Mar 2012 16:13:11 -0800 [thread overview]
Message-ID: <20120307001311.GB12083@atomide.com> (raw)
In-Reply-To: <87hay1b7i0.fsf@ti.com>
* Kevin Hilman <khilman@ti.com> [120306 15:33]:
> Nishanth Menon <nm@ti.com> writes:
>
> > From: Yuan Jiangli <jlyuan@motorola.com>
> >
> > commit 2f34ce81b8c05c900e45bd88595cc154f7bb5957
> > (OMAP3: PM: Adding voltage driver support.)
> > introduced runtime computation of waittime to handle all potential
> > sys clocks available.
> >
> > In the voltage processor, the SPMSUpdateWait is calculated based on
> > the slew rate and the voltage step (SMPSUpdateWait = slew rate *
> > Voltage Step). After the voltage processor receives the SMPS_Ack
> > signal, the Voltage Controller will wait for SMPSUpdateWait clock
> > cycles for the voltage to settle to the new value. For all
> > practical purposes, the waittime parameter is the OMAP hardware
> > translation of what the slew rate on the PMIC is.
> >
> > As an example, with TPS62361 on OMAP4460,
> > step_size = 10000
> > slew_rate = 32000
> > sys_clk_rate = 38400
> >
> > Our current computation results in the following:
> > = ((step_size / slew_rate) * sys_clk_rate) / 1000
> > = ((10000 / 32000) * 38400 / 1000
> > = 0
> >
> > Fix the same using DIV_ROUND_UP as an extra wait clock cycle
> > is better than lesser clock cycle. For the above example, this
> > translates to:
> > = (10000 * 38400) / (1000 * 32000)
> > = 12
> >
> > Acked-by: Jon Hunter <jon-hunter@ti.com>
> > [nm@ti.com: slightly better implementation]
> > Signed-off-by: Nishanth Menon <nm@ti.com>
> > Signed-off-by: Yuan Jiangli <jlyuan@motorola.com>
>
> Acked-by: Kevin Hilman <khilman@ti.com>
>
> Tony, I don't have any more PM fixes for this cycle, so feel free to add
> this to fixes-non-critical-part2.
>
> This is an important fix, but since we're not doing active voltage
> scaling in mainline today, I don't think it's 3.3 material.
OK, adding.
Thanks,
Tony
WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2] OMAP3+: PM: VP: fix integer truncation error
Date: Tue, 6 Mar 2012 16:13:11 -0800 [thread overview]
Message-ID: <20120307001311.GB12083@atomide.com> (raw)
In-Reply-To: <87hay1b7i0.fsf@ti.com>
* Kevin Hilman <khilman@ti.com> [120306 15:33]:
> Nishanth Menon <nm@ti.com> writes:
>
> > From: Yuan Jiangli <jlyuan@motorola.com>
> >
> > commit 2f34ce81b8c05c900e45bd88595cc154f7bb5957
> > (OMAP3: PM: Adding voltage driver support.)
> > introduced runtime computation of waittime to handle all potential
> > sys clocks available.
> >
> > In the voltage processor, the SPMSUpdateWait is calculated based on
> > the slew rate and the voltage step (SMPSUpdateWait = slew rate *
> > Voltage Step). After the voltage processor receives the SMPS_Ack
> > signal, the Voltage Controller will wait for SMPSUpdateWait clock
> > cycles for the voltage to settle to the new value. For all
> > practical purposes, the waittime parameter is the OMAP hardware
> > translation of what the slew rate on the PMIC is.
> >
> > As an example, with TPS62361 on OMAP4460,
> > step_size = 10000
> > slew_rate = 32000
> > sys_clk_rate = 38400
> >
> > Our current computation results in the following:
> > = ((step_size / slew_rate) * sys_clk_rate) / 1000
> > = ((10000 / 32000) * 38400 / 1000
> > = 0
> >
> > Fix the same using DIV_ROUND_UP as an extra wait clock cycle
> > is better than lesser clock cycle. For the above example, this
> > translates to:
> > = (10000 * 38400) / (1000 * 32000)
> > = 12
> >
> > Acked-by: Jon Hunter <jon-hunter@ti.com>
> > [nm at ti.com: slightly better implementation]
> > Signed-off-by: Nishanth Menon <nm@ti.com>
> > Signed-off-by: Yuan Jiangli <jlyuan@motorola.com>
>
> Acked-by: Kevin Hilman <khilman@ti.com>
>
> Tony, I don't have any more PM fixes for this cycle, so feel free to add
> this to fixes-non-critical-part2.
>
> This is an important fix, but since we're not doing active voltage
> scaling in mainline today, I don't think it's 3.3 material.
OK, adding.
Thanks,
Tony
next prev parent reply other threads:[~2012-03-07 0:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-06 18:51 [PATCH V2] OMAP3+: PM: VP: fix integer truncation error Nishanth Menon
2012-03-06 18:51 ` Nishanth Menon
2012-03-07 0:05 ` Kevin Hilman
2012-03-07 0:05 ` Kevin Hilman
2012-03-07 0:13 ` Tony Lindgren [this message]
2012-03-07 0:13 ` Tony Lindgren
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=20120307001311.GB12083@atomide.com \
--to=tony@atomide.com \
--cc=jlyuan@motorola.com \
--cc=jon-hunter@ti.com \
--cc=khilman@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=nm@ti.com \
/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.