All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joseph Lo <josephl@nvidia.com>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: "linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 4/8] ARM: tegra: add common LP1 suspend support
Date: Mon, 5 Aug 2013 16:07:15 +0800	[thread overview]
Message-ID: <1375690035.1731.41.camel@jlo-ubuntu-64.nvidia.com> (raw)
In-Reply-To: <51FC1926.9030103@wwwdotorg.org>

On Sat, 2013-08-03 at 04:40 +0800, Stephen Warren wrote:
> On 08/02/2013 03:27 AM, Joseph Lo wrote:
> > On Tue, 2013-07-30 at 07:13 +0800, Stephen Warren wrote:
> >> On 07/26/2013 03:15 AM, Joseph Lo wrote:
> >>> The LP1 suspending mode on Tegra means CPU rail off, devices and PLLs are
> >>> clock gated and SDRAM in self-refresh mode. That means the low level LP1
> >>> suspending and resuming code couldn't be run on DRAM and the CPU must
> >>> switch to the always on clock domain (a.k.a. CLK_M 12MHz oscillator). And
> >>> the system clock (SCLK) would be switched to CLK_S, a 32KHz oscillator.
> >>> The LP1 low level handling code need to be moved to IRAM area first. And
> >>> marking the LP1 mask for indicating the Tegra device is in LP1. The CPU
> >>> power timer needs to be re-calculated based on 32KHz that was originally
> >>> based on PCLK.
> >>
> >>> diff --git a/arch/arm/mach-tegra/pm.c b/arch/arm/mach-tegra/pm.c
> >>
> >>>  #ifdef CONFIG_PM_SLEEP
> >>>  static DEFINE_SPINLOCK(tegra_lp2_lock);
> >>> +static void __iomem *iram_code = IO_ADDRESS(TEGRA_IRAM_CODE_AREA);
> >>> +static u32 iram_save_size;
> >>> +static void *iram_save_addr;
> >>> +struct tegra_lp1_iram *tegra_lp1_iram;
> >>>  void (*tegra_tear_down_cpu)(void);
> >>> +void (*tegra_sleep_core_finish)(unsigned long v2p);
> >>
> >> I'm not sure all of those are required to be global variables. For
> >> example, iram_code is just a constant, so you could easily just use it
> >> directly in code.
> >
> > All of them does not mean the same thing. The LP1 resume code was built
> > in kernel image and store in RAM.
> > The tegra_lp1_iram hooks the LP1 resume code for different chips. Before
> > LP1 suspend, the original stuffs that in the area of IRAM would be store
> > in the iram_save_addr (RAM). Then copy the LP1 resume code to iram_code
> > area (IRAM).
> 
> Sure, some of those variable may differ based on the SoC at runtime etc.
> 
> But at least the value of iram_code never changes, right?
Yes.

> >>> +static void tegra_suspend_enter_lp1(void)
> >>> +{
> >>> +	tegra_pmc_suspend();
> >>> +
> >>> +	/* copy the reset vector & SDRAM shutdown code into IRAM */
> >>> +	memcpy(iram_save_addr, iram_code, iram_save_size);
> >>> +	memcpy(iram_code, tegra_lp1_iram->start_addr, iram_save_size);
> >>> +
> >>> +	*((u32 *)tegra_cpu_lp1_mask) = 1;
> >>> +}
> >>> +
> >>> +static void tegra_suspend_exit_lp1(void)
> >>> +{
> >>> +	tegra_pmc_resume();
> >>> +
> >>> +	/* restore IRAM */
> >>> +	memcpy(iram_code, iram_save_addr, iram_save_size);
> >>> +
> >>> +	*(u32 *)tegra_cpu_lp1_mask = 0;
> >>> +}
> >>
> >> I'm not really sure I like that, but I suppose it's OK. It sure seems
> >> like a performance limiter, but I suppose LP1 is so slow it doesn't
> >> matter, due to the need to ramp power rails, PLLs, SDRAM controller, etc.
> >
> > That's why we only back up the code size that exactly same with the LP1
> > resume code of the SoC.
> >
> >> It'd be nice to simply reserve more IRAM for the kernel's use. Right
> >> now, only 1K is reserved, and presumably the code running on the AVP
> >> can't use the rest of that page anyway, or can it?
> >
> > The LP1 resume code still running on the CPU (The LP0 would resume from
> > AVP).
> 
> Sure. However, if the AVP never touched the IRAM region where the LP1
> resume code is placed, we would only need to copy the LP1 resume code to
> IRAM once at kernel boot time, rather than every time we enter/leave LP1.
> 
> I guess the idea is that once we have an AVP driver, we will force the
> AVP to suspend first, save the IRAM that it might have been using, do
> the system suspend/resume, then restore the IRAM. And that changing that
> sequence so that the AVP never ever touched the LP1 IRAM area would
> require AVP firmware changes that we can't make?
Yes, exactly.

