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

[Ben Gardiner]

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@xxxxxxxxxxxxxxxxxxxx> wrote:
> This patch modifies the sram allocator to allocate memory
> from the DA8XX shared RAM.
>
> Signed-off-by: Subhasish Ghosh <subhasish@xxxxxxxxxxxxxxxxxxxx>
> ---
>  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@xxxxxx> wrote:
> [...]
>> root@arago:~# 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/