linux-kernel - Re: [PATCH 18/19] ARM: at91: suspend both memory controllers on at91sam9263

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <516FF8FC.7070901@atmel.com>
Date:	Thu, 18 Apr 2013 15:45:32 +0200
From:	Nicolas Ferre <nicolas.ferre@...el.com>
To:	Arnd Bergmann <arnd@...db.de>,
	Jean-Christophe Plagniol-Villard <plagnioj@...osoft.com>,
	Daniel Lezcano <daniel.lezcano@...aro.org>
CC:	<linux-arm-kernel@...ts.infradead.org>,
	<linux-kernel@...r.kernel.org>, Andrew Victor <linux@...im.org.za>,
	Albin Tonnerre <albin.tonnerre@...e-electrons.com>
Subject: Re: [PATCH 18/19] ARM: at91: suspend both memory controllers on at91sam9263

I come back to this for AT91


On 01/25/2013 11:44 PM, Arnd Bergmann :
> For the past three years, we have had a #warning in
> mach-at91 about the sdram_selfrefresh_enable or
> at91sam9_standby functions possibly not working on
> at91sam9263. In the meantime a function was added
> to do the right thing on at91sam9g45, which looks like
> it should also work on '9263.
> 
> This patch blindly removes the warning and changes the
> at91sam9263 to use the same code at at91sam9g45, which
> may or may not be the right solution. If it is not,
> maybe someone could provide a better fix.

Maybe you can remove this paragraph: now you are using the proper fix
with proper RAM type.

> Signed-off-by: Arnd Bergmann <arnd@...db.de>
> Cc: Nicolas Ferre <nicolas.ferre@...el.com>

Acked-by: Nicolas Ferre <nicolas.ferre@...el.com>

What is the future of this patch series: do you want us to take this
patch separately or to you want to apply the whole series on the arm-soc
tree?


> Cc: Jean-Christophe Plagniol-Villard <plagnioj@...osoft.com>
> Cc: Andrew Victor <linux@...im.org.za>
> Cc: Albin Tonnerre <albin.tonnerre@...e-electrons.com>
> Cc: Daniel Lezcano <daniel.lezcano@...aro.org>

Moreover, this patch my conflict with Daniel's current initiative to
move cpuidle driver to its own directory: how do we coordinate with each
other?

Arnd,
Thanks a lot for having taking care of this old warning...


Best regards,

> ---
>  arch/arm/mach-at91/cpuidle.c |  2 ++
>  arch/arm/mach-at91/pm.c      |  2 ++
>  arch/arm/mach-at91/pm.h      | 30 ++++++++++++++++++++++++------
>  3 files changed, 28 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
> index 0c63815..4c67946 100644
> --- a/arch/arm/mach-at91/cpuidle.c
> +++ b/arch/arm/mach-at91/cpuidle.c
> @@ -38,6 +38,8 @@ static int at91_enter_idle(struct cpuidle_device *dev,
>  		at91rm9200_standby();
>  	else if (cpu_is_at91sam9g45())
>  		at91sam9g45_standby();
> +	else if (cpu_is_at91sam9263())
> +		at91sam9263_standby();
>  	else
>  		at91sam9_standby();
>  
> diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
> index adb6db8..b8017c1 100644
> --- a/arch/arm/mach-at91/pm.c
> +++ b/arch/arm/mach-at91/pm.c
> @@ -267,6 +267,8 @@ static int at91_pm_enter(suspend_state_t state)
>  				at91rm9200_standby();
>  			else if (cpu_is_at91sam9g45())
>  				at91sam9g45_standby();
> +			else if (cpu_is_at91sam9263())
> +				at91sam9263_standby();
>  			else
>  				at91sam9_standby();
>  			break;
> diff --git a/arch/arm/mach-at91/pm.h b/arch/arm/mach-at91/pm.h
> index 38f467c..2f5908f 100644
> --- a/arch/arm/mach-at91/pm.h
> +++ b/arch/arm/mach-at91/pm.h
> @@ -70,13 +70,31 @@ static inline void at91sam9g45_standby(void)
>  	at91_ramc_write(1, AT91_DDRSDRC_LPR, saved_lpr1);
>  }
>  
> -#ifdef CONFIG_SOC_AT91SAM9263
> -/*
> - * FIXME either or both the SDRAM controllers (EB0, EB1) might be in use;
> - * handle those cases both here and in the Suspend-To-RAM support.
> +/* We manage both DDRAM/SDRAM controllers, we need more than one value to
> + * remember.
>   */
> -#warning Assuming EB1 SDRAM controller is *NOT* used
> -#endif
> +static inline void at91sam9263_standby(void)
> +{
> +	u32 lpr0, lpr1;
> +	u32 saved_lpr0, saved_lpr1;
> +
> +	saved_lpr1 = at91_ramc_read(1, AT91_SDRAMC_LPR);
> +	lpr1 = saved_lpr1 & ~AT91_SDRAMC_LPCB;
> +	lpr1 |= AT91_SDRAMC_LPCB_SELF_REFRESH;
> +
> +	saved_lpr0 = at91_ramc_read(0, AT91_SDRAMC_LPR);
> +	lpr0 = saved_lpr0 & ~AT91_SDRAMC_LPCB;
> +	lpr0 |= AT91_SDRAMC_LPCB_SELF_REFRESH;
> +
> +	/* self-refresh mode now */
> +	at91_ramc_write(0, AT91_SDRAMC_LPR, lpr0);
> +	at91_ramc_write(1, AT91_SDRAMC_LPR, lpr1);
> +
> +	cpu_do_idle();
> +
> +	at91_ramc_write(0, AT91_SDRAMC_LPR, saved_lpr0);
> +	at91_ramc_write(1, AT91_SDRAMC_LPR, saved_lpr1);
> +}
>  
>  static inline void at91sam9_standby(void)
>  {
> 


-- 
Nicolas Ferre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/