linux-kernel - Re: [PATCH 1/1] davinci: changed SRAM allocator to shared ram.

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: <BANLkTimDw3T2CFAw6te-smj2q07F=+_wbA@mail.gmail.com>
Date:	Mon, 16 May 2011 15:08:21 -0400
From:	Ben Gardiner <bengardiner@...ometrics.ca>
To:	"Nori, Sekhar" <nsekhar@...com>,
	Subhasish Ghosh <subhasish@...tralsolutions.com>
Cc:	"davinci-linux-open-source@...ux.davincidsp.com" 
	<davinci-linux-open-source@...ux.davincidsp.com>,
	"sachi@...tralsolutions.com" <sachi@...tralsolutions.com>,
	Russell King <linux@....linux.org.uk>,
	Kevin Hilman <khilman@...prootsystems.com>,
	open list <linux-kernel@...r.kernel.org>,
	"Watkins, Melissa" <m-watkins@...com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 1/1] davinci: changed SRAM allocator to shared ram.

Hi Subhasish and Sekhar,

Subhashish, I was testing your patch here while investigating
davinci-pcm ping-pong buffers on da850.

On Fri, Feb 11, 2011 at 9:21 AM, Subhasish Ghosh
<subhasish@...tralsolutions.com> wrote:
> This patch modifies the sram allocator to allocate memory
> from the DA8XX shared RAM.
>
> Signed-off-by: Subhasish Ghosh <subhasish@...tralsolutions.com>
> ---
>  arch/arm/mach-davinci/da850.c              |    6 +++---
>  arch/arm/mach-davinci/include/mach/da8xx.h |    1 +

Since this changes only the da850 behaviour, a subject prefix of da850
might be more appropriate than 'davinci'.

>  2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> index 3443d97..8a4de97 100644
> --- a/arch/arm/mach-davinci/da850.c
> +++ b/arch/arm/mach-davinci/da850.c
> @@ -711,7 +711,7 @@ static struct map_desc da850_io_desc[] = {
>        },
>        {
>                .virtual        = SRAM_VIRT,
> -               .pfn            = __phys_to_pfn(DA8XX_ARM_RAM_BASE),
> +               .pfn            = __phys_to_pfn(DA8XX_SHARED_RAM_BASE),
>                .length         = SZ_8K,

Assigning only 8K to this iomap will result in a fault for the first
victim to access SRAM_VIRT+0x2000. This will happen for example with
mcasp ping-pong buffers totalling more than 8K on the da850.

Unfortunately SZ_128K cannot be used here since it will cause a panic
on boot. SZ_64K works though.

>                .type           = MT_DEVICE
>        },
> @@ -1083,8 +1083,8 @@ static struct davinci_soc_info davinci_soc_info_da850 = {
>        .gpio_irq               = IRQ_DA8XX_GPIO0,
>        .serial_dev             = &da8xx_serial_device,
>        .emac_pdata             = &da8xx_emac_pdata,
> -       .sram_dma               = DA8XX_ARM_RAM_BASE,
> -       .sram_len               = SZ_8K,
> +       .sram_dma               = DA8XX_SHARED_RAM_BASE,
> +       .sram_len               = SZ_128K,

This should probably be set to match whatever is reported in the map
entry above -- or an ioremap could be issued later but before the sram
init?

On Wed, Mar 2, 2011 at 12:12 PM, Nori, Sekhar <nsekhar@...com> wrote:
> [...]
>> root@...go:~# rtcwake -d /dev/rtc0 -s 20 -m mem
>> wakeup from "mem" at Tue Apr 21 14:31:13 2009
>> PM: Syncing filesystems ... done.
>> Freezing user space processes ... (elapsed 0.01 seconds) done.
>> Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
>> Suspending console(s) (use no_console_suspend to debug)
>>
>> From the Kconfig I had enabled RTC_DRV_OMAP, CONFIG_PM, CONFIG_SUSPEND.
>
> Nothing stands out from these logs. One thing to
> verify is if the RTC Alarm interrupt is really
> working by using the test program present in the
> Documentation/ folder.
>
> Anyway, the easiest way for you to move quickly is
> to use ramdisk so you can bypass all driver specific
> issues.

I tested suspend here with the patch applied on top of 2.6.39-rc7
using "rtcwake -d /dev/rtc0 -s 20 -m mem" and it works.

Best Regards,
Ben Gardiner

---
Nanometrics Inc.
http://www.nanometrics.ca
--
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/