From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
To: Lucas Stach <dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
Cc: linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Thierry Reding
<thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org>,
Mark Zhang <nvmarkzhang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH 1/3] ARM: tegra: add EMC clock scaling API
Date: Mon, 17 Dec 2012 14:23:29 -0700 [thread overview]
Message-ID: <50CF8D51.6020208@wwwdotorg.org> (raw)
In-Reply-To: <1355516086-11116-2-git-send-email-dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
On 12/14/2012 01:14 PM, Lucas Stach wrote:
> This allows memory clients to collaboratively control the EMC
> performance.
> Each client may set its performance demands. EMC driver then tries to
> find a DRAM performance level which is able to statisfy all those
> demands.
> diff --git a/arch/arm/mach-tegra/tegra2_emc.c b/arch/arm/mach-tegra/tegra2_emc.c
> +struct emc_superclient_constraint {
Why "superclient" not just "client"?
> +static struct emc_superclient_constraint constraints[TEGRA_EMC_SC_NUM];
This way, the EMC driver must know all the possible clients. Wouldn't it
be better to maintain some kind of dynamic list/... so drivers can just
add/remove to/from this list. I'm not familiar with other
perf/constraints APIs already in the kernel, but I /think/ that's how
they tend to work. This would also mean not having to update the EMC
driver for new Tegra SoCs if all that changed was the set of clients
attached to the EMC.
> +static void tegra_emc_scale_clock(void)
> + clock_rate = bandwidth_floor >> 2; /* 4byte/clock */
That assumes a 32-bit SDRAM interface. I'm sure that won't always be
true. Perhaps we should invent a #define for this so it stands out
slightly more if/when this needs to change later.
> + switch (highest_level) {
> + case TEGRA_EMC_PL_MID:
> + clock_rate += 300000000;
> + break;
> + case TEGRA_EMC_PL_HIGH:
> + clock_rate += 600000000;
> + break;
> + default:
> + break;
> + }
> +
> + /* cap clock_rate at 600MHz, enough to select highest rate table */
> + clock_rate = min(600000000UL, clock_rate);
I think we should parameterize the 600MHz max clock rate, and perhaps
even get it from some kind of clk_get_max_rate() API; this 600MHz value
is highly unlikely to be invariant across SoC versions.
> +void tegra_emc_request_bandwidth(enum tegra_emc_superclient client,
> + int bandwidth)
> +{
> + constraints[client].bandwidth = bandwidth;
> +
> + tegra_emc_scale_clock();
Locking?
> +void tegra_emc_request_perf_level(enum tegra_emc_superclient client,
> + enum tegra_emc_perf_level level)
> +{
> + constraints[client].perf_level = level;
> +
> + tegra_emc_scale_clock();
Locking?
> static struct tegra_emc_pdata __devinit *tegra_emc_fill_pdata(struct platform_device *pdev)
> + emc_clk = clk_get_sys(NULL, "emc");
Is there a devm_clk_get_sys()? That would avoid the need to add
tegra_emc_remove().
Can we use (devm_)clk_get() instead, so we don't have to hard-code clock
names? That will help when clocks are in DT.
> diff --git a/include/memory/tegra_emc_performance.h b/include/memory/tegra_emc_performance.h
tegra_emc.h seems a better/shorter name.
BTW, did you check our downstream Android kernel to see what we already
have for EMC scaling constraints? It might provide some useful
ideas/background.
next prev parent reply other threads:[~2012-12-17 21:23 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-14 20:14 [PATCH 0/3] Tegra EMC clock scaling API Lucas Stach
[not found] ` <1355516086-11116-1-git-send-email-dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
2012-12-14 20:14 ` [PATCH 1/3] ARM: tegra: add " Lucas Stach
[not found] ` <1355516086-11116-2-git-send-email-dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
2012-12-17 11:08 ` Mark Zhang
[not found] ` <50CEFD28.7080601-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-12-17 11:18 ` Mark Zhang
[not found] ` <50CEFF8B.5030901-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-12-17 11:23 ` Lucas Stach
2012-12-17 11:22 ` Lucas Stach
2012-12-18 8:09 ` Mark Zhang
[not found] ` <50D024B7.400-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-12-18 9:11 ` Lucas Stach
2012-12-18 11:50 ` Mark Zhang
[not found] ` <50D05891.3070006-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-12-18 12:02 ` Lucas Stach
2012-12-19 3:21 ` Mark Zhang
2012-12-17 21:23 ` Stephen Warren [this message]
[not found] ` <50CF8D51.6020208-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-12-17 21:43 ` Lucas Stach
2012-12-17 21:57 ` Stephen Warren
2012-12-14 20:14 ` [PATCH 2/3] ARM: tegra: use new EMC clock scaling API in CPUfreq driver Lucas Stach
2012-12-14 20:14 ` [PATCH 3/3] ARM: tegra: drm: use new EMC clock scaling API to reserve DC bandwidth Lucas Stach
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=50CF8D51.6020208@wwwdotorg.org \
--to=swarren-3lzwwm7+weoh9zmkesr00q@public.gmane.org \
--cc=dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=nvmarkzhang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@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.