From: Romit Dasgupta <romit@ti.com>
To: "Menon, Nishanth" <nm@ti.com>
Cc: linux-omap <linux-omap@vger.kernel.org>,
Ameya Palande <ameya.palande@nokia.com>,
"Chitriki Rudramuni, Deepak" <deepak.chitriki@ti.com>,
Felipe Contreras <felipe.contreras@nokia.com>,
Hiroshi Doyu <hiroshi.doyu@nokia.com>,
"Ramirez Luna, Omar" <omar.ramirez@ti.com>
Subject: Re: [PATCH 2/2] DSPBRIDGE: pm: use old implementation for opps
Date: Thu, 21 Jan 2010 13:08:19 +0530 [thread overview]
Message-ID: <4B58046B.9040804@ti.com> (raw)
In-Reply-To: <1264025953-4620-3-git-send-email-nm@ti.com>
>
> arch/arm/mach-omap2/dspbridge.c | 59 ++++++++++++++++++++++++++++++++++++++-
> 1 files changed, 58 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/dspbridge.c b/arch/arm/mach-omap2/dspbridge.c
> index 26b860f..120d8a2 100644
> --- a/arch/arm/mach-omap2/dspbridge.c
> +++ b/arch/arm/mach-omap2/dspbridge.c
> @@ -42,7 +42,64 @@ static struct dspbridge_platform_data dspbridge_pdata __initdata = {
> static int get_opp_table(struct dspbridge_platform_data *pdata)
> {
> #ifdef CONFIG_BRIDGE_DVFS
> - /* Do nothing now - fill based on PM implementation */
> + /* legacy values for 3430 */
> + u32 vdd1_dsp_freq[6][4] = {
> + {0, 0, 0, 0},
> + /*OPP1*/
> + {0, 90000, 0, 86000},
> + /*OPP2*/
> + {0, 180000, 80000, 170000},
> + /*OPP3*/
> + {0, 360000, 160000, 340000},
> + /*OPP4*/
> + {0, 396000, 325000, 376000},
> + /*OPP5*/
> + {0, 430000, 355000, 430000},
> + };
> + struct omap_opp vdd1_rate_table_bridge[] = {
> + {0, 0, 0},
> + /*OPP1*/
> + {S125M, VDD1_OPP1, 0},
> + /*OPP2*/
> + {S250M, VDD1_OPP2, 0},
> + /*OPP3*/
> + {S500M, VDD1_OPP3, 0},
> + /*OPP4*/
> + {S550M, VDD1_OPP4, 0},
> + /*OPP5*/
> + {S600M, VDD1_OPP5, 0},
> + };
> + pdata->dsp_num_speeds = VDD1_OPP5;
Why dont you use ARRAY_SIZE - 1 ?
> + pdata->mpu_speeds = kzalloc(sizeof(u32) * pdata->dsp_num_speeds,
> + GFP_KERNEL);
I understand pdata->dsp_num_speeds == pdata->mpu_num_speeds. But don't you think
passing pdata->mpu_num_speeds makes more sense here?
> + if (!pdata->mpu_speeds) {
> + pr_err("unable to allocate memory for the mpu"
> + "frequencies\n");
> + return -ENOMEM;
> + }
As I mentioned in my earlier email. You return to the caller here but you free
pdata->dsp_freq_table in the caller even if pdata->dsp_freq_table is not allocated.
> + pdata->dsp_freq_table = kzalloc(
> + sizeof(struct dsp_shm_freq_table) *
> + (pdata->dsp_num_speeds + 1), GFP_KERNEL);
> + if (!pdata->dsp_freq_table) {
> + pr_err("unable to allocate memory for the dsp"
> + "frequencies\n");
> + return -ENOMEM;
> + }
> + for (i = 0; i < 6; i++)
Why are you hard coding numeric 6 here?
> + pdata->mpu_speed[i] = vdd1_rate_table_bridge[i].rate;
> + pdata->mpu_max_speed = pdata->mpu_speed[VDD1_OPP5];
You can use ARRAY_SIZE.
> + pdata->mpu_min_speed = pdata->mpu_speed[VDD1_OPP1];
> + pdata->dsp_num_speeds = VDD1_OPP5;
Same..ARRAY_SIZE...
> + for (i = 0; i <= pdata->dsp_num_speeds; i++) {
> + pdata->dsp_freq_table[i].u_volts =
> + vdd1_dsp_freq[i][0];
> + frequency = pdata->dsp_freq_table[i].dsp_freq =
> + frequency = vdd1_dsp_freq[i][1];
> + pdata->dsp_freq_table[i].thresh_min_freq =
> + vdd1_dsp_freq[i][2];
> + pdata->dsp_freq_table[i].thresh_max_freq =
> + vdd1_dsp_freq[i][3];
> + }
> #endif
> return 0;
> }
next prev parent reply other threads:[~2010-01-21 7:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-20 22:19 [PATCH 0/2] DSPBRIDGE: cleanup OPP handling Nishanth Menon
2010-01-20 22:19 ` [PATCH 1/2] DSPBRIDGE: remove dependency of mpu freq Nishanth Menon
2010-01-20 22:19 ` [PATCH 2/2] DSPBRIDGE: pm: use old implementation for opps Nishanth Menon
2010-01-20 22:19 ` [RFC] [PATCH 2/2] DSPBRIDGE: pm: use pm-wip-opp APIs for opp list Nishanth Menon
2010-01-21 7:58 ` Romit Dasgupta
2010-01-21 7:59 ` Nishanth Menon
2010-01-21 7:38 ` Romit Dasgupta [this message]
2010-01-21 7:47 ` [PATCH 2/2] DSPBRIDGE: pm: use old implementation for opps Nishanth Menon
2010-01-21 7:38 ` [PATCH 1/2] DSPBRIDGE: remove dependency of mpu freq Romit Dasgupta
2010-01-21 7:40 ` Romit Dasgupta
2010-01-21 7:42 ` Nishanth Menon
2010-01-21 7:45 ` Romit Dasgupta
2010-01-21 7:48 ` Nishanth Menon
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=4B58046B.9040804@ti.com \
--to=romit@ti.com \
--cc=ameya.palande@nokia.com \
--cc=deepak.chitriki@ti.com \
--cc=felipe.contreras@nokia.com \
--cc=hiroshi.doyu@nokia.com \
--cc=linux-omap@vger.kernel.org \
--cc=nm@ti.com \
--cc=omar.ramirez@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.