From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
To: Joseph Lo <josephl-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cc: linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH 04/10] ARM: tegra: pm: add platform suspend support
Date: Tue, 05 Mar 2013 11:45:37 -0700 [thread overview]
Message-ID: <51363D51.6000908@wwwdotorg.org> (raw)
In-Reply-To: <1362397218-5675-1-git-send-email-josephl-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On 03/04/2013 04:40 AM, Joseph Lo wrote:
> Adding suspend to ram support for Tegra platform. There are three suspend
nit: s/ram/RAM/
> mode for Tegra. The difference were below.
Does this patch work for all 3 upstream Tegras, or just Tegra20 (or 20+30?).
> diff --git a/arch/arm/mach-tegra/common.c b/arch/arm/mach-tegra/common.c
> + tegra_init_suspend();
That call isn't ifdef'd on anything ...
> diff --git a/arch/arm/mach-tegra/pm.c b/arch/arm/mach-tegra/pm.c
> +static void tegra_suspend_enter_lp2(void)
> +{
> + tegra_set_cpu_in_lp2(0);
> +}
> +
> +static void tegra_suspend_exit_lp2(void)
> +{
> + tegra_clear_cpu_in_lp2(0);
> +}
Are those two functions going to get larger? If not, why not just call
tegra_{set,clear}_cpu_in_lp2() from tegra_suspend_enter()?
Note: I realized that the LP0/LP1 functions might be larger, and feel
free to make them separate functions when they're implemented, but if
those two functions specifically are always going to be a single line,
then there's little point in separating them out, is there?
> +void __init tegra_init_suspend(void)
...
> #endif
... but this function is only implemented inside an ifdef ...
> diff --git a/arch/arm/mach-tegra/pm.h b/arch/arm/mach-tegra/pm.h
> +void tegra_init_suspend(void);
... and no dummy inline is provided if the ifdef isn't defined.
So, turning off whatever that ifdef is would cause a build error.
> diff --git a/arch/arm/mach-tegra/pmc.c b/arch/arm/mach-tegra/pmc.c
> +unsigned long tegra_pmc_get_cpu_timer(void)
...
> +unsigned long tegra_pmc_get_cpu_off_timer(void)
I think you want to make those return u32, since the values they return
should be u32 to match DT cell type.
> +void tegra_pmc_pm_set(enum tegra_suspend_mode mode)
> +{
> + u32 reg;
> +
> + reg = tegra_pmc_readl(PMC_CTRL);
> + reg |= TEGRA_POWER_CPU_PWRREQ_OE;
> + reg &= ~TEGRA_POWER_EFFECT_LP0;
> +
> + tegra_pmc_writel(reg, PMC_CTRL);
> +}
The "mode" parameter doesn't seem to be used here.
One overall comment: tegra_suspend_enter() only supports LP2 so far, but
I don't see a check anywhere (e.g. tegra_init_suspend() or
tegra_pmc_parse_dt()) which prevents suspend from being initialized if
the user requested some other type, or on SoCs where even LP2 isn't
supported yet (e.g. Tegra114).
WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 04/10] ARM: tegra: pm: add platform suspend support
Date: Tue, 05 Mar 2013 11:45:37 -0700 [thread overview]
Message-ID: <51363D51.6000908@wwwdotorg.org> (raw)
In-Reply-To: <1362397218-5675-1-git-send-email-josephl@nvidia.com>
On 03/04/2013 04:40 AM, Joseph Lo wrote:
> Adding suspend to ram support for Tegra platform. There are three suspend
nit: s/ram/RAM/
> mode for Tegra. The difference were below.
Does this patch work for all 3 upstream Tegras, or just Tegra20 (or 20+30?).
> diff --git a/arch/arm/mach-tegra/common.c b/arch/arm/mach-tegra/common.c
> + tegra_init_suspend();
That call isn't ifdef'd on anything ...
> diff --git a/arch/arm/mach-tegra/pm.c b/arch/arm/mach-tegra/pm.c
> +static void tegra_suspend_enter_lp2(void)
> +{
> + tegra_set_cpu_in_lp2(0);
> +}
> +
> +static void tegra_suspend_exit_lp2(void)
> +{
> + tegra_clear_cpu_in_lp2(0);
> +}
Are those two functions going to get larger? If not, why not just call
tegra_{set,clear}_cpu_in_lp2() from tegra_suspend_enter()?
Note: I realized that the LP0/LP1 functions might be larger, and feel
free to make them separate functions when they're implemented, but if
those two functions specifically are always going to be a single line,
then there's little point in separating them out, is there?
> +void __init tegra_init_suspend(void)
...
> #endif
... but this function is only implemented inside an ifdef ...
> diff --git a/arch/arm/mach-tegra/pm.h b/arch/arm/mach-tegra/pm.h
> +void tegra_init_suspend(void);
... and no dummy inline is provided if the ifdef isn't defined.
So, turning off whatever that ifdef is would cause a build error.
> diff --git a/arch/arm/mach-tegra/pmc.c b/arch/arm/mach-tegra/pmc.c
> +unsigned long tegra_pmc_get_cpu_timer(void)
...
> +unsigned long tegra_pmc_get_cpu_off_timer(void)
I think you want to make those return u32, since the values they return
should be u32 to match DT cell type.
> +void tegra_pmc_pm_set(enum tegra_suspend_mode mode)
> +{
> + u32 reg;
> +
> + reg = tegra_pmc_readl(PMC_CTRL);
> + reg |= TEGRA_POWER_CPU_PWRREQ_OE;
> + reg &= ~TEGRA_POWER_EFFECT_LP0;
> +
> + tegra_pmc_writel(reg, PMC_CTRL);
> +}
The "mode" parameter doesn't seem to be used here.
One overall comment: tegra_suspend_enter() only supports LP2 so far, but
I don't see a check anywhere (e.g. tegra_init_suspend() or
tegra_pmc_parse_dt()) which prevents suspend from being initialized if
the user requested some other type, or on SoCs where even LP2 isn't
supported yet (e.g. Tegra114).
next prev parent reply other threads:[~2013-03-05 18:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-04 11:40 [PATCH 04/10] ARM: tegra: pm: add platform suspend support Joseph Lo
2013-03-04 11:40 ` Joseph Lo
[not found] ` <1362397218-5675-1-git-send-email-josephl-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-03-05 18:45 ` Stephen Warren [this message]
2013-03-05 18:45 ` Stephen Warren
[not found] ` <51363D51.6000908-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-03-07 10:59 ` Joseph Lo
2013-03-07 10:59 ` Joseph Lo
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=51363D51.6000908@wwwdotorg.org \
--to=swarren-3lzwwm7+weoh9zmkesr00q@public.gmane.org \
--cc=josephl-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@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.