WARNING: multiple messages have this Message-ID (diff)
From: josephl@nvidia.com (Joseph Lo)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/8] ARM: tegra: add common LP1 suspend support
Date: Mon, 5 Aug 2013 16:07:15 +0800	[thread overview]
Message-ID: <1375690035.1731.41.camel@jlo-ubuntu-64.nvidia.com> (raw)
In-Reply-To: <51FC1926.9030103@wwwdotorg.org>

On Sat, 2013-08-03 at 04:40 +0800, Stephen Warren wrote:
> On 08/02/2013 03:27 AM, Joseph Lo wrote:
> > On Tue, 2013-07-30 at 07:13 +0800, Stephen Warren wrote:
> >> On 07/26/2013 03:15 AM, Joseph Lo wrote:
> >>> The LP1 suspending mode on Tegra means CPU rail off, devices and PLLs are
> >>> clock gated and SDRAM in self-refresh mode. That means the low level LP1
> >>> suspending and resuming code couldn't be run on DRAM and the CPU must
> >>> switch to the always on clock domain (a.k.a. CLK_M 12MHz oscillator). And
> >>> the system clock (SCLK) would be switched to CLK_S, a 32KHz oscillator.
> >>> The LP1 low level handling code need to be moved to IRAM area first. And
> >>> marking the LP1 mask for indicating the Tegra device is in LP1. The CPU
> >>> power timer needs to be re-calculated based on 32KHz that was originally
> >>> based on PCLK.
> >>
> >>> diff --git a/arch/arm/mach-tegra/pm.c b/arch/arm/mach-tegra/pm.c
> >>
> >>>  #ifdef CONFIG_PM_SLEEP
> >>>  static DEFINE_SPINLOCK(tegra_lp2_lock);
> >>> +static void __iomem *iram_code = IO_ADDRESS(TEGRA_IRAM_CODE_AREA);
> >>> +static u32 iram_save_size;
> >>> +static void *iram_save_addr;
> >>> +struct tegra_lp1_iram *tegra_lp1_iram;
> >>>  void (*tegra_tear_down_cpu)(void);
> >>> +void (*tegra_sleep_core_finish)(unsigned long v2p);
> >>
> >> I'm not sure all of those are required to be global variables. For
> >> example, iram_code is just a constant, so you could easily just use it
> >> directly in code.
> >
> > All of them does not mean the same thing. The LP1 resume code was built
> > in kernel image and store in RAM.
> > The tegra_lp1_iram hooks the LP1 resume code for different chips. Before
> > LP1 suspend, the original stuffs that in the area of IRAM would be store
> > in the iram_save_addr (RAM). Then copy the LP1 resume code to iram_code
> > area (IRAM).
> 
> Sure, some of those variable may differ based on the SoC at runtime etc.
> 
> But at least the value of iram_code never changes, right?
Yes.

> >>> +static void tegra_suspend_enter_lp1(void)
> >>> +{
> >>> +	tegra_pmc_suspend();
> >>> +
> >>> +	/* copy the reset vector & SDRAM shutdown code into IRAM */
> >>> +	memcpy(iram_save_addr, iram_code, iram_save_size);
> >>> +	memcpy(iram_code, tegra_lp1_iram->start_addr, iram_save_size);
> >>> +
> >>> +	*((u32 *)tegra_cpu_lp1_mask) = 1;
> >>> +}
> >>> +
> >>> +static void tegra_suspend_exit_lp1(void)
> >>> +{
> >>> +	tegra_pmc_resume();
> >>> +
> >>> +	/* restore IRAM */
> >>> +	memcpy(iram_code, iram_save_addr, iram_save_size);
> >>> +
> >>> +	*(u32 *)tegra_cpu_lp1_mask = 0;
> >>> +}
> >>
> >> I'm not really sure I like that, but I suppose it's OK. It sure seems
> >> like a performance limiter, but I suppose LP1 is so slow it doesn't
> >> matter, due to the need to ramp power rails, PLLs, SDRAM controller, etc.
> >
> > That's why we only back up the code size that exactly same with the LP1
> > resume code of the SoC.
> >
> >> It'd be nice to simply reserve more IRAM for the kernel's use. Right
> >> now, only 1K is reserved, and presumably the code running on the AVP
> >> can't use the rest of that page anyway, or can it?
> >
> > The LP1 resume code still running on the CPU (The LP0 would resume from
> > AVP).
> 
> Sure. However, if the AVP never touched the IRAM region where the LP1
> resume code is placed, we would only need to copy the LP1 resume code to
> IRAM once at kernel boot time, rather than every time we enter/leave LP1.
> 
> I guess the idea is that once we have an AVP driver, we will force the
> AVP to suspend first, save the IRAM that it might have been using, do
> the system suspend/resume, then restore the IRAM. And that changing that
> sequence so that the AVP never ever touched the LP1 IRAM area would
> require AVP firmware changes that we can't make?
Yes, exactly.

  reply	other threads:[~2013-08-05  8:07 UTC|newest]

