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 <[email protected]> wrote: > This patch modifies the sram allocator to allocate memory > from the DA8XX shared RAM. > > Signed-off-by: Subhasish Ghosh <[email protected]> > --- > 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 <[email protected]> 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 _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
