From: James Liao <jamesjj.liao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
To: "Heiko Stübner" <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Mike Turquette
<mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org,
Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Ricky Liang <jcliang-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Sascha Hauer <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
Matthias Brugger
<matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH] clk: mediatek: Add MT8173 MMPLL change rate support
Date: Tue, 7 Jul 2015 17:48:45 +0800 [thread overview]
Message-ID: <1436262525.3526.103.camel@mtksdaap41> (raw)
In-Reply-To: <1618189.7QkIIkOn1c@diego>
Hi Heiko,
On Tue, 2015-07-07 at 11:34 +0200, Heiko Stübner wrote:
> > > > @@ -135,16 +138,26 @@ static void mtk_pll_calc_values(struct mtk_clk_pll
> > > > *pll, u32 *pcw, u32 *postdiv, u32 freq, u32 fin)
> > > >
> > > > {
> > > >
> > > > unsigned long fmin = 1000 * MHZ;
> > > >
> > > > + const unsigned long *div_rate = pll->data->div_rate;
> > > >
> > > > u64 _pcw;
> > > > u32 val;
> > > >
> > > > if (freq > pll->data->fmax)
> > > >
> > > > freq = pll->data->fmax;
> > > >
> > > > - for (val = 0; val < 4; val++) {
> > > > + if (div_rate) {
> > > > + for (val = 1; div_rate[val] != 0; val++) {
> > > > + if (freq > div_rate[val])
> > > > + break;
> > > > + }
> > > > + val--;
> > >
> > > if you're changing the table struct, this of course also would need to be
> > > adapted.
> > >
> > >
> > > Hmm, what I don't understand is, what does MT8173_PLL_FMAX in the table,
> > > if
> > > you ignore it here all the time?
> > >
> > > So the table should probably look more like [when using the concept from
> > > above]
> > >
> > > static const struct mtk_pll_div_table mmpll_div_rate[] = {
> > >
> > > { .freq = 1000000000, .div = 0 },
> > > { .freq = 702000000, .div = 1 },
> > > { .freq = 253500000, .div = 2 },
> > > { .freq = 126750000, .div = 3 },
> > > { /* sentinel */ },
> > >
> > > };
> >
> > The freq-div table describes the maximum frequency of each divider
> > setting. Although the first element doesn't used in current
> > implementation, I think it's better to keep freq-div table's
> > completeness.
>
> the issue I see is, that its value is currently 0 and the code substracts 1.
> So if anything would (accidentially) select MT8173_PLL_FMAX, the u32 val would
> wrap around, as you're subtracting 1 from 0 .
Subtracting 1 from val is safe now because it starts from 1:
for (val = 1; div_rate[val] != 0; val++) {
...
}
val--;
I can change this implementation to a more readable one such as:
for (val = 0; div_rate[val + 1] != 0; val++) {
if (freq <= div_rate[val] && freq > div_rate[val + 1]) {
...
Do you think it is OK?
Best regards,
James
--
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: jamesjj.liao@mediatek.com (James Liao)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] clk: mediatek: Add MT8173 MMPLL change rate support
Date: Tue, 7 Jul 2015 17:48:45 +0800 [thread overview]
Message-ID: <1436262525.3526.103.camel@mtksdaap41> (raw)
In-Reply-To: <1618189.7QkIIkOn1c@diego>
Hi Heiko,
On Tue, 2015-07-07 at 11:34 +0200, Heiko St?bner wrote:
> > > > @@ -135,16 +138,26 @@ static void mtk_pll_calc_values(struct mtk_clk_pll
> > > > *pll, u32 *pcw, u32 *postdiv, u32 freq, u32 fin)
> > > >
> > > > {
> > > >
> > > > unsigned long fmin = 1000 * MHZ;
> > > >
> > > > + const unsigned long *div_rate = pll->data->div_rate;
> > > >
> > > > u64 _pcw;
> > > > u32 val;
> > > >
> > > > if (freq > pll->data->fmax)
> > > >
> > > > freq = pll->data->fmax;
> > > >
> > > > - for (val = 0; val < 4; val++) {
> > > > + if (div_rate) {
> > > > + for (val = 1; div_rate[val] != 0; val++) {
> > > > + if (freq > div_rate[val])
> > > > + break;
> > > > + }
> > > > + val--;
> > >
> > > if you're changing the table struct, this of course also would need to be
> > > adapted.
> > >
> > >
> > > Hmm, what I don't understand is, what does MT8173_PLL_FMAX in the table,
> > > if
> > > you ignore it here all the time?
> > >
> > > So the table should probably look more like [when using the concept from
> > > above]
> > >
> > > static const struct mtk_pll_div_table mmpll_div_rate[] = {
> > >
> > > { .freq = 1000000000, .div = 0 },
> > > { .freq = 702000000, .div = 1 },
> > > { .freq = 253500000, .div = 2 },
> > > { .freq = 126750000, .div = 3 },
> > > { /* sentinel */ },
> > >
> > > };
> >
> > The freq-div table describes the maximum frequency of each divider
> > setting. Although the first element doesn't used in current
> > implementation, I think it's better to keep freq-div table's
> > completeness.
>
> the issue I see is, that its value is currently 0 and the code substracts 1.
> So if anything would (accidentially) select MT8173_PLL_FMAX, the u32 val would
> wrap around, as you're subtracting 1 from 0 .
Subtracting 1 from val is safe now because it starts from 1:
for (val = 1; div_rate[val] != 0; val++) {
...
}
val--;
I can change this implementation to a more readable one such as:
for (val = 0; div_rate[val + 1] != 0; val++) {
if (freq <= div_rate[val] && freq > div_rate[val + 1]) {
...
Do you think it is OK?
Best regards,
James
WARNING: multiple messages have this Message-ID (diff)
From: James Liao <jamesjj.liao@mediatek.com>
To: "Heiko Stübner" <heiko@sntech.de>
Cc: <devicetree@vger.kernel.org>,
Mike Turquette <mturquette@linaro.org>,
<srv_heupstream@mediatek.com>,
Stephen Boyd <sboyd@codeaurora.org>,
<linux-kernel@vger.kernel.org>,
Ricky Liang <jcliang@chromium.org>,
"Rob Herring" <robh+dt@kernel.org>,
<linux-mediatek@lists.infradead.org>,
"Sascha Hauer" <kernel@pengutronix.de>,
Matthias Brugger <matthias.bgg@gmail.com>,
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] clk: mediatek: Add MT8173 MMPLL change rate support
Date: Tue, 7 Jul 2015 17:48:45 +0800 [thread overview]
Message-ID: <1436262525.3526.103.camel@mtksdaap41> (raw)
In-Reply-To: <1618189.7QkIIkOn1c@diego>
Hi Heiko,
On Tue, 2015-07-07 at 11:34 +0200, Heiko Stübner wrote:
> > > > @@ -135,16 +138,26 @@ static void mtk_pll_calc_values(struct mtk_clk_pll
> > > > *pll, u32 *pcw, u32 *postdiv, u32 freq, u32 fin)
> > > >
> > > > {
> > > >
> > > > unsigned long fmin = 1000 * MHZ;
> > > >
> > > > + const unsigned long *div_rate = pll->data->div_rate;
> > > >
> > > > u64 _pcw;
> > > > u32 val;
> > > >
> > > > if (freq > pll->data->fmax)
> > > >
> > > > freq = pll->data->fmax;
> > > >
> > > > - for (val = 0; val < 4; val++) {
> > > > + if (div_rate) {
> > > > + for (val = 1; div_rate[val] != 0; val++) {
> > > > + if (freq > div_rate[val])
> > > > + break;
> > > > + }
> > > > + val--;
> > >
> > > if you're changing the table struct, this of course also would need to be
> > > adapted.
> > >
> > >
> > > Hmm, what I don't understand is, what does MT8173_PLL_FMAX in the table,
> > > if
> > > you ignore it here all the time?
> > >
> > > So the table should probably look more like [when using the concept from
> > > above]
> > >
> > > static const struct mtk_pll_div_table mmpll_div_rate[] = {
> > >
> > > { .freq = 1000000000, .div = 0 },
> > > { .freq = 702000000, .div = 1 },
> > > { .freq = 253500000, .div = 2 },
> > > { .freq = 126750000, .div = 3 },
> > > { /* sentinel */ },
> > >
> > > };
> >
> > The freq-div table describes the maximum frequency of each divider
> > setting. Although the first element doesn't used in current
> > implementation, I think it's better to keep freq-div table's
> > completeness.
>
> the issue I see is, that its value is currently 0 and the code substracts 1.
> So if anything would (accidentially) select MT8173_PLL_FMAX, the u32 val would
> wrap around, as you're subtracting 1 from 0 .
Subtracting 1 from val is safe now because it starts from 1:
for (val = 1; div_rate[val] != 0; val++) {
...
}
val--;
I can change this implementation to a more readable one such as:
for (val = 0; div_rate[val + 1] != 0; val++) {
if (freq <= div_rate[val] && freq > div_rate[val + 1]) {
...
Do you think it is OK?
Best regards,
James
next prev parent reply other threads:[~2015-07-07 9:48 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-02 5:26 [PATCH] clk: mediatek: Add MT8173 MMPLL change rate support James Liao
2015-06-02 5:26 ` James Liao
2015-06-02 5:26 ` James Liao
2015-07-07 7:17 ` James Liao
2015-07-07 7:17 ` James Liao
2015-07-07 7:17 ` James Liao
[not found] ` <1433222760-5924-1-git-send-email-jamesjj.liao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2015-07-07 8:58 ` Heiko Stübner
2015-07-07 8:58 ` Heiko Stübner
2015-07-07 8:58 ` Heiko Stübner
2015-07-07 9:28 ` James Liao
2015-07-07 9:28 ` James Liao
2015-07-07 9:28 ` James Liao
2015-07-07 9:34 ` Heiko Stübner
2015-07-07 9:34 ` Heiko Stübner
2015-07-07 9:48 ` James Liao [this message]
2015-07-07 9:48 ` James Liao
2015-07-07 9:48 ` James Liao
2015-07-07 10:46 ` Heiko Stübner
2015-07-07 10:46 ` Heiko Stübner
2015-07-07 10:46 ` Heiko Stübner
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=1436262525.3526.103.camel@mtksdaap41 \
--to=jamesjj.liao-nus5lvnupcjwk0htik3j/w@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org \
--cc=jcliang-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
--cc=srv_heupstream-NuS5LvNUpcJWk0Htik3J/w@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.