Thread overview: 88+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-26  9:15 [PATCH 0/8] ARM: tegra: support LP1 suspend mode Joseph Lo
2013-07-26  9:15 ` Joseph Lo
     [not found] ` <1374830110-30685-1-git-send-email-josephl-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-07-26  9:15   ` [PATCH 1/8] ARM: tegra: add common resume handling code for LP1 resuming Joseph Lo
2013-07-26  9:15     ` Joseph Lo
     [not found]     ` <1374830110-30685-2-git-send-email-josephl-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-07-29 22:38       ` Stephen Warren
2013-07-29 22:38         ` Stephen Warren
2013-07-26  9:15   ` [PATCH 2/8] ARM: tegra: config the polarity of the request of sys clock Joseph Lo
2013-07-26  9:15     ` Joseph Lo
     [not found]     ` <1374830110-30685-3-git-send-email-josephl-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-07-29 22:47       ` Stephen Warren
2013-07-29 22:47         ` Stephen Warren
     [not found]         ` <51F6F109.8010102-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-08-02  7:48           ` Joseph Lo
2013-08-02  7:48             ` Joseph Lo
     [not found]             ` <1375429739.6761.31.camel-yx3yKKdKkHfc7b1ADBJPm0n48jw8i0AO@public.gmane.org>
2013-08-02 20:24               ` Stephen Warren
2013-08-02 20:24                 ` Stephen Warren
     [not found]                 ` <51FC1579.50100-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-08-05  8:42                   ` Joseph Lo
2013-08-05  8:42                     ` Joseph Lo
2013-07-26  9:15   ` [PATCH 3/8] clk: tegra114: add LP1 suspend/resume support Joseph Lo
2013-07-26  9:15     ` Joseph Lo
     [not found]     ` <1374830110-30685-4-git-send-email-josephl-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-07-29 22:51       ` Stephen Warren
2013-07-29 22:51         ` Stephen Warren
     [not found]         ` <51F6F209.2090309-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-08-02  8:09           ` Joseph Lo
2013-08-02  8:09             ` Joseph Lo
     [not found]             ` <1375430985.6761.51.camel-yx3yKKdKkHfc7b1ADBJPm0n48jw8i0AO@public.gmane.org>
2013-08-02 20:32               ` Stephen Warren
2013-08-02 20:32                 ` Stephen Warren
     [not found]                 ` <51FC1751.9010401-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-08-05  8:02                   ` Joseph Lo
2013-08-05  8:02                     ` Joseph Lo
     [not found]                     ` <1375689749.1731.36.camel-yx3yKKdKkHfc7b1ADBJPm0n48jw8i0AO@public.gmane.org>
2013-08-05 17:00                       ` Stephen Warren
2013-08-05 17:00                         ` Stephen Warren
     [not found]                         ` <51FFDA20.6050403-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-08-05 17:39                           ` Stephen Warren
