Commit Graph

5 Commits

Author SHA1 Message Date
Matt Porter 983c42ba34 ARM: davinci: add platform hook to fetch the SRAM pool
Adds sram_get_gen_pool() which allows platform code to get
the machine's SRAM gen_pool. The gen_pool may be passed in
platform data for driver genalloc use.

Signed-off-by: Matt Porter <mporter@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2012-10-27 16:28:35 +05:30
Ben Gardiner 626863a3f3 ARM: davinci: sram: switch from iotable to ioremapped regions
The current davinci init sets up SRAM in iotables. There has been
an observed failure to boot a da850 with 128K specified in the
iotable.

Make the davinci sram allocator do an ioremap of the region
specified by the entries in davinci_soc_info before registering
with gen_pool_add_virt(). Remove all iotable SRAM mappings and
SRAM_VIRT.

Regression tested suspend/resume on AM180x EVM.

Signed-off-by: Ben Gardiner <bengardiner@nanometrics.ca>
Signed-off-by: Matt Porter <mporter@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2012-10-27 16:28:33 +05:30
Sergei Shtylyov 42d399e418 DaVinci: remove unneeded #include's
There have accumulated quite a lot of them after the code reorganizations...

In several cases I had to replace #include <linux/dma-mapping.h> which wasn't
needed directly but happened to #include <linux/err.h> which was needed.

Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-11-25 10:21:31 -08:00
David Brownell 1d3bba61f6 davinci: sram warning fix
CC      arch/arm/mach-davinci/sram.o
arch/arm/mach-davinci/sram.c: In function 'sram_init':
arch/arm/mach-davinci/sram.c:63: warning: comparison of distinct pointer types lacks a cast

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-08-26 10:56:57 +03:00
David Brownell 20e9969b3a davinci: add SRAM allocator
Provide a generic SRAM allocator using genalloc, and vaguely
modeled after what AVR32 uses.  This builds on top of the
static CPU mapping set up in the previous patch, and returns
DMA mappings as requested (if possible).

Compared to its OMAP cousin, there's no current support for
(currently non-existent) DaVinci power management code running
in SRAM; and this has ways to deallocate, instead of being
allocate-only.

The initial user of this should probably be the audio code,
because EDMA from DDR is subject to various dropouts on at
least DM355 and DM6446 chips.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-28 15:18:13 -07:00