Added definitions for tnetv107x uart base addresses, and modified base address
selection for kernel decompressor to check for tnetv107x machine type.
Signed-off-by: Cyril Chemparathy <cyril@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
This patch adopts a debug uart selection similar to the OMAP model. During
the boot process, the uncompress code determines the physical and virtual base
addresses of the board-specific debug uart. These addresses are then passed
on to the in-kernel debug macros through a small chunk of memory placed just
below the page tables (@0x80003ff8).
Signed-off-by: Cyril Chemparathy <cyril@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
The uart pdata array is already terminated by a zero flag field.
This patch reuses this terminator and eliminates DAVINCI_MAX_NR_UARTS
definition. This way, future platforms can have different number of uarts
initialized via davinci_serial_init().
Signed-off-by: Cyril Chemparathy <cyril@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
This patch takes out IO mapping macros from mach/io.h and puts them in
mach/hardware.h avoiding need to include mach/io.h in various files such as
serial.h, vmalloc.h etc.
The main reason to avoid inclusion of mach/io.h is, when default in/out macros
are overridden by machine specific functions (e.g., in case of PCI I/O), they
result into linker error. An example snippet and error snapshot is listed below.
Following code in mach/io.h:
#define inl(p) my_inl()
static inline unsigned int my_inl(unsigned int addr)
{
if (IS_PCI_IO(addr))
return pci_inl ();
else
return le32_to_cpu(__raw_readl(__typesafe_io(addr)));
}
leads to error:
LD arch/arm/boot/compressed/vmlinux
arch/arm/boot/compressed/misc.o: In function `my_inl':
misc.c:(.text+0x2744): undefined reference to `pci_inl'
make[2]: *** [arch/arm/boot/compressed/vmlinux] Error 1
This is because mach/io.h gets included in arch/arm/boot/compressed/misc.c
through mach/serial.h but pci.c file, which defines 'pci_inl' doesn't get built
into compressed vmlinux.
Signed-off-by: Hemant Pedanekar <hemantp@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
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>
Currently, there is one set of platform_device and platform_data
structures for all DaVinci SoCs. The differences in the data
between the various SoCs is handled by davinci_serial_init()
by checking the SoC type. However, as new SoCs appear, this
routine will become more & more cluttered.
To clean up the routine and make it easier to add support for new
SoCs, move the platform_device and platform_data structures into the
SoC-specific code and use the SoC infrastructure to provide access
to the data.
In the process, fix a bug where the wrong irq is used for uart2
of the dm646x.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
In addition, add board support for the DM355 Evaluation Module (EVM)
and the DM355 Leopard board.
Original DM355 EVM support done by Sandeep Paulraj, with significant
updates and improvements by David Brownell. DM355 Leopord support
done by Koen Kooi.
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
Signed-off-by: Koen Kooi <koen@beagleboard.org>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