2013-08-05 17:39                             ` Stephen Warren
     [not found]                             ` <51FFE363.4080603-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-08-06  9:10                               ` Joseph Lo
2013-08-06  9:10                                 ` Joseph Lo
     [not found]                                 ` <1375780249.2261.63.camel-yx3yKKdKkHfc7b1ADBJPm0n48jw8i0AO@public.gmane.org>
2013-08-06 18:37                                   ` Stephen Warren
2013-08-06 18:37                                     ` Stephen Warren
     [not found]                                     ` <52014258.9070602-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-08-07  9:12                                       ` Joseph Lo
2013-08-07  9:12                                         ` Joseph Lo
     [not found]                                         ` <1375866749.8111.57.camel-yx3yKKdKkHfc7b1ADBJPm0n48jw8i0AO@public.gmane.org>
2013-08-07 16:46                                           ` Stephen Warren
2013-08-07 16:46                                             ` Stephen Warren
     [not found]                                             ` <520279FC.1000006-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-08-08  2:23                                               ` Joseph Lo
2013-08-08  2:23                                                 ` Joseph Lo
     [not found]                                                 ` <1375928591.1758.66.camel-yx3yKKdKkHfc7b1ADBJPm0n48jw8i0AO@public.gmane.org>
2013-08-08 19:54                                                   ` Stephen Warren
2013-08-08 19:54                                                     ` Stephen Warren
     [not found]                                                     ` <5203F766.9050100-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-08-09  9:23                                                       ` Joseph Lo
2013-08-09  9:23                                                         ` Joseph Lo
2013-08-06  9:19                           ` Joseph Lo
2013-08-06  9:19                             ` Joseph Lo
2013-07-26  9:15   ` [PATCH 4/8] ARM: tegra: add common LP1 suspend support Joseph Lo
2013-07-26  9:15     ` Joseph Lo
     [not found]     ` <1374830110-30685-5-git-send-email-josephl-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-07-29 23:13       ` Stephen Warren
2013-07-29 23:13         ` Stephen Warren
     [not found]         ` <51F6F725.6000106-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-08-02  9:27           ` Joseph Lo
2013-08-02  9:27             ` Joseph Lo
     [not found]             ` <1375435620.6761.120.camel-yx3yKKdKkHfc7b1ADBJPm0n48jw8i0AO@public.gmane.org>
2013-08-02 20:40               ` Stephen Warren
2013-08-02 20:40                 ` Stephen Warren
2013-08-05  8:07                 ` Joseph Lo [this message]
2013-08-05  8:07                   ` Joseph Lo
2013-07-26  9:15   ` [PATCH 5/8] ARM: tegra30: add " Joseph Lo
2013-07-26  9:15     ` Joseph Lo
     [not found]     ` <1374830110-30685-6-git-send-email-josephl-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-07-29 23:45       ` Stephen Warren
2013-07-29 23:45         ` Stephen Warren
     [not found]         ` <51F6FE89.4060402-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-08-05  6:46           ` Joseph Lo
2013-08-05  6:46             ` Joseph Lo
2013-07-26  9:15   ` [PATCH 6/8] ARM: tegra20: " Joseph Lo
2013-07-26  9:15     ` Joseph Lo
2013-07-26  9:15   ` [PATCH 7/8] ARM: tegra114: " Joseph Lo
2013-07-26  9:15     ` Joseph Lo
     [not found]     ` <1374830110-30685-8-git-send-email-josephl-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-07-29 23:53       ` Stephen Warren
2013-07-29 23:53         ` Stephen Warren
     [not found]         ` <51F7007F.6090200-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-08-05  6:51           ` Joseph Lo
2013-08-05  6:51             ` Joseph Lo
2013-07-26  9:15   ` [PATCH 8/8] ARM: dts: tegra: enable LP1 suspend mode Joseph Lo
2013-07-26  9:15     ` Joseph Lo
2013-07-27 16:12   ` [PATCH 0/8] ARM: tegra: support " Marc Dietrich
2013-07-27 16:12     ` Marc Dietrich
2013-07-27 16:20     ` Dmitry Osipenko
2013-07-27 16:20       ` Dmitry Osipenko
     [not found]       ` <51F3F356.8080709-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-07-27 18:09         ` Marc Dietrich
2013-07-27 18:09           ` Marc Dietrich
2013-07-27 18:26           ` Dmitry Osipenko
2013-07-27 18:26             ` Dmitry Osipenko
     [not found]             ` <51F410BE.3000904-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-07-27 18:29               ` Dmitry Osipenko
2013-07-27 18:29                 ` Dmitry Osipenko
2013-07-27 19:03               ` Marc Dietrich
2013-07-27 19:03                 ` Marc Dietrich
2013-07-27 19:11                 ` Dmitry Osipenko
2013-07-27 19:11                   ` Dmitry Osipenko
2013-07-30  9:49     ` Joseph Lo
2013-07-30  9:49       ` 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=1375690035.1731.41.camel@jlo-ubuntu-64.nvidia.com \
    --to=josephl@nvidia.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=swarren@wwwdotorg.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.