The da830/omap l137 is a new SoC from TI that is similar
to the davinci line. Since its so similar to davinci,
put the support for the da830 in the same directory as
the davinci code.
There are differences, however. Some of those differences
prevent support for davinci and da830 platforms to work
in the same kernel binary. Those differences are:
1) Different physical address for RAM. This is relevant
to Makefile.boot addresses and PHYS_OFFSET. The
Makefile.boot issue isn't truly a kernel issue but
it means u-boot won't work with a uImage including
both architectures. The PHYS_OFFSET issue is
addressed by the "Allow for runtime-determined
PHYS_OFFSET" patch by Lennert Buytenhek but it
hasn't been accepted yet.
2) Different uart addresses. This is only an issue
for the 'addruart' assembly macro when CONFIG_DEBUG_LL
is enabled. Since the code in that macro is called
so early (e.g., by _error_p in kernel/head.S when
the processor lookup fails), we can't determine what
platform the kernel is running on at runtime to use
the correct uart address.
These areas have compile errors intentionally inserted
to indicate to the builder they're doing something wrong.
A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added
to distinguish between a true davinci architecture and
the da830 architecture.
Note that the da830 currently has an issue with writeback
data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be
enabled when building a da830 kernel.
Additional generalizations for future SoCs in the da8xx family done by
Sudhakar Rajashekhara and Sekhar Nori.
Signed-off-by: Steve Chen <schen@mvista.com>
Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com>
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Cc: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Remove remnants of dm6446-specific SRAM allocator, as preparation for
a more generic replacement.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Both of these symbols should be defined by a platform, or neither
should be defined. Ensure that all platforms conform.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Let's provide an overridable default instead of having every machine
class define __virt_to_bus and __bus_to_virt to the same thing. What
most platforms are using is bus_addr == phys_addr so such is the default.
One exception is ebsa110 which has no DMA what so ever, so the actual
definition is not important except only for proper compilation. Also
added a comment about the special footbridge bus translation.
Let's also remove comments alluding to set_dma_addr which is not
(and should not) be commonly used.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Mark A. Greer